Re: [PATCH v2 00/24] Documentation fixes in unix(7)

["Günther Noack" <gnoack3000@gmail.com>]

Hello Alejandro and Kuniyuki!

On Mon, Oct 19, 2026 at 09:05:21AM +0200, Alejandro Colomar wrote:
> > Date: 2026-10-18 11:37:16-0700
> > From: Kuniyuki Iwashima <kuniyu@google.com>
> > On Sun, Oct 18, 2026 at 10:37 AM Günther Noack <gnoack3000@gmail.com> wrote:
> > > Alejandro, I am sorry that you don't want to review this any further
> > > due to LLM use.
> > 
> > I understand the frustration since maintainers are getting
> > overwhelmed by too many AI slops these days (I'm not saying
> > this series is) and the review cost is way higher than before.
> > 
> > I'm happy to review this series as a AF_UNIX maintainer to
> > reduce Alejandro's cost, so please CC me on every patch, and
> > CC each author of (relatively) new functionality.
> 
> Thanks a lot!

Thanks from me as well, I will happily take you up on that offer.

Thanks to you as well Alejandro, for reconsidering in [1] and
continuing the review!

[1] https://lore.kernel.org/all/atW-XL6H72Nyy3N3@debian/


> > Also, please split the series into 3, general part (socket, bind,
> > protocol stuff, etc), socket diag part, and scm part (SCM_XXX,
> > SO_PASSXXX, etc).
> > 
> > It would be easier for us to review small series than a single
> > large series. (fwiw, netdev mailing list has ~15 patch limit)
> 
> I'm okay with a split.

I agree, it is admittedly a large number of patches that I sent here,
and I can understand that this is tedious.

I'll have a look in the next days and split this patch set up into
more digestible chunks.

> 
> [...]
> > > Some mentionworthy points about features that were missing or had out
> > > of date documentation:
> > >
> > > * Out of band messaging support (MSG_OOB):
> > 
> > Please drop these changes.  I planned to remove it in the next
> > cycle since recent AI-driven security research targets the poor
> > implementation, and even if the bug is trivial for the plain AF_UNIX,
> > MSG_OOB tends to promote it to UAF (and thus LPE) and risks
> > users for no good reason.

Yes, OK.  To be clear, the man page currently just says that OOB is
not supported for Unix Domain Sockets, and my plan was to remove that
wording (because it's technically wrong), but to refrain from
documenting it so that not even more people pick it up and so that
that doesn't get into the way of your deprecation efforts.  (It's in
commit 22/24.)

If you are saying that the deprecation is close enough, I'll just
leave it as is then, so that it keeps saying OOB is not supported.


> > > [1] https://lore.kernel.org/all/bef45d8e-35b7-42e4-bf6c-768da5b6d8f2@oracle.com/
> > > [2] https://projectzero.google/2025/08/from-chrome-renderer-code-exec-to-kernel.html
> > >
> > > Günther Noack (24):
> > >   man/man7/unix.7: ERRORS: EINVAL: The address field is sun_family, not
> > >     sun_type
> > 
> > Correct the address field s/sun_family/sun_type/
> 
> I think you meant s/sun_type/sun_family/?
> 
> > It seems the subjects are not formatted well, which makes me
> > feel AI cannot follow the standard and it is not worth reviewing :/
> 
> The subjects seem okay to me.  In the man-pages, we use slightly
> different conventions than in the kernel, so I guess that's why it seems
> strange to you.  :)
> 
> > 
> > >   man/man7/unix.7: Socket options: SOL_SOCKET is a level, not a family
> > 
> > Describe SOL_SOCKET as socket level, not family
> 
> To my own understanding, I'll ask: technically, SOL_SOCKET (like any
> SOL_*) is a protocol level.  The socket level is just one of the many
> protocol levels, right?

In my interpretation (but this is also only gathered from the
setsockopt(2) man page), the "level" option to setsockopt() and
getsockopt() acts as a "namespace" for the actual option value, so
that the unrelated socket options that are specific to the protocols
don't all need to use the same enum space?

I skimmed through Steven's "UNIX Network Programming Volume 1: The
Sockets Networking API" looking for mentions of "level", but the only
places where I found it was for getsockopt()/setsockopt() and in
struct cmsghdr (see cmsg(3)), where it is also used to qualify a
similar enum.

About the getsockopt()/setsockopt() use, the book says:

  "level" specifies the code in the system that interprets the option:
  the general socket code or some protocol-specific code (e.g., IPv4,
  IPv6, TCP, or SCTP).

As valid level values that can be passed, the book lists SOL_SOCKET,
IPPROTO_IP, IPPROTO_ICMPV6, IPPROTO_IPV6, IPPROTO_TCP and
IPPROTO_SCTP.


In any case, in the commit here, we are replacing a mention of

  "...can be read with [...] getsockopt(2) by specifying SOL_SOCKET as
  the socket family"

with:

  "...can be read with [...] getsockopt(2) by specifying SOL_SOCKET as
  the level"

Independent of the exact terminology, that is still a good change to
do because it identifies the name of the getsockopt(2) argument, which
is "level".  (There are also some values which can be passed as level
which correspond to socket families in the sense of socket(2), but
SOL_SOCKET is not one of them.)

> > >   man/man7/unix.7: SO_PASSCRED: ffix
> > 
> > ??  This reminds me of Final Fantasy IX :p
> > 
> > Please fix all of them.
> 
> We use 'ffix' as a shorthand for 'formatting fix'.  Those patches
> usually make something bold, or remove bold, but don't do anything
> meaningful to the page.

Hah, yes. :)  As documented in CONTRIBUTING.d/patches/subject

Computer game references are unintended. ;-)

–Günther