Re: [PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers



[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux