From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:53534 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751841AbeAZXRb (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 26 Jan 2018 18:17:31 -0500
Date: Fri, 26 Jan 2018 23:17:29 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-fsdevel@vger.kernel.org, kernel-team@fb.com,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] fs: only sync() superblocks reachable from the current
 namespace
Message-ID: <20180126231729.GD13338@ZenIV.linux.org.uk>
References: <05434cda5cc3b461b5d70467b094904ad23fdc11.1517007510.git.osandov@fb.com>
 <20180126231350.GC13338@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180126231350.GC13338@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Fri, Jan 26, 2018 at 11:13:51PM +0000, Al Viro wrote:

> Erm...  And just what is protecting the list here?
> 
> >  static void fdatawrite_one_bdev(struct block_device *bdev, void *arg)
> > @@ -107,12 +138,18 @@ static void fdatawait_one_bdev(struct block_device *bdev, void *arg)
> >   */
> >  SYSCALL_DEFINE0(sync)
> >  {
> > -	int nowait = 0, wait = 1;
> > +	struct sb_sync arg = {
> > +		.mnt_ns = current->nsproxy->mnt_ns,
> > +	};
> > +
> > +	if (arg.mnt_ns == init_task.nsproxy->mnt_ns)
> > +		arg.mnt_ns = NULL;
> >  
> >  	wakeup_flusher_threads(WB_REASON_SYNC);
> > -	iterate_supers(sync_inodes_one_sb, NULL);
> > -	iterate_supers(sync_fs_one_sb, &nowait);
> > -	iterate_supers(sync_fs_one_sb, &wait);
> > +	iterate_supers(sync_inodes_one_sb, &arg);
> > +	iterate_supers(sync_fs_one_sb, &arg);
> > +	arg.wait = 1;
> > +	iterate_supers(sync_fs_one_sb, &arg);
> 
> So now sync() includes O(total vfsmounts on the system) walking the lists, no
> matter what *and* in a situation when a lazy-unmounted filesystem is held active
> by an opened file sync(2) won't touch that filesystem.  Unless done in the
> magical namespace init(8) happens to run in.

BTW, if your process happens to have inherited an opened file from parent,
then unshares the namespace and unmounts the filesystem that file came
from, sync(2) won't affect the writes on that descriptor.