On Mon, May 24, 2010 at 4:51 PM, Brian Bloniarz <bmb@xxxxxxxxxxxx> wrote: > On 05/24/2010 03:28 AM, Michael Kerrisk wrote: >> Actually, SO_*BUF is pretty weird. It returns double what was >> supplied. It's not simply a matter of rounding up: it always doubles >> what was supplied. > > Rationale in net/core/sock.c: > > set_rcvbuf: > sk->sk_userlocks |= SOCK_RCVBUF_LOCK; > /* > * We double it on the way in to account for > * "struct sk_buff" etc. overhead. Applications > * assume that the SO_RCVBUF setting they make will > * allow that much actual data to be received on that > * socket. > * > * Applications are unaware that "struct sk_buff" and > * other overheads allocate from the receive buffer > * during socket buffer allocation. > * > * And after considering the possible alternatives, > * returning the value we actually used in getsockopt > * is the most desirable behavior. > */ > if ((val * 2) < SOCK_MIN_RCVBUF) > sk->sk_rcvbuf = SOCK_MIN_RCVBUF; > else > sk->sk_rcvbuf = val * 2; > break; > > I'm guessing pipes don't have this kind of wrinkle. Yes, all of the above is understood. It's exposing these details to userspace that's weird... -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface" http://blog.man7.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
