On Sun, Mar 1, 2026 at 9:10 PM Jeff Layton <[email protected]> wrote: > > 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 >
Thanks! This is a separate git repository, so I guess for both manpages and fstests I need to submit separate patch series for O_REGULAR. Do I need to wait first for this patch series to be merged? How does it work? Regards, Dorjoy
