linux-stable.git/drivers/net, branch v6.2.13

wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()

2023-04-26T12:30:03+00:00

commit 0f2a4af27b649c13ba76431552fe49c60120d0f6 upstream.

This partially reverts commit e161d4b60ae3a5356e07202e0bfedb5fad82c6aa.

Turns out the channelmap variable is not actually read-only, it's modified
through the MCI_GPM_CLR_CHANNEL_BIT() macro further down in the function,
so making it read-only causes page faults when that code is hit.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217183
Link: https://lore.kernel.org/r/20230413214118.153781-1-toke@toke.dk
Fixes: e161d4b60ae3 ("wifi: ath9k: Make arrays prof_prio and channelmap static const")
Cc: stable@vger.kernel.org
Signed-off-by: Toke Høiland-Jørgensen 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen/netback: use same error messages for same errors

2023-04-26T12:30:01+00:00

[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]

Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.

Suggested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Link: https://lore.kernel.org/r/20230329080259.14823-1-jgross@suse.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

net: dsa: b53: mmap: add phy ops

2023-04-26T12:30:00+00:00

[ Upstream commit 45977e58ce65ed0459edc9a0466d9dfea09463f5 ]

Implement phy_read16() and phy_write16() ops for B53 MMAP to avoid accessing
B53_PORT_MII_PAGE registers which hangs the device.
This access should be done through the MDIO Mux bus controller.

Signed-off-by: Álvaro Fernández Rojas 
Acked-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

e1000e: Disable TSO on i219-LM card to increase speed

2023-04-26T12:29:59+00:00

[ Upstream commit 67d47b95119ad589b0a0b16b88b1dd9a04061ced ]

While using i219-LM card currently it was only possible to achieve
about 60% of maximum speed due to regression introduced in Linux 5.8.
This was caused by TSO not being disabled by default despite commit
f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround").
Fix that by disabling TSO during driver probe.

Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround")
Signed-off-by: Sebastian Basierski 
Signed-off-by: Mateusz Palczewski 
Tested-by: Naama Meir 
Signed-off-by: Tony Nguyen 
Reviewed-by: Simon Horman 
Link: https://lore.kernel.org/r/20230417205345.1030801-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

bnxt_en: fix free-runnig PHC mode

2023-04-26T12:29:58+00:00

[ Upstream commit 8c154d272c3e03b100baaf1df473f22a78fa403e ]

The patch in fixes changed the way real-time mode is chosen for PHC on
the NIC. Apparently there is one more use case of the check outside of
ptp part of the driver which was not converted to the new macro and is
making a lot of noise in free-running mode.

Fixes: 131db4991622 ("bnxt_en: reset PHC frequency in free-running mode")
Signed-off-by: Vadim Fedorenko 
Reviewed-by: Michael Chan 
Reviewed-by: Pavan Chebbi 
Link: https://lore.kernel.org/r/20230418202511.1544735-1-vadfed@meta.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: dsa: microchip: ksz8795: Correctly handle huge frame configuration

2023-04-26T12:29:58+00:00

[ Upstream commit 3d2f8f1f184c60508f7af3022536651d7ac2dd07 ]

Because of the logic in place, SW_HUGE_PACKET can never be set.
(If the first condition is true, then the 2nd one is also true, but is not
executed)

Change the logic and update each bit individually.

Fixes: 29d1e85f45e0 ("net: dsa: microchip: ksz8: add MTU configuration support")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Oleksij Rempel 
Reviewed-by: Simon Horman 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Link: https://lore.kernel.org/r/43107d9e8b5b8b05f0cbd4e1f47a2bb88c8747b2.1681755535.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

mlxsw: pci: Fix possible crash during initialization

2023-04-26T12:29:58+00:00

[ Upstream commit 1f64757ee2bb22a93ec89b4c71707297e8cca0ba ]

During initialization the driver issues a reset command via its command
interface in order to remove previous configuration from the device.

After issuing the reset, the driver waits for 200ms before polling on
the "system_status" register using memory-mapped IO until the device
reaches a ready state (0x5E). The wait is necessary because the reset
command only triggers the reset, but the reset itself happens
asynchronously. If the driver starts polling too soon, the read of the
"system_status" register will never return and the system will crash
[1].

The issue was discovered when the device was flashed with a development
firmware version where the reset routine took longer to complete. The
issue was fixed in the firmware, but it exposed the fact that the
current wait time is borderline.

Fix by increasing the wait time from 200ms to 400ms. With this patch and
the buggy firmware version, the issue did not reproduce in 10 reboots
whereas without the patch the issue is reproduced quite consistently.

[1]
mce: CPUs not responding to MCE broadcast (may include false positives): 0,4
mce: CPUs not responding to MCE broadcast (may include false positives): 0,4
Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
Shutting down cpus with NMI
Kernel Offset: 0x12000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Fixes: ac004e84164e ("mlxsw: pci: Wait longer before accessing the device after reset")
Signed-off-by: Ido Schimmel
Reviewed-by: Petr Machata
Signed-off-by: Petr Machata
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin

bonding: Fix memory leak when changing bond type to Ethernet

2023-04-26T12:29:58+00:00

[ Upstream commit c484fcc058bada604d7e4e5228d4affb646ddbc2 ]

When a net device is put administratively up, its 'IFF_UP' flag is set
(if not set already) and a 'NETDEV_UP' notification is emitted, which
causes the 8021q driver to add VLAN ID 0 on the device. The reverse
happens when a net device is put administratively down.

When changing the type of a bond to Ethernet, its 'IFF_UP' flag is
incorrectly cleared, resulting in the kernel skipping the above process
and VLAN ID 0 being leaked [1].

