Re: [PATCH v4 1/4] openat2: new OPENAT2_REGULAR flag support

On Sun, 2026-03-01 at 21:01 +0600, Dorjoy Chowdhury wrote:
> On Sun, Mar 1, 2026 at 8:47 PM Jeff Layton <[email protected]> wrote:
> > 
> > On Sun, 2026-03-01 at 20:16 +0600, Dorjoy Chowdhury wrote:
> > > On Sun, Mar 1, 2026 at 6:44 PM Jeff Layton <[email protected]> wrote:
> > > > 
> > > > On Sat, 2026-02-21 at 20:45 +0600, Dorjoy Chowdhury wrote:
> > > > > This flag indicates the path should be opened if it's a regular file.
> > > > > This is useful to write secure programs that want to avoid being
> > > > > tricked into opening device nodes with special semantics while thinking
> > > > > they operate on regular files. This is a requested feature from the
> > > > > uapi-group[1].
> > > > > 
> > > > > A corresponding error code EFTYPE has been introduced. For example, if
> > > > > openat2 is called on path /dev/null with OPENAT2_REGULAR in the flag
> > > > > param, it will return -EFTYPE.
> > > > > 
> > > > > When used in combination with O_CREAT, either the regular file is
> > > > > created, or if the path already exists, it is opened if it's a regular
> > > > > file. Otherwise, -EFTYPE is returned.
> > > > > 
> > > > 
> > > > It would be good to mention that EFTYPE has precedent in BSD/Darwin.
> > > > When an error code is already supported in another UNIX-y OS, then it
> > > > bolsters the case for adding it here.
> > > > 
> > > 
> > > Good suggestion. Yes, I can include this information in the commit
> > > message during the next posting.
> > > 
> > > > Your cover letter mentions that you only tested this on btrfs. At the
> > > > very least, you should test NFS and SMB. It should be fairly easy to
> > > > set up mounts over loopback for those cases.
> > > > 
> > > 
> > > I used virtme-ng (which I think reuses the host's filesystem) to run
> > > the compiled bzImage and ran the openat2 kselftests there to verify
> > > it's working. Is there a similar way I can test NFS/SMB by adding
> > > kselftests? Or would I need to setup NFS/SMB inside a full VM distro
> > > with a modified kernel to test this? I would appreciate any suggestion
> > > on this.
> > > 
> > 
> > I imagine virtme would need some configuration to set up for nfs or
> > cifs, but maybe it's possible. I mostly use kdevops for this sort of
> > testing.
> > 
> 
> Got it. I will try to figure this out and do some testing for NFS/SMB. Thanks.
> 
> > > > There are some places where it doesn't seem like -EFTYPE will be
> > > > returned. It looks like it can send back -EISDIR and -ENOTDIR in some
> > > > cases as well. With a new API like this, I think we ought to strive for
> > > > consistency.
> > > > 
> > > 
> > > Good point. There was a comment in a previous posting of this patch
> > > series "The most useful behavior would indicate what was found (e.g.,
> > > a pipe)."
> > > (ref: https://lore.kernel.org/linux-fsdevel/vhq3osjqs3nn764wrp2lxp66b4dxpb3n5x3dijhe2yr53qfgy3@tfswbjskc3y6/
> > > )
> > > So I thought maybe it would be useful to return -EISDIR where it was
> > > already doing that. But it is a good point about consistency that we
> > > won't be doing this for other different types so I guess it's better
> > > to return -EFTYPE for all the cases anyway as you mention. Any
> > > thoughts?
> > > 
> > 
> > There is a case to be made for either. The big question is whether you
> > can consistently return the same error codes in the same situations.
> > 
> > For instance, you can return -EISDIR on NFS when the target is a
> > directory, but can you do the same on btrfs or ceph? If not, then we
> > have a situation where we have to deal with the possibility of two
> > different error codes.
> > 
> > In general, I think returning EFTYPE for everything is simplest and
> > therefore best. Sure, EISDIR tells you a bit more about the target, but
> > that info is probably not that helpful if you were expecting it to be a
> > regular file.
> > 
> 
> Good point. I agree. I will fix this and return -EFTYPE for everything
> in the next posting.
> 
> > > 
> > > > Should this API return -EFTYPE for all cases where it's not S_IFREG? If
> > > > not, then what other errors are allowed? Bear in mind that you'll need
> > > > to document this in the manpages too.
> > > > 
> > > 
> > > Are the manpages in the kernel git repository or in a separate
> > > repository? Do I make separate patch series for that? Sorry I don't
> > > know about this in detail.
> > > 
> > 
> > Separate repo and mailing list: https://www.kernel.org/doc/man-pages/
> > 
> > ...come to think of it, you should also cc the linux-api mailing list
> > when you send the next version:
> > 
> >     https://www.kernel.org/doc/man-pages/linux-api-ml.html
> > 
> > This one is fairly straightforward, but once a new API is in a released
> > kernel, it's hard to change things, so we'll want to make sure we get
> > this right.
> > 
> 
> I did not know about this. I will cc linux-api mailing list from the
> next posting.
> 
> > I should also ask you about testcases here. You should add some tests
> > to fstests for O_REGULAR if you haven't already:
> > 
> >     https://www.kernel.org/doc/man-pages/linux-api-ml.html
> > 
> 
> I only added a kselftest for the new flag in
> tools/testing/selftests/openat2/openat2_test.c in my second commit in
> this patch series. Where are the fstests that I should add tests? I
> think you added the wrong URL above, probably a typo.
> 
> 

I did indeed, sorry. They're here:

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

-- 
Jeff Layton <[email protected]>