Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > On Fri, Jan 09, 2015 at 03:30:10PM -0600, Eric W. Biederman wrote: > >> Where does the rcu_read_lock() happen? >> I assume this is kill from fs_pin.kill? > > This is what I'd rather have *calling* fs_pin.kill (the ... part in there > being the callback, with wakeup done as part of pin_remove(), which would > be called by ->kill()). The thing is, I don't want mnt_pin_kill() et.al. > to grab refcount on fs_pin (or for the refcount to be necessary there). > > IOW, any refcounting belong on the same level as ->kill() implementation > itself; for ex-mountpoint-related ones we'd need none whatsoever (->kill() > would do > dput(ex-mountpoint dentry); > pin_remove(pin); > mntput_no_expire(containing struct mount); > and that would be it), for kernel/acct.c ones we do need some refcounting, > but only for the local reasons - note that it's playing directly with > refcount anyway, which is a pretty clear indication that we'd be better off > with fs/fs_pin.c _not_ messing with that refcount in the first place. > Getting rid of pin_put() also wouldn't hurt. Got it. I agree the infrastructure related to fs_pin is pretty awakward right now. I am digging in and seeing if I can figure out what the awkardness you are seeing that needs the suggested changes, and then I will give you my feedback. Eric -- 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
