1. 30 10月, 2019 11 次提交
    • T
      bonding: fix using uninitialized mode_lock · ad9bd8da
      Taehee Yoo 提交于
      When a bonding interface is being created, it setups its mode and options.
      At that moment, it uses mode_lock so mode_lock should be initialized
      before that moment.
      
      rtnl_newlink()
      	rtnl_create_link()
      		alloc_netdev_mqs()
      			->setup() //bond_setup()
      	->newlink //bond_newlink
      		bond_changelink()
      		register_netdevice()
      			->ndo_init() //bond_init()
      
      After commit 089bca2c ("bonding: use dynamic lockdep key instead of
      subclass"), mode_lock is initialized in bond_init().
      So in the bond_changelink(), un-initialized mode_lock can be used.
      mode_lock should be initialized in bond_setup().
      This patch partially reverts commit 089bca2c ("bonding: use dynamic
      lockdep key instead of subclass")
      
      Test command:
          ip link add bond0 type bond mode 802.3ad lacp_rate 0
      
      Splat looks like:
      [   60.615127] INFO: trying to register non-static key.
      [   60.615900] the code is fine but needs lockdep annotation.
      [   60.616697] turning off the locking correctness validator.
      [   60.617490] CPU: 1 PID: 957 Comm: ip Not tainted 5.4.0-rc3+ #109
      [   60.618350] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   60.619481] Call Trace:
      [   60.619918]  dump_stack+0x7c/0xbb
      [   60.620453]  register_lock_class+0x1215/0x14d0
      [   60.621131]  ? alloc_netdev_mqs+0x7b3/0xcc0
      [   60.621771]  ? is_bpf_text_address+0x86/0xf0
      [   60.622416]  ? is_dynamic_key+0x230/0x230
      [   60.623032]  ? unwind_get_return_address+0x5f/0xa0
      [   60.623757]  ? create_prof_cpu_mask+0x20/0x20
      [   60.624408]  ? arch_stack_walk+0x83/0xb0
      [   60.625023]  __lock_acquire+0xd8/0x3de0
      [   60.625616]  ? stack_trace_save+0x82/0xb0
      [   60.626225]  ? stack_trace_consume_entry+0x160/0x160
      [   60.626957]  ? deactivate_slab.isra.80+0x2c5/0x800
      [   60.627668]  ? register_lock_class+0x14d0/0x14d0
      [   60.628380]  ? alloc_netdev_mqs+0x7b3/0xcc0
      [   60.629020]  ? save_stack+0x69/0x80
      [   60.629574]  ? save_stack+0x19/0x80
      [   60.630121]  ? __kasan_kmalloc.constprop.4+0xa0/0xd0
      [   60.630859]  ? __kmalloc_node+0x16f/0x480
      [   60.631472]  ? alloc_netdev_mqs+0x7b3/0xcc0
      [   60.632121]  ? rtnl_create_link+0x2ed/0xad0
      [   60.634388]  ? __rtnl_newlink+0xad4/0x11b0
      [   60.635024]  lock_acquire+0x164/0x3b0
      [   60.635608]  ? bond_3ad_update_lacp_rate+0x91/0x200 [bonding]
      [   60.636463]  _raw_spin_lock_bh+0x38/0x70
      [   60.637084]  ? bond_3ad_update_lacp_rate+0x91/0x200 [bonding]
      [   60.637930]  bond_3ad_update_lacp_rate+0x91/0x200 [bonding]
      [   60.638753]  ? bond_3ad_lacpdu_recv+0xb30/0xb30 [bonding]
      [   60.639552]  ? bond_opt_get_val+0x180/0x180 [bonding]
      [   60.640307]  ? ___slab_alloc+0x5aa/0x610
      [   60.640925]  bond_option_lacp_rate_set+0x71/0x140 [bonding]
      [   60.641751]  __bond_opt_set+0x1ff/0xbb0 [bonding]
      [   60.643217]  ? kasan_unpoison_shadow+0x30/0x40
      [   60.643924]  bond_changelink+0x9a4/0x1700 [bonding]
      [   60.644653]  ? memset+0x1f/0x40
      [   60.742941]  ? bond_slave_changelink+0x1a0/0x1a0 [bonding]
      [   60.752694]  ? alloc_netdev_mqs+0x8ea/0xcc0
      [   60.753330]  ? rtnl_create_link+0x2ed/0xad0
      [   60.753964]  bond_newlink+0x1e/0x60 [bonding]
      [   60.754612]  __rtnl_newlink+0xb9f/0x11b0
      [ ... ]
      
      Reported-by: syzbot+8da67f407bcba2c72e6e@syzkaller.appspotmail.com
      Reported-by: syzbot+0d083911ab18b710da71@syzkaller.appspotmail.com
      Fixes: 089bca2c ("bonding: use dynamic lockdep key instead of subclass")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad9bd8da
    • A
      net: fec_ptp: Use platform_get_irq_xxx_optional() to avoid error message · b86bcb29
      Anson Huang 提交于
      Use platform_get_irq_byname_optional() and platform_get_irq_optional()
      instead of platform_get_irq_byname() and platform_get_irq() for optional
      IRQs to avoid below error message during probe:
      
      [    0.795803] fec 30be0000.ethernet: IRQ pps not found
      [    0.800787] fec 30be0000.ethernet: IRQ index 3 not found
      Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
      Acked-by: NFugang Duan <fugang.duan@nxp.com>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b86bcb29
    • A
      net: fec_main: Use platform_get_irq_byname_optional() to avoid error message · 3b56be21
      Anson Huang 提交于
      Failed to get irq using name is NOT fatal as driver will use index
      to get irq instead, use platform_get_irq_byname_optional() instead
      of platform_get_irq_byname() to avoid below error message during
      probe:
      
      [    0.819312] fec 30be0000.ethernet: IRQ int0 not found
      [    0.824433] fec 30be0000.ethernet: IRQ int1 not found
      [    0.829539] fec 30be0000.ethernet: IRQ int2 not found
      Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
      Acked-by: NFugang Duan <fugang.duan@nxp.com>
      Reviewed-by: NStephen Boyd <swboyd@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b56be21
    • X
      vxlan: check tun_info options_len properly · eadf52cf
      Xin Long 提交于
      This patch is to improve the tun_info options_len by dropping
      the skb when TUNNEL_VXLAN_OPT is set but options_len is less
      than vxlan_metadata. This can void a potential out-of-bounds
      access on ip_tun_info.
      
      Fixes: ee122c79 ("vxlan: Flow based tunneling")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eadf52cf
    • J
      net: hisilicon: Fix ping latency when deal with high throughput · e56bd641
      Jiangfeng Xiao 提交于
      This is due to error in over budget processing.
      When dealing with high throughput, the used buffers
      that exceeds the budget is not cleaned up. In addition,
      it takes a lot of cycles to clean up the used buffer,
      and then the buffer where the valid data is located can take effect.
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e56bd641
    • E
      net/mlx4_core: Dynamically set guaranteed amount of counters per VF · e19868ef
      Eran Ben Elisha 提交于
      Prior to this patch, the amount of counters guaranteed per VF in the
      resource tracker was MLX4_VF_COUNTERS_PER_PORT * MLX4_MAX_PORTS. It was
      set regardless if the VF was single or dual port.
      This caused several VFs to have no guaranteed counters although the
      system could satisfy their request.
      
      The fix is to dynamically guarantee counters, based on each VF
      specification.
      
      Fixes: 9de92c60 ("net/mlx4_core: Adjust counter grant policy in the resource tracker")
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e19868ef
    • V
      net: mscc: ocelot: refuse to overwrite the port's native vlan · b9cd75e6
      Vladimir Oltean 提交于
      The switch driver keeps a "vid" variable per port, which signifies _the_
      VLAN ID that is stripped on that port's egress (aka the native VLAN on a
      trunk port).
      
      That is the way the hardware is designed (mostly). The port->vid is
      programmed into REW:PORT:PORT_VLAN_CFG:PORT_VID and the rewriter is told
      to send all traffic as tagged except the one having port->vid.
      
      There exists a possibility of finer-grained egress untagging decisions:
      using the VCAP IS1 engine, one rule can be added to match every
      VLAN-tagged frame whose VLAN should be untagged, and set POP_CNT=1 as
      action. However, the IS1 can hold at most 512 entries, and the VLANs are
      in the order of 6 * 4096.
      
      So the code is fine for now. But this sequence of commands:
      
      $ bridge vlan add dev swp0 vid 1 pvid untagged
      $ bridge vlan add dev swp0 vid 2 untagged
      
      makes untagged and pvid-tagged traffic be sent out of swp0 as tagged
      with VID 1, despite user's request.
      
      Prevent that from happening. The user should temporarily remove the
      existing untagged VLAN (1 in this case), add it back as tagged, and then
      add the new untagged VLAN (2 in this case).
      
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Fixes: 7142529f ("net: mscc: ocelot: add VLAN filtering")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9cd75e6
    • V
      net: mscc: ocelot: fix vlan_filtering when enslaving to bridge before link is up · 1c44ce56
      Vladimir Oltean 提交于
      Background information: the driver operates the hardware in a mode where
      a single VLAN can be transmitted as untagged on a particular egress
      port. That is the "native VLAN on trunk port" use case. Its value is
      held in port->vid.
      
      Consider the following command sequence (no network manager, all
      interfaces are down, debugging prints added by me):
      
      $ ip link add dev br0 type bridge vlan_filtering 1
      $ ip link set dev swp0 master br0
      
      Kernel code path during last command:
      
      br_add_slave -> ocelot_netdevice_port_event (NETDEV_CHANGEUPPER):
      [   21.401901] ocelot_vlan_port_apply: port 0 vlan aware 0 pvid 0 vid 0
      
      br_add_slave -> nbp_vlan_init -> switchdev_port_attr_set -> ocelot_port_attr_set (SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING):
      [   21.413335] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 0 vid 0
      
      br_add_slave -> nbp_vlan_init -> nbp_vlan_add -> br_switchdev_port_vlan_add -> switchdev_port_obj_add -> ocelot_port_obj_add -> ocelot_vlan_vid_add
      [   21.667421] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 1 vid 1
      
      So far so good. The bridge has replaced the driver's default pvid used
      in standalone mode (0) with its own default_pvid (1). The port's vid
      (native VLAN) has also changed from 0 to 1.
      
      $ ip link set dev swp0 up
      
      [   31.722956] 8021q: adding VLAN 0 to HW filter on device swp0
      do_setlink -> dev_change_flags -> vlan_vid_add -> ocelot_vlan_rx_add_vid -> ocelot_vlan_vid_add:
      [   31.728700] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 1 vid 0
      
      The 8021q module uses the .ndo_vlan_rx_add_vid API on .ndo_open to make
      ports be able to transmit and receive 802.1p-tagged traffic by default.
      This API is supposed to offload a VLAN sub-interface, which for a switch
      port means to add a VLAN that is not a pvid, and tagged on egress.
      
      But the driver implementation of .ndo_vlan_rx_add_vid is wrong: it adds
      back vid 0 as "egress untagged". Now back to the initial paragraph:
      there is a single untagged VID that the driver keeps track of, and that
      has just changed from 1 (the pvid) to 0. So this breaks the bridge
      core's expectation, because it has changed vid 1 from untagged to
      tagged, when what the user sees is.
      
      $ bridge vlan
      port    vlan ids
      swp0     1 PVID Egress Untagged
      
      br0      1 PVID Egress Untagged
      
      But curiously, instead of manifesting itself as "untagged and
      pvid-tagged traffic gets sent as tagged on egress", the bug:
      
      - is hidden when vlan_filtering=0
      - manifests as dropped traffic when vlan_filtering=1, due to this setting:
      
      	if (port->vlan_aware && !port->vid)
      		/* If port is vlan-aware and tagged, drop untagged and priority
      		 * tagged frames.
      		 */
      		val |= ANA_PORT_DROP_CFG_DROP_UNTAGGED_ENA |
      		       ANA_PORT_DROP_CFG_DROP_PRIO_S_TAGGED_ENA |
      		       ANA_PORT_DROP_CFG_DROP_PRIO_C_TAGGED_ENA;
      
      which would have made sense if it weren't for this bug. The setting's
      intention was "this is a trunk port with no native VLAN, so don't accept
      untagged traffic". So the driver was never expecting to set VLAN 0 as
      the value of the native VLAN, 0 was just encoding for "invalid".
      
      So the fix is to not send 802.1p traffic as untagged, because that would
      change the port's native vlan to 0, unbeknownst to the bridge, and
      trigger unexpected code paths in the driver.
      
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Fixes: 7142529f ("net: mscc: ocelot: add VLAN filtering")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c44ce56
    • N
      wimax: i2400: Fix memory leak in i2400m_op_rfkill_sw_toggle · 6f3ef5c2
      Navid Emamdoost 提交于
      In the implementation of i2400m_op_rfkill_sw_toggle() the allocated
      buffer for cmd should be released before returning. The
      documentation for i2400m_msg_to_dev() says when it returns the buffer
      can be reused. Meaning cmd should be released in either case. Move
      kfree(cmd) before return to be reached by all execution paths.
      
      Fixes: 2507e6ab ("wimax: i2400: fix memory leak")
      Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f3ef5c2
    • J
      net: hisilicon: Fix "Trying to free already-free IRQ" · 63a41746
      Jiangfeng Xiao 提交于
      When rmmod hip04_eth.ko, we can get the following warning:
      
      Task track: rmmod(1623)>bash(1591)>login(1581)>init(1)
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1623 at kernel/irq/manage.c:1557 __free_irq+0xa4/0x2ac()
      Trying to free already-free IRQ 200
      Modules linked in: ping(O) pramdisk(O) cpuinfo(O) rtos_snapshot(O) interrupt_ctrl(O) mtdblock mtd_blkdevrtfs nfs_acl nfs lockd grace sunrpc xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables nf_reject_ipv
      CPU: 0 PID: 1623 Comm: rmmod Tainted: G           O    4.4.193 #1
      Hardware name: Hisilicon A15
      [<c020b408>] (rtos_unwind_backtrace) from [<c0206624>] (show_stack+0x10/0x14)
      [<c0206624>] (show_stack) from [<c03f2be4>] (dump_stack+0xa0/0xd8)
      [<c03f2be4>] (dump_stack) from [<c021a780>] (warn_slowpath_common+0x84/0xb0)
      [<c021a780>] (warn_slowpath_common) from [<c021a7e8>] (warn_slowpath_fmt+0x3c/0x68)
      [<c021a7e8>] (warn_slowpath_fmt) from [<c026876c>] (__free_irq+0xa4/0x2ac)
      [<c026876c>] (__free_irq) from [<c0268a14>] (free_irq+0x60/0x7c)
      [<c0268a14>] (free_irq) from [<c0469e80>] (release_nodes+0x1c4/0x1ec)
      [<c0469e80>] (release_nodes) from [<c0466924>] (__device_release_driver+0xa8/0x104)
      [<c0466924>] (__device_release_driver) from [<c0466a80>] (driver_detach+0xd0/0xf8)
      [<c0466a80>] (driver_detach) from [<c0465e18>] (bus_remove_driver+0x64/0x8c)
      [<c0465e18>] (bus_remove_driver) from [<c02935b0>] (SyS_delete_module+0x198/0x1e0)
      [<c02935b0>] (SyS_delete_module) from [<c0202ed0>] (__sys_trace_return+0x0/0x10)
      ---[ end trace bb25d6123d849b44 ]---
      
      Currently "rmmod hip04_eth.ko" call free_irq more than once
      as devres_release_all and hip04_remove both call free_irq.
      This results in a 'Trying to free already-free IRQ' warning.
      To solve the problem free_irq has been moved out of hip04_remove.
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63a41746
    • W
      fjes: Handle workqueue allocation failure · 85ac30fa
      Will Deacon 提交于
      In the highly unlikely event that we fail to allocate either of the
      "/txrx" or "/control" workqueues, we should bail cleanly rather than
      blindly march on with NULL queue pointer(s) installed in the
      'fjes_adapter' instance.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Reported-by: NNicolas Waisman <nico@semmle.com>
      Link: https://lore.kernel.org/lkml/CADJ_3a8WFrs5NouXNqS5WYe7rebFP+_A5CheeqAyD_p7DFJJcg@mail.gmail.com/Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85ac30fa
  2. 29 10月, 2019 6 次提交
    • D
      net: usb: lan78xx: Disable interrupts before calling generic_handle_irq() · 0a29ac5b
      Daniel Wagner 提交于
      lan78xx_status() will run with interrupts enabled due to the change in
      ed194d13 ("usb: core: remove local_irq_save() around ->complete()
      handler"). generic_handle_irq() expects to be run with IRQs disabled.
      
      [    4.886203] 000: irq 79 handler irq_default_primary_handler+0x0/0x8 enabled interrupts
      [    4.886243] 000: WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:152 __handle_irq_event_percpu+0x154/0x168
      [    4.896294] 000: Modules linked in:
      [    4.896301] 000: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.6 #39
      [    4.896310] 000: Hardware name: Raspberry Pi 3 Model B+ (DT)
      [    4.896315] 000: pstate: 60000005 (nZCv daif -PAN -UAO)
      [    4.896321] 000: pc : __handle_irq_event_percpu+0x154/0x168
      [    4.896331] 000: lr : __handle_irq_event_percpu+0x154/0x168
      [    4.896339] 000: sp : ffff000010003cc0
      [    4.896346] 000: x29: ffff000010003cc0 x28: 0000000000000060
      [    4.896355] 000: x27: ffff000011021980 x26: ffff00001189c72b
      [    4.896364] 000: x25: ffff000011702bc0 x24: ffff800036d6e400
      [    4.896373] 000: x23: 000000000000004f x22: ffff000010003d64
      [    4.896381] 000: x21: 0000000000000000 x20: 0000000000000002
      [    4.896390] 000: x19: ffff8000371c8480 x18: 0000000000000060
      [    4.896398] 000: x17: 0000000000000000 x16: 00000000000000eb
      [    4.896406] 000: x15: ffff000011712d18 x14: 7265746e69206465
      [    4.896414] 000: x13: ffff000010003ba0 x12: ffff000011712df0
      [    4.896422] 000: x11: 0000000000000001 x10: ffff000011712e08
      [    4.896430] 000: x9 : 0000000000000001 x8 : 000000000003c920
      [    4.896437] 000: x7 : ffff0000118cc410 x6 : ffff0000118c7f00
      [    4.896445] 000: x5 : 000000000003c920 x4 : 0000000000004510
      [    4.896453] 000: x3 : ffff000011712dc8 x2 : 0000000000000000
      [    4.896461] 000: x1 : 73a3f67df94c1500 x0 : 0000000000000000
      [    4.896466] 000: Call trace:
      [    4.896471] 000:  __handle_irq_event_percpu+0x154/0x168
      [    4.896481] 000:  handle_irq_event_percpu+0x50/0xb0
      [    4.896489] 000:  handle_irq_event+0x40/0x98
      [    4.896497] 000:  handle_simple_irq+0xa4/0xf0
      [    4.896505] 000:  generic_handle_irq+0x24/0x38
      [    4.896513] 000:  intr_complete+0xb0/0xe0
      [    4.896525] 000:  __usb_hcd_giveback_urb+0x58/0xd8
      [    4.896533] 000:  usb_giveback_urb_bh+0xd0/0x170
      [    4.896539] 000:  tasklet_action_common.isra.0+0x9c/0x128
      [    4.896549] 000:  tasklet_hi_action+0x24/0x30
      [    4.896556] 000:  __do_softirq+0x120/0x23c
      [    4.896564] 000:  irq_exit+0xb8/0xd8
      [    4.896571] 000:  __handle_domain_irq+0x64/0xb8
      [    4.896579] 000:  bcm2836_arm_irqchip_handle_irq+0x60/0xc0
      [    4.896586] 000:  el1_irq+0xb8/0x140
      [    4.896592] 000:  arch_cpu_idle+0x10/0x18
      [    4.896601] 000:  do_idle+0x200/0x280
      [    4.896608] 000:  cpu_startup_entry+0x20/0x28
      [    4.896615] 000:  rest_init+0xb4/0xc0
      [    4.896623] 000:  arch_call_rest_init+0xc/0x14
      [    4.896632] 000:  start_kernel+0x454/0x480
      
      Fixes: ed194d13 ("usb: core: remove local_irq_save() around ->complete() handler")
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stefan Wahren <wahrenst@gmx.net>
      Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NDaniel Wagner <dwagner@suse.de>
      Tested-by: NStefan Wahren <wahrenst@gmx.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a29ac5b
    • A
      net: dsa: sja1105: improve NET_DSA_SJA1105_TAS dependency · 5d294fc4
      Arnd Bergmann 提交于
      An earlier bugfix introduced a dependency on CONFIG_NET_SCH_TAPRIO,
      but this missed the case of NET_SCH_TAPRIO=m and NET_DSA_SJA1105=y,
      which still causes a link error:
      
      drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_setup_tc_taprio':
      sja1105_tas.c:(.text+0x5c): undefined reference to `taprio_offload_free'
      sja1105_tas.c:(.text+0x3b4): undefined reference to `taprio_offload_get'
      drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_tas_teardown':
      sja1105_tas.c:(.text+0x6ec): undefined reference to `taprio_offload_free'
      
      Change the dependency to only allow selecting the TAS code when it
      can link against the taprio code.
      
      Fixes: a8d570de ("net: dsa: sja1105: Add dependency for NET_DSA_SJA1105_TAS")
      Fixes: 317ab5b8 ("net: dsa: sja1105: Configure the Time-Aware Scheduler via tc-taprio offload")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d294fc4
    • B
      net: ethernet: ftgmac100: Fix DMA coherency issue with SW checksum · 88824e3b
      Benjamin Herrenschmidt 提交于
      We are calling the checksum helper after the dma_map_single()
      call to map the packet. This is incorrect as the checksumming
      code will touch the packet from the CPU. This means the cache
      won't be properly flushes (or the bounce buffering will leave
      us with the unmodified packet to DMA).
      
      This moves the calculation of the checksum & vlan tags to
      before the DMA mapping.
      
      This also has the side effect of fixing another bug: If the
      checksum helper fails, we goto "drop" to drop the packet, which
      will not unmap the DMA mapping.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Fixes: 05690d63 ("ftgmac100: Upgrade to NETIF_F_HW_CSUM")
      Reviewed-by: NVijay Khemka <vijaykhemka@fb.com>
      Tested-by: NVijay Khemka <vijaykhemka@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88824e3b
    • N
      net: dpaa2: Use the correct style for SPDX License Identifier · 7de4344f
      Nishad Kamdar 提交于
      This patch corrects the SPDX License Identifier style in
      header files related to DPAA2 Ethernet driver supporting
      Freescale SoCs with DPAA2. For C header files
      Documentation/process/license-rules.rst mandates C-like comments
      (opposed to C source files where C++ style should be used)
      
      Changes made by using a script provided by Joe Perches here:
      https://lkml.org/lkml/2019/2/7/46.
      Suggested-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NNishad Kamdar <nishadkamdar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7de4344f
    • E
      net: use skb_queue_empty_lockless() in busy poll contexts · 3f926af3
      Eric Dumazet 提交于
      Busy polling usually runs without locks.
      Let's use skb_queue_empty_lockless() instead of skb_queue_empty()
      
      Also uses READ_ONCE() in __skb_try_recv_datagram() to address
      a similar potential problem.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f926af3
    • E
      net: use skb_queue_empty_lockless() in poll() handlers · 3ef7cf57
      Eric Dumazet 提交于
      Many poll() handlers are lockless. Using skb_queue_empty_lockless()
      instead of skb_queue_empty() is more appropriate.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ef7cf57
  3. 26 10月, 2019 3 次提交
    • R
      cxgb4: request the TX CIDX updates to status page · 7c3bebc3
      Raju Rangoju 提交于
      For adapters which support the SGE Doorbell Queue Timer facility,
      we configured the Ethernet TX Queues to send CIDX Updates to the
      Associated Ethernet RX Response Queue with CPL_SGE_EGR_UPDATE
      messages to allow us to respond more quickly to the CIDX Updates.
      But, this was adding load to PCIe Link RX bandwidth and,
      potentially, resulting in higher CPU Interrupt load.
      
      This patch requests the HW to deliver the CIDX updates to the TX
      queue status page rather than generating an ingress queue message
      (as an interrupt). With this patch, the load on RX bandwidth is
      reduced and a substantial improvement in BW is noticed at lower
      IO sizes.
      
      Fixes: d429005f ("cxgb4/cxgb4vf: Add support for SGE doorbell queue timer")
      Signed-off-by: NRaju Rangoju <rajur@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c3bebc3
    • N
      net: ethernet: Use the correct style for SPDX License Identifier · 16d65287
      Nishad Kamdar 提交于
      This patch corrects the SPDX License Identifier style in
      header file related to ethernet driver for Cortina Gemini
      devices. For C header files Documentation/process/license-rules.rst
      mandates C-like comments (opposed to C source files where
      C++ style should be used)
      
      Changes made by using a script provided by Joe Perches here:
      https://lkml.org/lkml/2019/2/7/46.
      Suggested-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NNishad Kamdar <nishadkamdar@gmail.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16d65287
    • B
      net: mvneta: make stub functions static inline · 3f6b2c44
      Ben Dooks (Codethink) 提交于
      If the CONFIG_MVNET_BA is not set, then make the stub functions
      static inline to avoid trying to export them, and remove hte
      following sparse warnings:
      
      drivers/net/ethernet/marvell/mvneta_bm.h:163:6: warning: symbol 'mvneta_bm_pool_destroy' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:165:6: warning: symbol 'mvneta_bm_bufs_free' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:167:5: warning: symbol 'mvneta_bm_construct' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:168:5: warning: symbol 'mvneta_bm_pool_refill' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:170:23: warning: symbol 'mvneta_bm_pool_use' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:181:18: warning: symbol 'mvneta_bm_get' was not declared. Should it be static?
      drivers/net/ethernet/marvell/mvneta_bm.h:182:6: warning: symbol 'mvneta_bm_put' was not declared. Should it be static?
      Signed-off-by: NBen Dooks (Codethink) <ben.dooks@codethink.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f6b2c44
  4. 25 10月, 2019 8 次提交
    • T
      virt_wifi: fix refcnt leak in module exit routine · 1962f86b
      Taehee Yoo 提交于
      virt_wifi_newlink() calls netdev_upper_dev_link() and it internally
      holds reference count of lower interface.
      
      Current code does not release a reference count of the lower interface
      when the lower interface is being deleted.
      So, reference count leaks occur.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add vw1 link dummy0 type virt_wifi
          ip link del dummy0
      
      Splat looks like:
      [  133.787526][  T788] WARNING: CPU: 1 PID: 788 at net/core/dev.c:8274 rollback_registered_many+0x835/0xc80
      [  133.788355][  T788] Modules linked in: virt_wifi cfg80211 dummy team af_packet sch_fq_codel ip_tables x_tables unix
      [  133.789377][  T788] CPU: 1 PID: 788 Comm: ip Not tainted 5.4.0-rc3+ #96
      [  133.790069][  T788] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  133.791167][  T788] RIP: 0010:rollback_registered_many+0x835/0xc80
      [  133.791906][  T788] Code: 00 4d 85 ff 0f 84 b5 fd ff ff ba c0 0c 00 00 48 89 de 4c 89 ff e8 9b 58 04 00 48 89 df e8 30
      [  133.794317][  T788] RSP: 0018:ffff88805ba3f338 EFLAGS: 00010202
      [  133.795080][  T788] RAX: ffff88805e57e801 RBX: ffff88805ba34000 RCX: ffffffffa9294723
      [  133.796045][  T788] RDX: 1ffff1100b746816 RSI: 0000000000000008 RDI: ffffffffabcc4240
      [  133.797006][  T788] RBP: ffff88805ba3f4c0 R08: fffffbfff5798849 R09: fffffbfff5798849
      [  133.797993][  T788] R10: 0000000000000001 R11: fffffbfff5798848 R12: dffffc0000000000
      [  133.802514][  T788] R13: ffff88805ba3f440 R14: ffff88805ba3f400 R15: ffff88805ed622c0
      [  133.803237][  T788] FS:  00007f2e9608c0c0(0000) GS:ffff88806cc00000(0000) knlGS:0000000000000000
      [  133.804002][  T788] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  133.804664][  T788] CR2: 00007f2e95610603 CR3: 000000005f68c004 CR4: 00000000000606e0
      [  133.805363][  T788] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  133.806073][  T788] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  133.806787][  T788] Call Trace:
      [  133.807069][  T788]  ? generic_xdp_install+0x310/0x310
      [  133.807612][  T788]  ? lock_acquire+0x164/0x3b0
      [  133.808077][  T788]  ? is_bpf_text_address+0x5/0xf0
      [  133.808640][  T788]  ? deref_stack_reg+0x9c/0xd0
      [  133.809138][  T788]  ? __nla_validate_parse+0x98/0x1ab0
      [  133.809944][  T788]  unregister_netdevice_many.part.122+0x13/0x1b0
      [  133.810599][  T788]  rtnl_delete_link+0xbc/0x100
      [  133.811073][  T788]  ? rtnl_af_register+0xc0/0xc0
      [  133.811672][  T788]  rtnl_dellink+0x30e/0x8a0
      [  133.812205][  T788]  ? is_bpf_text_address+0x5/0xf0
      [ ... ]
      
      [  144.110530][  T788] unregister_netdevice: waiting for dummy0 to become free. Usage count = 1
      
      This patch adds notifier routine to delete upper interface before deleting
      lower interface.
      
      Fixes: c7cdba31 ("mac80211-next: rtnetlink wifi simulation device")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1962f86b
    • T
      net: remove unnecessary variables and callback · f3b0a18b
      Taehee Yoo 提交于
      This patch removes variables and callback these are related to the nested
      device structure.
      devices that can be nested have their own nest_level variable that
      represents the depth of nested devices.
      In the previous patch, new {lower/upper}_level variables are added and
      they replace old private nest_level variable.
      So, this patch removes all 'nest_level' variables.
      
      In order to avoid lockdep warning, ->ndo_get_lock_subclass() was added
      to get lockdep subclass value, which is actually lower nested depth value.
      But now, they use the dynamic lockdep key to avoid lockdep warning instead
      of the subclass.
      So, this patch removes ->ndo_get_lock_subclass() callback.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3b0a18b
    • T
      vxlan: add adjacent link to limit depth level · 0ce1822c
      Taehee Yoo 提交于
      Current vxlan code doesn't limit the number of nested devices.
      Nested devices would be handled recursively and this routine needs
      huge stack memory. So, unlimited nested devices could make
      stack overflow.
      
      In order to fix this issue, this patch adds adjacent links.
      The adjacent link APIs internally check the depth level.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add vxlan0 type vxlan id 0 group 239.1.1.1 dev dummy0 \
      	    dstport 4789
          for i in {1..100}
          do
      	    let A=$i-1
      	    ip link add vxlan$i type vxlan id $i group 239.1.1.1 \
      		    dev vxlan$A dstport 4789
          done
          ip link del dummy0
      
      The top upper link is vxlan100 and the lowest link is vxlan0.
      When vxlan0 is deleting, the upper devices will be deleted recursively.
      It needs huge stack memory so it makes stack overflow.
      
      Splat looks like:
      [  229.628477] =============================================================================
      [  229.629785] BUG page->ptl (Not tainted): Padding overwritten. 0x0000000026abf214-0x0000000091f6abb2
      [  229.629785] -----------------------------------------------------------------------------
      [  229.629785]
      [  229.655439] ==================================================================
      [  229.629785] INFO: Slab 0x00000000ff7cfda8 objects=19 used=19 fp=0x00000000fe33776c flags=0x200000000010200
      [  229.655688] BUG: KASAN: stack-out-of-bounds in unmap_single_vma+0x25a/0x2e0
      [  229.655688] Read of size 8 at addr ffff888113076928 by task vlan-network-in/2334
      [  229.655688]
      [  229.629785] Padding 0000000026abf214: 00 80 14 0d 81 88 ff ff 68 91 81 14 81 88 ff ff  ........h.......
      [  229.629785] Padding 0000000001e24790: 38 91 81 14 81 88 ff ff 68 91 81 14 81 88 ff ff  8.......h.......
      [  229.629785] Padding 00000000b39397c8: 33 30 62 a7 ff ff ff ff ff eb 60 22 10 f1 ff 1f  30b.......`"....
      [  229.629785] Padding 00000000bc98f53a: 80 60 07 13 81 88 ff ff 00 80 14 0d 81 88 ff ff  .`..............
      [  229.629785] Padding 000000002aa8123d: 68 91 81 14 81 88 ff ff f7 21 17 a7 ff ff ff ff  h........!......
      [  229.629785] Padding 000000001c8c2369: 08 81 14 0d 81 88 ff ff 03 02 00 00 00 00 00 00  ................
      [  229.629785] Padding 000000004e290c5d: 21 90 a2 21 10 ed ff ff 00 00 00 00 00 fc ff df  !..!............
      [  229.629785] Padding 000000000e25d731: 18 60 07 13 81 88 ff ff c0 8b 13 05 81 88 ff ff  .`..............
      [  229.629785] Padding 000000007adc7ab3: b3 8a b5 41 00 00 00 00                          ...A....
      [  229.629785] FIX page->ptl: Restoring 0x0000000026abf214-0x0000000091f6abb2=0x5a
      [  ... ]
      
      Fixes: acaf4e70 ("net: vxlan: when lower dev unregisters remove vxlan dev as well")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ce1822c
    • T
      macsec: fix refcnt leak in module exit routine · 2bce1ebe
      Taehee Yoo 提交于
      When a macsec interface is created, it increases a refcnt to a lower
      device(real device). when macsec interface is deleted, the refcnt is
      decreased in macsec_free_netdev(), which is ->priv_destructor() of
      macsec interface.
      
      The problem scenario is this.
      When nested macsec interfaces are exiting, the exit routine of the
      macsec module makes refcnt leaks.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add macsec0 link dummy0 type macsec
          ip link add macsec1 link macsec0 type macsec
          modprobe -rv macsec
      
      [  208.629433] unregister_netdevice: waiting for macsec0 to become free. Usage count = 1
      
      Steps of exit routine of macsec module are below.
      1. Calls ->dellink() in __rtnl_link_unregister().
      2. Checks refcnt and wait refcnt to be 0 if refcnt is not 0 in
      netdev_run_todo().
      3. Calls ->priv_destruvtor() in netdev_run_todo().
      
      Step2 checks refcnt, but step3 decreases refcnt.
      So, step2 waits forever.
      
      This patch makes the macsec module do not hold a refcnt of the lower
      device because it already holds a refcnt of the lower device with
      netdev_upper_dev_link().
      
      Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2bce1ebe
    • T
      team: fix nested locking lockdep warning · 369f61be
      Taehee Yoo 提交于
      team interface could be nested and it's lock variable could be nested too.
      But this lock uses static lockdep key and there is no nested locking
      handling code such as mutex_lock_nested() and so on.
      so the Lockdep would warn about the circular locking scenario that
      couldn't happen.
      In order to fix, this patch makes the team module to use dynamic lock key
      instead of static key.
      
      Test commands:
          ip link add team0 type team
          ip link add team1 type team
          ip link set team0 master team1
          ip link set team0 nomaster
          ip link set team1 master team0
          ip link set team1 nomaster
      
      Splat that looks like:
      [   40.364352] WARNING: possible recursive locking detected
      [   40.364964] 5.4.0-rc3+ #96 Not tainted
      [   40.365405] --------------------------------------------
      [   40.365973] ip/750 is trying to acquire lock:
      [   40.366542] ffff888060b34c40 (&team->lock){+.+.}, at: team_set_mac_address+0x151/0x290 [team]
      [   40.367689]
      	       but task is already holding lock:
      [   40.368729] ffff888051201c40 (&team->lock){+.+.}, at: team_del_slave+0x29/0x60 [team]
      [   40.370280]
      	       other info that might help us debug this:
      [   40.371159]  Possible unsafe locking scenario:
      
      [   40.371942]        CPU0
      [   40.372338]        ----
      [   40.372673]   lock(&team->lock);
      [   40.373115]   lock(&team->lock);
      [   40.373549]
      	       *** DEADLOCK ***
      
      [   40.374432]  May be due to missing lock nesting notation
      
      [   40.375338] 2 locks held by ip/750:
      [   40.375851]  #0: ffffffffabcc42b0 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0
      [   40.376927]  #1: ffff888051201c40 (&team->lock){+.+.}, at: team_del_slave+0x29/0x60 [team]
      [   40.377989]
      	       stack backtrace:
      [   40.378650] CPU: 0 PID: 750 Comm: ip Not tainted 5.4.0-rc3+ #96
      [   40.379368] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   40.380574] Call Trace:
      [   40.381208]  dump_stack+0x7c/0xbb
      [   40.381959]  __lock_acquire+0x269d/0x3de0
      [   40.382817]  ? register_lock_class+0x14d0/0x14d0
      [   40.383784]  ? check_chain_key+0x236/0x5d0
      [   40.384518]  lock_acquire+0x164/0x3b0
      [   40.385074]  ? team_set_mac_address+0x151/0x290 [team]
      [   40.385805]  __mutex_lock+0x14d/0x14c0
      [   40.386371]  ? team_set_mac_address+0x151/0x290 [team]
      [   40.387038]  ? team_set_mac_address+0x151/0x290 [team]
      [   40.387632]  ? mutex_lock_io_nested+0x1380/0x1380
      [   40.388245]  ? team_del_slave+0x60/0x60 [team]
      [   40.388752]  ? rcu_read_lock_sched_held+0x90/0xc0
      [   40.389304]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [   40.389819]  ? lock_acquire+0x164/0x3b0
      [   40.390285]  ? lockdep_rtnl_is_held+0x16/0x20
      [   40.390797]  ? team_port_get_rtnl+0x90/0xe0 [team]
      [   40.391353]  ? __module_text_address+0x13/0x140
      [   40.391886]  ? team_set_mac_address+0x151/0x290 [team]
      [   40.392547]  team_set_mac_address+0x151/0x290 [team]
      [   40.393111]  dev_set_mac_address+0x1f0/0x3f0
      [ ... ]
      
      Fixes: 3d249d4c ("net: introduce ethernet teaming device")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      369f61be
    • T
      bonding: use dynamic lockdep key instead of subclass · 089bca2c
      Taehee Yoo 提交于
      All bonding device has same lockdep key and subclass is initialized with
      nest_level.
      But actual nest_level value can be changed when a lower device is attached.
      And at this moment, the subclass should be updated but it seems to be
      unsafe.
      So this patch makes bonding use dynamic lockdep key instead of the
      subclass.
      
      Test commands:
          ip link add bond0 type bond
      
          for i in {1..5}
          do
      	    let A=$i-1
      	    ip link add bond$i type bond
      	    ip link set bond$i master bond$A
          done
          ip link set bond5 master bond0
      
      Splat looks like:
      [  307.992912] WARNING: possible recursive locking detected
      [  307.993656] 5.4.0-rc3+ #96 Tainted: G        W
      [  307.994367] --------------------------------------------
      [  307.995092] ip/761 is trying to acquire lock:
      [  307.995710] ffff8880513aac60 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding]
      [  307.997045]
      	       but task is already holding lock:
      [  307.997923] ffff88805fcbac60 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding]
      [  307.999215]
      	       other info that might help us debug this:
      [  308.000251]  Possible unsafe locking scenario:
      
      [  308.001137]        CPU0
      [  308.001533]        ----
      [  308.001915]   lock(&(&bond->stats_lock)->rlock#2/2);
      [  308.002609]   lock(&(&bond->stats_lock)->rlock#2/2);
      [  308.003302]
      		*** DEADLOCK ***
      
      [  308.004310]  May be due to missing lock nesting notation
      
      [  308.005319] 3 locks held by ip/761:
      [  308.005830]  #0: ffffffff9fcc42b0 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0
      [  308.006894]  #1: ffff88805fcbac60 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding]
      [  308.008243]  #2: ffffffff9f9219c0 (rcu_read_lock){....}, at: bond_get_stats+0x9f/0x500 [bonding]
      [  308.009422]
      	       stack backtrace:
      [  308.010124] CPU: 0 PID: 761 Comm: ip Tainted: G        W         5.4.0-rc3+ #96
      [  308.011097] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  308.012179] Call Trace:
      [  308.012601]  dump_stack+0x7c/0xbb
      [  308.013089]  __lock_acquire+0x269d/0x3de0
      [  308.013669]  ? register_lock_class+0x14d0/0x14d0
      [  308.014318]  lock_acquire+0x164/0x3b0
      [  308.014858]  ? bond_get_stats+0xb8/0x500 [bonding]
      [  308.015520]  _raw_spin_lock_nested+0x2e/0x60
      [  308.016129]  ? bond_get_stats+0xb8/0x500 [bonding]
      [  308.017215]  bond_get_stats+0xb8/0x500 [bonding]
      [  308.018454]  ? bond_arp_rcv+0xf10/0xf10 [bonding]
      [  308.019710]  ? rcu_read_lock_held+0x90/0xa0
      [  308.020605]  ? rcu_read_lock_sched_held+0xc0/0xc0
      [  308.021286]  ? bond_get_stats+0x9f/0x500 [bonding]
      [  308.021953]  dev_get_stats+0x1ec/0x270
      [  308.022508]  bond_get_stats+0x1d1/0x500 [bonding]
      
      Fixes: d3fff6c4 ("net: add netdev_lockdep_set_classes() helper")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      089bca2c
    • T
      bonding: fix unexpected IFF_BONDING bit unset · 65de65d9
      Taehee Yoo 提交于
      The IFF_BONDING means bonding master or bonding slave device.
      ->ndo_add_slave() sets IFF_BONDING flag and ->ndo_del_slave() unsets
      IFF_BONDING flag.
      
      bond0<--bond1
      
      Both bond0 and bond1 are bonding device and these should keep having
      IFF_BONDING flag until they are removed.
      But bond1 would lose IFF_BONDING at ->ndo_del_slave() because that routine
      do not check whether the slave device is the bonding type or not.
      This patch adds the interface type check routine before removing
      IFF_BONDING flag.
      
      Test commands:
          ip link add bond0 type bond
          ip link add bond1 type bond
          ip link set bond1 master bond0
          ip link set bond1 nomaster
          ip link del bond1 type bond
          ip link add bond1 type bond
      
      Splat looks like:
      [  226.665555] proc_dir_entry 'bonding/bond1' already registered
      [  226.666440] WARNING: CPU: 0 PID: 737 at fs/proc/generic.c:361 proc_register+0x2a9/0x3e0
      [  226.667571] Modules linked in: bonding af_packet sch_fq_codel ip_tables x_tables unix
      [  226.668662] CPU: 0 PID: 737 Comm: ip Not tainted 5.4.0-rc3+ #96
      [  226.669508] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  226.670652] RIP: 0010:proc_register+0x2a9/0x3e0
      [  226.671612] Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 39 01 00 00 48 8b 04 24 48 89 ea 48 c7 c7 a0 0b 14 9f 48 8b b0 e
      0 00 00 00 e8 07 e7 88 ff <0f> 0b 48 c7 c7 40 2d a5 9f e8 59 d6 23 01 48 8b 4c 24 10 48 b8 00
      [  226.675007] RSP: 0018:ffff888050e17078 EFLAGS: 00010282
      [  226.675761] RAX: dffffc0000000008 RBX: ffff88805fdd0f10 RCX: ffffffff9dd344e2
      [  226.676757] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88806c9f6b8c
      [  226.677751] RBP: ffff8880507160f3 R08: ffffed100d940019 R09: ffffed100d940019
      [  226.678761] R10: 0000000000000001 R11: ffffed100d940018 R12: ffff888050716008
      [  226.679757] R13: ffff8880507160f2 R14: dffffc0000000000 R15: ffffed100a0e2c1e
      [  226.680758] FS:  00007fdc217cc0c0(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
      [  226.681886] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  226.682719] CR2: 00007f49313424d0 CR3: 0000000050e46001 CR4: 00000000000606f0
      [  226.683727] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  226.684725] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  226.685681] Call Trace:
      [  226.687089]  proc_create_seq_private+0xb3/0xf0
      [  226.687778]  bond_create_proc_entry+0x1b3/0x3f0 [bonding]
      [  226.691458]  bond_netdev_event+0x433/0x970 [bonding]
      [  226.692139]  ? __module_text_address+0x13/0x140
      [  226.692779]  notifier_call_chain+0x90/0x160
      [  226.693401]  register_netdevice+0x9b3/0xd80
      [  226.694010]  ? alloc_netdev_mqs+0x854/0xc10
      [  226.694629]  ? netdev_change_features+0xa0/0xa0
      [  226.695278]  ? rtnl_create_link+0x2ed/0xad0
      [  226.695849]  bond_newlink+0x2a/0x60 [bonding]
      [  226.696422]  __rtnl_newlink+0xb9f/0x11b0
      [  226.696968]  ? rtnl_link_unregister+0x220/0x220
      [ ... ]
      
      Fixes: 0b680e75 ("[PATCH] bonding: Add priv_flag to avoid event mishandling")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65de65d9
    • T
      net: core: add generic lockdep keys · ab92d68f
      Taehee Yoo 提交于
      Some interface types could be nested.
      (VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI, VXLAN, etc..)
      These interface types should set lockdep class because, without lockdep
      class key, lockdep always warn about unexisting circular locking.
      
      In the current code, these interfaces have their own lockdep class keys and
      these manage itself. So that there are so many duplicate code around the
      /driver/net and /net/.
      This patch adds new generic lockdep keys and some helper functions for it.
      
      This patch does below changes.
      a) Add lockdep class keys in struct net_device
         - qdisc_running, xmit, addr_list, qdisc_busylock
         - these keys are used as dynamic lockdep key.
      b) When net_device is being allocated, lockdep keys are registered.
         - alloc_netdev_mqs()
      c) When net_device is being free'd llockdep keys are unregistered.
         - free_netdev()
      d) Add generic lockdep key helper function
         - netdev_register_lockdep_key()
         - netdev_unregister_lockdep_key()
         - netdev_update_lockdep_key()
      e) Remove unnecessary generic lockdep macro and functions
      f) Remove unnecessary lockdep code of each interfaces.
      
      After this patch, each interface modules don't need to maintain
      their lockdep keys.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab92d68f
  5. 24 10月, 2019 1 次提交
  6. 23 10月, 2019 7 次提交
  7. 22 10月, 2019 1 次提交
  8. 20 10月, 2019 3 次提交
新手
引导
客服 返回
顶部