1. 02 4月, 2018 1 次提交
  2. 16 6月, 2017 1 次提交
    • J
      networking: make skb_push & __skb_push return void pointers · d58ff351
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions return void * and remove all the casts across
      the tree, adding a (u8 *) cast only where the unsigned char pointer
      was used directly, all done with the following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
          @@
          expression SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - fn(SKB, LEN)[0]
          + *(u8 *)fn(SKB, LEN)
      
      Note that the last part there converts from push(...)[0] to the
      more idiomatic *(u8 *)push(...).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d58ff351
  3. 09 6月, 2017 1 次提交
  4. 08 6月, 2017 1 次提交
    • D
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller 提交于
      Network devices can allocate reasources and private memory using
      netdev_ops->ndo_init().  However, the release of these resources
      can occur in one of two different places.
      
      Either netdev_ops->ndo_uninit() or netdev->destructor().
      
      The decision of which operation frees the resources depends upon
      whether it is necessary for all netdev refs to be released before it
      is safe to perform the freeing.
      
      netdev_ops->ndo_uninit() presumably can occur right after the
      NETDEV_UNREGISTER notifier completes and the unicast and multicast
      address lists are flushed.
      
      netdev->destructor(), on the other hand, does not run until the
      netdev references all go away.
      
      Further complicating the situation is that netdev->destructor()
      almost universally does also a free_netdev().
      
      This creates a problem for the logic in register_netdevice().
      Because all callers of register_netdevice() manage the freeing
      of the netdev, and invoke free_netdev(dev) if register_netdevice()
      fails.
      
      If netdev_ops->ndo_init() succeeds, but something else fails inside
      of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
      it is not able to invoke netdev->destructor().
      
      This is because netdev->destructor() will do a free_netdev() and
      then the caller of register_netdevice() will do the same.
      
      However, this means that the resources that would normally be released
      by netdev->destructor() will not be.
      
      Over the years drivers have added local hacks to deal with this, by
      invoking their destructor parts by hand when register_netdevice()
      fails.
      
      Many drivers do not try to deal with this, and instead we have leaks.
      
      Let's close this hole by formalizing the distinction between what
      private things need to be freed up by netdev->destructor() and whether
      the driver needs unregister_netdevice() to perform the free_netdev().
      
      netdev->priv_destructor() performs all actions to free up the private
      resources that used to be freed by netdev->destructor(), except for
      free_netdev().
      
      netdev->needs_free_netdev is a boolean that indicates whether
      free_netdev() should be done at the end of unregister_netdevice().
      
      Now, register_netdevice() can sanely release all resources after
      ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
      and netdev->priv_destructor().
      
      And at the end of unregister_netdevice(), we invoke
      netdev->priv_destructor() and optionally call free_netdev().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf124db5
  5. 09 5月, 2017 1 次提交
    • V
      vlan: Keep NETIF_F_HW_CSUM similar to other software devices · 8403debe
      Vlad Yasevich 提交于
      Vlan devices, like all other software devices, enable
      NETIF_F_HW_CSUM feature.  However, unlike all the othe other
      software devices, vlans will switch to using IP|IPV6_CSUM
      features, if the underlying devices uses them.  In these situations,
      checksum offload features on the vlan device can't be controlled
      via ethtool.
      
      This patch makes vlans keep HW_CSUM feature if the underlying
      device supports checksum offloading.  This makes vlan devices
      behave like other software devices, and restores control to the
      user.
      
      A side-effect is that some offload settings (typically UFO)
      may be enabled on the vlan device while being disabled on the HW.
      However, the GSO code will correctly process the packets. This
      actually results in slightly better raw throughput.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8403debe
  6. 22 3月, 2017 1 次提交
    • A
      net/8021q: create device with all possible features in wanted_features · 88997e42
      Andrey Vagin 提交于
      wanted_features is a set of features which have to be enabled if a
      hardware allows that.
      
      Currently when a vlan device is created, its wanted_features is set to
      current features of its base device.
      
      The problem is that the base device can get new features and they are
      not propagated to vlan-s of this device.
      
      If we look at bonding devices, they doesn't have this problem and this
      patch suggests to fix this issue by the same way how it works for bonding
      devices.
      
      We meet this problem, when we try to create a vlan device over a bonding
      device. When a system are booting, real devices require time to be
      initialized, so bonding devices created without slaves, then vlan
      devices are created and only then ethernet devices are added to the
      bonding device. As a result we have vlan devices with disabled
      scatter-gather.
      
      * create a bonding device
        $ ip link add bond0 type bond
        $ ethtool -k bond0 | grep scatter
        scatter-gather: off
      	tx-scatter-gather: off [requested on]
      	tx-scatter-gather-fraglist: off [requested on]
      
      * create a vlan device
        $ ip link add link bond0 name bond0.10 type vlan id 10
        $ ethtool -k bond0.10 | grep scatter
        scatter-gather: off
      	tx-scatter-gather: off
      	tx-scatter-gather-fraglist: off
      
      * Add a slave device to bond0
        $ ip link set dev eth0 master bond0
      
      And now we can see that the bond0 device has got the scatter-gather
      feature, but the bond0.10 hasn't got it.
      [root@laptop linux-task-diag]# ethtool -k bond0 | grep scatter
      scatter-gather: on
      	tx-scatter-gather: on
      	tx-scatter-gather-fraglist: on
      [root@laptop linux-task-diag]# ethtool -k bond0.10 | grep scatter
      scatter-gather: off
      	tx-scatter-gather: off
      	tx-scatter-gather-fraglist: off
      
      With this patch the vlan device will get all new features from the
      bonding device.
      
      Here is a call trace how features which are set in this patch reach
      dev->wanted_features.
      
      register_netdevice
         vlan_dev_init
      	...
      	dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
      		       NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
      		       NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
      		       NETIF_F_ALL_FCOE;
      
      	dev->features |= dev->hw_features;
      	...
          dev->wanted_features = dev->features & dev->hw_features;
          __netdev_update_features(dev);
              vlan_dev_fix_features
      	   ...
      
      Cc: Alexey Kuznetsov <kuznet@virtuozzo.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrei Vagin <avagin@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88997e42
  7. 07 2月, 2017 1 次提交
  8. 09 1月, 2017 1 次提交
  9. 21 10月, 2016 1 次提交
    • J
      net: use core MTU range checking in core net infra · 91572088
      Jarod Wilson 提交于
      geneve:
      - Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
      - This one isn't quite as straight-forward as others, could use some
        closer inspection and testing
      
      macvlan:
      - set min/max_mtu
      
      tun:
      - set min/max_mtu, remove tun_net_change_mtu
      
      vxlan:
      - Merge __vxlan_change_mtu back into vxlan_change_mtu
      - Set max_mtu to IP_MAX_MTU and retain dynamic MTU range checks in
        change_mtu function
      - This one is also not as straight-forward and could use closer inspection
        and testing from vxlan folks
      
      bridge:
      - set max_mtu of IP_MAX_MTU and retain dynamic MTU range checks in
        change_mtu function
      
      openvswitch:
      - set min/max_mtu, remove internal_dev_change_mtu
      - note: max_mtu wasn't checked previously, it's been set to 65535, which
        is the largest possible size supported
      
      sch_teql:
      - set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)
      
      macsec:
      - min_mtu = 0, max_mtu = 65535
      
      macvlan:
      - min_mtu = 0, max_mtu = 65535
      
      ntb_netdev:
      - min_mtu = 0, max_mtu = 65535
      
      veth:
      - min_mtu = 68, max_mtu = 65535
      
      8021q:
      - min_mtu = 0, max_mtu = 65535
      
      CC: netdev@vger.kernel.org
      CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
      CC: Tom Herbert <tom@herbertland.com>
      CC: Daniel Borkmann <daniel@iogearbox.net>
      CC: Alexander Duyck <alexander.h.duyck@intel.com>
      CC: Paolo Abeni <pabeni@redhat.com>
      CC: Jiri Benc <jbenc@redhat.com>
      CC: WANG Cong <xiyou.wangcong@gmail.com>
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      CC: Pravin B Shelar <pshelar@ovn.org>
      CC: Sabrina Dubroca <sd@queasysnail.net>
      CC: Patrick McHardy <kaber@trash.net>
      CC: Stephen Hemminger <stephen@networkplumber.org>
      CC: Pravin Shelar <pshelar@nicira.com>
      CC: Maxim Krasnyansky <maxk@qti.qualcomm.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91572088
  10. 17 7月, 2016 1 次提交
    • P
      vlan: use a valid default mtu value for vlan over macsec · 18d3df3e
      Paolo Abeni 提交于
      macsec can't cope with mtu frames which need vlan tag insertion, and
      vlan device set the default mtu equal to the underlying dev's one.
      By default vlan over macsec devices use invalid mtu, dropping
      all the large packets.
      This patch adds a netif helper to check if an upper vlan device
      needs mtu reduction. The helper is used during vlan devices
      initialization to set a valid default and during mtu updating to
      forbid invalid, too bit, mtu values.
      The helper currently only check if the lower dev is a macsec device,
      if we get more users, we need to update only the helper (possibly
      reserving an additional IFF bit).
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18d3df3e
  11. 06 7月, 2016 1 次提交
  12. 01 6月, 2016 1 次提交
    • M
      vlan: Propagate MAC address to VLANs · 308453aa
      Mike Manning 提交于
      The MAC address of the physical interface is only copied to the VLAN
      when it is first created, resulting in an inconsistency after MAC
      address changes of only newly created VLANs having an up-to-date MAC.
      
      The VLANs should continue inheriting the MAC address of the physical
      interface until the VLAN MAC address is explicitly set to any value.
      This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
      to the MAC of the physical interface and thus for DAD to behave as
      expected.
      Signed-off-by: NMike Manning <mmanning@brocade.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      308453aa
  13. 18 3月, 2016 1 次提交
  14. 26 2月, 2016 1 次提交
  15. 22 2月, 2016 1 次提交
  16. 16 12月, 2015 3 次提交
  17. 19 8月, 2015 1 次提交
  18. 03 4月, 2015 1 次提交
  19. 30 3月, 2015 1 次提交
    • T
      vlan: Add features for stacked vlan device · 8d463504
      Toshiaki Makita 提交于
      Stacked vlan devices curretly have few features (GRO, HIGHDMA, LLTX).
      Since we have software fallbacks in case the NIC can not handle some
      features for multiple vlans, we can add the same features as the lower
      vlan devices for stacked vlan devices.
      
      This allows stacked vlan devices to create large (GSO) packets and not to
      segment packets. Those packets will be segmented by software on the real
      device, or even can be segmented by the NIC once TSO for multiple vlans
      becomes enabled by the following patches.
      
      The exception is those related to FCoE, which does not have a software
      fallback.
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d463504
  20. 04 3月, 2015 1 次提交
  21. 03 3月, 2015 1 次提交
  22. 12 12月, 2014 1 次提交
  23. 22 11月, 2014 2 次提交
  24. 08 10月, 2014 1 次提交
    • E
      net: better IFF_XMIT_DST_RELEASE support · 02875878
      Eric Dumazet 提交于
      Testing xmit_more support with netperf and connected UDP sockets,
      I found strange dst refcount false sharing.
      
      Current handling of IFF_XMIT_DST_RELEASE is not optimal.
      
      Dropping dst in validate_xmit_skb() is certainly too late in case
      packet was queued by cpu X but dequeued by cpu Y
      
      The logical point to take care of drop/force is in __dev_queue_xmit()
      before even taking qdisc lock.
      
      As Julian Anastasov pointed out, need for skb_dst() might come from some
      packet schedulers or classifiers.
      
      This patch adds new helper to cleanly express needs of various drivers
      or qdiscs/classifiers.
      
      Drivers that need skb_dst() in their ndo_start_xmit() should call
      following helper in their setup instead of the prior :
      
      	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
      ->
      	netif_keep_dst(dev);
      
      Instead of using a single bit, we use two bits, one being
      eventually rebuilt in bonding/team drivers.
      
      The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
      rebuilt in bonding/team. Eventually, we could add something
      smarter later.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02875878
  25. 08 7月, 2014 1 次提交
  26. 03 7月, 2014 1 次提交
    • E
      vlan: free percpu stats in device destructor · a48e5faf
      Eric Dumazet 提交于
      Madalin-Cristian reported crashs happening after a recent commit
      (5a4ae5f6 "vlan: unnecessary to check if vlan_pcpu_stats is NULL")
      
      -----------------------------------------------------------------------
      root@p5040ds:~# vconfig add eth8 1
      root@p5040ds:~# vconfig rem eth8.1
      Unable to handle kernel paging request for data at address 0x2bc88028
      Faulting instruction address: 0xc058e950
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=8 CoreNet Generic
      Modules linked in:
      CPU: 3 PID: 2167 Comm: vconfig Tainted: G        W     3.16.0-rc3-00346-g65e85bf #2
      task: e7264d90 ti: e2c2c000 task.ti: e2c2c000
      NIP: c058e950 LR: c058ea30 CTR: c058e900
      REGS: e2c2db20 TRAP: 0300   Tainted: G        W      (3.16.0-rc3-00346-g65e85bf)
      MSR: 00029002 <CE,EE,ME>  CR: 48000428  XER: 20000000
      DEAR: 2bc88028 ESR: 00000000
      GPR00: c047299c e2c2dbd0 e7264d90 00000000 2bc88000 00000000 ffffffff 00000000
      GPR08: 0000000f 00000000 000000ff 00000000 28000422 10121928 10100000 10100000
      GPR16: 10100000 00000000 c07c5968 00000000 00000000 00000000 e2c2dc48 e7838000
      GPR24: c07c5bac c07c58a8 e77290cc c07b0000 00000000 c05de6c0 e7838000 e2c2dc48
      NIP [c058e950] vlan_dev_get_stats64+0x50/0x170
      LR [c058ea30] vlan_dev_get_stats64+0x130/0x170
      Call Trace:
      [e2c2dbd0] [ffffffea] 0xffffffea (unreliable)
      [e2c2dc20] [c047299c] dev_get_stats+0x4c/0x140
      [e2c2dc40] [c0488ca8] rtnl_fill_ifinfo+0x3d8/0x960
      [e2c2dd70] [c0489f4c] rtmsg_ifinfo+0x6c/0x110
      [e2c2dd90] [c04731d4] rollback_registered_many+0x344/0x3b0
      [e2c2ddd0] [c047332c] rollback_registered+0x2c/0x50
      [e2c2ddf0] [c0476058] unregister_netdevice_queue+0x78/0xf0
      [e2c2de00] [c058d800] unregister_vlan_dev+0xc0/0x160
      [e2c2de20] [c058e360] vlan_ioctl_handler+0x1c0/0x550
      [e2c2de90] [c045d11c] sock_ioctl+0x28c/0x2f0
      [e2c2deb0] [c010d070] do_vfs_ioctl+0x90/0x7b0
      [e2c2df20] [c010d7d0] SyS_ioctl+0x40/0x80
      [e2c2df40] [c000f924] ret_from_syscall+0x0/0x3c
      
      Fix this problem by freeing percpu stats from dev->destructor() instead
      of ndo_uninit()
      Reported-by: NMadalin-Cristian Bucur <madalin.bucur@freescale.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NMadalin-Cristian Bucur <madalin.bucur@freescale.com>
      Fixes: 5a4ae5f6 ("vlan: unnecessary to check if vlan_pcpu_stats is NULL")
      Cc: Li RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a48e5faf
  27. 23 5月, 2014 1 次提交
    • M
      vlan: more careful checksum features handling · da08143b
      Michal Kubeček 提交于
      When combining real_dev's features and vlan_features, simple
      bitwise AND is used. This doesn't work well for checksum
      offloading features as if one set has NETIF_F_HW_CSUM and the
      other NETIF_F_IP_CSUM and/or NETIF_F_IPV6_CSUM, we end up with
      no checksum offloading. However, from the logical point of view
      (how can_checksum_protocol() works), NETIF_F_HW_CSUM contains
      the functionality of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM so
      that the result should be IP/IPV6.
      
      Add helper function netdev_intersect_features() implementing
      this logic and use it in vlan_dev_fix_features().
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da08143b
  28. 17 5月, 2014 1 次提交
  29. 23 4月, 2014 1 次提交
  30. 19 4月, 2014 1 次提交
    • D
      vlan: Fix lockdep warning when vlan dev handle notification · dc8eaaa0
      dingtianhong 提交于
      When I open the LOCKDEP config and run these steps:
      
      modprobe 8021q
      vconfig add eth2 20
      vconfig add eth2.20 30
      ifconfig eth2 xx.xx.xx.xx
      
      then the Call Trace happened:
      
      [32524.386288] =============================================
      [32524.386293] [ INFO: possible recursive locking detected ]
      [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G           O
      [32524.386302] ---------------------------------------------
      [32524.386306] ifconfig/3103 is trying to acquire lock:
      [32524.386310]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386326]
      [32524.386326] but task is already holding lock:
      [32524.386330]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386341]
      [32524.386341] other info that might help us debug this:
      [32524.386345]  Possible unsafe locking scenario:
      [32524.386345]
      [32524.386350]        CPU0
      [32524.386352]        ----
      [32524.386354]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386359]   lock(&vlan_netdev_addr_lock_key/1);
      [32524.386364]
      [32524.386364]  *** DEADLOCK ***
      [32524.386364]
      [32524.386368]  May be due to missing lock nesting notation
      [32524.386368]
      [32524.386373] 2 locks held by ifconfig/3103:
      [32524.386376]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81431d42>] rtnl_lock+0x12/0x20
      [32524.386387]  #1:  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff8141af83>] dev_set_rx_mode+0x23/0x40
      [32524.386398]
      [32524.386398] stack backtrace:
      [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G           O 3.14.0-rc2-0.7-default+ #35
      [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [32524.386414]  ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8
      [32524.386421]  ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0
      [32524.386428]  000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000
      [32524.386435] Call Trace:
      [32524.386441]  [<ffffffff814f68a2>] dump_stack+0x6a/0x78
      [32524.386448]  [<ffffffff810a35fb>] __lock_acquire+0x7ab/0x1940
      [32524.386454]  [<ffffffff810a323a>] ? __lock_acquire+0x3ea/0x1940
      [32524.386459]  [<ffffffff810a4874>] lock_acquire+0xe4/0x110
      [32524.386464]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386471]  [<ffffffff814fc07a>] _raw_spin_lock_nested+0x2a/0x40
      [32524.386476]  [<ffffffff814275f4>] ? dev_mc_sync+0x64/0xb0
      [32524.386481]  [<ffffffff814275f4>] dev_mc_sync+0x64/0xb0
      [32524.386489]  [<ffffffffa0500cab>] vlan_dev_set_rx_mode+0x2b/0x50 [8021q]
      [32524.386495]  [<ffffffff8141addf>] __dev_set_rx_mode+0x5f/0xb0
      [32524.386500]  [<ffffffff8141af8b>] dev_set_rx_mode+0x2b/0x40
      [32524.386506]  [<ffffffff8141b3cf>] __dev_open+0xef/0x150
      [32524.386511]  [<ffffffff8141b177>] __dev_change_flags+0xa7/0x190
      [32524.386516]  [<ffffffff8141b292>] dev_change_flags+0x32/0x80
      [32524.386524]  [<ffffffff8149ca56>] devinet_ioctl+0x7d6/0x830
      [32524.386532]  [<ffffffff81437b0b>] ? dev_ioctl+0x34b/0x660
      [32524.386540]  [<ffffffff814a05b0>] inet_ioctl+0x80/0xa0
      [32524.386550]  [<ffffffff8140199d>] sock_do_ioctl+0x2d/0x60
      [32524.386558]  [<ffffffff81401a52>] sock_ioctl+0x82/0x2a0
      [32524.386568]  [<ffffffff811a7123>] do_vfs_ioctl+0x93/0x590
      [32524.386578]  [<ffffffff811b2705>] ? rcu_read_lock_held+0x45/0x50
      [32524.386586]  [<ffffffff811b39e5>] ? __fget_light+0x105/0x110
      [32524.386594]  [<ffffffff811a76b1>] SyS_ioctl+0x91/0xb0
      [32524.386604]  [<ffffffff815057e2>] system_call_fastpath+0x16/0x1b
      
      ========================================================================
      
      The reason is that all of the addr_lock_key for vlan dev have the same class,
      so if we change the status for vlan dev, the vlan dev and its real dev will
      hold the same class of addr_lock_key together, so the warning happened.
      
      we should distinguish the lock depth for vlan dev and its real dev.
      
      v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which
      	could support to add 8 vlan id on a same vlan dev, I think it is enough for current
      	scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id,
      	and the vlan dev would not meet the same class key with its real dev.
      
      	The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan
      	dev could get a suitable class key.
      
      v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev
      	and its real dev, but it make no sense, because the difference for subclass in the
      	lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth
      	to distinguish the different depth for every vlan dev, the same depth of the vlan dev
      	could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h,
      	I think it is enough here, the lockdep should never exceed that value.
      
      v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method,
      	we could use _nested() variants to fix the problem, calculate the depth for every vlan dev,
      	and use the depth as the subclass for addr_lock_key.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc8eaaa0
  31. 30 3月, 2014 1 次提交
  32. 29 3月, 2014 1 次提交
  33. 28 3月, 2014 1 次提交
  34. 15 3月, 2014 1 次提交
  35. 11 3月, 2014 1 次提交
  36. 15 2月, 2014 1 次提交
  37. 22 1月, 2014 1 次提交