Re: [PATCH] vfs: missing inode operation should return a consistent error code

[Jan Kara]

On Mon 01-06-26 18:27:53, Jori Koolstra wrote:
> 
> > Op 01-06-2026 17:58 CEST schreef Jan Kara <jack@xxxxxxx>:
> > 
> >  
> > On Sun 31-05-26 10:08:47, Jeff Layton wrote:
> > > 
> > > This seems ill-advised. The problem is that most of this behavior has
> > > been well established for years, and not all userland software (and
> > > even some internal callers like nfsd), will react well when you go
> > > changing behavior like this.
> > > 
> > > As a case in point, the POSIX spec doesn't list EOPNOTSUPP as a valid
> > > error return for open():
> > > 
> > >    https://pubs.opengroup.org/onlinepubs/9690949399/functions/open.html
> > > 
> > > The manpage for open() says only:
> > > 
> > >        EOPNOTSUPP
> > >               The filesystem containing pathname does not support O_TMPFILE.
> > > 
> > > What is the poor userland developer to make of this when open() starts
> > > returning EOPNOTSUPP without O_TMPFILE being specified?
> > 
> > So I wouldn't care as much about POSIX, we largely ignore it anyway in the
> > kernel. But I tend to agree that changing the error code we returned for
> > several decades just for the sake of "cleanliness" isn't IMHO a good enough
> > reason to risk breaking userspace or causing confusion.
> > 
> > 								Honza
> > -- 
> > Jan Kara <jack@xxxxxxxx>
> > SUSE Labs, CR
> 
> For what its worth, the EACCES return value for not having a create()
> call on the fs is also not specified in the open() man page. For mkdir,
> EPERM IS specified.

Yep, as I said we don't really follow POSIX closely. And it goes way
further than just error code :)

> But in general, can we never add new error codes to any syscall? Are
> there user programs that do neatly check for each specified error code in
> the man page, but that do not implement a fallback at all? I mean, I am
> not unsympathetic to the arguments that you and Jeff make, but such a
> user program would be odd.

We certainly can (and sometimes do) modify the returned errors. It is
always just a balancing act between the benefit of the change and chances
somebody will get broken by it. In this case I don't quite see the
benefit, not that I'd be too worried about the a regression but there's
always the chance...

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR