1. 17 5月, 2019 1 次提交
    • Y
      net: dsa: Fix error cleanup path in dsa_init_module · 9284895b
      YueHaibing 提交于
      [ Upstream commit 68be930249d051fd54d3d99156b3dcadcb2a1f9b ]
      
      BUG: unable to handle kernel paging request at ffffffffa01c5430
      PGD 3270067 P4D 3270067 PUD 3271063 PMD 230bc5067 PTE 0
      Oops: 0000 [#1
      CPU: 0 PID: 6159 Comm: modprobe Not tainted 5.1.0+ #33
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:raw_notifier_chain_register+0x16/0x40
      Code: 63 f8 66 90 e9 5d ff ff ff 90 90 90 90 90 90 90 90 90 90 90 55 48 8b 07 48 89 e5 48 85 c0 74 1c 8b 56 10 3b 50 10 7e 07 eb 12 <39> 50 10 7c 0d 48 8d 78 08 48 8b 40 08 48 85 c0 75 ee 48 89 46 08
      RSP: 0018:ffffc90001c33c08 EFLAGS: 00010282
      RAX: ffffffffa01c5420 RBX: ffffffffa01db420 RCX: 4fcef45928070a8b
      RDX: 0000000000000000 RSI: ffffffffa01db420 RDI: ffffffffa01b0068
      RBP: ffffc90001c33c08 R08: 000000003e0a33d0 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000094443661 R12: ffff88822c320700
      R13: ffff88823109be80 R14: 0000000000000000 R15: ffffc90001c33e78
      FS:  00007fab8bd08540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa01c5430 CR3: 00000002297ea000 CR4: 00000000000006f0
      Call Trace:
       register_netdevice_notifier+0x43/0x250
       ? 0xffffffffa01e0000
       dsa_slave_register_notifier+0x13/0x70 [dsa_core
       ? 0xffffffffa01e0000
       dsa_init_module+0x2e/0x1000 [dsa_core
       do_one_initcall+0x6c/0x3cc
       ? do_init_module+0x22/0x1f1
       ? rcu_read_lock_sched_held+0x97/0xb0
       ? kmem_cache_alloc_trace+0x325/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Cleanup allocated resourses if there are errors,
      otherwise it will trgger memleak.
      
      Fixes: c9eb3e0f ("net: dsa: Add support for learning FDB through notification")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9284895b
  2. 13 2月, 2019 3 次提交
    • R
      net: dsa: slave: Don't propagate flag changes on down slave interfaces · 8104a5e7
      Rundong Ge 提交于
      [ Upstream commit 17ab4f61b8cd6f9c38e9d0b935d86d73b5d0d2b5 ]
      
      The unbalance of master's promiscuity or allmulti will happen after ifdown
      and ifup a slave interface which is in a bridge.
      
      When we ifdown a slave interface , both the 'dsa_slave_close' and
      'dsa_slave_change_rx_flags' will clear the master's flags. The flags
      of master will be decrease twice.
      In the other hand, if we ifup the slave interface again, since the
      slave's flags were cleared the 'dsa_slave_open' won't set the master's
      flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if'
      will set the master's flags. The flags of master is increase once.
      
      Only propagating flag changes when a slave interface is up makes
      sure this does not happen. The 'vlan_dev_change_rx_flags' had the
      same problem and was fixed, and changes here follows that fix.
      
      Fixes: 91da11f8 ("net: Distributed Switch Architecture protocol support")
      Signed-off-by: NRundong Ge <rdong.ge@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8104a5e7
    • D
      net: dsa: Fix NULL checking in dsa_slave_set_eee() · c8dfab5c
      Dan Carpenter 提交于
      [ Upstream commit 00670cb8a73b10b10d3c40f045c15411715e4465 ]
      
      This function can't succeed if dp->pl is NULL.  It will Oops inside the
      call to return phylink_ethtool_get_eee(dp->pl, e);
      
      Fixes: 1be52e97 ("dsa: slave: eee: Allow ports to use phylink")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8dfab5c
    • M
      net: dsa: Fix lockdep false positive splat · 98cedccb
      Marc Zyngier 提交于
      [ Upstream commit c8101f7729daee251f4f6505f9d135ec08e1342f ]
      
      Creating a macvtap on a DSA-backed interface results in the following
      splat when lockdep is enabled:
      
      [   19.638080] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready
      [   23.041198] device lan0 entered promiscuous mode
      [   23.043445] device eth0 entered promiscuous mode
      [   23.049255]
      [   23.049557] ============================================
      [   23.055021] WARNING: possible recursive locking detected
      [   23.060490] 5.0.0-rc3-00013-g56c857a1b8d3 #118 Not tainted
      [   23.066132] --------------------------------------------
      [   23.071598] ip/2861 is trying to acquire lock:
      [   23.076171] 00000000f61990cb (_xmit_ETHER){+...}, at: dev_set_rx_mode+0x1c/0x38
      [   23.083693]
      [   23.083693] but task is already holding lock:
      [   23.089696] 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
      [   23.096774]
      [   23.096774] other info that might help us debug this:
      [   23.103494]  Possible unsafe locking scenario:
      [   23.103494]
      [   23.109584]        CPU0
      [   23.112093]        ----
      [   23.114601]   lock(_xmit_ETHER);
      [   23.117917]   lock(_xmit_ETHER);
      [   23.121233]
      [   23.121233]  *** DEADLOCK ***
      [   23.121233]
      [   23.127325]  May be due to missing lock nesting notation
      [   23.127325]
      [   23.134315] 2 locks held by ip/2861:
      [   23.137987]  #0: 000000003b766c72 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x338/0x4e0
      [   23.146231]  #1: 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
      [   23.153757]
      [   23.153757] stack backtrace:
      [   23.158243] CPU: 0 PID: 2861 Comm: ip Not tainted 5.0.0-rc3-00013-g56c857a1b8d3 #118
      [   23.166212] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
      [   23.172843] Call trace:
      [   23.175358]  dump_backtrace+0x0/0x188
      [   23.179116]  show_stack+0x14/0x20
      [   23.182524]  dump_stack+0xb4/0xec
      [   23.185928]  __lock_acquire+0x123c/0x1860
      [   23.190048]  lock_acquire+0xc8/0x248
      [   23.193724]  _raw_spin_lock_bh+0x40/0x58
      [   23.197755]  dev_set_rx_mode+0x1c/0x38
      [   23.201607]  dev_set_promiscuity+0x3c/0x50
      [   23.205820]  dsa_slave_change_rx_flags+0x5c/0x70
      [   23.210567]  __dev_set_promiscuity+0x148/0x1e0
      [   23.215136]  __dev_set_rx_mode+0x74/0x98
      [   23.219167]  dev_uc_add+0x54/0x70
      [   23.222575]  macvlan_open+0x170/0x1d0
      [   23.226336]  __dev_open+0xe0/0x160
      [   23.229830]  __dev_change_flags+0x16c/0x1b8
      [   23.234132]  dev_change_flags+0x20/0x60
      [   23.238074]  do_setlink+0x2d0/0xc50
      [   23.241658]  __rtnl_newlink+0x5f8/0x6e8
      [   23.245601]  rtnl_newlink+0x50/0x78
      [   23.249184]  rtnetlink_rcv_msg+0x360/0x4e0
      [   23.253397]  netlink_rcv_skb+0xe8/0x130
      [   23.257338]  rtnetlink_rcv+0x14/0x20
      [   23.261012]  netlink_unicast+0x190/0x210
      [   23.265043]  netlink_sendmsg+0x288/0x350
      [   23.269075]  sock_sendmsg+0x18/0x30
      [   23.272659]  ___sys_sendmsg+0x29c/0x2c8
      [   23.276602]  __sys_sendmsg+0x60/0xb8
      [   23.280276]  __arm64_sys_sendmsg+0x1c/0x28
      [   23.284488]  el0_svc_common+0xd8/0x138
      [   23.288340]  el0_svc_handler+0x24/0x80
      [   23.292192]  el0_svc+0x8/0xc
      
      This looks fairly harmless (no actual deadlock occurs), and is
      fixed in a similar way to c6894dec ("bridge: fix lockdep
      addr_list_lock false positive splat") by putting the addr_list_lock
      in its own lockdep class.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98cedccb
  3. 28 8月, 2018 1 次提交
  4. 22 8月, 2018 1 次提交
  5. 09 8月, 2018 1 次提交
  6. 02 8月, 2018 1 次提交
  7. 19 7月, 2018 1 次提交
  8. 26 6月, 2018 1 次提交
  9. 12 6月, 2018 1 次提交
  10. 01 6月, 2018 1 次提交
  11. 20 5月, 2018 1 次提交
  12. 19 5月, 2018 1 次提交
  13. 12 5月, 2018 3 次提交
    • F
      net: dsa: Plug in PHYLINK support · aab9c406
      Florian Fainelli 提交于
      Add support for PHYLINK within the DSA subsystem in order to support more
      complex devices such as pluggable (SFP) and non-pluggable (SFF) modules, 10G
      PHYs, and traditional PHYs. Using PHYLINK allows us to drop some amount of
      complexity we had while probing fixed and non-fixed PHYs using Device Tree.
      
      Because PHYLINK separates the Ethernet MAC/port configuration into different
      stages, we let switch drivers implement those, and for now, we maintain
      functionality by calling dsa_slave_adjust_link() during
      phylink_mac_link_{up,down} which provides semantically equivalent steps.
      
      Drivers willing to take advantage of PHYLINK should implement the phylink_mac_*
      operations that DSA wraps.
      
      We cannot quite remove the adjust_link() callback just yet, because a number of
      drivers rely on that for configuring their "CPU" and "DSA" ports, this is done
      dsa_port_setup_phy_of() and dsa_port_fixed_link_register_of() still.
      
      Drivers that utilize fixed links for user-facing ports (e.g: bcm_sf2) will need
      to implement phylink_mac_ops from now on to preserve functionality, since PHYLINK
      *does not* create a phy_device instance for fixed links.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aab9c406
    • F
      net: dsa: Eliminate dsa_slave_get_link() · c4aef9fc
      Florian Fainelli 提交于
      Since we use PHYLIB to manage the per-port link indication, this will
      also be reflected correctly in the network device's carrier state, so we
      can use ethtool_op_get_link() instead.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4aef9fc
    • F
      net: dsa: Add PHYLINK switch operations · 11d8f3dd
      Florian Fainelli 提交于
      In preparation for adding support for PHYLINK within DSA, define a number of
      operations that we will need and that switch drivers can start implementing.
      Proper integration with PHYLINK will follow in subsequent patches.
      
      We start selecting PHYLINK (which implies PHYLIB) in net/dsa/Kconfig
      such that drivers can be guaranteed that this dependency is properly
      taken care of and can start referencing PHYLINK helper functions without
      requiring stubs or anything.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d8f3dd
  14. 11 5月, 2018 1 次提交
    • V
      net: dsa: fix added_by_user switchdev notification · a37fb855
      Vivien Didelot 提交于
      Commit 161d82de ("net: bridge: Notify about !added_by_user FDB
      entries") causes the below oops when bringing up a slave interface,
      because dsa_port_fdb_add is still scheduled, but with a NULL address.
      
      To fix this, keep the dsa_slave_switchdev_event function agnostic of the
      notified info structure and handle the added_by_user flag in the
      specific dsa_slave_switchdev_event_work function.
      
          [   75.512263] Unable to handle kernel NULL pointer dereference at virtual address 00000000
          [   75.519063] pgd = (ptrval)
          [   75.520545] [00000000] *pgd=00000000
          [   75.522839] Internal error: Oops: 17 [#1] ARM
          [   75.525898] Modules linked in:
          [   75.527673] CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 4.17.0-rc2 #78
          [   75.532988] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
          [   75.538153] Workqueue: dsa_ordered dsa_slave_switchdev_event_work
          [   75.542970] PC is at mv88e6xxx_port_db_load_purge+0x60/0x1b0
          [   75.547341] LR is at mdiobus_read_nested+0x6c/0x78
          [   75.550833] pc : [<804cd5c0>]    lr : [<804bba84>]    psr: 60070013
          [   75.555796] sp : 9f54bd78  ip : 9f54bd87  fp : 9f54bddc
          [   75.559719] r10: 00000000  r9 : 0000000e  r8 : 9f6a6010
          [   75.563643] r7 : 00000000  r6 : 81203048  r5 : 9f6a6010  r4 : 9f6a601c
          [   75.568867] r3 : 00000000  r2 : 00000000  r1 : 0000000d  r0 : 00000000
          [   75.574094] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
          [   75.579933] Control: 10c53c7d  Table: 9de20059  DAC: 00000051
          [   75.584384] Process kworker/u2:1 (pid: 9, stack limit = 0x(ptrval))
          [   75.589349] Stack: (0x9f54bd78 to 0x9f54c000)
          [   75.592406] bd60:                                                       00000000 00000000
          [   75.599295] bd80: 00000391 9f299d10 9f299d68 8014317c 9f7f0000 8120af00 00006dc2 00000000
          [   75.606186] bda0: 8120af00 00000000 9f54bdec 1c9f5d92 8014317c 9f6a601c 9f6a6010 00000000
          [   75.613076] bdc0: 00000000 00000000 9dd1141c 8125a0b4 9f54be0c 9f54bde0 804cd8a8 804cd56c
          [   75.619966] bde0: 0000000e 80143680 00000001 9dce9c1c 81203048 9dce9c10 00000003 00000000
          [   75.626858] be00: 9f54be5c 9f54be10 806abcac 804cd864 9f54be54 80143664 8014317c 80143054
          [   75.633748] be20: ffcaa81d 00000000 812030b0 1c9f5d92 00000000 81203048 9f54beb4 00000003
          [   75.640639] be40: ffffffff 00000000 9dd1141c 8125a0b4 9f54be84 9f54be60 80138e98 806abb18
          [   75.647529] be60: 81203048 9ddc4000 9dce9c54 9f72a300 00000000 00000000 9f54be9c 9f54be88
          [   75.654420] be80: 801390bc 80138e50 00000000 9dce9c54 9f54beac 9f54bea0 806a9524 801390a0
          [   75.661310] bea0: 9f54bedc 9f54beb0 806a9c7c 806a950c 9f54becc 00000000 00000000 00000000
          [   75.668201] bec0: 9f540000 1c9f5d92 805fe604 9ddffc00 9f54befc 9f54bee0 806ab228 806a9c38
          [   75.675092] bee0: 806ab178 9ddffc00 9f4c1900 9f40d200 9f54bf34 9f54bf00 80131e30 806ab184
          [   75.681983] bf00: 9f40d214 9f54a038 9f40d200 9f40d200 9f4c1918 812119a0 9f40d214 9f54a038
          [   75.688873] bf20: 9f40d200 9f4c1900 9f54bf7c 9f54bf38 80132124 80131d1c 9f5f2dd8 00000000
          [   75.695764] bf40: 812119a0 9f54a038 812119a0 81259c5b 9f5f2dd8 9f5f2dc0 9f53dbc0 00000000
          [   75.702655] bf60: 9f4c1900 801320b4 9f5f2dd8 9f4f7e88 9f54bfac 9f54bf80 80137ad0 801320c0
          [   75.709544] bf80: 9f54a000 9f53dbc0 801379a0 00000000 00000000 00000000 00000000 00000000
          [   75.716434] bfa0: 00000000 9f54bfb0 801010e8 801379ac 00000000 00000000 00000000 00000000
          [   75.723324] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          [   75.730206] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
          [   75.737083] Backtrace:
          [   75.738252] [<804cd560>] (mv88e6xxx_port_db_load_purge) from [<804cd8a8>] (mv88e6xxx_port_fdb_add+0x50/0x68)
          [   75.746795]  r10:8125a0b4 r9:9dd1141c r8:00000000 r7:00000000 r6:00000000 r5:9f6a6010
          [   75.753323]  r4:9f6a601c
          [   75.754570] [<804cd858>] (mv88e6xxx_port_fdb_add) from [<806abcac>] (dsa_switch_event+0x1a0/0x660)
          [   75.762238]  r8:00000000 r7:00000003 r6:9dce9c10 r5:81203048 r4:9dce9c1c
          [   75.767655] [<806abb0c>] (dsa_switch_event) from [<80138e98>] (notifier_call_chain+0x54/0x94)
          [   75.774893]  r10:8125a0b4 r9:9dd1141c r8:00000000 r7:ffffffff r6:00000003 r5:9f54beb4
          [   75.781423]  r4:81203048
          [   75.782672] [<80138e44>] (notifier_call_chain) from [<801390bc>] (raw_notifier_call_chain+0x28/0x30)
          [   75.790514]  r9:00000000 r8:00000000 r7:9f72a300 r6:9dce9c54 r5:9ddc4000 r4:81203048
          [   75.796982] [<80139094>] (raw_notifier_call_chain) from [<806a9524>] (dsa_port_notify+0x24/0x38)
          [   75.804483] [<806a9500>] (dsa_port_notify) from [<806a9c7c>] (dsa_port_fdb_add+0x50/0x6c)
          [   75.811371] [<806a9c2c>] (dsa_port_fdb_add) from [<806ab228>] (dsa_slave_switchdev_event_work+0xb0/0x10c)
          [   75.819635]  r4:9ddffc00
          [   75.820885] [<806ab178>] (dsa_slave_switchdev_event_work) from [<80131e30>] (process_one_work+0x120/0x3a4)
          [   75.829241]  r6:9f40d200 r5:9f4c1900 r4:9ddffc00 r3:806ab178
          [   75.833612] [<80131d10>] (process_one_work) from [<80132124>] (worker_thread+0x70/0x574)
          [   75.840415]  r10:9f4c1900 r9:9f40d200 r8:9f54a038 r7:9f40d214 r6:812119a0 r5:9f4c1918
          [   75.846945]  r4:9f40d200
          [   75.848191] [<801320b4>] (worker_thread) from [<80137ad0>] (kthread+0x130/0x160)
          [   75.854300]  r10:9f4f7e88 r9:9f5f2dd8 r8:801320b4 r7:9f4c1900 r6:00000000 r5:9f53dbc0
          [   75.860830]  r4:9f5f2dc0
          [   75.862076] [<801379a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
          [   75.867999] Exception stack(0x9f54bfb0 to 0x9f54bff8)
          [   75.871753] bfa0:                                     00000000 00000000 00000000 00000000
          [   75.878640] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          [   75.885519] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
          [   75.890844]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801379a0
          [   75.897377]  r4:9f53dbc0 r3:9f54a000
          [   75.899663] Code: e3a02000 e3a03000 e14b26f4 e24bc055 (e5973000)
          [   75.904575] ---[ end trace fbca818a124dbf0d ]---
      
      Fixes: 816a3bed ("switchdev: Add fdb.added_by_user to switchdev notifications")
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a37fb855
  15. 04 5月, 2018 1 次提交
  16. 27 4月, 2018 4 次提交
  17. 08 4月, 2018 1 次提交
  18. 13 3月, 2018 1 次提交
  19. 05 3月, 2018 1 次提交
  20. 15 2月, 2018 2 次提交
  21. 24 1月, 2018 1 次提交
  22. 06 1月, 2018 1 次提交
  23. 03 1月, 2018 1 次提交
  24. 15 12月, 2017 1 次提交
  25. 14 12月, 2017 1 次提交
  26. 08 12月, 2017 1 次提交
  27. 07 12月, 2017 1 次提交
  28. 06 12月, 2017 1 次提交
  29. 03 12月, 2017 4 次提交