Skip to content

L
linux
Switch branch/tag
  1. 21 Oct, 2020 16 commits
  3. 20 Oct, 2020 13 commits
  5. 19 Oct, 2020 1 commit
  7. 18 Oct, 2020 5 commits
    • Taehee Yoo's avatar
      net: core: use list_del_init() instead of list_del() in netdev_run_todo() · 0e8b8d6a
      Taehee Yoo authored 
      dev->unlink_list is reused unless dev is deleted.
So, list_del() should not be used.
Due to using list_del(), dev->unlink_list can't be reused so that
dev->nested_level update logic doesn't work.
In order to fix this bug, list_del_init() should be used instead
of list_del().

Test commands:
    ip link add bond0 type bond
    ip link add bond1 type bond
    ip link set bond0 master bond1
    ip link set bond0 nomaster
    ip link set bond1 master bond0
    ip link set bond1 nomaster

Splat looks like:
[  255.750458][ T1030] ============================================
[  255.751967][ T1030] WARNING: possible recursive locking detected
[  255.753435][ T1030] 5.9.0-rc8+ #772 Not tainted
[  255.754553][ T1030] --------------------------------------------
[  255.756047][ T1030] ip/1030 is trying to acquire lock:
[  255.757304][ T1030] ffff88811782a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync_multiple+0xc2/0x150
[  255.760056][ T1030]
[  255.760056][ T1030] but task is already holding lock:
[  255.761862][ T1030] ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
[  255.764581][ T1030]
[  255.764581][ T1030] other info that might help us debug this:
[  255.766645][ T1030]  Possible unsafe locking scenario:
[  255.766645][ T1030]
[  255.768566][ T1030]        CPU0
[  255.769415][ T1030]        ----
[  255.770259][ T1030]   lock(&dev_addr_list_lock_key/1);
[  255.771629][ T1030]   lock(&dev_addr_list_lock_key/1);
[  255.772994][ T1030]
[  255.772994][ T1030]  *** DEADLOCK ***
[  255.772994][ T1030]
[  255.775091][ T1030]  May be due to missing lock nesting notation
[  255.775091][ T1030]
[  255.777182][ T1030] 2 locks held by ip/1030:
[  255.778299][ T1030]  #0: ffffffffb1f63250 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x2e4/0x8b0
[  255.780600][ T1030]  #1: ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
[  255.783411][ T1030]
[  255.783411][ T1030] stack backtrace:
[  255.784874][ T1030] CPU: 7 PID: 1030 Comm: ip Not tainted 5.9.0-rc8+ #772
[  255.786595][ T1030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[  255.789030][ T1030] Call Trace:
[  255.789850][ T1030]  dump_stack+0x99/0xd0
[  255.790882][ T1030]  __lock_acquire.cold.71+0x166/0x3cc
[  255.792285][ T1030]  ? register_lock_class+0x1a30/0x1a30
[  255.793619][ T1030]  ? rcu_read_lock_sched_held+0x91/0xc0
[  255.794963][ T1030]  ? rcu_read_lock_bh_held+0xa0/0xa0
[  255.796246][ T1030]  lock_acquire+0x1b8/0x850
[  255.797332][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
[  255.798624][ T1030]  ? bond_enslave+0x3d4d/0x43e0 [bonding]
[  255.800039][ T1030]  ? check_flags+0x50/0x50
[  255.801143][ T1030]  ? lock_contended+0xd80/0xd80
[  255.802341][ T1030]  _raw_spin_lock_nested+0x2e/0x70
[  255.803592][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
[  255.804897][ T1030]  dev_mc_sync_multiple+0xc2/0x150
[  255.806168][ T1030]  bond_enslave+0x3d58/0x43e0 [bonding]
[  255.807542][ T1030]  ? __lock_acquire+0xe53/0x51b0
[  255.808824][ T1030]  ? bond_update_slave_arr+0xdc0/0xdc0 [bonding]
[  255.810451][ T1030]  ? check_chain_key+0x236/0x5e0
[  255.811742][ T1030]  ? mutex_is_locked+0x13/0x50
[  255.812910][ T1030]  ? rtnl_is_locked+0x11/0x20
[  255.814061][ T1030]  ? netdev_master_upper_dev_get+0xf/0x120
[  255.815553][ T1030]  do_setlink+0x94c/0x3040
[ ... ]

Reported-by: syzbot+4a0f7bc34e3997a6c7df@syzkaller.appspotmail.com
Fixes: 1fc70edb ("net: core: add nested_level variable in net_device")
Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
Link: https://lore.kernel.org/r/20201015162606.9377-1-ap420073@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0e8b8d6a
    • Jakub Kicinski's avatar
      ixgbe: fix probing of multi-port devices with one MDIO · bd7f14df
      Jakub Kicinski authored 
      Ian reports that after upgrade from v5.8.14 to v5.9 only one
of his 4 ixgbe netdevs appear in the system.

Quoting the comment on ixgbe_x550em_a_has_mii():
 * Returns true if hw points to lowest numbered PCI B:D.F x550_em_a device in
 * the SoC.  There are up to 4 MACs sharing a single MDIO bus on the x550em_a,
 * but we only want to register one MDIO bus.

This matches the symptoms, since the return value from
ixgbe_mii_bus_init() is no longer ignored we need to handle
the higher ports of x550em without an error.

Fixes: 09ef193f ("net: ethernet: ixgbe: check the return value of ixgbe_mii_bus_init()")
Reported-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
Tested-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
Acked-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
Link: https://lore.kernel.org/r/20201016232006.3352947-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bd7f14df
    • Anant Thazhemadam's avatar
      net: usb: rtl8150: don't incorrectly assign random MAC addresses · 60f1626f
      Anant Thazhemadam authored 
      In set_ethernet_addr(), if get_registers() succeeds, the ethernet address
that was read must be copied over. Otherwise, a random ethernet address
must be assigned.

get_registers() returns 0 if successful, and negative error number
otherwise. However, in set_ethernet_addr(), this return value is
incorrectly checked.

Since this return value will never be equal to sizeof(node_id), a
random MAC address will always be generated and assigned to the
device; even in cases when get_registers() is successful.

Correctly modifying the condition that checks if get_registers() was
successful or not fixes this problem, and copies the ethernet address
appropriately.

Fixes: b2a0f274 ("net: rtl8150: Use the new usb control message API.")
Signed-off-by: default avatarAnant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20201011173030.141582-1-anant.thazhemadam@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      60f1626f
    • Ido Schimmel's avatar
      selftests: forwarding: Add missing 'rp_filter' configuration · 71a0e29e
      Ido Schimmel authored 
      When 'rp_filter' is configured in strict mode (1) the tests fail because
packets received from the macvlan netdevs would not be forwarded through
them on the reverse path.

Fix this by disabling the 'rp_filter', meaning no source validation is
performed.

Fixes: 1538812e ("selftests: forwarding: Add a test for VXLAN asymmetric routing")
Fixes: 438a4f56 ("selftests: forwarding: Add a test for VXLAN symmetric routing")
Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
Tested-by: default avatarHangbin Liu <liuhangbin@gmail.com>
Link: https://lore.kernel.org/r/20201015084525.135121-1-idosch@idosch.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      71a0e29e
    • Eelco Chaudron's avatar
      net: openvswitch: fix to make sure flow_lookup() is not preempted · f981fc3d
      Eelco Chaudron authored 
      The flow_lookup() function uses per CPU variables, which must be called
with BH disabled. However, this is fine in the general NAPI use case
where the local BH is disabled. But, it's also called from the netlink
context. The below patch makes sure that even in the netlink path, the
BH is disabled.

In addition, u64_stats_update_begin() requires a lock to ensure one writer
which is not ensured here. Making it per-CPU and disabling NAPI (softirq)
ensures that there is always only one writer.

Fixes: eac87c41 ("net: openvswitch: reorder masks array based on usage")
Reported-by: default avatarJuri Lelli <jlelli@redhat.com>
Signed-off-by: default avatarEelco Chaudron <echaudro@redhat.com>
Link: https://lore.kernel.org/r/160295903253.7789.826736662555102345.stgit@ebuildSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f981fc3d
  9. 16 Oct, 2020 5 commits
    • Ioana Ciornei's avatar
      net: pcs-xpcs: depend on MDIO_BUS instead of selecting it · f355a55f
      Ioana Ciornei authored 
      The below compile time error can be seen when PHYLIB is configured as a
module.

 ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_read':
 pcs-xpcs.c:(.text+0x29): undefined reference to `mdiobus_read'
 ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_soft_reset.constprop.7':
 pcs-xpcs.c:(.text+0x80): undefined reference to `mdiobus_write'
 ld: drivers/net/pcs/pcs-xpcs.o: in function `xpcs_config_aneg':
 pcs-xpcs.c:(.text+0x318): undefined reference to `mdiobus_write'
 ld: pcs-xpcs.c:(.text+0x38e): undefined reference to `mdiobus_write'
 ld: pcs-xpcs.c:(.text+0x3eb): undefined reference to `mdiobus_write'
 ld: pcs-xpcs.c:(.text+0x437): undefined reference to `mdiobus_write'
 ld: drivers/net/pcs/pcs-xpcs.o:pcs-xpcs.c:(.text+0xb1e): more undefined references to `mdiobus_write' follow

PHYLIB being a module leads to MDIO_BUS being a module as well while the
XPCS is still built-in. What should happen in this configuration is that
PCS_XPCS should be forced to build as module. However, that select only
acts in the opposite way so we should turn it into a depends.

Fix this up by explicitly depending on MDIO_BUS.
Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Fixes: 2fa4e4b7 ("net: pcs: Move XPCS into new PCS subdirectory")
Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f355a55f
    • Eric Dumazet's avatar
      icmp: randomize the global rate limiter · b38e7819
      Eric Dumazet authored 
      Keyu Man reported that the ICMP rate limiter could be used
by attackers to get useful signal. Details will be provided
in an upcoming academic publication.

Our solution is to add some noise, so that the attackers
no longer can get help from the predictable token bucket limiter.

Fixes: 4cdf507d ("icmp: add a global rate limitation")
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Reported-by: default avatarKeyu Man <kman001@ucr.edu>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b38e7819
    • Dylan Hung's avatar
      net: ftgmac100: Fix Aspeed ast2600 TX hang issue · 137d23ce
      Dylan Hung authored 
      The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to
hang when handling scatter-gather DMA.  Disable the problematic feature
by setting MAC register 0x58 bit28 and bit27.

Fixes: 39bfab88 ("net: ftgmac100: Add support for DT phy-handle property")
Signed-off-by: default avatarDylan Hung <dylan_hung@aspeedtech.com>
Reviewed-by: default avatarJoel Stanley <joel@jms.id.au>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      137d23ce
    • Hoang Huu Le's avatar
      tipc: fix incorrect setting window for bcast link · ec78e318
      Hoang Huu Le authored 
      In commit 16ad3f40
("tipc: introduce variable window congestion control"), we applied
the algorithm to select window size from minimum window to the
configured maximum window for unicast link, and, besides we chose
to keep the window size for broadcast link unchanged and equal (i.e
fix window 50)

However, when setting maximum window variable via command, the window
variable was re-initialized to unexpect value (i.e 32).

We fix this by updating the fix window for broadcast as we stated.

Fixes: 16ad3f40 ("tipc: introduce variable window congestion control")
Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
Signed-off-by: default avatarHoang Huu Le <hoang.h.le@dektech.com.au>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ec78e318
    • Hoang Huu Le's avatar
      tipc: re-configure queue limit for broadcast link · 75cee397
      Hoang Huu Le authored 
      The queue limit of the broadcast link is being calculated base on initial
MTU. However, when MTU value changed (e.g manual changing MTU on NIC
device, MTU negotiation etc.,) we do not re-calculate queue limit.
This gives throughput does not reflect with the change.

So fix it by calling the function to re-calculate queue limit of the
broadcast link.
Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
Signed-off-by: default avatarHoang Huu Le <hoang.h.le@dektech.com.au>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      75cee397
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7