Re: [PATCH 06/24] man/man7/unix.7: ERRORS: EPROTONOSUPPORT: Protocol 0 is also accepted

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

On Sun, Oct 18, 2026 at 01:19:34PM +0200, Alejandro Colomar wrote:
> Hi,
> 
> > Date: 2026-10-16 19:31:21+0200
> > From: Günther Noack <gnoack3000@gmail.com>
> >
> > unix_create() in linux.git net/unix/af_unix.c only fails if
> > 'protocol && protocol != PF_UNIX'.  0 is the usual value, and the one
> > used in the SYNOPSIS.
> 
> The commit message seems bogus.  What does that 'only' intend to mean?
> The actual diff seems better than the commit message, but I'm not taking
> it.  This is an example of the nonsense produced by LLMs.  I'm NAKing
> the remainders of the patch set; that is, for patches 06..24/24:
> 
> 	Nacked-by: Alejandro Colomar <alx@kernel.org>
> 
> The exception for LLM use is explicitly terminated.

The commit message may be short, but it is factually correct: The
referenced unix_create() function starts with this guard at the
beginning:

  if (protocol && protocol != PF_UNIX)
  	return -EPROTONOSUPPORT;

It rejects the creation with EPROTONOSUPPORT (only) if the condition
"protocol && protocol != PF_UNIX) is met.  That is, protocol must be
either 0, or it must be PF_UNIX (a.k.a. AF_UNIX) to pass the check.

The "protocol" value corresponds to the protocol value passed to
socket(2), which is left at 0 in most common protocols, such as when
invoked with socket(AF_UNIX, SOCK_STREAM, 0) or socket(AF_INET,
SOCK_{STREAM,DGRAM}, 0).

I can send you an updated version if you prefer more context in the
commit message.


> The patches I've already reviewed seem okay, although please have
> another look at them, especially at their commit messages, in case I
> missed anything.  Please resend the patches that I've reviewed,
> including my review tags and any other tags, and I'll apply them.

Fair, I'll update and resend the patchset with more information.

I would like to point out two things though:

1. I have done a pretty tedious and manual review to verify and often
   reword each single patch.  It's possible that a commit message with
   a lower level of detail slipped through, but this is all fixable.

2. The fixes are largely independent of each other, and if you think
   that patches within 1-5 are good, then you'll very likely find the
   same for patches after that as well.

I'd encourage you to rethink your decision; I do think that these
patches improve the documentation.

–Günther