On Mon, 13 Jul 2015 05:45:53 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jul 13, 2015 at 02:20:59PM +1000, NeilBrown wrote: > > > Actually, with that change to pin_kill, this side of things becomes > > really easy. > > All expXXX_pin_kill needs to do is call your new cache_delete_entry. > > If that doesn't cause the entry to be put, then something else has a > > temporary reference which will be put soon. In any case, pin_kill() > > will wait long enough, but not indefinitely. > > No need for kref_get_unless_zero() or any of that. > > No. You are seriously misunderstanding what ->kill() is for and what the > existing instances are doing. Again, there is no promise whatsoever that > the object containing fs_pin instance will *survive* past ->kill(). > At all. Ah... I missed that rcu_read_unlock happened before ->kill. Sorry about that. It still seems like the waiting that pin_kill does is exactly what we need. I'll think about it some more. Thanks, NeilBrown > > RTFS, please. What is sorely missing in this recurring patchset is a clear > description of lifetime rules and ordering (who waits for whom and how long). > For all the objects involved. -- 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
