kern/80587: accept(2) can return EINVAL for undocumented reason

Giorgos Keramidas keramida at freebsd.org
Tue May 3 16:10:07 PDT 2005


The following reply was made to PR kern/80587; it has been noted by GNATS.

From: Giorgos Keramidas <keramida at freebsd.org>
To: Arne H Juul <arnej at europe.yahoo-inc.com>
Cc: bug-followup at freebsd.org
Subject: Re: kern/80587: accept(2) can return EINVAL for undocumented reason
Date: Wed, 4 May 2005 02:00:22 +0300

 On 2005-05-03 20:35, Arne H Juul <arnej at europe.yahoo-inc.com> wrote:
 > We had a problem where a daemon wouldn't read commands on its socket;
 > after some debugging we found that accept() on the socket didn't work
 > (with errno EINVAL).  According to man 2 accept this can only be
 > caused by "listen(2) has not been called" but after more intensive
 > debugging we couldn't figure out how that was possible in our program.
 >
 > Inspection of the actual kernel source for accept(2) however shows
 > that it also returns EINVAL when the namelen argument is negative; it
 > turns out the program had a stupid bug where the namelen was
 > uninitialized causing accept() to fail unpredicably depending on stack
 > contents.  The following documentation fix would (hopefully) have
 > saved us some time chasing down codepaths through listen().
 
 True!  The relevant bits in CURRENT are in uipc_syscalls.c (which you
 already know, but I'm posting here for the audit trail):
 
     281 static int
     282 accept1(td, uap, compat)
     ...
     290 {
     ...
     307                 if (namelen < 0)
     308                         return (EINVAL);
 
 >  .It Bq Er EINVAL
 >  .Xr listen 2
 >  has not been called on the socket descriptor.
 > +.It Bq Er EINVAL
 > +The
 > +.Fa addrlen
 > +argument is negative.
 
 I think that documenting both cases in a single paragraph of accept(2)
 is ok too:
 
 	 .It Bq Er EINVAL
 	 .Xr listen 2
 	-has not been called on the socket descriptor.
 	+has not been called on the socket descriptor or the
 	+.Fa addrlen
 	+argument is negative.
 
 If this change to the diff is ok with you too, I'll see that it gets
 committed.
 
 - Giorgos
 


More information about the freebsd-bugs mailing list