[NET]: Please revert disallowing zero listen queues

[NET]: Please revert disallowing zero listen queues

[Gerrit Renker]

Please can you reconsider the patch regarding the accept_queue

http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.22.git;a=commit;h=8488df894d05d6fa41c2bd298c335f944bb0e401

It disallows to set a `backlog' argument to listen(2) of zero. Using
a zero backlog is often done (e.g. ttcp), and disallowing a zero 
backlog will break many applications. I had to recode several applications
which rely on this convention.

The problem further spreads from TCP to DCCP (same behaviour).

Below is a patch to revert this change.

Thank you 
Gerrit

diff --git a/include/net/sock.h b/include/net/sock.h
index 849c7df..2c7d60c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -426,7 +426,7 @@ static inline void sk_acceptq_added(stru
 
 static inline int sk_acceptq_is_full(struct sock *sk)
 {
-	return sk->sk_ack_backlog >= sk->sk_max_ack_backlog;
+	return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
 }
 
 /*

Re: [NET]: Please revert disallowing zero listen queues

[David Miller]

From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Tue, 6 Mar 2007 13:32:09 +0000

> Please can you reconsider the patch regarding the accept_queue
> 
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.22.git;a=commit;h=8488df894d05d6fa41c2bd298c335f944bb0e401
> 
> It disallows to set a `backlog' argument to listen(2) of zero. Using
> a zero backlog is often done (e.g. ttcp), and disallowing a zero 
> backlog will break many applications. I had to recode several applications
> which rely on this convention.
> 
> The problem further spreads from TCP to DCCP (same behaviour).
> 
> Below is a patch to revert this change.

Everything I've ever seen clearly states that a backlog of
zero means that zero connections are allowed.

So we're not "disallowing" a backlog argument of zero to
listen().  We'll accept that just fine, the only thing that
happens is that you'll get what you ask for, that being
no connections :-)

Re: [NET]: Please revert disallowing zero listen queues

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 06 Mar 2007 10:37:06 -0800 (PST)

> Everything I've ever seen clearly states that a backlog of
> zero means that zero connections are allowed.
> 
> So we're not "disallowing" a backlog argument of zero to
> listen().  We'll accept that just fine, the only thing that
> happens is that you'll get what you ask for, that being
> no connections :-)

I'm not saying that a backlog of zero might mean allow one,
in which case we do need to revert the change.  Rather, I'm
trying to clarify what is the real issue here as Gerrit's
email implied that listen() with a zero backlog returns
an error now, which is not true.

Re: [NET]: Please revert disallowing zero listen queues

[Rick Jones]

> So we're not "disallowing" a backlog argument of zero to
> listen().  We'll accept that just fine, the only thing that
> happens is that you'll get what you ask for, that being
> no connections :-)

I'm not sure where HP-UX inherited the 0 = 1 bit - perhaps from BSD, nor 
am I sure there is official chapter and verse, but:

<excerpt>
backlog is limited to the range of 0 to SOMAXCONN, which is 	defined in 
<sys/socket.h>.  SOMAXCONN is currently set to 4096.  If any other 
value is specified, the system automatically assigns the closest value 
     within the range.  A backlog of 0 specifies only 1 pending 
connection      is allowed at any given time.
</excerpt>

I don't have a Solaris, BSD or AIX manpage for listen handy to check 
them but would not be surprised to see they are similar.

rick jones

Re: [NET]: Please revert disallowing zero listen queues

[David Miller]

From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 06 Mar 2007 10:54:00 -0800

> > So we're not "disallowing" a backlog argument of zero to
> > listen().  We'll accept that just fine, the only thing that
> > happens is that you'll get what you ask for, that being
> > no connections :-)
> 
> I'm not sure where HP-UX inherited the 0 = 1 bit - perhaps from BSD, nor 
> am I sure there is official chapter and verse, but:
> 
> <excerpt>
> backlog is limited to the range of 0 to SOMAXCONN, which is 	defined in 
> <sys/socket.h>.  SOMAXCONN is currently set to 4096.  If any other 
> value is specified, the system automatically assigns the closest value 
>      within the range.  A backlog of 0 specifies only 1 pending 
> connection      is allowed at any given time.
> </excerpt>
> 
> I don't have a Solaris, BSD or AIX manpage for listen handy to check 
> them but would not be surprised to see they are similar.

Ok, that seals the deal for me, I'll revert the change :)

Re: [NET]: Please revert disallowing zero listen queues

[Vlad Yasevich]

David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Tue, 06 Mar 2007 10:54:00 -0800
> 
>>> So we're not "disallowing" a backlog argument of zero to
>>> listen().  We'll accept that just fine, the only thing that
>>> happens is that you'll get what you ask for, that being
>>> no connections :-)
>> I'm not sure where HP-UX inherited the 0 = 1 bit - perhaps from BSD, nor 
>> am I sure there is official chapter and verse, but:
>>
>> <excerpt>
>> backlog is limited to the range of 0 to SOMAXCONN, which is 	defined in 
>> <sys/socket.h>.  SOMAXCONN is currently set to 4096.  If any other 
>> value is specified, the system automatically assigns the closest value 
>>      within the range.  A backlog of 0 specifies only 1 pending 
>> connection      is allowed at any given time.
>> </excerpt>
>>
>> I don't have a Solaris, BSD or AIX manpage for listen handy to check 
>> them but would not be surprised to see they are similar.
> 
> Ok, that seals the deal for me, I'll revert the change :)

Ahh, crap.  Even Posix wiesel-words around this issue:

> A backlog argument of 0 may allow the socket to accept connections, in which case
> the length of the listen queue may be set to an implementation-defined minimum value.

(from http://www.opengroup.org/onlinepubs/009695399/functions/listen.html)

No, to go and fix the SCTP spec....

-vlad