From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH review 11/11] mnt: Honor MNT_LOCKED when detaching mounts Date: Fri, 9 Jan 2015 22:17:15 +0000 Message-ID: <20150109221715.GN22149@ZenIV.linux.org.uk> References: <87mw5xq7lt.fsf@x220.int.ebiederm.org> <1420490787-14387-11-git-send-email-ebiederm@xmission.com> <20150107184334.GZ22149@ZenIV.linux.org.uk> <87h9w2gzht.fsf@x220.int.ebiederm.org> <20150107205239.GB22149@ZenIV.linux.org.uk> <87iogi8dka.fsf@x220.int.ebiederm.org> <20150108002227.GC22149@ZenIV.linux.org.uk> <20150108223212.GF22149@ZenIV.linux.org.uk> <20150109203126.GI22149@ZenIV.linux.org.uk> <87k30vwskd.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Andrey Vagin , Richard Weinberger , Linux Containers , Andy Lutomirski , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linus Torvalds To: "Eric W. Biederman" Return-path: Content-Disposition: inline In-Reply-To: <87k30vwskd.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org 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.