From: Jori Koolstra <jkoolstra@xs4all.nl>
To: NeilBrown <neil@brown.name>, NeilBrown <neilb@ownmail.net>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Steve French <sfrench@samba.org>,
Steve French <smfrench@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/1] vfs: pass S_IFDIR mode to vfs_prepare_mode()
Date: Sun, 14 Jun 2026 18:57:40 +0200 (CEST) [thread overview]
Message-ID: <586018010.1683063.1781456260309@kpc.webmail.kpnmail.nl> (raw)
In-Reply-To: <178131507850.3002522.16819279282508142089@noble.neil.brown.name>
> Op 13-06-2026 03:44 CEST schreef NeilBrown <neilb@ownmail.net>:
>
>
> On Fri, 12 Jun 2026, Jori Koolstra wrote:
> > There is a comment in vfs_prepare_mode() that says:
> >
> > Note that it's currently valid for @type to be 0 if a directory is
> > created. Filesystems raise that flag individually and we need to check
> > whether each filesystem can deal with receiving S_IFDIR from the vfs
> > before we enforce a non-zero type.
> >
> > This is a bit challenging since there are many filesystems. Claude Opus
> > 4.8 was used to generate the context for each mkdir implementation from
> > which it can be judged whether passing S_IFDIR is safe. The result was
> > then verified by hand by looking at how the mode argument is used in
> > each case. To check whether all mkdir implementations are convered,
> > 'rg "\.mkdir" ' was used and checked against the list of uses Claude
> > found.
> >
> > The only mkdir implementation that I am not as sure of is
> > cifs_mkdir(). So this goes cc to the cifs people. But of course, I might
> > have made errors in other places (except probably not for the A list as
> > those are all just mode | S_IFDIR cases without other uses of mode
> > besides logging)
>
> I agree that cifs_mkdir() is not obviously safe.
> I think coda_mkdir() and fuse_mkdir() at also not obviously safe.
> In all three cases the mode, which now has S_IFDIR included, is sent
> unchanged to something outside of Linux - either user-space or over at
> network connection.
You are (of course) right. I missed to mention coda. Also, I missed that
for FUSE inarg.mode = mode; is set, and this is passed, despite the mode
in create_new_entry(idmap, fm, &args, dir, entry, S_IFDIR); being hardwired
to S_IFDIR.
>
> I think you patch which adds S_IFDIR to mode should mask it back out in
> those three functions. Then we could be certain it is safe.
> The maintainers of those filesystems might then choose to remove the
> mask if they know it to be safe to do so
That seems like a good idea, agreed.
>
> Thanks,
> NeilBrown
prev parent reply other threads:[~2026-06-14 16:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 14:57 Jori Koolstra
2026-06-11 14:57 ` [RFC PATCH 1/1] " Jori Koolstra
2026-06-11 15:33 ` [RFC PATCH 0/1] " Jan Kara
2026-06-11 20:20 ` Jori Koolstra
2026-06-12 10:33 ` Jan Kara
2026-06-12 12:19 ` Christian Brauner
2026-06-11 16:37 ` Al Viro
2026-06-11 20:16 ` Jori Koolstra
2026-06-13 1:44 ` NeilBrown
2026-06-14 16:57 ` Jori Koolstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=586018010.1683063.1781456260309@kpc.webmail.kpnmail.nl \
--to=jkoolstra@xs4all.nl \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neil@brown.name \
--cc=neilb@ownmail.net \
--cc=sfrench@samba.org \
--cc=smfrench@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®