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. Regards, Dorjoy
