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

[Jori Koolstra]

> 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.

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.

Best,
Jori.