On Mon, Jul 13, 2015 at 03:19:10PM +1000, NeilBrown wrote: > > Hell, no. Intended use is to have ->kill() free the damn thing, period. > > It is not possible to revise that intention? > The apparent purpose of pin_kill() is to wait until the thing is freed, > or to trigger that freeing itself. Why not do both: trigger then wait? Huh? The first to come calls ->kill(); anybody coming between that and pin_remove() done by ->kill() waits until pin_remove() is called and buggers off. > Given that all current uses have ->kill() call pin_remove, and as > pin_remove sets ->done to 1, and as the patch makes no change to > behaviour when ->kill() completes with ->done set to 1, I don't see how > it can break anything. > 'rcu' ensures that it is still save to examine p->done, and it will be > '1'. RCU ensures no such thing. Where's the rcu_read_lock() opening the RCU-critical area you need? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
