linux-stable.git/net/l2tp, branch v3.5

net: l2tp_eth: use LLTX to avoid LOCKDEP splats

2012-06-26T23:42:33+00:00

Denys Fedoryshchenko reported a LOCKDEP issue with l2tp code.

[ 8683.927442] ======================================================
[ 8683.927555] [ INFO: possible circular locking dependency detected ]
[ 8683.927672] 3.4.1-build-0061 #14 Not tainted
[ 8683.927782] -------------------------------------------------------
[ 8683.927895] swapper/0/0 is trying to acquire lock:
[ 8683.928007]  (slock-AF_INET){+.-...}, at: []
l2tp_xmit_skb+0x173/0x47e [l2tp_core]
[ 8683.928121]
[ 8683.928121] but task is already holding lock:
[ 8683.928121]  (_xmit_ETHER#2){+.-...}, at: []
sch_direct_xmit+0x36/0x119
[ 8683.928121]
[ 8683.928121] which lock already depends on the new lock.
[ 8683.928121]
[ 8683.928121]
[ 8683.928121] the existing dependency chain (in reverse order) is:
[ 8683.928121]
[ 8683.928121] -> #1 (_xmit_ETHER#2){+.-...}:
[ 8683.928121]        [] lock_acquire+0x71/0x85
[ 8683.928121]        [] _raw_spin_lock+0x33/0x40
[ 8683.928121]        [] ip_send_reply+0xf2/0x1ce
[ 8683.928121]        [] tcp_v4_send_reset+0x153/0x16f
[ 8683.928121]        [] tcp_v4_do_rcv+0x172/0x194
[ 8683.928121]        [] tcp_v4_rcv+0x387/0x5a0
[ 8683.928121]        [] ip_local_deliver_finish+0x13a/0x1e9
[ 8683.928121]        [] NF_HOOK.clone.11+0x46/0x4d
[ 8683.928121]        [] ip_local_deliver+0x41/0x45
[ 8683.928121]        [] ip_rcv_finish+0x31a/0x33c
[ 8683.928121]        [] NF_HOOK.clone.11+0x46/0x4d
[ 8683.928121]        [] ip_rcv+0x201/0x23d
[ 8683.928121]        [] __netif_receive_skb+0x329/0x378
[ 8683.928121]        [] netif_receive_skb+0x4e/0x7d
[ 8683.928121]        [] rtl8139_poll+0x243/0x33d [8139too]
[ 8683.928121]        [] net_rx_action+0x90/0x15d
[ 8683.928121]        [] __do_softirq+0x7b/0x118
[ 8683.928121]
[ 8683.928121] -> #0 (slock-AF_INET){+.-...}:
[ 8683.928121]        [] __lock_acquire+0x9a3/0xc27
[ 8683.928121]        [] lock_acquire+0x71/0x85
[ 8683.928121]        [] _raw_spin_lock+0x33/0x40
[ 8683.928121]        [] l2tp_xmit_skb+0x173/0x47e
[l2tp_core]
[ 8683.928121]        [] l2tp_eth_dev_xmit+0x1a/0x2f
[l2tp_eth]
[ 8683.928121]        [] dev_hard_start_xmit+0x333/0x3f2
[ 8683.928121]        [] sch_direct_xmit+0x55/0x119
[ 8683.928121]        [] dev_queue_xmit+0x282/0x418
[ 8683.928121]        [] NF_HOOK.clone.19+0x45/0x4c
[ 8683.928121]        [] arp_xmit+0x22/0x24
[ 8683.928121]        [] arp_send+0x41/0x48
[ 8683.928121]        [] arp_process+0x289/0x491
[ 8683.928121]        [] NF_HOOK.clone.19+0x45/0x4c
[ 8683.928121]        [] arp_rcv+0xb1/0xc3
[ 8683.928121]        [] __netif_receive_skb+0x329/0x378
[ 8683.928121]        [] process_backlog+0x69/0x130
[ 8683.928121]        [] net_rx_action+0x90/0x15d
[ 8683.928121]        [] __do_softirq+0x7b/0x118
[ 8683.928121]
[ 8683.928121] other info that might help us debug this:
[ 8683.928121]
[ 8683.928121]  Possible unsafe locking scenario:
[ 8683.928121]
[ 8683.928121]        CPU0                    CPU1
[ 8683.928121]        ----                    ----
[ 8683.928121]   lock(_xmit_ETHER#2);
[ 8683.928121]                                lock(slock-AF_INET);
[ 8683.928121]                                lock(_xmit_ETHER#2);
[ 8683.928121]   lock(slock-AF_INET);
[ 8683.928121]
[ 8683.928121]  *** DEADLOCK ***
[ 8683.928121]
[ 8683.928121] 3 locks held by swapper/0/0:
[ 8683.928121]  #0:  (rcu_read_lock){.+.+..}, at: []
rcu_lock_acquire+0x0/0x30
[ 8683.928121]  #1:  (rcu_read_lock_bh){.+....}, at: []
rcu_lock_acquire+0x0/0x30
[ 8683.928121]  #2:  (_xmit_ETHER#2){+.-...}, at: []
sch_direct_xmit+0x36/0x119
[ 8683.928121]
[ 8683.928121] stack backtrace:
[ 8683.928121] Pid: 0, comm: swapper/0 Not tainted 3.4.1-build-0061 #14
[ 8683.928121] Call Trace:
[ 8683.928121]  [] ? printk+0x18/0x1a
[ 8683.928121]  [] print_circular_bug+0x1ac/0x1b6
[ 8683.928121]  [] __lock_acquire+0x9a3/0xc27
[ 8683.928121]  [] lock_acquire+0x71/0x85
[ 8683.928121]  [] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
[ 8683.928121]  [] _raw_spin_lock+0x33/0x40
[ 8683.928121]  [] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
[ 8683.928121]  [] l2tp_xmit_skb+0x173/0x47e [l2tp_core]
[ 8683.928121]  [] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth]
[ 8683.928121]  [] dev_hard_start_xmit+0x333/0x3f2
[ 8683.928121]  [] sch_direct_xmit+0x55/0x119
[ 8683.928121]  [] dev_queue_xmit+0x282/0x418
[ 8683.928121]  [] ? dev_hard_start_xmit+0x3f2/0x3f2
[ 8683.928121]  [] NF_HOOK.clone.19+0x45/0x4c
[ 8683.928121]  [] arp_xmit+0x22/0x24
[ 8683.928121]  [] ? dev_hard_start_xmit+0x3f2/0x3f2
[ 8683.928121]  [] arp_send+0x41/0x48
[ 8683.928121]  [] arp_process+0x289/0x491
[ 8683.928121]  [] ? __neigh_lookup.clone.20+0x42/0x42
[ 8683.928121]  [] NF_HOOK.clone.19+0x45/0x4c
[ 8683.928121]  [] arp_rcv+0xb1/0xc3
[ 8683.928121]  [] ? __neigh_lookup.clone.20+0x42/0x42
[ 8683.928121]  [] __netif_receive_skb+0x329/0x378
[ 8683.928121]  [] process_backlog+0x69/0x130
[ 8683.928121]  [] net_rx_action+0x90/0x15d
[ 8683.928121]  [] __do_softirq+0x7b/0x118
[ 8683.928121]  [] ? local_bh_enable+0xd/0xd
[ 8683.928121]    [] ? irq_exit+0x41/0x91
[ 8683.928121]  [] ? do_IRQ+0x79/0x8d
[ 8683.928121]  [] ? trace_hardirqs_off_caller+0x2e/0x86
[ 8683.928121]  [] ? common_interrupt+0x2e/0x34
[ 8683.928121]  [] ? default_idle+0x23/0x38
[ 8683.928121]  [] ? cpu_idle+0x55/0x6f
[ 8683.928121]  [] ? rest_init+0xa1/0xa7
[ 8683.928121]  [] ? __read_lock_failed+0x14/0x14
[ 8683.928121]  [] ? start_kernel+0x303/0x30a
[ 8683.928121]  [] ? repair_env_string+0x51/0x51
[ 8683.928121]  [] ? i386_start_kernel+0xa8/0xaf

It appears that like most virtual devices, l2tp should be converted to
LLTX mode.

This patch takes care of statistics using atomic_long in both RX and TX
paths, and fix a bug in l2tp_eth_dev_recv(), which was caching skb->data
before a pskb_may_pull() call.

Signed-off-by: Eric Dumazet 
Reported-by: Denys Fedoryshchenko 
Cc: James Chapman 
Cc: Hong zhi guo 
Cc: Francois Romieu 
Signed-off-by: David S. Miller

net: l2tp_eth: fix l2tp_eth_dev_xmit race

2012-06-25T23:30:54+00:00

Its illegal to dereference skb after giving it to l2tp_xmit_skb()
as it might be already freed/reused.

Signed-off-by: Eric Dumazet 
Cc: James Chapman 
Signed-off-by: David S. Miller

l2tp: fix a race in l2tp_ip_sendmsg()

2012-06-08T21:30:51+00:00

Commit 081b1b1bb27f (l2tp: fix l2tp_ip_sendmsg() route handling) added
a race, in case IP route cache is disabled.

In this case, we should not do the dst_release(&rt->dst), since it'll
free the dst immediately, instead of waiting a RCU grace period.

Signed-off-by: Eric Dumazet 
Cc: James Chapman 
Cc: Denys Fedoryshchenko 
Signed-off-by: David S. Miller

net: l2tp_eth: fix kernel panic on rmmod l2tp_eth

2012-06-07T20:02:20+00:00

We must prevent module unloading if some devices are still attached to
l2tp_eth driver.

Signed-off-by: Eric Dumazet 
Reported-by: Denys Fedoryshchenko 
Tested-by: Denys Fedoryshchenko 
Cc: James Chapman 
Signed-off-by: David S. Miller

genetlink: Build a generic netlink family module alias

2012-05-30T02:33:56+00:00

Generic netlink searches for -type- formatted aliases when requesting a module to
fulfill a protocol request (i.e. net-pf-16-proto-16-type-, where x is a type
value).  However generic netlink protocols have no well defined type numbers,
they have string names.  Modify genl_ctrl_getfamily to request an alias in the
format net-pf-16-proto-16-family- instead, where x is a generic string, and
add a macro that builds on the previously added MODULE_ALIAS_NET_PF_PROTO_NAME
macro to allow modules to specifify those generic strings.

Note, l2tp previously hacked together an net-pf-16-proto-16-type-l2tp alias
using the MODULE_ALIAS macro, with these updates we can convert that to use the
PROTO_NAME macro.

Signed-off-by: Neil Horman 
CC: Eric Dumazet 
CC: James Chapman 
CC: David Miller 
Signed-off-by: David S. Miller

l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case

2012-05-29T21:19:44+00:00

An application may call connect() to disconnect a socket using an
address with family AF_UNSPEC. The L2TP IP sockets were not handling
this case when the socket is not bound and an attempt to connect()
using AF_UNSPEC in such cases would result in an oops. This patch
addresses the problem by protecting the sk_prot->disconnect() call
against trying to unhash the socket before it is bound.

The L2TP IPv4 and IPv6 sockets have the same problem. Both are fixed
by this patch.

The patch also adds more checks that the sockaddr supplied to bind()
and connect() calls is valid.

 RIP: 0010:[]  [] inet_unhash+0x50/0xd0
 RSP: 0018:ffff88001989be28  EFLAGS: 00010293
 Stack:
  ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
  ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
  0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
 Call Trace:
 [] udp_disconnect+0x1f9/0x290
 [] inet_dgram_connect+0x29/0x80
 [] sys_connect+0x9c/0x100

Reported-by: Sasha Levin 
Signed-off-by: James Chapman 
Signed-off-by: David S. Miller

net: l2tp: Standardize logging styles

2012-05-17T08:34:38+00:00

Use more current logging styles.

Add pr_fmt to prefix output appropriately.
Convert printks to pr_.
Convert PRINTK macros to new l2tp_ macros.
Neaten some _refcount debugging macros.
Use print_hex_dump_bytes instead of hand-coded loops.
Coalesce formats and align arguments.

Some KERN_DEBUG output is not now emitted unless
dynamic_debugging is enabled.

Signed-off-by: Joe Perches 
Signed-off-by: James Chapman 
Signed-off-by: David S. Miller

l2tp: fix data packet sequence number handling

2012-05-11T03:27:34+00:00

If enabled, L2TP data packets have sequence numbers which a receiver
can use to drop out of sequence frames or try to reorder them. The
first frame has sequence number 0, but the L2TP code currently expects
it to be 1. This results in the first data frame being handled as out
of sequence.

This one-line patch fixes the problem.

Signed-off-by: James Chapman 
Signed-off-by: David S. Miller

l2tp: fix reorder timeout recovery

2012-05-11T03:27:34+00:00

When L2TP data packet reordering is enabled, packets are held in a
queue while waiting for out-of-sequence packets. If a packet gets
lost, packets will be held until the reorder timeout expires, when we
are supposed to then advance to the sequence number of the next packet
but we don't currently do so. As a result, the data channel is stuck
because we are waiting for a packet that will never arrive - all
packets age out and none are passed.

The fix is to add a flag to the session context, which is set when the
reorder timeout expires and tells the receive code to reset the next
expected sequence number to that of the next packet in the queue.

Tested in a production L2TP network with Starent and Nortel L2TP gear.

Signed-off-by: James Chapman 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2012-05-08T03:35:40+00:00

Conflicts:
	drivers/net/ethernet/intel/e1000e/param.c
	drivers/net/wireless/iwlwifi/iwl-agn-rx.c
	drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
	drivers/net/wireless/iwlwifi/iwl-trans.h

Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell.  In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.

In e1000e a conflict arose in the validation code for settings of
adapter->itr.  'net-next' had more sophisticated logic so that
logic was used.

Signed-off-by: David S. Miller