linux-kernel - Re: [PATCH] vfs: fix EBUSY on FSCONFIG_CMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3jqjyw7p4sbnlle7y7qprlcf36siyqykkk6s7hjzfdhypyvwb4@mg6hu54lloff>
Date: Mon, 15 Dec 2025 14:04:31 +0100
From: Jan Kara <jack@...e.cz>
To: Christian Brauner <brauner@...nel.org>
Cc: Jan Kara <jack@...e.cz>, me@...ck-desk.cn, 
	Alexander Viro <viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] vfs: fix EBUSY on FSCONFIG_CMD_CREATE retry

On Mon 15-12-25 12:55:12, Christian Brauner wrote:
> On Mon, Dec 15, 2025 at 09:46:19AM +0100, Jan Kara wrote:
> > On Sat 13-12-25 02:03:56, Chen Linxuan via B4 Relay wrote:
> > > From: Chen Linxuan <me@...ck-desk.cn>
> > > 
> > > When using fsconfig(..., FSCONFIG_CMD_CREATE, ...), the filesystem
> > > context is retrieved from the file descriptor. Since the file structure
> > > persists across syscall restarts, the context state is preserved:
> > > 
> > > 	// fs/fsopen.c
> > > 	SYSCALL_DEFINE5(fsconfig, ...)
> > > 	{
> > > 		...
> > > 		fc = fd_file(f)->private_data;
> > > 		...
> > > 		ret = vfs_fsconfig_locked(fc, cmd, &param);
> > > 		...
> > > 	}
> > > 
> > > In vfs_cmd_create(), the context phase is transitioned to
> > > FS_CONTEXT_CREATING before calling vfs_get_tree():
> > > 
> > > 	// fs/fsopen.c
> > > 	static int vfs_cmd_create(struct fs_context *fc, bool exclusive)
> > > 	{
> > > 		...
> > > 		fc->phase = FS_CONTEXT_CREATING;
> > > 		...
> > > 		ret = vfs_get_tree(fc);
> > > 		...
> > > 	}
> > > 
> > > However, vfs_get_tree() may return -ERESTARTNOINTR if the filesystem
> > > implementation needs to restart the syscall. For example, cgroup v1 does
> > > this when it encounters a race condition where the root is dying:
> > > 
> > > 	// kernel/cgroup/cgroup-v1.c
> > > 	int cgroup1_get_tree(struct fs_context *fc)
> > > 	{
> > > 		...
> > > 		if (unlikely(ret > 0)) {
> > > 			msleep(10);
> > > 			return restart_syscall();
> > > 		}
> > > 		return ret;
> > > 	}
> > > 
> > > If the syscall is restarted, fsconfig() is called again and retrieves
> > > the *same* fs_context. However, vfs_cmd_create() rejects the call
> > > because the phase was left as FS_CONTEXT_CREATING during the first
> > > attempt:
> > 
> > Well, not quite. The phase is actually set to FS_CONTEXT_FAILED if
> > vfs_get_tree() returns any error. Still the effect is the same.
> 
> Uh, I'm not sure we should do this. If this only affects cgroup v1 then
> I say we should simply not care at all. It's a deprecated api and anyone
> using it uses something that is inherently broken and a big portion of
> userspace has already migrated. The current or upcoming systemd release
> has dropped all cgroup v1 support.
> 
> Generally, making fsconfig() restartable is not as trivial as it looks
> because once you called into the filesystem the config that was setup
> might have already been consumed. That's definitely the case for stuff
> in overlayfs and others. So no, that patch won't work and btw, I
> remembered that we already had that discussion a few years ago and I was
> right:
> 
> https://lore.kernel.org/20200923201958.b27ecda5a1e788fb5f472bcd@virtuozzo.com

I see. I was assuming that if the filesystem returns ERESTART* it will make
sure to not consume the context it wants to restart with. But I can see why
that might be too errorprone and not really worth the hassle in this case.
So fine by me if you don't want to go that route.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR