linux.git/net/core/sock.c, branch v2.6.22

[NET] gso: Fix GSO feature mask in sk_setup_caps

2007-06-04T01:08:49+00:00

This isn't a bug just yet as only TCP uses sk_setup_caps for GSO.
However, if and when UDP or something else starts using it this is
likely to cause a problem if we forget to add software emulation
for it at the same time.

The problem is that right now we translate GSO emulation to the
bitmask NETIF_F_GSO_MASK, which includes every protocol, even
ones that we cannot emulate.

This patch makes it provide only the ones that we can emulate.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

[NET]: "wrong timeout value" in sk_wait_data() v2

2007-05-24T23:58:54+00:00

sys_setsockopt() do not check properly timeout values for
SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout
values. POSIX do not defines behaviour for sys_setsockopt in case negative
timeouts, but requires that setsockopt() shall fail with -EDOM if the send and
receive timeout values are too big to fit into the timeout fields in the socket
structure.
In current implementation negative timeout can lead to error messages like
"schedule_timeout: wrong timeout value".

Proposed patch:
- checks tv_usec and returns -EDOM if it is wrong
- do not allows to set negative timeout values (sets 0 instead) and outputs
ratelimited information message about such attempts.

Signed-off-By: Vasily Averin 
Signed-off-by: David S. Miller

[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both

2007-04-26T22:48:28+00:00

Provide AF_RXRPC sockets that can be used to talk to AFS servers, or serve
answers to AFS clients.  KerberosIV security is fully supported.  The patches
and some example test programs can be found in:

	http://people.redhat.com/~dhowells/rxrpc/

This will eventually replace the old implementation of kernel-only RxRPC
currently resident in net/rxrpc/.

Signed-off-by: David Howells 
Signed-off-by: David S. Miller

[NET]: Move sk_setup_caps() out of line.

2007-04-26T05:29:26+00:00

It is far too large to be an inline and not in any hot paths.

Signed-off-by: Andi Kleen 
Signed-off-by: David S. Miller

[NET]: make seq_operations const

2007-04-26T05:25:03+00:00

The seq_file operations stuff can be marked constant to
get it out of dirty cache.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[NET]: Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support

2007-04-26T05:24:21+00:00

Now that network timestamps use ktime_t infrastructure, we can add a new
SOL_SOCKET sockopt  SO_TIMESTAMPNS.

This command is similar to SO_TIMESTAMP, but permits transmission of
a 'timespec struct' instead of a 'timeval struct' control message.
(nanosecond resolution instead of microsecond)

Control message is labelled SCM_TIMESTAMPNS instead of SCM_TIMESTAMP

A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS : the two modes are
mutually exclusive.

sock_recv_timestamp() became too big to be fully inlined so I added a
__sock_recv_timestamp() helper function.

Signed-off-by: Eric Dumazet 
CC: linux-arch@vger.kernel.org
Signed-off-by: David S. Miller

[NET] core: whitespace cleanup

2007-04-26T05:24:09+00:00

Fix whitespace around keywords. Fix indentation especially of switch
statements.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[NET]: Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution

2007-04-26T05:24:04+00:00

Now network timestamps use ktime_t infrastructure, we can add a new
ioctl() SIOCGSTAMPNS command to get timestamps in 'struct timespec'.
User programs can thus access to nanosecond resolution.

Signed-off-by: Eric Dumazet 
CC: Stephen Hemminger 
Signed-off-by: David S. Miller

[NET]: convert network timestamps to ktime_t

2007-04-26T05:23:34+00:00

We currently use a special structure (struct skb_timeval) and plain
'struct timeval' to store packet timestamps in sk_buffs and struct
sock.

This has some drawbacks :
- Fixed resolution of micro second.
- Waste of space on 64bit platforms where sizeof(struct timeval)=16

I suggest using ktime_t that is a nice abstraction of high resolution
time services, currently capable of nanosecond resolution.

As sizeof(ktime_t) is 8 bytes, using ktime_t in 'struct sock' permits
a 8 byte shrink of this structure on 64bit architectures. Some other
structures also benefit from this size reduction (struct ipq in
ipv4/ip_fragment.c, struct frag_queue in ipv6/reassembly.c, ...)

Once this ktime infrastructure adopted, we can more easily provide
nanosecond resolution on top of it. (ioctl SIOCGSTAMPNS and/or
SO_TIMESTAMPNS/SCM_TIMESTAMPNS)

Note : this patch includes a bug correction in
compat_sock_get_timestamp() where a "err = 0;" was missing (so this
syscall returned -ENOENT instead of 0)

Signed-off-by: Eric Dumazet 
CC: Stephen Hemminger 
CC: John find 
Signed-off-by: David S. Miller

[NET]: Keep sk_backlog near sk_lock

2007-04-26T05:23:27+00:00

sk_backlog is a critical field of struct sock. (known famous words)

It is (ab)used in hot paths, in particular in release_sock(), tcp_recvmsg(),
tcp_v4_rcv(), sk_receive_skb().

It really makes sense to place it next to sk_lock, because sk_backlog is only
used after sk_lock locked (and thus memory cache line in L1 cache). This
should reduce cache misses and sk_lock acquisition time.

(In theory, we could only move the head pointer near sk_lock, and leaving tail
far away, because 'tail' is normally not so hot, but keep it simple :) )

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller