kernel/include/net/sock.h, branch linux-2.6.21.y

[NET]: Revert incorrect accept queue backlog changes.

2007-03-06T19:21:05Z

This reverts two changes: 8488df894d05d6fa41c2bd298c335f944bb0e401 248f06726e866942b3d8ca8f411f9067713b7ff8 A backlog value of N really does mean allow "N + 1" connections to queue to a listening socket. This allows one to specify "0" as the backlog and still get 1 connection. Noticed by Gerrit Renker and Rick Jones. Signed-off-by: David S. Miller

[NET]: Fix bugs in "Whether sock accept queue is full" checking

2007-03-03T04:37:33Z

when I use linux TCP socket, and find there is a bug in function sk_acceptq_is_full(). When a new SYN comes, TCP module first checks its validation. If valid, send SYN,ACK to the client and add the sock to the syn hash table. Next time if received the valid ACK for SYN,ACK from the client. server will accept this connection and increase the sk->sk_ack_backlog -- which is done in function tcp_check_req().We check wether acceptq is full in function tcp_v4_syn_recv_sock(). Consider an example: After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to 1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept() system call is not invoked now. 1. 1st connection comes. invoke sk_acceptq_is_full(). sk- >sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept this connection. Increase the sk->sk_ack_backlog 2. 2nd connection comes. invoke sk_acceptq_is_full(). sk- >sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept this connection. Increase the sk->sk_ack_backlog 3. 3rd connection comes. invoke sk_acceptq_is_full(). sk- >sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse this connection. I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1 but now it can accept 2 connections. Signed-off-by: Wei Dong Signed-off-by: David S. Miller

[NET]: Handle disabled preemption in gfp_any()

2007-02-28T17:42:13Z

ctnetlink uses netlink_unicast from an atomic_notifier_chain (which is called within a RCU read side critical section) without holding further locks. netlink_unicast calls netlink_trim with the result of gfp_any() for the gfp flags, which are passed down to pskb_expand_header. gfp_any() only checks for softirq context and returns GFP_KERNEL, resulting in this warning: BUG: sleeping function called from invalid context at mm/slab.c:3032 in_atomic():1, irqs_disabled():0 no locks held by rmmod/7010. Call Trace: [] debug_show_held_locks+0x9/0xb [] __might_sleep+0xd9/0xdb [] __kmalloc+0x68/0x110 [] pskb_expand_head+0x4d/0x13b [] netlink_broadcast+0xa5/0x2e0 [] :nfnetlink:nfnetlink_send+0x83/0x8a [] :nf_conntrack_netlink:ctnetlink_conntrack_event+0x94c/0x96a [] notifier_call_chain+0x29/0x3e [] atomic_notifier_call_chain+0x32/0x60 [] :nf_conntrack:destroy_conntrack+0xa5/0x1d3 [] :nf_conntrack:nf_ct_cleanup+0x8c/0x12c [] :nf_conntrack:kill_l3proto+0x0/0x13 [] :nf_conntrack:nf_conntrack_l3proto_unregister+0x90/0x94 [] :nf_conntrack_ipv4:nf_conntrack_l3proto_ipv4_fini+0x2b/0x5d [] sys_delete_module+0x1b5/0x1e6 [] trace_hardirqs_on_thunk+0x35/0x37 [] system_call+0x7e/0x83 Since netlink_unicast is supposed to be callable from within RCU read side critical sections, make gfp_any() check for in_atomic() instead of in_softirq(). Additionally nfnetlink_send needs to use gfp_any() as well for the call to netlink_broadcast). Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[PATCH] lockdep: annotate nfs/nfsd in-kernel sockets

2006-12-07T16:39:30Z

Stick NFS sockets in their own class to avoid some lockdep warnings. NFS sockets are never exposed to user-space, and will hence not trigger certain code paths that would otherwise pose deadlock scenarios. [akpm@osdl.org: cleanups] Signed-off-by: Peter Zijlstra Signed-off-by: Steven Dickson Acked-by: Ingo Molnar Cc: Trond Myklebust Acked-by: Neil Brown Cc: "David S. Miller" Signed-off-by: Andrew Morton [ Fixed patch corruption by quilt, pointed out by Peter Zijlstra ] Signed-off-by: Linus Torvalds

[PATCH] slab: remove kmem_cache_t

2006-12-07T16:39:25Z

Replace all uses of kmem_cache_t with struct kmem_cache. The patch was generated using the following script: #!/bin/sh # # Replace one string by another in all the kernel sources. # set -e for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do quilt add $file sed -e "1,\$s/$1/$2/g" $file >/tmp/$$ mv /tmp/$$ $file quilt refresh done The script was run like this sh replace kmem_cache_t "struct kmem_cache" Signed-off-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] severing skbuff.h -> mm.h

2006-12-04T07:00:34Z

Signed-off-by: Al Viro

[NET]: Conditionally use bh_lock_sock_nested in sk_receive_skb

2006-12-03T05:23:51Z

Spotted by Ian McDonald, tentatively fixed by Gerrit Renker: http://www.mail-archive.com/dccp%40vger.kernel.org/msg00599.html Rewritten not to unroll sk_receive_skb, in the common case, i.e. no lock debugging, its optimized away. Signed-off-by: Arnaldo Carvalho de Melo

[NET]: Annotate callers of csum_partial_copy_...() and csum_and_copy...() in net/*

2006-12-03T05:23:33Z

Signed-off-by: Al Viro Signed-off-by: David S. Miller

[BLUETOOTH] lockdep: annotate sk_lock nesting in AF_BLUETOOTH

2006-12-03T05:21:35Z

============================================= [ INFO: possible recursive locking detected ] 2.6.18-1.2726.fc6 #1

[NET]: Re-fix of doc-comment in sock.h

2006-11-25T23:16:51Z

Restoring old, correct comment for sk_filter_release, moving it to where it should actually be, and changing new comment into proper comment for sk_filter_rcu_free, where it actually makes sense. The original fix submitted for this on Oct 23 mistakenly documented the wrong function. Signed-off-by: Paul Bonser Signed-off-by: David S. Miller