On Mon, Jan 28, 2013 at 12:27:45PM -0800, Tejun Heo wrote: > Hey, Kent. > > On Mon, Jan 28, 2013 at 12:22 PM, Kent Overstreet > <koverstr...@google.com> wrote: > > Could do that too, but then teardown gets really messy for the user - we > > need two synchronize_rcu()s: > > > > state := dying > > > > synchronize_rcu() > > > > /* Now nothing's changing the per cpu counters */ > > > > Add per cpu counters to atomic counter counter > > > > /* Atomic counter is now consistent */ > > > > state := dead > > > > synchronize_rcu() > > I don't understand why we need two stages. What prevents the killing > thread from fetching percpu counters after dying passes one > synchronize_sched()?
It does. The second synchronize_sched() is needed after we set state := dead, and before we drop the initial ref. Otherwise the ref could hit 0 before percpu_ref_put knows to check for it. > > > /* Now percpu_ref_put will check for ref == 0 */ > > > > /* Drop initial ref */ > > > > percpu_ref_put() > > > > And note that the first synchronize_rcu() is only needed when we had > > allocated per cpu counters, my current code skips it otherwise. > > And regardless, at the interface level, can't it just provide > percpu_ref_put_base_ref(release_fn)? Yeah, can definitely provide one that wraps it all together. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
