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. 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
