linux-toradex.git/include/net, branch v2.6.23.17

TCP: MTUprobe: fix potential sk_send_head corruption

2007-12-14T17:51:04+00:00

[TCP] MTUprobe: fix potential sk_send_head corruption

[ Upstream commit: 6e42141009ff18297fe19d19296738b742f861db ]

When the abstraction functions got added, conversion here was
made incorrectly. As a result, the skb may end up pointing
to skb which got included to the probe skb and then was freed.
For it to trigger, however, skb_transmit must fail sending as
well.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Cc: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

TCP: Fix TCP header misalignment

2007-12-14T17:51:04+00:00

[TCP]: Fix TCP header misalignment

[ Upstream commit: 21df56c6e2372e09c916111efb6c14c372a5ab2e ]

Indeed my previous change to alloc_pskb has made it possible
for the TCP header to be misaligned iff the MTU is not a multiple
of 4 (and less than a page).  So I suspect the optimised IPsec
MTU calculation is giving you just such an MTU :)

This patch fixes it by changing alloc_pskb to make sure that
the size is at least 32-bit aligned.  This does not cause the
problem fixed by the previous patch because max_header is always
32-bit aligned which means that in the SG/NOTSO case this will
be a no-op.

I thought about putting this in the callers but all the current
callers are from TCP.  If and when we get a non-TCP caller we
can always create a TCP wrapper for this function and move the
alignment over there.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

TCP: Fix size calculation in sk_stream_alloc_pskb

2007-11-16T16:27:36+00:00

[TCP]: Fix size calculation in sk_stream_alloc_pskb

[ Upstream commit: fb93134dfc2a6e6fbedc7c270a31da03fce88db9 ]

We round up the header size in sk_stream_alloc_pskb so that
TSO packets get zero tail room.  Unfortunately this rounding
up is not coordinated with the select_size() function used by
TCP to calculate the second parameter of sk_stream_alloc_pskb.

As a result, we may allocate more than a page of data in the
non-TSO case when exactly one page is desired.

In fact, rounding up the head room is detrimental in the non-TSO
case because it makes memory that would otherwise be available to
the payload head room.  TSO doesn't need this either, all it wants
is the guarantee that there is no tail room.

So this patch fixes this by adjusting the skb_reserve call so that
exactly the requested amount (which all callers have calculated in
a precise way) is made available as tail room.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix 9P protocol build

2007-11-16T16:27:36+00:00

patch 092e9d93b3728d484a4e73df9852dc4002cf9923 in mainline.

[9P]: build fix with !CONFIG_SYSCTL

found via make randconfig build testing:

 net/built-in.o: In function `init_p9':
 mod.c:(.init.text+0x3b39): undefined reference to `p9_sysctl_register'
 net/built-in.o: In function `exit_p9':
 mod.c:(.exit.text+0x36b): undefined reference to `p9_sysctl_unregister'

Signed-off-by: Ingo Molnar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[ROSE]: Fix rose.ko oops on unload

2007-10-08T06:44:17+00:00

Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka
"[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
transformed rose_loopback_neigh var into statically allocated one.
However, on unload it will be kfree's which can't work.

Steps to reproduce:

	modprobe rose
	rmmod rose

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
 printing eip:
c014c664
*pde = 00000000
Oops: 0000 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom
CPU:    0
EIP:    0060:[]    Not tainted VLI
EFLAGS: 00210086   (2.6.23-rc9 #3)
EIP is at kfree+0x48/0xa1
eax: 00000556   ebx: c1734aa0   ecx: f6a5e000   edx: f7082000
esi: 00000000   edi: f9a55d20   ebp: 00200287   esp: f6a5ef28
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000)
Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 
       00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 
       f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 
Call Trace:
 [] rose_rt_free+0x1d/0x49 [rose]
 [] rose_rt_free+0x1d/0x49 [rose]
 [] rose_exit+0x4c/0xd5 [rose]
 [] sys_delete_module+0x15e/0x186
 [] remove_vma+0x40/0x45
 [] sysenter_past_esp+0x8f/0x99
 [] trace_hardirqs_on+0x118/0x13b
 [] sysenter_past_esp+0x5f/0x99
 =======================
Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f 
EIP: [] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller

[TCP]: Fix MD5 signature handling on big-endian.

2007-09-28T22:18:35+00:00

Based upon a report and initial patch by Peter Lieven.

tcp4_md5sig_key and tcp6_md5sig_key need to start with
the exact same members as tcp_md5sig_key.  Because they
are both cast to that type by tcp_v{4,6}_md5_do_lookup().

Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
length instead of a u8, which is what tcp_md5sig_key
uses.  This just so happens to work by accident on
little-endian, but on big-endian it doesn't.

Instead of casting, just place tcp_md5sig_key as the first member of
the address-family specific structures, adjust the access sites, and
kill off the ugly casts.

Signed-off-by: David S. Miller

fix sctp_del_bind_addr() last argument type

2007-09-26T16:22:04+00:00

It gets pointer to fastcall function, expects a pointer to normal
one and calls the sucker.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

SCTP : Add paramters validity check for ASCONF chunk

2007-09-26T05:55:49+00:00

If ADDIP is enabled, when an ASCONF chunk is received with ASCONF
paramter length set to zero, this will cause infinite loop.
By the way, if an malformed ASCONF chunk is received, will cause
processing to access memory without verifying.

This is because of not check the validity of parameters in ASCONF chunk.
This patch fixed this.

Signed-off-by: Wei Yongjun 
Signed-off-by: Vlad Yasevich

SCTP: Clean up OOTB handling and fix infinite loop processing

2007-09-26T05:55:47+00:00

While processing OOTB chunks as well as chunks with an invalid
length of 0, it was possible to SCTP to get wedged inside an
infinite loop because we didn't catch the condition correctly,
or didn't mark the packet for discard correctly.
This work is based on original findings and work by
Wei Yongjun 

Signed-off-by: Vlad Yasevich

[SCTP]: Convert bind_addr_list locking to RCU

2007-09-16T23:03:28+00:00

Since the sctp_sockaddr_entry is now RCU enabled as part of
the patch to synchronize sctp_localaddr_list, it makes sense to
change all handling of these entries to RCU.  This includes the
sctp_bind_addrs structure and it's list of bound addresses.

This list is currently protected by an external rw_lock and that
looks like an overkill.  There are only 2 writers to the list:
bind()/bindx() calls, and BH processing of ASCONF-ACK chunks.
These are already seriealized via the socket lock, so they will
not step on each other.  These are also relatively rare, so we
should be good with RCU.

The readers are varied and they are easily converted to RCU.

Signed-off-by: Vlad Yasevich 
Acked-by: Paul E. McKenney 
Acked-by: Sridhar Samdurala 
Signed-off-by: David S. Miller