linux.git/net/ipv4, branch v3.6-rc7

net: change return values from -EACCES to -EPERM

2012-09-21T17:58:08+00:00

Change return value from -EACCES to -EPERM when the permission check fails.

Signed-off-by: Zhao Hongjiang 
Signed-off-by: David S. Miller

tcp: restore rcv_wscale in a repair mode (v2)

2012-09-20T21:49:58+00:00

rcv_wscale is a symetric parameter with snd_wscale.

Both this parameters are set on a connection handshake.

Without this value a remote window size can not be interpreted correctly,
because a value from a packet should be shifted on rcv_wscale.

And one more thing is that wscale_ok should be set too.

This patch doesn't break a backward compatibility.
If someone uses it in a old scheme, a rcv window
will be restored with the same bug (rcv_wscale = 0).

v2: Save backward compatibility on big-endian system. Before
    the first two bytes were snd_wscale and the second two bytes were
    rcv_wscale. Now snd_wscale is opt_val & 0xFFFF and rcv_wscale >> 16.
    This approach is independent on byte ordering.

Cc: David S. Miller 
Cc: Alexey Kuznetsov 
Cc: James Morris 
Cc: Hideaki YOSHIFUJI 
Cc: Patrick McHardy 
CC: Pavel Emelyanov 
Signed-off-by: Andrew Vagin 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tcp: flush DMA queue before sk_wait_data if rcv_wnd is zero

2012-09-19T20:07:58+00:00

If recv() syscall is called for a TCP socket so that
  - IOAT DMA is used
  - MSG_WAITALL flag is used
  - requested length is bigger than sk_rcvbuf
  - enough data has already arrived to bring rcv_wnd to zero
then when tcp_recvmsg() gets to calling sk_wait_data(), receive
window can be still zero while sk_async_wait_queue exhausts
enough space to keep it zero. As this queue isn't cleaned until
the tcp_service_net_dma() call, sk_wait_data() cannot receive
any data and blocks forever.

If zero receive window and non-empty sk_async_wait_queue is
detected before calling sk_wait_data(), process the queue first.

Signed-off-by: Michal Kubecek 
Signed-off-by: David S. Miller

tcp: fix regression in urgent data handling

2012-09-18T20:26:27+00:00

Stephan Springl found that commit 1402d366019fed "tcp: introduce
tcp_try_coalesce" introduced a regression for rlogin

It turns out problem comes from TCP urgent data handling and
a change in behavior in input path.

rlogin sends two one-byte packets with URG ptr set, and when next data
frame is coalesced, we lack sk_data_ready() calls to wakeup consumer.

Signed-off-by: Eric Dumazet 
Reported-by: Stephan Springl 
Cc: Alexander Duyck 
Signed-off-by: David S. Miller

netns: move net->ipv4.rt_genid to net->rt_genid

2012-09-18T19:57:03+00:00

This commit prepares the use of rt_genid by both IPv4 and IPv6.
Initialization is left in IPv4 part.

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

net: rt_cache_flush() cleanup

2012-09-18T19:54:19+00:00

We dont use jhash anymore since route cache removal,
so we can get rid of get_random_bytes() calls for rt_genid
changes.

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

ipv4/route: arg delay is useless in rt_cache_flush()

2012-09-18T19:44:34+00:00

Since route cache deletion (89aef8921bfbac22f), delay is no
more used. Remove it.

Signed-off-by: Nicolas Dichtel 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

udp: increment UDP_MIB_INERRORS if copy failed

2012-09-07T16:56:00+00:00

In UDP recvmsg(), we miss an increase of UDP_MIB_INERRORS if the copy
of skb to userspace failed for whatever reason.

Reported-by: Shawn Bohrer 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

Merge branch 'master' of git://1984.lsi.us.es/nf

2012-08-31T17:06:37+00:00

ipv4: must use rcu protection while calling fib_lookup

2012-08-30T17:33:08+00:00

Following lockdep splat was reported by Pavel Roskin :

[ 1570.586223] ===============================
[ 1570.586225] [ INFO: suspicious RCU usage. ]
[ 1570.586228] 3.6.0-rc3-wl-main #98 Not tainted
[ 1570.586229] -------------------------------
[ 1570.586231] /home/proski/src/linux/net/ipv4/route.c:645 suspicious rcu_dereference_check() usage!
[ 1570.586233]
[ 1570.586233] other info that might help us debug this:
[ 1570.586233]
[ 1570.586236]
[ 1570.586236] rcu_scheduler_active = 1, debug_locks = 0
[ 1570.586238] 2 locks held by Chrome_IOThread/4467:
[ 1570.586240]  #0:  (slock-AF_INET){+.-...}, at: [] release_sock+0x2c/0xa0
[ 1570.586253]  #1:  (fnhe_lock){+.-...}, at: [] update_or_create_fnhe+0x2c/0x270
[ 1570.586260]
[ 1570.586260] stack backtrace:
[ 1570.586263] Pid: 4467, comm: Chrome_IOThread Not tainted 3.6.0-rc3-wl-main #98
[ 1570.586265] Call Trace:
[ 1570.586271]  [] lockdep_rcu_suspicious+0xfd/0x130
[ 1570.586275]  [] update_or_create_fnhe+0x15c/0x270
[ 1570.586278]  [] __ip_rt_update_pmtu+0x73/0xb0
[ 1570.586282]  [] ip_rt_update_pmtu+0x29/0x90
[ 1570.586285]  [] inet_csk_update_pmtu+0x2c/0x80
[ 1570.586290]  [] tcp_v4_mtu_reduced+0x2e/0xc0
[ 1570.586293]  [] tcp_release_cb+0xa4/0xb0
[ 1570.586296]  [] release_sock+0x55/0xa0
[ 1570.586300]  [] tcp_sendmsg+0x4af/0xf50
[ 1570.586305]  [] inet_sendmsg+0x120/0x230
[ 1570.586308]  [] ? inet_sk_rebuild_header+0x40/0x40
[ 1570.586312]  [] ? sock_update_classid+0xbd/0x3b0
[ 1570.586315]  [] ? sock_update_classid+0x130/0x3b0
[ 1570.586320]  [] do_sock_write+0xc5/0xe0
[ 1570.586323]  [] sock_aio_write+0x53/0x80
[ 1570.586328]  [] do_sync_write+0xa3/0xe0
[ 1570.586332]  [] vfs_write+0x165/0x180
[ 1570.586335]  [] sys_write+0x45/0x90
[ 1570.586340]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Eric Dumazet 
Reported-by: Pavel Roskin 
Signed-off-by: David S. Miller