From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2388426980B; Wed, 29 Oct 2025 13:24:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761744242; cv=none; b=jcSG4fBZnuzVCe8PvQZ86zf6SxWS7YVFx1LmPg4uAgJcOEnxshLmr/MoG7PhW58t/F6IpNGIIJhyCpF4g6tjfku5xuPv6X6Fd32unoT2dGtMOau/RLIDIkKCqUKve5AeRMa9ndbHBAPviJzHPR+Tre3xkgTvB29ueEroRWfWDHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761744242; c=relaxed/simple; bh=tnQ7CAQ/zrazskDouHnus3UXop3oRcNTaKyJpkol4Y4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BmK0kP8LQU4GmWIZDJmzyevRGghMm7y8XwjMTPHmoX/1BtGj5X07LGW9/p0E/J+VjjHCSTZO7l5PuFhUlJgij5VQIopwx9ihQcbMyB8/DoabRbRvCDDksYlMU+cL6dsoNLOCIqMSowEB5hA8Hb5LnpbYjKlwdFYA4cp5ZcJ2R1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mNOSdOAy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mNOSdOAy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA982C4CEF7; Wed, 29 Oct 2025 13:23:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761744240; bh=tnQ7CAQ/zrazskDouHnus3UXop3oRcNTaKyJpkol4Y4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mNOSdOAyHbR1VT/fF2/pkmXxetdEzzrKRuVqgkh1vAl0cw2TE7FbX9LXe+xQVy0Wd GHUxzdoNjbJ8DOnGyUjAHVcDWHzV0x/OQbJOcRGPBj/H6KHrK9wk8lKPRz3oRlA8yZ 1iRW3c8Eg11hR3E1tPmdtpRpZUaIu4Fv1o+wPwlkTgoxO95Wmdr4m6yMNIY/mhk4SG Y1+B+pJfTPYKuUbD/AWB5VoYivRdvEKKcMYRrnYlFJ0djwF9QuFkIy5mVfS7+uWKjy EmYOnbWmT1O185HtStSd04ZYpyopo4on0Ta9FEFVGNQ8vvit3zJfVgXinV0wo0cEKZ 5BCqVzBhaNuLQ== Date: Wed, 29 Oct 2025 14:23:49 +0100 From: Christian Brauner To: Jeff Layton Cc: Miklos Szeredi , Alexander Viro , Jan Kara , Chuck Lever , Alexander Aring , Trond Myklebust , Anna Schumaker , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Bharath SM , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , David Howells , Tyler Hicks , NeilBrown , Olga Kornievskaia , Dai Ngo , Amir Goldstein , Namjae Jeon , Steve French , Sergey Senozhatsky , Carlos Maiolino , Kuniyuki Iwashima , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, netfs@lists.linux.dev, ecryptfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v3 06/13] vfs: make vfs_create break delegations on parent directory Message-ID: <20251029-lenken-scham-0cf009d5a7dd@brauner> References: <20251021-dir-deleg-ro-v3-0-a08b1cde9f4c@kernel.org> <20251021-dir-deleg-ro-v3-6-a08b1cde9f4c@kernel.org> Precedence: bulk X-Mailing-List: ecryptfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20251021-dir-deleg-ro-v3-6-a08b1cde9f4c@kernel.org> On Tue, Oct 21, 2025 at 11:25:41AM -0400, Jeff Layton wrote: > In order to add directory delegation support, we need to break > delegations on the parent whenever there is going to be a change in the > directory. > > Add a delegated_inode parameter to vfs_create. Most callers are > converted to pass in NULL, but do_mknodat() is changed to wait for a > delegation break if there is one. > > Reviewed-by: Jan Kara > Reviewed-by: NeilBrown > Signed-off-by: Jeff Layton > --- > fs/ecryptfs/inode.c | 2 +- > fs/namei.c | 26 +++++++++++++++++++------- > fs/nfsd/nfs3proc.c | 2 +- > fs/nfsd/vfs.c | 3 +-- > fs/open.c | 2 +- > fs/overlayfs/overlayfs.h | 2 +- > fs/smb/server/vfs.c | 2 +- > include/linux/fs.h | 2 +- > 8 files changed, 26 insertions(+), 15 deletions(-) > > diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c > index 88631291b32535f623a3fbe4ea9b6ed48a306ca0..661709b157ce854c3bfdfdb13f7c10435fad9756 100644 > --- a/fs/ecryptfs/inode.c > +++ b/fs/ecryptfs/inode.c > @@ -189,7 +189,7 @@ ecryptfs_do_create(struct inode *directory_inode, > rc = lock_parent(ecryptfs_dentry, &lower_dentry, &lower_dir); > if (!rc) > rc = vfs_create(&nop_mnt_idmap, lower_dir, > - lower_dentry, mode, true); > + lower_dentry, mode, true, NULL); Starts to look like we should epxlore whether a struct create_args (or some other name) similar to struct renamedata I did some years ago would help make the code a bit more legible in the future.