kernel/linux.git/include/net/sctp/structs.h, branch v2.6.38

sctp: kill unused macros in head file

2010-11-29T17:41:12+00:00

1. SCTP_CMD_NUM_VERBS,SCTP_CMD_MAX These two macros have never been used for several years since v2.6.12-rc2. 2.sctp_port_rover,sctp_port_alloc_lock The commit 063930 abandoned global variables of port_rover and port_alloc_lock, but still keep two macros to refer to them. So, remove them now. commit 06393009000779b00a558fd2f280882cc7dc2008 Author: Stephen Hemminger Date: Wed Oct 10 17:30:18 2007 -0700 [SCTP]: port randomization Signed-off-by: Shan Wei Signed-off-by: David S. Miller

net: return operator cleanup

2010-09-23T21:33:39+00:00

Change "return (EXPR);" to "return EXPR;" return is not a function, parentheses are not required. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

net: use __packed annotation

2010-06-03T10:21:52+00:00

cleanup patch. Use new __packed annotation in net/ and include/ (except netfilter) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

sctp: dubious bitfields in sctp_transport

2010-05-26T07:40:11+00:00

Sparse complains because these one-bit bitfields are signed. include/net/sctp/structs.h:879:24: error: dubious one-bit signed bitfield include/net/sctp/structs.h:889:31: error: dubious one-bit signed bitfield include/net/sctp/structs.h:895:26: error: dubious one-bit signed bitfield include/net/sctp/structs.h:898:31: error: dubious one-bit signed bitfield include/net/sctp/structs.h:901:27: error: dubious one-bit signed bitfield It doesn't cause a problem in the current code, but it would be better to clean it up. This was introduced by c0058a35aacc7: "sctp: Save some room in the sctp_transport by using bitfields". Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2010-05-12T07:05:35+00:00

Conflicts: Documentation/feature-removal-schedule.txt drivers/net/wireless/ath/ar9170/usb.c drivers/scsi/iscsi_tcp.c net/ipv4/ipmr.c

sctp: Fix a race between ICMP protocol unreachable and connect()

2010-05-06T07:56:07+00:00

ICMP protocol unreachable handling completely disregarded the fact that the user may have locked the socket. It proceeded to destroy the association, even though the user may have held the lock and had a ref on the association. This resulted in the following: Attempt to release alive inet socket f6afcc00 ========================= [ BUG: held lock freed! ] ------------------------- somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held there! (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c 1 lock held by somenu/2672: #0: (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c stack backtrace: Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55 Call Trace: [] ? printk+0xf/0x11 [] debug_check_no_locks_freed+0xce/0xff [] kmem_cache_free+0x21/0x66 [] __sk_free+0x9d/0xab [] sk_free+0x1c/0x1e [] sctp_association_put+0x32/0x89 [] __sctp_connect+0x36d/0x3f4 [] ? sctp_connect+0x13/0x4c [] ? autoremove_wake_function+0x0/0x33 [] sctp_connect+0x31/0x4c [] inet_dgram_connect+0x4b/0x55 [] sys_connect+0x54/0x71 [] ? lock_release_non_nested+0x88/0x239 [] ? might_fault+0x42/0x7c [] ? might_fault+0x42/0x7c [] sys_socketcall+0x6d/0x178 [] ? trace_hardirqs_on_thunk+0xc/0x10 [] syscall_call+0x7/0xb This was because the sctp_wait_for_connect() would aqcure the socket lock and then proceed to release the last reference count on the association, thus cause the fully destruction path to finish freeing the socket. The simplest solution is to start a very short timer in case the socket is owned by user. When the timer expires, we can do some verification and be able to do the release properly. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

Merge branch 'net-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vxy/lksctp-dev

2010-05-03T23:24:31+00:00

Add missing linux/vmalloc.h include to net/sctp/probe.c Signed-off-by: David S. Miller

sctp: Tag messages that can be Nagle delayed at creation.

2010-05-01T02:41:10+00:00

When we create the sctp_datamsg and fragment the user data, we know exactly if we are sending full segments or not and how they might be bundled. During this time, we can mark messages a Nagle capable or not. This makes the check at transmit time much simpler. Signed-off-by: Vlad Yasevich

sctp: fast recovery algorithm is per association.

2010-05-01T02:41:10+00:00

SCTP fast recovery algorithm really applies per association and impacts all transports. Signed-off-by: Vlad Yasevich

sctp: Save some room in the sctp_transport by using bitfields

2010-05-01T02:41:09+00:00

Saves some room in the sctp_transport structure. Signed-off-by: Vlad Yasevich