[PATCH] open.2: Clarify different POSIX uses of EOPNOTSUPP and ENXIO

[PATCH] open.2: Clarify different POSIX uses of EOPNOTSUPP and ENXIO

[Christoph Anton Mitterer]

Starting with POSIX.1-2017, EOPNOTSUPP is specified as the error when the path
argument names a socket, whereas Linux uses this for indicating a filesystem
containing pathname does not support O_TMPFILE and uses ENXIO to indicate a
socket.

For reference, SUSv4, 2018 Edition (POSIX.1-2017):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

SUSv2 does not yet contain an error for when the file is socket, nor does it use
a different meaning for EOPNOTSUPP:
https://pubs.opengroup.org/onlinepubs/7908799/xsh/open.html

The same is the case for SUSv3, 2004 Edition, (“POSIX.1-2004”):
https://pubs.opengroup.org/onlinepubs/009695399/functions/open.html

The same is the case for SUSv4, 2008 Edition, (POSIX.1-2008):
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/open.html

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217821
Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
---
 man2/open.2 | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/man2/open.2 b/man2/open.2
index 4c921723c..2975db017 100644
--- a/man2/open.2
+++ b/man2/open.2
@@ -1218,12 +1218,14 @@ The file is a device special file and no corresponding device exists.
 .TP
 .B ENXIO
 The file is a UNIX domain socket.
+See STANDARDS for differences with POSIX.
 .TP
 .B EOPNOTSUPP
 The filesystem containing
 .I pathname
 does not support
 .BR O_TMPFILE .
+See STANDARDS for differences with POSIX.
 .TP
 .B EOVERFLOW
 .I pathname
@@ -1437,6 +1439,12 @@ with a value greater than or equal to 200809L or
 with a value greater than or equal to 700.
 In glibc 2.11 and earlier, one obtains the definitions by defining
 .BR _GNU_SOURCE .
+.PP
+POSIX.1-2017 uses
+.B EOPNOTSUPP
+instead of
+.B ENXIO
+to indicate that the file is a UNIX domain socket.
 .SH HISTORY
 .TP
 .BR open ()
-- 
2.40.1

Re: [PATCH] open.2: Clarify different POSIX uses of EOPNOTSUPP and ENXIO

[Florian Weimer]

* Christoph Anton Mitterer:

> @@ -1437,6 +1439,12 @@ with a value greater than or equal to 200809L or
>  with a value greater than or equal to 700.
>  In glibc 2.11 and earlier, one obtains the definitions by defining
>  .BR _GNU_SOURCE .
> +.PP
> +POSIX.1-2017 uses
> +.B EOPNOTSUPP
> +instead of
> +.B ENXIO
> +to indicate that the file is a UNIX domain socket.
>  .SH HISTORY
>  .TP
>  .BR open ()

To what degree is this dependent on the file system?  Does the VFS layer
restrict these error codes for anything else?  I don't think so.  Maybe
strictly speaking, the added wording is still accurate, but the
conclusion that ENXIO means socket would be incorrect draw, I think.

Thanks,
Florian

Re: [PATCH] open.2: Clarify different POSIX uses of EOPNOTSUPP and ENXIO

[Christoph Anton Mitterer]

Hey Florian.

On Sun, 2023-08-27 at 21:41 +0200, Florian Weimer wrote:
> To what degree is this dependent on the file system?  Does the VFS
> layer
> restrict these error codes for anything else?  I don't think so. 

THB, no idea what the various filesystems or the VFS do - I merely
tried to clarify between what's already documented as of now and what
POSIX specifies.


> Maybe
> strictly speaking, the added wording is still accurate, but the
> conclusion that ENXIO means socket would be incorrect draw, I think.

Well, strictly speaking, I think that my wording doesn't say that...
but I see that one could easily conclude that.

If I add something like

> …
> ENXIO, which Linux uses to indicate (amongst others) that the file is
> a UNIX domain socket.

?


But the same possible ambiguity might come up in the future for
POSIX/EOPNOTSUPP.
Should POSIX add further semantics to that error (like it also already
does for ENXIO), a reader could conclude that in POSIX EOPNOTSUPP would
only be used to indicate a socket (which would then no longer be the
case).

OTOH, I think it might get a bit overkill if we describe all these
details.



Cheers,
Chris

Re: [PATCH] open.2: Clarify different POSIX uses of EOPNOTSUPP and ENXIO

[Matthew House]

On Sun, Aug 27, 2023 at 3:41 PM Florian Weimer <fweimer@redhat.com> wrote:
> To what degree is this dependent on the file system?  Does the VFS layer
> restrict these error codes for anything else?  I don't think so.  Maybe
> strictly speaking, the added wording is still accurate, but the
> conclusion that ENXIO means socket would be incorrect draw, I think.

-ENXIO is returned by no_open() in fs/inode.c, which is automatically set
as the ->open() function (by inode_init_always()) for every inode that
isn't a symlink and doesn't set its ->i_fop to something else. As far as I
am aware, every filesystem uses this fallback only for files of socket
type; all non-socket inodes (except for dummy inodes) set either ->i_fop
or ->i_op->read_link().

Note that this doesn't apply only to Unix domain sockets, but to all
sockets, if one attempts to open() them via their links in /proc/pid/fd.
Open sockets in another process can only be duplicated (AFAIK) using
pidfd_getfd() or SCM_RIGHTS.

Of course, some filesystems also return -ENXIO for their own error
conditions, e.g., opening a pipe for writing with O_NONBLOCK when it has no
readers.

Matthew House