Bug 12860

Summary:	SO_RCVBUF and SO_SNDBUF must be set before connect() or listen()
Product:	Networking	Reporter:	Cristian KLEIN (cristiklein)
Component:	IPV4	Assignee:	Stephen Hemminger (stephen)
Status:	REJECTED UNREPRODUCIBLE
Severity:	normal	CC:	alan
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.18	Subsystem:
Regression:	---	Bisected commit-id:

Description Cristian KLEIN 2009-03-12 10:23:51 UTC

Problem Description:

Calling setsockopt() with SO_RCVBUF or SO_SNDBUF after connect() or listen() makes sockets have a horrible performance. Moreover, getsockopt() returns values as if the previous setsockopt() was successful.

Solution:

1) Document this somewhere in the man-pages (e.g. socket(7))
2) Make setsockopt() fail after connect() or listen()

If you need an example code, I'll be happy to provide it.

Comment 1 Anonymous Emailer 2009-03-12 13:14:10 UTC

Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 12 Mar 2009 10:23:52 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12860
> 
>            Summary: SO_RCVBUF and SO_SNDBUF must be set before connect() or
>                     listen()
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.18
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>         AssignedTo: shemminger@linux-foundation.org
>         ReportedBy: cristiklein@gmail.com
> 
> 
> Problem Description:
> 
> Calling setsockopt() with SO_RCVBUF or SO_SNDBUF after connect() or listen()
> makes sockets have a horrible performance. Moreover, getsockopt() returns
> values as if the previous setsockopt() was successful.
> 
> Solution:
> 
> 1) Document this somewhere in the man-pages (e.g. socket(7))
> 2) Make setsockopt() fail after connect() or listen()
> 
> If you need an example code, I'll be happy to provide it.
>

Comment 2 Alan 2009-03-17 08:06:16 UTC

Please retest with a kernel somewhat newer than 2.6.18, or if your 2.6.18 is a vendor supplied kernel (eg RHEL, Centos) take the bug up with them.

Huge amounts have changed over the years since 2.6.18 was released

Comment 3 Cristian KLEIN 2009-03-23 03:02:58 UTC

I'm not able to reproduce this error on newer kernels.