1. 03 Nov, 2012 1 commit
    • Tom Parkin's avatar
      l2tp: fix oops in l2tp_eth_create() error path · 78933636
      Tom Parkin authored
      
      
      When creating an L2TPv3 Ethernet session, if register_netdev() should fail for
      any reason (for example, automatic naming for "l2tpeth%d" interfaces hits the
      32k-interface limit), the netdev is freed in the error path.  However, the
      l2tp_eth_sess structure's dev pointer is left uncleared, and this results in
      l2tp_eth_delete() then attempting to unregister the same netdev later in the
      session teardown.  This results in an oops.
      
      To avoid this, clear the session dev pointer in the error path.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78933636
  2. 05 Sep, 2012 1 commit
    • Eric Dumazet's avatar
      net: qdisc busylock needs lockdep annotations · 23d3b8bf
      Eric Dumazet authored
      
      
      It seems we need to provide ability for stacked devices
      to use specific lock_class_key for sch->busylock
      
      We could instead default l2tpeth tx_queue_len to 0 (no qdisc), but
      a user might use a qdisc anyway.
      
      (So same fixes are probably needed on non LLTX stacked drivers)
      
      Noticed while stressing L2TPV3 setup :
      
      ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.6.0-rc3+ #788 Not tainted
       -------------------------------------------------------
       netperf/4660 is trying to acquire lock:
        (l2tpsock){+.-...}, at: [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      
       but task is already holding lock:
        (&(&sch->busylock)->rlock){+.-...}, at: [<ffffffff81596595>] dev_queue_xmit+0xd75/0xe00
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&(&sch->busylock)->rlock){+.-...}:
              [<ffffffff810a5df0>] lock_acquire+0x90/0x200
              [<ffffffff817499fc>] _raw_spin_lock_irqsave+0x4c/0x60
              [<ffffffff81074872>] __wake_up+0x32/0x70
              [<ffffffff8136d39e>] tty_wakeup+0x3e/0x80
              [<ffffffff81378fb3>] pty_write+0x73/0x80
              [<ffffffff8136cb4c>] tty_put_char+0x3c/0x40
              [<ffffffff813722b2>] process_echoes+0x142/0x330
              [<ffffffff813742ab>] n_tty_receive_buf+0x8fb/0x1230
              [<ffffffff813777b2>] flush_to_ldisc+0x142/0x1c0
              [<ffffffff81062818>] process_one_work+0x198/0x760
              [<ffffffff81063236>] worker_thread+0x186/0x4b0
              [<ffffffff810694d3>] kthread+0x93/0xa0
              [<ffffffff81753e24>] kernel_thread_helper+0x4/0x10
      
       -> #0 (l2tpsock){+.-...}:
              [<ffffffff810a5288>] __lock_acquire+0x1628/0x1b10
              [<ffffffff810a5df0>] lock_acquire+0x90/0x200
              [<ffffffff817498c1>] _raw_spin_lock+0x41/0x50
              [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
              [<ffffffffa021a802>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
              [<ffffffff815952b2>] dev_hard_start_xmit+0x502/0xa70
              [<ffffffff815b63ce>] sch_direct_xmit+0xfe/0x290
              [<ffffffff81595a05>] dev_queue_xmit+0x1e5/0xe00
              [<ffffffff815d9d60>] ip_finish_output+0x3d0/0x890
              [<ffffffff815db019>] ip_output+0x59/0xf0
              [<ffffffff815da36d>] ip_local_out+0x2d/0xa0
              [<ffffffff815da5a3>] ip_queue_xmit+0x1c3/0x680
              [<ffffffff815f4192>] tcp_transmit_skb+0x402/0xa60
              [<ffffffff815f4a94>] tcp_write_xmit+0x1f4/0xa30
              [<ffffffff815f5300>] tcp_push_one+0x30/0x40
              [<ffffffff815e6672>] tcp_sendmsg+0xe82/0x1040
              [<ffffffff81614495>] inet_sendmsg+0x125/0x230
              [<ffffffff81576cdc>] sock_sendmsg+0xdc/0xf0
              [<ffffffff81579ece>] sys_sendto+0xfe/0x130
              [<ffffffff81752c92>] system_call_fastpath+0x16/0x1b
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&(&sch->busylock)->rlock);
                                      lock(l2tpsock);
                                      lock(&(&sch->busylock)->rlock);
         lock(l2tpsock);
      
        *** DEADLOCK ***
      
       5 locks held by netperf/4660:
        #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff815e581c>] tcp_sendmsg+0x2c/0x1040
        #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff815da3e0>] ip_queue_xmit+0x0/0x680
        #2:  (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9ac5>] ip_finish_output+0x135/0x890
        #3:  (rcu_read_lock_bh){.+....}, at: [<ffffffff81595820>] dev_queue_xmit+0x0/0xe00
        #4:  (&(&sch->busylock)->rlock){+.-...}, at: [<ffffffff81596595>] dev_queue_xmit+0xd75/0xe00
      
       stack backtrace:
       Pid: 4660, comm: netperf Not tainted 3.6.0-rc3+ #788
       Call Trace:
        [<ffffffff8173dbf8>] print_circular_bug+0x1fb/0x20c
        [<ffffffff810a5288>] __lock_acquire+0x1628/0x1b10
        [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0
        [<ffffffff810a3f44>] ? __lock_acquire+0x2e4/0x1b10
        [<ffffffff810a5df0>] lock_acquire+0x90/0x200
        [<ffffffffa0208db2>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffff817498c1>] _raw_spin_lock+0x41/0x50
        [<ffffffffa0208db2>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffffa0208db2>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
        [<ffffffffa021a802>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
        [<ffffffff815952b2>] dev_hard_start_xmit+0x502/0xa70
        [<ffffffff81594e0e>] ? dev_hard_start_xmit+0x5e/0xa70
        [<ffffffff81595961>] ? dev_queue_xmit+0x141/0xe00
        [<ffffffff815b63ce>] sch_direct_xmit+0xfe/0x290
        [<ffffffff81595a05>] dev_queue_xmit+0x1e5/0xe00
        [<ffffffff81595820>] ? dev_hard_start_xmit+0xa70/0xa70
        [<ffffffff815d9d60>] ip_finish_output+0x3d0/0x890
        [<ffffffff815d9ac5>] ? ip_finish_output+0x135/0x890
        [<ffffffff815db019>] ip_output+0x59/0xf0
        [<ffffffff815da36d>] ip_local_out+0x2d/0xa0
        [<ffffffff815da5a3>] ip_queue_xmit+0x1c3/0x680
        [<ffffffff815da3e0>] ? ip_local_out+0xa0/0xa0
        [<ffffffff815f4192>] tcp_transmit_skb+0x402/0xa60
        [<ffffffff815fa25e>] ? tcp_md5_do_lookup+0x18e/0x1a0
        [<ffffffff815f4a94>] tcp_write_xmit+0x1f4/0xa30
        [<ffffffff815f5300>] tcp_push_one+0x30/0x40
        [<ffffffff815e6672>] tcp_sendmsg+0xe82/0x1040
        [<ffffffff81614495>] inet_sendmsg+0x125/0x230
        [<ffffffff81614370>] ? inet_create+0x6b0/0x6b0
        [<ffffffff8157e6e2>] ? sock_update_classid+0xc2/0x3b0
        [<ffffffff8157e750>] ? sock_update_classid+0x130/0x3b0
        [<ffffffff81576cdc>] sock_sendmsg+0xdc/0xf0
        [<ffffffff81162579>] ? fget_light+0x3f9/0x4f0
        [<ffffffff81579ece>] sys_sendto+0xfe/0x130
        [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10
        [<ffffffff8174a0b0>] ? _raw_spin_unlock_irq+0x30/0x50
        [<ffffffff810757e3>] ? finish_task_switch+0x83/0xf0
        [<ffffffff810757a6>] ? finish_task_switch+0x46/0xf0
        [<ffffffff81752cb7>] ? sysret_check+0x1b/0x56
        [<ffffffff81752c92>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23d3b8bf
  3. 04 Sep, 2012 1 commit
  4. 29 Jun, 2012 1 commit
  5. 26 Jun, 2012 1 commit
    • Eric Dumazet's avatar
      net: l2tp_eth: use LLTX to avoid LOCKDEP splats · a2842a1e
      Eric Dumazet authored
      
      
      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: [<e0fc73ec>]
      l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]
      [ 8683.928121] but task is already holding lock:
      [ 8683.928121]  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      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]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<c0304e0c>] ip_send_reply+0xf2/0x1ce
      [ 8683.928121]        [<c0317dbc>] tcp_v4_send_reset+0x153/0x16f
      [ 8683.928121]        [<c0317f4a>] tcp_v4_do_rcv+0x172/0x194
      [ 8683.928121]        [<c031929b>] tcp_v4_rcv+0x387/0x5a0
      [ 8683.928121]        [<c03001d0>] ip_local_deliver_finish+0x13a/0x1e9
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c030075b>] ip_local_deliver+0x41/0x45
      [ 8683.928121]        [<c03005dd>] ip_rcv_finish+0x31a/0x33c
      [ 8683.928121]        [<c0300645>] NF_HOOK.clone.11+0x46/0x4d
      [ 8683.928121]        [<c0300960>] ip_rcv+0x201/0x23d
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02deae8>] netif_receive_skb+0x4e/0x7d
      [ 8683.928121]        [<e08d5ef3>] rtl8139_poll+0x243/0x33d [8139too]
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]
      [ 8683.928121] -> #0 (slock-AF_INET){+.-...}:
      [ 8683.928121]        [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]        [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]        [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]        [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e
      [l2tp_core]
      [ 8683.928121]        [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f
      [l2tp_eth]
      [ 8683.928121]        [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]        [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]        [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]        [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]        [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]        [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]        [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]        [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]        [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]        [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]        [<c012b2b5>] __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: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #1:  (rcu_read_lock_bh){.+....}, at: [<c02dbc10>]
      rcu_lock_acquire+0x0/0x30
      [ 8683.928121]  #2:  (_xmit_ETHER#2){+.-...}, at: [<c02f062d>]
      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]  [<c034bdd2>] ? printk+0x18/0x1a
      [ 8683.928121]  [<c0158904>] print_circular_bug+0x1ac/0x1b6
      [ 8683.928121]  [<c0159f1b>] __lock_acquire+0x9a3/0xc27
      [ 8683.928121]  [<c015a561>] lock_acquire+0x71/0x85
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<c034da2d>] _raw_spin_lock+0x33/0x40
      [ 8683.928121]  [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core]
      [ 8683.928121]  [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth]
      [ 8683.928121]  [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2
      [ 8683.928121]  [<c02f064c>] sch_direct_xmit+0x55/0x119
      [ 8683.928121]  [<c02e0528>] dev_queue_xmit+0x282/0x418
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f524>] arp_xmit+0x22/0x24
      [ 8683.928121]  [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2
      [ 8683.928121]  [<c031f567>] arp_send+0x41/0x48
      [ 8683.928121]  [<c031fa7d>] arp_process+0x289/0x491
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c
      [ 8683.928121]  [<c031f7a0>] arp_rcv+0xb1/0xc3
      [ 8683.928121]  [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42
      [ 8683.928121]  [<c02de91b>] __netif_receive_skb+0x329/0x378
      [ 8683.928121]  [<c02de9d3>] process_backlog+0x69/0x130
      [ 8683.928121]  [<c02df103>] net_rx_action+0x90/0x15d
      [ 8683.928121]  [<c012b2b5>] __do_softirq+0x7b/0x118
      [ 8683.928121]  [<c012b23a>] ? local_bh_enable+0xd/0xd
      [ 8683.928121]  <IRQ>  [<c012b4d0>] ? irq_exit+0x41/0x91
      [ 8683.928121]  [<c0103c6f>] ? do_IRQ+0x79/0x8d
      [ 8683.928121]  [<c0157ea1>] ? trace_hardirqs_off_caller+0x2e/0x86
      [ 8683.928121]  [<c034ef6e>] ? common_interrupt+0x2e/0x34
      [ 8683.928121]  [<c0108a33>] ? default_idle+0x23/0x38
      [ 8683.928121]  [<c01091a8>] ? cpu_idle+0x55/0x6f
      [ 8683.928121]  [<c033df25>] ? rest_init+0xa1/0xa7
      [ 8683.928121]  [<c033de84>] ? __read_lock_failed+0x14/0x14
      [ 8683.928121]  [<c0498745>] ? start_kernel+0x303/0x30a
      [ 8683.928121]  [<c0498209>] ? repair_env_string+0x51/0x51
      [ 8683.928121]  [<c04980a8>] ? 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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDenys Fedoryshchenko <denys@visp.net.lb>
      Cc: James Chapman <jchapman@katalix.com>
      Cc: Hong zhi guo <honkiko@gmail.com>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2842a1e
  6. 25 Jun, 2012 1 commit
  7. 07 Jun, 2012 1 commit
  8. 17 May, 2012 1 commit
  9. 15 Feb, 2012 1 commit
  10. 28 Jul, 2011 1 commit
    • Neil Horman's avatar
      net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared · 550fd08c
      Neil Horman authored
      
      
      After the last patch, We are left in a state in which only drivers calling
      ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
      hardware call ether_setup for their net_devices and don't hold any state in
      their skbs.  There are a handful of drivers that violate this assumption of
      course, and need to be fixed up.  This patch identifies those drivers, and marks
      them as not being able to support the safe transmission of skbs by clearning the
      IFF_TX_SKB_SHARING flag in priv_flags
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Karsten Keil <isdn@linux-pingi.de>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Krzysztof Halasa <khc@pm.waw.pl>
      CC: "John W. Linville" <linville@tuxdriver.com>
      CC: Greg Kroah-Hartman <gregkh@suse.de>
      CC: Marcel Holtmann <marcel@holtmann.org>
      CC: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      550fd08c
  11. 22 Mar, 2011 1 commit
    • James Chapman's avatar
      l2tp: fix possible oops on l2tp_eth module unload · 8aa525a9
      James Chapman authored
      
      
      A struct used in the l2tp_eth driver for registering network namespace
      ops was incorrectly marked as __net_initdata, leading to oops when
      module unloaded.
      
      BUG: unable to handle kernel paging request at ffffffffa00ec098
      IP: [<ffffffff8123dbd8>] ops_exit_list+0x7/0x4b
      PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0
      Oops: 0000 [#1] SMP 
      last sysfs file: /sys/module/l2tp_eth/refcnt
      Call Trace:
       [<ffffffff8123dc94>] ? unregister_pernet_operations+0x32/0x93
       [<ffffffff8123dd20>] ? unregister_pernet_device+0x2b/0x38
       [<ffffffff81068b6e>] ? sys_delete_module+0x1b8/0x222
       [<ffffffff810c7300>] ? do_munmap+0x254/0x318
       [<ffffffff812c64e5>] ? page_fault+0x25/0x30
       [<ffffffff812c6952>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8aa525a9
  12. 02 Sep, 2010 1 commit
  13. 26 Aug, 2010 1 commit
  14. 23 Apr, 2010 1 commit
  15. 03 Apr, 2010 3 commits
    • David S. Miller's avatar
      l2tp: Fix L2TP_DEBUGFS ifdef tests. · f66ef2d0
      David S. Miller authored
      
      
      We have to check CONFIG_L2TP_DEBUGFS_MODULE as well as
      CONFIG_L2TP_DEBUGFS.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f66ef2d0
    • James Chapman's avatar
      l2tp: Add debugfs files for dumping l2tp debug info · 0ad66140
      James Chapman authored
      
      
      The existing pppol2tp driver exports debug info to
      /proc/net/pppol2tp. Rather than adding info to that file for the new
      functionality added in this patch series, we add new files in debugfs,
      leaving the old /proc file for backwards compatibility (L2TPv2 only).
      
      Currently only one file is provided: l2tp/tunnels, which lists
      internal debug info for all l2tp tunnels and sessions. More files may
      be added later. The info is for debug and problem analysis only -
      userspace apps should use netlink to obtain status about l2tp tunnels
      and sessions.
      
      Although debugfs does not support net namespaces, the tunnels and
      sessions dumped in l2tp/tunnels are only those in the net namespace of
      the process reading the file.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ad66140
    • James Chapman's avatar
      l2tp: Add L2TP ethernet pseudowire support · d9e31d17
      James Chapman authored
      
      
      This driver presents a regular net_device for each L2TP ethernet
      pseudowire instance. These interfaces are named l2tpethN by default,
      though userspace can specify an alternative name when the L2TP
      session is created, if preferred. When the pseudowire is established,
      regular Linux networking utilities may be used to configure the
      interface, i.e. give it IP address info or add it to a bridge. Any
      data passed over the interface is carried over an L2TP tunnel.
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Reviewed-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9e31d17