Fix by restoring the flag when changing the type to Ethernet, in a
similar fashion to the restoration of the 'IFF_SLAVE' flag.

The issue can be reproduced using the script in [2], with example out
before and after the fix in [3].

[1]
unreferenced object 0xffff888103479900 (size 256):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    00 a0 0c 15 81 88 ff ff 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmalloc_trace+0x2a/0xe0
    [] vlan_vid_add+0x30c/0x790
    [] vlan_device_event+0x1491/0x21a0
    [] notifier_call_chain+0xbe/0x1f0
    [] call_netdevice_notifiers_info+0xba/0x150
    [] __dev_notify_flags+0x132/0x2e0
    [] dev_change_flags+0x11f/0x180
    [] do_setlink+0xb96/0x4060
    [] __rtnl_newlink+0xc0a/0x18a0
    [] rtnl_newlink+0x6c/0xa0
    [] rtnetlink_rcv_msg+0x43e/0xe00
    [] netlink_rcv_skb+0x170/0x440
    [] netlink_unicast+0x53f/0x810
    [] netlink_sendmsg+0x96b/0xe90
    [] ____sys_sendmsg+0x30f/0xa70
    [] ___sys_sendmsg+0x13a/0x1e0
unreferenced object 0xffff88810f6a83e0 (size 32):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    a0 99 47 03 81 88 ff ff a0 99 47 03 81 88 ff ff  ..G.......G.....
    81 00 00 00 01 00 00 00 cc cc cc cc cc cc cc cc  ................
  backtrace:
    [] kmalloc_trace+0x2a/0xe0
    [] vlan_vid_add+0x409/0x790
    [] vlan_device_event+0x1491/0x21a0
    [] notifier_call_chain+0xbe/0x1f0
    [] call_netdevice_notifiers_info+0xba/0x150
    [] __dev_notify_flags+0x132/0x2e0
    [] dev_change_flags+0x11f/0x180
    [] do_setlink+0xb96/0x4060
    [] __rtnl_newlink+0xc0a/0x18a0
    [] rtnl_newlink+0x6c/0xa0
    [] rtnetlink_rcv_msg+0x43e/0xe00
    [] netlink_rcv_skb+0x170/0x440
    [] netlink_unicast+0x53f/0x810
    [] netlink_sendmsg+0x96b/0xe90
    [] ____sys_sendmsg+0x30f/0xa70
    [] ___sys_sendmsg+0x13a/0x1e0

[2]
ip link add name t-nlmon type nlmon
ip link add name t-dummy type dummy
ip link add name t-bond type bond mode active-backup

ip link set dev t-bond up
ip link set dev t-nlmon master t-bond
ip link set dev t-nlmon nomaster
ip link show dev t-bond
ip link set dev t-dummy master t-bond
ip link show dev t-bond

ip link del dev t-bond
ip link del dev t-dummy
ip link del dev t-nlmon

[3]
Before:

12: t-bond:  mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 46:57:39:a4:46:a2 brd ff:ff:ff:ff:ff:ff

After:

12: t-bond:  mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 66:48:7b:74:b6:8a brd ff:ff:ff:ff:ff:ff

Fixes: e36b9d16c6a6 ("bonding: clean muticast addresses when device changes type")
Fixes: 75c78500ddad ("bonding: remap muticast addresses without using dev_close() and dev_open()")
Fixes: 9ec7eb60dcbc ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change")
Reported-by: Mirsad Goran Todorovac 
Link: https://lore.kernel.org/netdev/78a8a03b-6070-3e6b-5042-f848dab16fb8@alu.unizg.hr/
Tested-by: Mirsad Goran Todorovac 
Signed-off-by: Ido Schimmel 
Acked-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

mlxfw: fix null-ptr-deref in mlxfw_mfa2_tlv_next()

2023-04-26T12:29:57+00:00

[ Upstream commit c0e73276f0fcbbd3d4736ba975d7dc7a48791b0c ]

Function mlxfw_mfa2_tlv_multi_get() returns NULL if 'tlv' in
question does not pass checks in mlxfw_mfa2_tlv_payload_get(). This
behaviour may lead to NULL pointer dereference in 'multi->total_len'.
Fix this issue by testing mlxfw_mfa2_tlv_multi_get()'s return value
against NULL.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process")
Co-developed-by: Natalia Petrova 
Signed-off-by: Nikita Zhandarovich 
Reviewed-by: Ido Schimmel 
Link: https://lore.kernel.org/r/20230417120718.52325-1-n.zhandarovich@fintech.ru
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

bnxt_en: Do not initialize PTP on older P3/P4 chips

2023-04-26T12:29:57+00:00

[ Upstream commit e8b51a1a15d5a3cce231e0669f6a161dc5bb9b75 ]

The driver does not support PTP on these older chips and it is assuming
that firmware on these older chips will not return the
PORT_MAC_PTP_QCFG_RESP_FLAGS_HWRM_ACCESS flag in __bnxt_hwrm_ptp_qcfg(),
causing the function to abort quietly.

But newer firmware now sets this flag and so __bnxt_hwrm_ptp_qcfg()
will proceed further.  Eventually it will fail in bnxt_ptp_init() ->
bnxt_map_ptp_regs() because there is no code to support the older chips.
The driver will then complain:

"PTP initialization failed.\n"

Fix it so that we abort quietly earlier without going through the
unnecessary steps and alarming the user with the warning log.

Fixes: ae5c42f0b92c ("bnxt_en: Get PTP hardware capability from firmware")
Signed-off-by: Michael Chan 
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin