linux/drivers/net/ppp, branch v4.9

ppp: declare PPP devices as LLTX

2016-08-31T21:33:09Z

ppp_xmit_process() already locks the xmit path. If HARD_TX_LOCK() tries to hold the _xmit_lock we can get lock inversion. [ 973.726130] ====================================================== [ 973.727311] [ INFO: possible circular locking dependency detected ] [ 973.728546] 4.8.0-rc2 #1 Tainted: G O [ 973.728986] ------------------------------------------------------- [ 973.728986] accel-pppd/1806 is trying to acquire lock: [ 973.728986] (&qdisc_xmit_lock_key){+.-...}, at: [] sch_direct_xmit+0x8d/0x221 [ 973.728986] [ 973.728986] but task is already holding lock: [ 973.728986] (l2tp_sock){+.-...}, at: [] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core] [ 973.728986] [ 973.728986] which lock already depends on the new lock. [ 973.728986] [ 973.728986] [ 973.728986] the existing dependency chain (in reverse order) is: [ 973.728986] -> #3 (l2tp_sock){+.-...}: [ 973.728986] [] lock_acquire+0x150/0x217 [ 973.728986] [] _raw_spin_lock+0x2d/0x3c [ 973.728986] [] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core] [ 973.728986] [] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp] [ 973.728986] [] ppp_channel_push+0xb5/0x14a [ppp_generic] [ 973.728986] [] ppp_write+0x104/0x11c [ppp_generic] [ 973.728986] [] __vfs_write+0x56/0x120 [ 973.728986] [] vfs_write+0xbd/0x11b [ 973.728986] [] SyS_write+0x5e/0x96 [ 973.728986] [] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 973.728986] -> #2 (&(&pch->downl)->rlock){+.-...}: [ 973.728986] [] lock_acquire+0x150/0x217 [ 973.728986] [] _raw_spin_lock_bh+0x31/0x40 [ 973.728986] [] ppp_push+0xa7/0x82d [ppp_generic] [ 973.728986] [] __ppp_xmit_process+0x48/0x877 [ppp_generic] [ 973.728986] [] ppp_xmit_process+0x4b/0xaf [ppp_generic] [ 973.728986] [] ppp_write+0x10e/0x11c [ppp_generic] [ 973.728986] [] __vfs_write+0x56/0x120 [ 973.728986] [] vfs_write+0xbd/0x11b [ 973.728986] [] SyS_write+0x5e/0x96 [ 973.728986] [] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 973.728986] -> #1 (&(&ppp->wlock)->rlock){+.-...}: [ 973.728986] [] lock_acquire+0x150/0x217 [ 973.728986] [] _raw_spin_lock_bh+0x31/0x40 [ 973.728986] [] __ppp_xmit_process+0x27/0x877 [ppp_generic] [ 973.728986] [] ppp_xmit_process+0x4b/0xaf [ppp_generic] [ 973.728986] [] ppp_start_xmit+0x21b/0x22a [ppp_generic] [ 973.728986] [] dev_hard_start_xmit+0x1a9/0x43d [ 973.728986] [] sch_direct_xmit+0xd6/0x221 [ 973.728986] [] __dev_queue_xmit+0x62a/0x912 [ 973.728986] [] dev_queue_xmit+0xb/0xd [ 973.728986] [] neigh_direct_output+0xc/0xe [ 973.728986] [] ip6_finish_output2+0x5a9/0x623 [ 973.728986] [] ip6_output+0x15e/0x16a [ 973.728986] [] dst_output+0x76/0x7f [ 973.728986] [] mld_sendpack+0x335/0x404 [ 973.728986] [] mld_send_initial_cr.part.21+0x99/0xa2 [ 973.728986] [] ipv6_mc_dad_complete+0x42/0x71 [ 973.728986] [] addrconf_dad_completed+0x1cf/0x2ea [ 973.728986] [] addrconf_dad_work+0x453/0x520 [ 973.728986] [] process_one_work+0x365/0x6f0 [ 973.728986] [] worker_thread+0x2de/0x421 [ 973.728986] [] kthread+0x121/0x130 [ 973.728986] [] ret_from_fork+0x1f/0x40 [ 973.728986] -> #0 (&qdisc_xmit_lock_key){+.-...}: [ 973.728986] [] __lock_acquire+0x1118/0x1483 [ 973.728986] [] lock_acquire+0x150/0x217 [ 973.728986] [] _raw_spin_lock+0x2d/0x3c [ 973.728986] [] sch_direct_xmit+0x8d/0x221 [ 973.728986] [] __dev_queue_xmit+0x62a/0x912 [ 973.728986] [] dev_queue_xmit+0xb/0xd [ 973.728986] [] neigh_direct_output+0xc/0xe [ 973.728986] [] ip_finish_output2+0x5db/0x609 [ 973.728986] [] ip_finish_output+0x152/0x15e [ 973.728986] [] ip_output+0x8c/0x96 [ 973.728986] [] ip_local_out+0x41/0x4a [ 973.728986] [] ip_queue_xmit+0x5a5/0x609 [ 973.728986] [] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core] [ 973.728986] [] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp] [ 973.728986] [] ppp_channel_push+0xb5/0x14a [ppp_generic] [ 973.728986] [] ppp_write+0x104/0x11c [ppp_generic] [ 973.728986] [] __vfs_write+0x56/0x120 [ 973.728986] [] vfs_write+0xbd/0x11b [ 973.728986] [] SyS_write+0x5e/0x96 [ 973.728986] [] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 973.728986] [ 973.728986] other info that might help us debug this: [ 973.728986] [ 973.728986] Chain exists of: &qdisc_xmit_lock_key --> &(&pch->downl)->rlock --> l2tp_sock [ 973.728986] Possible unsafe locking scenario: [ 973.728986] [ 973.728986] CPU0 CPU1 [ 973.728986] ---- ---- [ 973.728986] lock(l2tp_sock); [ 973.728986] lock(&(&pch->downl)->rlock); [ 973.728986] lock(l2tp_sock); [ 973.728986] lock(&qdisc_xmit_lock_key); [ 973.728986] [ 973.728986] *** DEADLOCK *** [ 973.728986] [ 973.728986] 6 locks held by accel-pppd/1806: [ 973.728986] #0: (&(&pch->downl)->rlock){+.-...}, at: [] ppp_channel_push+0x56/0x14a [ppp_generic] [ 973.728986] #1: (l2tp_sock){+.-...}, at: [] l2tp_xmit_skb+0x1e8/0x5d7 [l2tp_core] [ 973.728986] #2: (rcu_read_lock){......}, at: [] rcu_lock_acquire+0x0/0x20 [ 973.728986] #3: (rcu_read_lock_bh){......}, at: [] rcu_lock_acquire+0x0/0x20 [ 973.728986] #4: (rcu_read_lock_bh){......}, at: [] rcu_lock_acquire+0x0/0x20 [ 973.728986] #5: (dev->qdisc_running_key ?: &qdisc_running_key#2){+.....}, at: [] __dev_queue_xmit+0x564/0x912 [ 973.728986] [ 973.728986] stack backtrace: [ 973.728986] CPU: 2 PID: 1806 Comm: accel-pppd Tainted: G O 4.8.0-rc2 #1 [ 973.728986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 973.728986] ffff7fffffffffff ffff88003436f850 ffffffff812a20f4 ffffffff82156e30 [ 973.728986] ffffffff82156920 ffff88003436f890 ffffffff8115c759 ffff88003344ae00 [ 973.728986] ffff88003344b5c0 0000000000000002 0000000000000006 ffff88003344b5e8 [ 973.728986] Call Trace: [ 973.728986] [] dump_stack+0x67/0x90 [ 973.728986] [] print_circular_bug+0x22e/0x23c [ 973.728986] [] __lock_acquire+0x1118/0x1483 [ 973.728986] [] lock_acquire+0x150/0x217 [ 973.728986] [] ? lock_acquire+0x150/0x217 [ 973.728986] [] ? sch_direct_xmit+0x8d/0x221 [ 973.728986] [] _raw_spin_lock+0x2d/0x3c [ 973.728986] [] ? sch_direct_xmit+0x8d/0x221 [ 973.728986] [] sch_direct_xmit+0x8d/0x221 [ 973.728986] [] __dev_queue_xmit+0x62a/0x912 [ 973.728986] [] dev_queue_xmit+0xb/0xd [ 973.728986] [] neigh_direct_output+0xc/0xe [ 973.728986] [] ip_finish_output2+0x5db/0x609 [ 973.728986] [] ? dst_mtu+0x29/0x2e [ 973.728986] [] ip_finish_output+0x152/0x15e [ 973.728986] [] ? ip_output+0x74/0x96 [ 973.728986] [] ip_output+0x8c/0x96 [ 973.728986] [] ip_local_out+0x41/0x4a [ 973.728986] [] ip_queue_xmit+0x5a5/0x609 [ 973.728986] [] ? udp_set_csum+0x207/0x21e [ 973.728986] [] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core] [ 973.728986] [] pppol2tp_xmit+0x1f2/0x25e [l2tp_ppp] [ 973.728986] [] ppp_channel_push+0xb5/0x14a [ppp_generic] [ 973.728986] [] ppp_write+0x104/0x11c [ppp_generic] [ 973.728986] [] __vfs_write+0x56/0x120 [ 973.728986] [] ? fsnotify_perm+0x27/0x95 [ 973.728986] [] ? security_file_permission+0x4d/0x54 [ 973.728986] [] vfs_write+0xbd/0x11b [ 973.728986] [] SyS_write+0x5e/0x96 [ 973.728986] [] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 973.728986] [] ? trace_hardirqs_off_caller+0x121/0x12f Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller

ppp: avoid dealock on recursive xmit

2016-08-31T21:33:08Z

In case of misconfiguration, a virtual PPP channel might send packets back to their parent PPP interface. This typically happens in misconfigured L2TP setups, where PPP's peer IP address is set with the IP of the L2TP peer. When that happens the system hangs due to PPP trying to recursively lock its xmit path. [ 243.332155] BUG: spinlock recursion on CPU#1, accel-pppd/926 [ 243.333272] lock: 0xffff880033d90f18, .magic: dead4ead, .owner: accel-pppd/926, .owner_cpu: 1 [ 243.334859] CPU: 1 PID: 926 Comm: accel-pppd Not tainted 4.8.0-rc2 #1 [ 243.336010] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 243.336018] ffff7fffffffffff ffff8800319a77a0 ffffffff8128de85 ffff880033d90f18 [ 243.336018] ffff880033ad8000 ffff8800319a77d8 ffffffff810ad7c0 ffffffff0000039e [ 243.336018] ffff880033d90f18 ffff880033d90f60 ffff880033d90f18 ffff880033d90f28 [ 243.336018] Call Trace: [ 243.336018] [] dump_stack+0x4f/0x65 [ 243.336018] [] spin_dump+0xe1/0xeb [ 243.336018] [] spin_bug+0x26/0x28 [ 243.336018] [] do_raw_spin_lock+0x5c/0x160 [ 243.336018] [] _raw_spin_lock_bh+0x35/0x3c [ 243.336018] [] ? ppp_push+0xa7/0x82d [ppp_generic] [ 243.336018] [] ppp_push+0xa7/0x82d [ppp_generic] [ 243.336018] [] ? do_raw_spin_unlock+0xc2/0xcc [ 243.336018] [] ? preempt_count_sub+0x13/0xc7 [ 243.336018] [] ? _raw_spin_unlock_irqrestore+0x34/0x49 [ 243.336018] [] ppp_xmit_process+0x48/0x877 [ppp_generic] [ 243.336018] [] ? preempt_count_sub+0x13/0xc7 [ 243.336018] [] ? skb_queue_tail+0x71/0x7c [ 243.336018] [] ppp_start_xmit+0x21b/0x22a [ppp_generic] [ 243.336018] [] dev_hard_start_xmit+0x15e/0x32c [ 243.336018] [] sch_direct_xmit+0xd6/0x221 [ 243.336018] [] __dev_queue_xmit+0x52a/0x820 [ 243.336018] [] dev_queue_xmit+0xb/0xd [ 243.336018] [] neigh_direct_output+0xc/0xe [ 243.336018] [] ip_finish_output2+0x4d2/0x548 [ 243.336018] [] ? dst_mtu+0x29/0x2e [ 243.336018] [] ip_finish_output+0x152/0x15e [ 243.336018] [] ? ip_output+0x74/0x96 [ 243.336018] [] ip_output+0x8c/0x96 [ 243.336018] [] ip_local_out+0x41/0x4a [ 243.336018] [] ip_queue_xmit+0x531/0x5c5 [ 243.336018] [] ? udp_set_csum+0x207/0x21e [ 243.336018] [] l2tp_xmit_skb+0x582/0x5d7 [l2tp_core] [ 243.336018] [] pppol2tp_xmit+0x1eb/0x257 [l2tp_ppp] [ 243.336018] [] ppp_channel_push+0x91/0x102 [ppp_generic] [ 243.336018] [] ppp_write+0x104/0x11c [ppp_generic] [ 243.336018] [] __vfs_write+0x56/0x120 [ 243.336018] [] ? fsnotify_perm+0x27/0x95 [ 243.336018] [] ? security_file_permission+0x4d/0x54 [ 243.336018] [] vfs_write+0xbd/0x11b [ 243.336018] [] SyS_write+0x5e/0x96 [ 243.336018] [] entry_SYSCALL_64_fastpath+0x13/0x94 The main entry points for sending packets over a PPP unit are the .write() and .ndo_start_xmit() callbacks (simplified view): .write(unit fd) or .ndo_start_xmit() \ CALL ppp_xmit_process() \ LOCK unit's xmit path (ppp->wlock) | CALL ppp_push() \ LOCK channel's xmit path (chan->downl) | CALL lower layer's .start_xmit() callback \ ... might recursively call .ndo_start_xmit() ... / RETURN from .start_xmit() | UNLOCK channel's xmit path / RETURN from ppp_push() | UNLOCK unit's xmit path / RETURN from ppp_xmit_process() Packets can also be directly sent on channels (e.g. LCP packets): .write(channel fd) or ppp_output_wakeup() \ CALL ppp_channel_push() \ LOCK channel's xmit path (chan->downl) | CALL lower layer's .start_xmit() callback \ ... might call .ndo_start_xmit() ... / RETURN from .start_xmit() | UNLOCK channel's xmit path / RETURN from ppp_channel_push() Key points about the lower layer's .start_xmit() callback: * It can be called directly by a channel fd .write() or by ppp_output_wakeup() or indirectly by a unit fd .write() or by .ndo_start_xmit(). * In any case, it's always called with chan->downl held. * It might route the packet back to its parent unit using .ndo_start_xmit() as entry point. This patch detects and breaks recursion in ppp_xmit_process(). This function is a good candidate for the task because it's called early enough after .ndo_start_xmit(), it's always part of the recursion loop and it's on the path of whatever entry point is used to send a packet on a PPP unit. Recursion detection is done using the per-cpu ppp_xmit_recursion variable. Since ppp_channel_push() too locks the channel's xmit path and calls the lower layer's .start_xmit() callback, we need to also increment ppp_xmit_recursion there. However there's no need to check for recursion, as it's out of the recursion loop. Reported-by: Feng Gao Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller

pptp: Refactor the struct and macros of PPTP codes

2016-08-15T17:55:53Z

1. Use struct gre_base_hdr directly in pptp_gre_header instead of duplicated members; 2. Use existing macros like GRE_KEY, GRE_SEQ, and so on instead of duplicated macros defined by PPTP; 3. Add new macros like GRE_IS_ACK/SEQ and so on instead of PPTP_GRE_IS_A/S and so on; Signed-off-by: Gao Feng Reviewed-by: Philip Prindeville Signed-off-by: David S. Miller

rps: Inspect PPTP encapsulated by GRE to get flow hash

2016-08-11T00:22:14Z

The PPTP is encapsulated by GRE header with that GRE_VERSION bits must contain one. But current GRE RPS needs the GRE_VERSION must be zero. So RPS does not work for PPTP traffic. In my test environment, there are four MIPS cores, and all traffic are passed through by PPTP. As a result, only one core is 100% busy while other three cores are very idle. After this patch, the usage of four cores are balanced well. Signed-off-by: Gao Feng Reviewed-by: Philip Prindeville Signed-off-by: David S. Miller

ppp: build ifname using unit identifier for rtnl based devices

2016-08-09T21:56:21Z

Userspace programs generally need to know the name of the ppp devices they create. Both ioctl and rtnl interfaces use the ppp sheme to name them. But although the suffix used by the ioctl interface can be known by userspace (it's the PPP unit identifier returned by the PPPIOCGUNIT ioctl), the one used by the rtnl is only known by the kernel. This patch brings more consistency between ioctl and rtnl based ppp devices by generating device names using the PPP unit identifer as suffix in both cases. This way, userspace can always infer the name of the devices they create. Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller

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

2016-07-24T04:53:32Z

Just several instances of overlapping changes. Signed-off-by: David S. Miller

ppp: defer netns reference release for ppp channel

2016-07-09T03:46:37Z

Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcdd296 ("ppp: take reference on channels netns") Reported-by: Matt Bennett Cc: Paul Mackerras Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault Cc: Cyrill Gorcunov Signed-off-by: Cong Wang Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller

net: add netdev_lockdep_set_classes() helper

2016-06-09T20:28:37Z

It is time to add netdev_lockdep_set_classes() helper so that lockdep annotations per device type are easier to manage. This removes a lot of copies and missing annotations. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller

net_sched: transform qdisc running bit into a seqcount

2016-06-07T23:37:13Z

Instead of using a single bit (__QDISC___STATE_RUNNING) in sch->__state, use a seqcount. This adds lockdep support, but more importantly it will allow us to sample qdisc/class statistics without having to grab qdisc root lock. Signed-off-by: Eric Dumazet Cc: Cong Wang Cc: Jamal Hadi Salim Signed-off-by: David S. Miller

ppp: add rtnetlink device creation support

2016-04-29T20:09:44Z

Define PPP device handler for use with rtnetlink. The only PPP specific attribute is IFLA_PPP_DEV_FD. It is mandatory and contains the file descriptor of the associated /dev/ppp instance (the file descriptor which would have been used for ioctl(PPPIOCNEWUNIT) in the ioctl-based API). The PPP device is removed when this file descriptor is released (same behaviour as with ioctl based PPP devices). PPP devices created with the rtnetlink API behave like the ones created with ioctl(PPPIOCNEWUNIT). In particular existing ioctls work the same way, no matter how the PPP device was created. The rtnl callbacks are also assigned to ioctl based PPP devices. This way, rtnl messages have the same effect on any PPP devices. The immediate effect is that all PPP devices, even ioctl-based ones, can now be removed with "ip link del". A minor difference still exists between ioctl and rtnl based PPP interfaces: in the device name, the number following the "ppp" prefix corresponds to the PPP unit number for ioctl based devices, while it is just an unrelated incrementing index for rtnl ones. Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller