* [PATCH net-next] octeontx2-af: Use LMAC_AF_ERR codes in CGX handlers
From: nshettyj @ 2026-07-17 5:11 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Hariprasad Kelam, Nitin Shetty J, Sunil Goutham, Ratheesh Kannoth,
Geetha sowjanya, Subbaraya Sundeep, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
From: Hariprasad Kelam <hkelam@marvell.com>
When a netdev that is not mapped to a MAC block (cgx/rpm) requests a
MAC feature, the AF driver currently returns generic errors like -EPERM.
Replace these generic error codes with driver-specific LMAC_AF_ERR_*
error codes to provide better debugging information.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
---
.../ethernet/marvell/octeontx2/af/rvu_cgx.c | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
index 4ff3935ed3fe..5558bb66bf9f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
@@ -709,7 +709,7 @@ int rvu_mbox_handler_cgx_mac_addr_add(struct rvu *rvu,
int rc = 0;
if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
if (rvu_npc_exact_has_match_table(rvu))
return rvu_npc_exact_mac_addr_add(rvu, req, rsp);
@@ -732,7 +732,7 @@ int rvu_mbox_handler_cgx_mac_addr_del(struct rvu *rvu,
u8 cgx_id, lmac_id;
if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
if (rvu_npc_exact_has_match_table(rvu))
return rvu_npc_exact_mac_addr_del(rvu, req, rsp);
@@ -789,7 +789,7 @@ int rvu_mbox_handler_cgx_promisc_enable(struct rvu *rvu, struct msg_req *req,
u8 cgx_id, lmac_id;
if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
/* Disable drop on non hit rule */
if (rvu_npc_exact_has_match_table(rvu))
@@ -808,7 +808,7 @@ int rvu_mbox_handler_cgx_promisc_disable(struct rvu *rvu, struct msg_req *req,
u8 cgx_id, lmac_id;
if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
/* Disable drop on non hit rule */
if (rvu_npc_exact_has_match_table(rvu))
@@ -877,7 +877,7 @@ static int rvu_cgx_config_linkevents(struct rvu *rvu, u16 pcifunc, bool en)
u8 cgx_id, lmac_id;
if (!is_cgx_config_permitted(rvu, pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
@@ -915,7 +915,7 @@ int rvu_mbox_handler_cgx_get_linkinfo(struct rvu *rvu, struct msg_req *req,
pf = rvu_get_pf(rvu->pdev, req->hdr.pcifunc);
if (!is_pf_cgxmapped(rvu, pf))
- return -ENODEV;
+ return LMAC_AF_ERR_PF_NOT_MAPPED;
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
@@ -975,7 +975,7 @@ static int rvu_cgx_config_intlbk(struct rvu *rvu, u16 pcifunc, bool en)
u8 cgx_id, lmac_id;
if (!is_cgx_config_permitted(rvu, pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
mac_ops = get_mac_ops(rvu_cgx_pdata(cgx_id, rvu));
@@ -1178,7 +1178,7 @@ int rvu_mbox_handler_cgx_set_fec_param(struct rvu *rvu,
u8 cgx_id, lmac_id;
if (!is_pf_cgxmapped(rvu, pf))
- return -EPERM;
+ return LMAC_AF_ERR_PF_NOT_MAPPED;
if (req->fec == OTX2_FEC_OFF)
req->fec = OTX2_FEC_NONE;
@@ -1197,7 +1197,7 @@ int rvu_mbox_handler_cgx_get_aux_link_info(struct rvu *rvu, struct msg_req *req,
return LMAC_AF_ERR_FIRMWARE_DATA_NOT_MAPPED;
if (!is_pf_cgxmapped(rvu, pf))
- return -EPERM;
+ return LMAC_AF_ERR_PF_NOT_MAPPED;
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
@@ -1226,7 +1226,7 @@ int rvu_mbox_handler_cgx_set_link_mode(struct rvu *rvu,
return LMAC_AF_ERR_FIRMWARE_DATA_NOT_MAPPED;
if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
- return -EPERM;
+ return LMAC_AF_ERR_PERM_DENIED;
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_idx, &lmac);
cgxd = rvu_cgx_pdata(cgx_idx, rvu);
--
2.48.1
^ permalink raw reply related
* Re: [PATCH rdma-next v3 14/14] RDMA/selftests: Add rxe_netns_names test
From: Zhu Yanjun @ 2026-07-17 4:22 UTC (permalink / raw)
To: Jiri Pirko, linux-rdma, yanjun.zhu@linux.dev
Cc: cgroups, netdev, linux-s390, linux-kselftest, jgg, leon, parav,
mbloch, cmeiohas, roman.gushchin, bvanassche, zyjzyj2000, shuah,
tj, mkoutny, hannes, alibuda, dust.li, sidraya, wenjia, cui.tao
In-Reply-To: <20260716132316.1495242-15-jiri@resnulli.us>
在 2026/7/16 6:23, Jiri Pirko 写道:
> From: Jiri Pirko <jiri@nvidia.com>
>
> Add a kselftest script that exercises per-netns RDMA device naming
> with RXE. Cover duplicate names across namespaces, move conflict
> handling, move-with-rename, and same-namespace rename requests.
>
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
> v2->v3:
> - added wait for rdma devices are removed
> - added retry for old rdma netns mode restore
> v1->v2:
> - fixed ktap_set_plan
> - s/RXE_A/RXE_SAME/ in dup rename
> ---
> tools/testing/selftests/rdma/Makefile | 3 +-
> tools/testing/selftests/rdma/config | 2 +
> .../testing/selftests/rdma/rxe_netns_names.sh | 334 ++++++++++++++++++
> 3 files changed, 338 insertions(+), 1 deletion(-)
> create mode 100755 tools/testing/selftests/rdma/rxe_netns_names.sh
>
> diff --git a/tools/testing/selftests/rdma/Makefile b/tools/testing/selftests/rdma/Makefile
> index 07af7f15c1bf..a91c14c45006 100644
> --- a/tools/testing/selftests/rdma/Makefile
> +++ b/tools/testing/selftests/rdma/Makefile
> @@ -3,6 +3,7 @@ TEST_PROGS := rxe_rping_between_netns.sh \
> rxe_ipv6.sh \
> rxe_socket_with_netns.sh \
> rxe_test_NETDEV_UNREGISTER.sh \
> - rxe_sent_rcvd_bytes.sh
> + rxe_sent_rcvd_bytes.sh \
> + rxe_netns_names.sh
>
> include ../lib.mk
> diff --git a/tools/testing/selftests/rdma/config b/tools/testing/selftests/rdma/config
> index 4ffb814e253b..e1ff54ec0f57 100644
> --- a/tools/testing/selftests/rdma/config
> +++ b/tools/testing/selftests/rdma/config
> @@ -1,3 +1,5 @@
> CONFIG_TUN
> CONFIG_VETH
> +CONFIG_DUMMY
> +CONFIG_NET_NS
> CONFIG_RDMA_RXE
> diff --git a/tools/testing/selftests/rdma/rxe_netns_names.sh b/tools/testing/selftests/rdma/rxe_netns_names.sh
> new file mode 100755
> index 000000000000..f40118407f4c
> --- /dev/null
> +++ b/tools/testing/selftests/rdma/rxe_netns_names.sh
> @@ -0,0 +1,334 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Exercise RDMA device name handling across network namespaces.
> +
> +source "$(dirname "$0")/../kselftest/ktap_helpers.sh"
> +
> +NAME_PREFIX="rxe_netns_names_$$"
> +NETDEV_PREFIX="rxn$$"
> +NS1="${NAME_PREFIX}ns1"
> +NS2="${NAME_PREFIX}ns2"
> +RXE_A="${NAME_PREFIX}rxe_a"
> +RXE_B="${NAME_PREFIX}rxe_b"
> +RXE_SAME="${NAME_PREFIX}rxe_same"
> +RXE_NEW="${NAME_PREFIX}rxe_new"
> +DUMMY_A="${NETDEV_PREFIX}a"
> +DUMMY_B="${NETDEV_PREFIX}b"
> +OLD_MODE=""
> +MODE_CHANGED=0
> +MODS=("dummy" "rdma_rxe")
> +TEST_SAME_NAMES="same RDMA device name can exist in two net namespaces"
> +TEST_MOVE_CONFLICT="move without rename fails on destination name conflict"
> +TEST_MOVE_RENAME="move then rename succeeds"
> +TEST_COMBINED_MOVE_RENAME="move with requested destination name succeeds"
> +TEST_SAME_NETNS_DUP_RENAME="same-netns rename rejects duplicate name"
> +TEST_TEARDOWN_RETURN="netns delete returns device to init_net and renames on conflict"
> +
> +ksft_skip()
> +{
> + ktap_skip_all "$*"
> + exit "$KSFT_SKIP"
> +}
> +
> +fail()
> +{
> + ktap_exit_fail_msg "$*"
> +}
> +
> +need_cmd()
> +{
> + command -v "$1" >/dev/null 2>&1 || ksft_skip "missing command: $1"
> +}
> +
> +rdma_ns()
> +{
> + local ns=$1
> +
> + shift
> + ip netns exec "$ns" rdma "$@"
> +}
> +
> +rdma_dev_exists()
> +{
> + local ns=$1
> + local dev=$2
> +
> + if [ -n "$ns" ]; then
> + rdma_ns "$ns" dev show "$dev" >/dev/null 2>&1
> + else
> + rdma dev show "$dev" >/dev/null 2>&1
> + fi
> +}
> +
> +add_dummy()
> +{
> + local netdev=$1
> +
> + ip link add "$netdev" type dummy || return 1
> + ip link set "$netdev" up || return 1
> +}
> +
> +add_rxe()
> +{
> + local dev=$1
> + local netdev=$2
> +
> + rdma link add "$dev" type rxe netdev "$netdev"
> +}
> +
> +rdma_dev_on_netdev()
> +{
> + local netdev=$1
> +
> + rdma link show 2>/dev/null | awk -v want="$netdev" '
> + {
> + for (i = 1; i < NF; i++)
> + if ($i == "netdev" && $(i + 1) == want) {
> + dev = $2
> + sub(/\/.*/, "", dev)
> + print dev
> + exit
> + }
> + }'
> +}
> +
> +wait_rdma_dev_on_netdev()
> +{
> + local netdev=$1
> + local dev
> + local i
> +
> + for i in $(seq 1 50); do
> + dev=$(rdma_dev_on_netdev "$netdev")
> + if [ -n "$dev" ]; then
> + echo "$dev"
> + return 0
> + fi
> + sleep 0.1
> + done
> +
> + return 1
> +}
> +
> +# ip link del returns after NETDEV_UNREGISTER, but rxe tears the RDMA device
> +# down asynchronously via ib_unregister_device_queued(). Wait until our names
> +# are gone.
> +wait_rdma_devs_gone()
> +{
> + local i name ns
> + local names=("$RXE_A" "$RXE_B" "$RXE_SAME" "$RXE_NEW")
> +
> + for i in $(seq 1 50); do
> + local found=0
> +
> + for name in "${names[@]}"; do
> + if rdma_dev_exists "" "$name"; then
> + found=1
> + break
> + fi
> + for ns in "$NS1" "$NS2"; do
> + ip netns exec "$ns" true 2>/dev/null || continue
> + if rdma_dev_exists "$ns" "$name"; then
> + found=1
> + break 2
> + fi
> + done
> + done
> +
> + [ "$found" -eq 0 ] && return 0
> + sleep 0.1
> + done
> +
> + return 1
> +}
> +
> +setup_devs()
> +{
> + cleanup_devs || return 1
> +
> + add_dummy "$DUMMY_A" || return 1
> + add_dummy "$DUMMY_B" || return 1
> +
> + add_rxe "$RXE_A" "$DUMMY_A" || return 1
> + add_rxe "$RXE_B" "$DUMMY_B" || return 1
> +}
> +
> +cleanup_devs()
> +{
> + ip link del "$DUMMY_A" 2>/dev/null
> + ip link del "$DUMMY_B" 2>/dev/null
> + wait_rdma_devs_gone
> +}
> +
> +setup()
> +{
> + OLD_MODE=$(rdma system show 2>/dev/null |
> + sed -n 's/.*netns \([^ ]*\).*/\1/p')
> + [ -n "$OLD_MODE" ] || ksft_skip "failed to read RDMA netns mode"
> +
> + rdma system set netns exclusive >/dev/null 2>&1 ||
> + ksft_skip "rdma netns exclusive mode is not supported"
> + MODE_CHANGED=1
> +
> + ip netns add "$NS1" || return 1
> + ip netns add "$NS2" || return 1
> +}
> +
> +# ip netns del returns before rdma_dev_exit_net() removes the net from
> +# rdma_nets. rdma_compatdev_set() returns -EBUSY until that completes, so
> +# retry the mode restore instead of leaving the system in exclusive mode.
> +restore_netns_mode()
> +{
> + local i
> +
> + [ "$MODE_CHANGED" -eq 1 ] || return 0
> +
> + for i in $(seq 1 50); do
> + if rdma system set netns "$OLD_MODE" >/dev/null 2>&1; then
> + MODE_CHANGED=0
> + return 0
> + fi
> + sleep 0.1
> + done
> +
> + echo "warning: failed to restore RDMA netns mode to $OLD_MODE" >&2
> + return 1
> +}
> +
> +cleanup()
> +{
> + cleanup_devs
> +
> + ip netns del "$NS1" 2>/dev/null
> + ip netns del "$NS2" 2>/dev/null
> +
> + restore_netns_mode
> +
> + for m in "${MODS[@]}"; do
> + modprobe -r "$m" 2>/dev/null
> + done
> +}
> +
> +rdma_supports_combined_move_rename()
> +{
> + rdma dev help 2>&1 | grep -Eq 'netns .*name|name .*netns'
> +}
> +
> +[ "$(id -u)" -eq 0 ] || ksft_skip "must be run as root"
> +need_cmd ip
> +need_cmd rdma
> +need_cmd modprobe
> +
> +trap cleanup EXIT
> +
> +for m in "${MODS[@]}"; do
> + modinfo "$m" >/dev/null 2>&1 || ksft_skip "module $m not found"
> + modprobe "$m" || fail "failed to load $m"
> +done
> +
> +setup || fail "failed to create net namespaces"
> +
> +ktap_print_header
> +ktap_set_plan 6
Hi, Jiri
Thanks a lot.
With the first version of this patch series, I already ran the selftests
with RXE, and everything worked as expected.
Only test case 4 was skipped because it depends on a recent commit.
Once that commit is merged, I'll rerun the tests.
As for the numbering, I'm fine with changing it from 7 to 6.
Thanks a lot.
Zhu Yanjun
> +
> +if setup_devs &&
> + rdma dev set "$RXE_A" netns "$NS1" &&
> + rdma_ns "$NS1" dev set "$RXE_A" name "$RXE_SAME" &&
> + rdma dev set "$RXE_B" netns "$NS2" &&
> + rdma_ns "$NS2" dev set "$RXE_B" name "$RXE_SAME" &&
> + rdma_dev_exists "$NS1" "$RXE_SAME" &&
> + rdma_dev_exists "$NS2" "$RXE_SAME"; then
> + ktap_test_pass "$TEST_SAME_NAMES"
> +else
> + ktap_test_fail "$TEST_SAME_NAMES"
> +fi
> +cleanup_devs
> +
> +if ! setup_devs ||
> + ! rdma dev set "$RXE_A" netns "$NS1" ||
> + ! rdma_ns "$NS1" dev set "$RXE_A" name "$RXE_SAME" ||
> + ! rdma dev set "$RXE_B" netns "$NS2" ||
> + ! rdma_ns "$NS2" dev set "$RXE_B" name "$RXE_SAME"; then
> + ktap_test_fail "$TEST_MOVE_CONFLICT"
> +elif rdma_ns "$NS1" dev set "$RXE_SAME" netns "$NS2" >/dev/null 2>&1; then
> + ktap_test_fail "$TEST_MOVE_CONFLICT"
> +elif rdma_dev_exists "$NS1" "$RXE_SAME" &&
> + rdma_dev_exists "$NS2" "$RXE_SAME"; then
> + ktap_test_pass "$TEST_MOVE_CONFLICT"
> +else
> + ktap_test_fail "$TEST_MOVE_CONFLICT"
> +fi
> +cleanup_devs
> +
> +if ! setup_devs; then
> + ktap_test_fail "$TEST_MOVE_RENAME"
> +elif rdma dev set "$RXE_A" netns "$NS2" &&
> + rdma_ns "$NS2" dev set "$RXE_A" name "$RXE_NEW"; then
> + if rdma_dev_exists "$NS2" "$RXE_NEW" &&
> + ! rdma_dev_exists "" "$RXE_A"; then
> + ktap_test_pass "$TEST_MOVE_RENAME"
> + else
> + ktap_test_fail "$TEST_MOVE_RENAME"
> + fi
> +else
> + ktap_test_fail "$TEST_MOVE_RENAME"
> +fi
> +cleanup_devs
> +
> +if ! rdma_supports_combined_move_rename; then
> + ktap_test_skip "$TEST_COMBINED_MOVE_RENAME"
> +elif ! setup_devs; then
> + ktap_test_fail "$TEST_COMBINED_MOVE_RENAME"
> +elif rdma dev set "$RXE_A" netns "$NS2" name "$RXE_NEW"; then
> + if rdma_dev_exists "$NS2" "$RXE_NEW" &&
> + ! rdma_dev_exists "" "$RXE_A"; then
> + ktap_test_pass "$TEST_COMBINED_MOVE_RENAME"
> + else
> + ktap_test_fail "$TEST_COMBINED_MOVE_RENAME"
> + fi
> +else
> + ktap_test_fail "$TEST_COMBINED_MOVE_RENAME"
> +fi
> +cleanup_devs
> +
> +if ! setup_devs; then
> + ktap_test_fail "$TEST_SAME_NETNS_DUP_RENAME"
> +elif rdma dev set "$RXE_A" name "$RXE_SAME" &&
> + rdma dev set "$RXE_B" name "$RXE_NEW"; then
> + if rdma dev set "$RXE_SAME" name "$RXE_NEW" >/dev/null 2>&1; then
> + ktap_test_fail "$TEST_SAME_NETNS_DUP_RENAME"
> + elif rdma_dev_exists "" "$RXE_SAME" &&
> + rdma_dev_exists "" "$RXE_NEW"; then
> + ktap_test_pass "$TEST_SAME_NETNS_DUP_RENAME"
> + else
> + ktap_test_fail "$TEST_SAME_NETNS_DUP_RENAME"
> + fi
> +else
> + ktap_test_fail "$TEST_SAME_NETNS_DUP_RENAME"
> +fi
> +cleanup_devs
> +
> +if ! setup_devs; then
> + ktap_test_fail "$TEST_TEARDOWN_RETURN"
> +elif ! rdma dev set "$RXE_A" name "$RXE_SAME" ||
> + ! rdma dev set "$RXE_B" netns "$NS2" ||
> + ! rdma_ns "$NS2" dev set "$RXE_B" name "$RXE_SAME" ||
> + ! rdma_dev_exists "$NS2" "$RXE_SAME"; then
> + ktap_test_fail "$TEST_TEARDOWN_RETURN"
> +else
> + ip netns del "$NS2"
> + returned=$(wait_rdma_dev_on_netdev "$DUMMY_B")
> + ktap_print_msg "device returned to init_net as '${returned:-<missing>}'"
> + if rdma_dev_exists "" "$RXE_SAME" &&
> + [ -n "$returned" ] &&
> + [ "$returned" != "$RXE_SAME" ] &&
> + [ "${returned#ibdev}" != "$returned" ]; then
> + ktap_test_pass "$TEST_TEARDOWN_RETURN"
> + else
> + ktap_test_fail "$TEST_TEARDOWN_RETURN"
> + fi
> +fi
> +cleanup_devs
> +
> +ktap_finished
--
Best Regards,
Yanjun.Zhu
^ permalink raw reply
* Re: [PATCH] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Kyle Switch @ 2026-07-17 3:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, jianmin.wang, ming.xu, xiaolin.xu, jie.han
In-Reply-To: <7f1b935d-732d-4d2f-a2c3-a0517c9301d7@lunn.ch>
On 7/15/26 21:09, Andrew Lunn wrote:
> On Wed, Jul 15, 2026 at 07:59:55PM +0800, Kyle Switch wrote:
>>
>>
>> On 7/15/26 05:46, Andrew Lunn wrote:
>>>> +static inline int ytphy_top_write(struct phy_device *phydev, u32 regnum,
>>>> + u16 val)
>>>> +{
>>>> + struct yt8521_priv *priv = phydev->priv;
>>>> + struct mii_bus *bus = phydev->mdio.bus;
>>>> +
>>>> + return bus->write(bus, priv->top_phy_addr, regnum, val);
>>>> +}
>>>
>>> Please could you explain the architecture in detail. It seems like you
>>> are accessing registers of some other device on the bus.
>>>
>>> Maybe you need to use the code in phy_package.c?
>>
>> Ans: YT8824 contains top extend reg space, and the addr is fixed, for
>> internal phy8824 the value is 9, and external phy8824 is (baseaddr + 4).
>
> Does the "top extend reg space" have values in the ID registers, 2 and
> 3? Is Linux trying to probe this address space?
>
> Anyway, it does sound like you need to use phy_package. That will give
> you a better API for accessing the registers in the other address
> space.
>
Ans: The "top extend reg space" does not have ID register, which is common
register space shared by UTP and serdes.
> Andrew
^ permalink raw reply
* [PATCH net-next v2 2/2] net: phy: Add support for the Maxio MAE0621A
From: Liu Changjie @ 2026-07-17 3:44 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
Add exact PHY ID matching and optional 125 MHz CLKOUT configuration
for the Maxio MAE0621A Gigabit Ethernet PHY. Preserve the existing
hardware configuration when the firmware property is absent.
Signed-off-by: Liu Changjie <liucj1228@outlook.com>
---
drivers/net/phy/Kconfig | 8 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/maxio.c | 103 +++++++++++++++++++++++++++++++++++++++
3 files changed, 112 insertions(+)
create mode 100644 drivers/net/phy/maxio.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 099f25dce..32e1a035b 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -283,6 +283,14 @@ config MARVELL_88X2222_PHY
Support for the Marvell 88X2222 Dual-port Multi-speed Ethernet
Transceiver.
+config MAXIO_PHY
+ tristate "Maxio Ethernet PHYs"
+ help
+ Support for Maxio Ethernet PHYs. Currently this driver supports the
+ MAE0621A Gigabit Ethernet PHY. The driver optionally selects a 125 MHz
+ clock on the CLKOUT pin while preserving the hardware configuration on
+ boards which do not request it.
+
config MAXLINEAR_GPHY
tristate "Maxlinear Ethernet PHYs"
select POLYNOMIAL if HWMON
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index de660ae94..7fb3626f0 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_MARVELL_10G_PHY) += marvell10g.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
obj-$(CONFIG_MARVELL_88Q2XXX_PHY) += marvell-88q2xxx.o
obj-$(CONFIG_MARVELL_88X2222_PHY) += marvell-88x2222.o
+obj-$(CONFIG_MAXIO_PHY) += maxio.o
obj-$(CONFIG_MAXLINEAR_GPHY) += mxl-gpy.o
obj-$(CONFIG_MAXLINEAR_86110_PHY) += mxl-86110.o
obj-y += mediatek/
diff --git a/drivers/net/phy/maxio.c b/drivers/net/phy/maxio.c
new file mode 100644
index 000000000..d2cb23895
--- /dev/null
+++ b/drivers/net/phy/maxio.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Driver for Maxio Ethernet PHYs. */
+
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/property.h>
+
+#define MAXIO_MAE0621A_PHY_ID 0x7b744412
+
+#define MAXIO_PAGE_SELECT 0x1f
+#define MAXIO_MAE0621A_PHYCR2_PAGE 0xa43
+#define MAXIO_MAE0621A_PHYCR2 0x19
+#define MAXIO_MAE0621A_CLKOUT_125M BIT(11)
+#define MAXIO_MAE0621A_CLKOUT_ENABLE BIT(0)
+
+struct maxio_priv {
+ bool clk_out_125m;
+};
+
+static int maxio_read_page(struct phy_device *phydev)
+{
+ return __phy_read(phydev, MAXIO_PAGE_SELECT);
+}
+
+static int maxio_write_page(struct phy_device *phydev, int page)
+{
+ return __phy_write(phydev, MAXIO_PAGE_SELECT, page);
+}
+
+static int maxio_mae0621a_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct maxio_priv *priv;
+ u32 frequency;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ ret = device_property_read_u32(dev, "maxio,clk-out-frequency-hz",
+ &frequency);
+ if (ret == -EINVAL)
+ return 0;
+ if (ret)
+ return ret;
+
+ if (frequency != 125000000) {
+ phydev_err(phydev, "invalid CLKOUT frequency %u\n", frequency);
+ return -EINVAL;
+ }
+
+ priv->clk_out_125m = true;
+
+ return 0;
+}
+
+static int maxio_mae0621a_config_init(struct phy_device *phydev)
+{
+ struct maxio_priv *priv = phydev->priv;
+ int ret;
+
+ if (!priv->clk_out_125m)
+ return 0;
+
+ ret = phy_modify_paged_changed(phydev, MAXIO_MAE0621A_PHYCR2_PAGE,
+ MAXIO_MAE0621A_PHYCR2,
+ MAXIO_MAE0621A_CLKOUT_ENABLE |
+ MAXIO_MAE0621A_CLKOUT_125M,
+ MAXIO_MAE0621A_CLKOUT_ENABLE |
+ MAXIO_MAE0621A_CLKOUT_125M);
+ if (ret <= 0)
+ return ret;
+
+ return genphy_soft_reset(phydev);
+}
+
+static struct phy_driver maxio_drivers[] = {
+ {
+ PHY_ID_MATCH_EXACT(MAXIO_MAE0621A_PHY_ID),
+ .name = "Maxio MAE0621A",
+ .probe = maxio_mae0621a_probe,
+ .config_init = maxio_mae0621a_config_init,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ .read_page = maxio_read_page,
+ .write_page = maxio_write_page,
+ },
+};
+module_phy_driver(maxio_drivers);
+
+static const struct mdio_device_id __maybe_unused maxio_tbl[] = {
+ { PHY_ID_MATCH_EXACT(MAXIO_MAE0621A_PHY_ID) },
+ { }
+};
+MODULE_DEVICE_TABLE(mdio, maxio_tbl);
+
+MODULE_AUTHOR("Liu Changjie <liucj1228@outlook.com>");
+MODULE_DESCRIPTION("Maxio Ethernet PHY driver");
+MODULE_LICENSE("GPL");
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] dt-bindings: net: Add Maxio MAE0621A PHY
From: Liu Changjie @ 2026-07-17 3:44 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
Document the MAE0621A PHY ID and its optional 125 MHz CLKOUT
setting. Boards which do not provide the property retain the hardware
strap or bootloader configuration.
Only the 125 MHz setting is exposed because it is the only setting
exercised on hardware.
Signed-off-by: Liu Changjie <liucj1228@outlook.com>
---
.../bindings/net/maxio,mae0621a.yaml | 38 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
diff --git a/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml b/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
new file mode 100644
index 000000000..f1ea54583
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxio,mae0621a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxio MAE0621A Ethernet PHY
+
+maintainers:
+ - Liu Changjie <liucj1228@outlook.com>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ const: ethernet-phy-id7b74.4412
+
+ maxio,clk-out-frequency-hz:
+ description:
+ Selects a 125 MHz clock on the CLKOUT pin. If the property is absent,
+ the hardware strap or bootloader configuration is preserved.
+ const: 125000000
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@1 {
+ compatible = "ethernet-phy-id7b74.4412";
+ reg = <1>;
+ maxio,clk-out-frequency-hz = <125000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f36..eeaf0b7a1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1013,6 +1013,8 @@ patternProperties:
description: MaxBotix Inc.
"^maxim,.*":
description: Maxim Integrated Products
+ "^maxio,.*":
+ description: Maxio Technology (Hangzhou) Co., Ltd.
"^maxlinear,.*":
description: MaxLinear Inc.
"^maxtor,.*":
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
From: Zhou, Yun @ 2026-07-17 3:42 UTC (permalink / raw)
To: Jagielski, Jedrzej, gregkh@linuxfoundation.org,
jirislaby@kernel.org, socketcan@hartkopp.net, sdf.kernel
Cc: linux-serial@vger.kernel.org, mkl@pengutronix.de,
linux-can@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PH0PR11MB5902C0DC3D8407F2701948C1F0C72@PH0PR11MB5902.namprd11.prod.outlook.com>
Hi Jagielski,
On 7/16/26 15:59, Jagielski, Jedrzej wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> From: Yun Zhou <yun.zhou@windriver.com>
> Sent: Thursday, July 16, 2026 8:47 AM
>
>> syzbot reported a circular lock dependency involving tty ldisc_sem and
>> the networking rtnl_mutex. The full chain is:
>>
>> rtnl_mutex --> nft_commit_mutex --> ... --> ep->mtx --> ldisc_sem --> rtnl_mutex
>
> still unclear where the first mutex may come from
tty_set_ldisc()
tty_ldisc_lock() <- hold ldisc_sem
tty_ldisc_open()
slcan_open()
register_candev()
register_netdev()
rtnl_net_lock_killable() <- hold rtnl_mutex
>
>>
>> + tty_ldisc_unlock(tty);
>>
>> + /*
>
> this blank line is redundant i believe
>
Isn't it common practice to leave the first line of a multi-line comment
blank? Does it violate the coding style guidelines?
BR,
Yun
^ permalink raw reply
* [PATCH net-next v2 0/2] net: phy: Add Maxio MAE0621A support
From: Liu Changjie @ 2026-07-17 3:39 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
Cc: Russell King, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luo Jie, Wolfram Sang, devicetree, linux-kernel
Add a binding and PHY driver for the Maxio MAE0621A Gigabit Ethernet
PHY. The driver matches the exact PHY ID and optionally selects a
125 MHz clock on CLKOUT. When the property is absent, the driver
preserves the hardware strap or bootloader setting.
This was tested on the LCKFB Taishan Pi 3M. With the PHY's default
CLKOUT configuration, the RK3576 GMAC negotiated a 1 Gbit/s link but
the data path did not work. A read-modify-write of page 0xa43,
register 0x19, setting bits 0 and 11 produced a readback value of
0x0823 and restored the data path without changing the RGMII delays.
The readback also confirmed that the unrelated set bits were
preserved.
Only the 125 MHz setting has been exercised on hardware and only that
value is exposed by this series. The 0 and 25 MHz choices from the
initial draft have been removed.
Public documentation for the MAE0621A register is not available. The
exact definitions of page 0xa43, register 0x19 bits 0 and 11, their
reset defaults, and whether a soft reset is required after changing
them still need confirmation from Maxio. The register programming in
this series is therefore supported by the hardware A/B result, not by
a public datasheet citation.
Hardware tests with the 125 MHz setting:
- all supported 10/100/1000 Mbit/s link modes
- 100 ICMP packets in each direction with no loss
- 936/934 Mbit/s host-to-board iperf3, no retransmits
- 943/941 Mbit/s board-to-host iperf3, no retransmits
- link unplug/replug and a normal reboot, followed by another 100 ICMP
packets in each direction with no loss
- no RX errors, missed packets, carrier errors or collisions
Static tests on net-next commit f6f3b36c15ed:
- dt_binding_check with dtschema 2026.6
- W=1 arm64 defconfig build of drivers/net/phy/maxio.o with GCC 10.3
- W=1 arm64 allmodconfig build of drivers/net/phy/maxio.o with GCC 10.3
- git diff --check and checkpatch.pl
Changes in v2:
- Extend hardware validation to all supported 10/100/1000 Mbit/s link
modes.
- Keep the binding limited to the tested 125 MHz setting. CLKOUT-disable
support can be added later after its register behavior is documented
and tested.
- No binding or driver code changes.
Link: https://lore.kernel.org/r/MN0PR19MB6091CD5A84D2DA5DACF434DAACF92@MN0PR19MB6091.namprd19.prod.outlook.com [v1]
Liu Changjie (2):
dt-bindings: net: Add Maxio MAE0621A PHY
net: phy: Add support for the Maxio MAE0621A
.../bindings/net/maxio,mae0621a.yaml | 38 +++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
drivers/net/phy/Kconfig | 8 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/maxio.c | 103 ++++++++++++++++++
5 files changed, 152 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/maxio,mae0621a.yaml
create mode 100644 drivers/net/phy/maxio.c
base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
--
2.55.0
^ permalink raw reply
* Re: (subset) [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Bjorn Andersson @ 2026-07-17 3:23 UTC (permalink / raw)
To: konradybcio, Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
bod, mchehab, elder, andrew+netdev, davem, edumazet, kuba, pabeni,
jjohnson, mathieu.poirier, trilokkumar.soni, mukesh.ojha,
pavan.kondeti, jorge.ramirez, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jenswi, op-tee, apurupa,
skare, linux-kernel, Sumit Garg
In-Reply-To: <20260702115835.167602-1-sumit.garg@kernel.org>
On Thu, 02 Jul 2026 17:28:16 +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> [...]
Applied, thanks!
[11/14] net: ipa: Switch to generic PAS TZ APIs
commit: 85b88ceeeeb7bb93cd0af7ccaf2a4b010d5bc5c6
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v3 15/15] ibmveth: Fix MQ RX poll and shutdown hangs after queue resize
From: mingming cao @ 2026-07-17 3:08 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bjking1, haren, ricklind, kuba, edumazet, pabeni,
linuxppc-dev, maddy, mpe, davemarq
In-Reply-To: <20260714131053.1844276-2-horms@kernel.org>
On 7/14/26 6:10 AM, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> ibmveth: Fix MQ RX poll and shutdown hangs after queue resize
>
> This commit fixes polling hangs in the ibmveth driver after queue resize
> by skipping over bad correlators instead of retrying endlessly. It also
> ensures NAPI completes when the interface is down or being disabled.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index 50a332ab83fd3..eb84b4e5f69fd 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
> [ ... ]
>
>> @@ -2959,8 +2978,23 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>> __sum16 iph_check = 0;
>>
>> skb = ibmveth_rxq_get_buffer(adapter, queue_index);
>> - if (unlikely(!skb))
>> - break;
>> + if (unlikely(!skb)) {
>> + if (net_ratelimit())
>> + netdev_err(netdev,
> [Severity: High]
> This isn't a bug introduced by this patch, but can the unvalidated packet
> lengths and offsets from hardware descriptors trigger an skb_over_panic()
> here?
yes
> Further down in ibmveth_poll(), the driver reads length and offset directly
> from the hardware receive descriptor and passes them to skb_reserve() and
> skb_put() on the reused SKB:
>
> int length = ibmveth_rxq_frame_length(adapter, queue_index);
> int offset = ibmveth_rxq_frame_offset(adapter, queue_index);
> ...
> } else {
> rc = ibmveth_rxq_harvest_buffer(adapter, queue_index, false);
> if (unlikely(rc))
> break;
> skb_reserve(skb, offset);
> }
>
> skb_put(skb, length);
>
> If a faulty hypervisor provides an abnormally large length or offset,
> skb_put() will extend the tail past the end of the buffer, which triggers an
> skb_over_panic() and causes a crash.
>
> Should the driver validate that offset + length is within the known buffer
> size before modifying the boundaries?
**
*Agreed this needs guarding. I'll add in v4: validates*
*
offset + length against skb_tailroom() before skb_reserve/skb_put, and
skips bad correlators.
*
>
> [ ... ]
>
>> @@ -3034,8 +3068,11 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>>
>> ibmveth_replenish_task(adapter, queue_index);
>>
>> - if (frames_processed == budget)
>> + if (frames_processed == budget) {
>> + if (!netif_running(netdev) || napi_disable_pending(napi))
>> + napi_complete_done(napi, frames_processed);
>> goto out;
>> + }
> [Severity: High]
> Does calling napi_complete_done() here conflict with the NAPI core contract?
>
> If the polling loop exhausts its budget (frames_processed == budget), returning
> the full budget after calling napi_complete_done() might cause issues with the
> NAPI state machine. The NAPI core (__napi_poll) will operate on the instance
> assuming it still holds the NAPIF_STATE_SCHED bit.
>
> If napi_disable_pending() is true, the core calls napi_complete(), which will
> hit a WARN_ON_ONCE.
>
> If napi_disable_pending() is false but !netif_running() is true, the core will
> add the NAPI instance back to the poll_list. Since the driver cleared
> NAPIF_STATE_SCHED, a subsequent interrupt can trigger another napi_schedule(),
> causing a double list_add_tail() and potentially leading to list corruption.
*
Good catch — completing and then
returning a full budget is wrong. In v4 I'll complete on
shutdown/disable and return a value < budget (same as at the top of
poll), and leave the normal budget-exhausted path returning budget
without completing.
Thanks,
Mingming
*
^ permalink raw reply
* Re: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
From: Zhou, Yun @ 2026-07-17 3:03 UTC (permalink / raw)
To: Greg KH, sdf.kernel
Cc: jirislaby, socketcan, linux-serial, mkl, linux-can, davem,
edumazet, kuba, pabeni, horms, netdev, linux-kernel
In-Reply-To: <2026071655-steering-cardstock-cd06@gregkh>
On 7/16/26 15:57, Greg KH wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Thu, Jul 16, 2026 at 02:47:19PM +0800, Yun Zhou wrote:
>> syzbot reported a circular lock dependency involving tty ldisc_sem and
>> the networking rtnl_mutex. The full chain is:
>>
>> rtnl_mutex --> nft_commit_mutex --> ... --> ep->mtx --> ldisc_sem --> rtnl_mutex
>>
>> The last edge (ldisc_sem -> rtnl_mutex) is created because tty line
>> discipline .open() callbacks (slcan, slip) call register_netdev() which
>> acquires rtnl_mutex, and .open() runs under ldisc_sem write lock in
>> tty_set_ldisc().
>>
>> Fix by moving the .open() call outside the ldisc_sem write lock. The
>> ldisc .open() is initialization of the NEW discipline after the old one
>> has been closed - there is no need for ldisc_sem protection at this
>> point since:
>>
>> - tty_lock is held throughout, preventing concurrent tty_set_ldisc,
>> hangup, or close
>> - tty->ldisc is set to NULL during the window, so concurrent readers
>> (tty_ldisc_ref, tty_ldisc_ref_wait) see NULL and return immediately,
>> which callers already handle as a hangup condition
>> - tty buffer data stays queued until the ldisc is installed
>>
>> The sequence becomes:
>> 1. Hold ldisc_sem(write): close old ldisc, set tty->ldisc = NULL
>> 2. Release ldisc_sem(write)
>> 3. Call new_ldisc->ops->open() without ldisc_sem
>> 4. Re-acquire ldisc_sem(write): install new ldisc (or restore old)
>> 5. Release ldisc_sem(write)
>>
>> Reported-by: syzbot+de610eeef174bd59a8a3@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=de610eeef174bd59a8a3
>> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
>> ---
>> drivers/tty/tty_ldisc.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> What commit caused this to be a problem and why have we not seen this in
> any real-world usages?
>
The circular dependency has existed for a long time - it just requires
ldisc_sem -> rtnl_mutex (from slcan/slip registering a netdev in
.open()) and the reverse path through nft_commit_mutex, epoll, and
tty_poll back to ldisc_sem.
The recent dev_instance_lock series (5326fefb9fe8 "net: hold instance
lock around NETDEV_DOWN/GOING_DOWN") increased lockdep's observability
by adding lock acquisitions in more notifier paths, making it easier for
lockdep to collect all edges in a single run. It did not create the
cycle.
We have not seen this in real-world usage because triggering the actual
deadlock requires 6 unrelated subsystems to contend simultaneously -
something only a fuzzer like syzkaller would construct.
>
>>
>> diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
>> index 27fe8236f662..248a6995cc53 100644
>> --- a/drivers/tty/tty_ldisc.c
>> +++ b/drivers/tty/tty_ldisc.c
>> @@ -556,15 +556,28 @@ int tty_set_ldisc(struct tty_struct *tty, int disc)
>> /* Shutdown the old discipline. */
>> tty_ldisc_close(tty, old_ldisc);
>>
>> - /* Now set up the new line discipline. */
>> - tty->ldisc = new_ldisc;
>> + /* Clear tty->ldisc so concurrent readers back off during transition */
>> + tty->ldisc = NULL;
>> tty_set_termios_ldisc(tty, disc);
>> + tty_ldisc_unlock(tty);
>>
>> + /*
>> + * Open the new discipline outside ldisc_sem. The ldisc .open()
>> + * may acquire locks (e.g., rtnl_mutex) that would create circular
>> + * dependencies if taken under ldisc_sem. tty_lock is still held,
>> + * preventing concurrent ldisc changes and hangup.
>> + */
>> retval = tty_ldisc_open(tty, new_ldisc);
>
> Now you are calling open when previously we were not, are you sure this
> isn't going to cause problems?
>
This is not a new .open() call - it is the same tty_ldisc_open() that
was always called here. The change only moves it outside ldisc_sem.
tty_lock is still held throughout, so .open() sees the same environment
as before.
>> +
>> + tty_ldisc_lock(tty, MAX_SCHEDULE_TIMEOUT);
>
> Why that timeout?
>
>> +
>> if (retval < 0) {
>> /* Back to the old one or N_TTY if we can't */
>> tty_ldisc_put(new_ldisc);
>> tty_ldisc_restore(tty, old_ldisc);
>> + } else {
>> + /* Success - install new ldisc */
>> + tty->ldisc = new_ldisc;
>> }
>
> Does open cause anything else to be incremented that you have to clean
> up when done that you aren't doing here?
>
tty_ldisc_open() only sets the TTY_LDISC_OPEN flag bit and calls
ld->ops->open(). On failure it clears the flag itself.
No refcounts or other state are incremented by tty_ldisc_open() that
would need additional cleanup.
BR,
Yun
^ permalink raw reply
* Re: [PATCH net-next v3 14/15] ibmveth: Wire ethtool set_channels to MQ RX queue resize
From: mingming cao @ 2026-07-17 3:02 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bjking1, haren, ricklind, kuba, edumazet, pabeni,
linuxppc-dev, maddy, mpe, davemarq
In-Reply-To: <20260714130752.1844153-1-horms@kernel.org>
On 7/14/26 6:07 AM, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> ibmveth: Wire ethtool set_channels to MQ RX queue resize
>
> Expose incremental RX resize through ethtool channel control.
> get_channels() reports rx_count from adapter->num_rx_queues and max_rx
> as IBMVETH_MAX_RX_QUEUES when MQ firmware is enabled, else 1.
> set_channels() validates rx_count is within 1..IBMVETH_MAX_RX_QUEUES.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index ac4d89a66a8db..50a332ab83fd3 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
>> @@ -2534,19 +2534,69 @@ static int ibmveth_set_channels(struct net_device *netdev,
>> struct ethtool_channels *channels)
>> {
>> struct ibmveth_adapter *adapter = netdev_priv(netdev);
> [ ... ]
>> - if (!(netdev->flags & IFF_UP))
>> + if (!(netdev->flags & IFF_UP)) {
>> + if (goal_rx > 1 && !adapter->multi_queue) {
> [ ... ]
>> + /* Stash desired RX count; open() publishes it via
>> + * netif_set_real_num_rx_queues() after queue registration.
>> + */
>> + if (goal_rx != adapter->num_rx_queues)
>> + adapter->num_rx_queues = goal_rx;
>> +
>> return netif_set_real_num_tx_queues(netdev, goal);
> [Severity: Medium]
> If netif_set_real_num_tx_queues() fails and returns an error, the TX
> configuration command will fail, but the RX queue count has already been
> permanently modified in adapter->num_rx_queues. Will this leave the device in
> an inconsistent state where the new RX count is applied on the next open
> despite the command failing?
*
Agreed — will only commit the stashed RX count after
netif_set_real_num_tx_queues() succeeds, or restore on failure.
*
>> + }
> [ ... ]
>> + if (goal_rx != old_rx) {
>> + rc = ibmveth_resize_rx_queues_incremental(adapter, goal_rx,
>> + rxq_entries);
> [Severity: High]
> Does this new ethtool scale-down path expose an interrupt storm?
>
> Looking at ibmveth_resize_rx_queues_incremental(), when scaling down queues it
> disables NAPI before disabling the hardware interrupt:
>
> drivers/net/ethernet/ibm/ibmveth.c:ibmveth_resize_rx_queues_incremental() {
> ...
> for (i = new_count; i < old_count; i++)
> napi_disable(&adapter->napi[i]);
>
> for (i = new_count; i < old_count; i++)
> ibmveth_drain_rx_queue(adapter, i);
>
> synchronize_net();
> ...
> /* Disable hypervisor interrupts and wait for handlers to complete
> * before updating num_rx_queues.
> */
> for (i = new_count; i < old_count; i++) {
> ibmveth_disable_irq(adapter, i);
> ...
> }
>
> If the hypervisor delivers a packet during this window, ibmveth_interrupt()
> will execute. Since NAPI is disabled, napi_schedule_prep() fails, causing the
> handler to return IRQ_HANDLED without disabling the hardware interrupt. Will
> this leave the virtual interrupt asserted and force an infinite interrupt loop?
Yeah, *Same issue as on the incremental resize patch — **
will fix IRQ/NAPI ordering in ibmveth_resize_rx_queues_incremental()
in v4.
*
>> + if (rc) {
>> + netdev_err(netdev, "Failed to resize RX queues: %d\n", rc);
>> + return rc;
>> + }
>> + }
>>
>> /* We have IBMVETH_MAX_QUEUES netdev_queue's allocated
>> * but we may need to alloc/free the ltb's.
>> */
> [Severity: High]
> This is a pre-existing issue, but does this function use an uninitialized
> variable in the error path?
>
> When decreasing the number of TX queues (goal < old), the allocation loop for
> (i = old; i < goal; i++) is skipped, leaving 'i' uninitialized. If
> netif_set_real_num_tx_queues() then fails, the error path assigns old = i;.
>
> The cleanup loop then uses this garbage value:
> for (i = old; i > goal; i--) {
> if (adapter->tx_ltb_ptr[i - 1])
>
> Will this access adapter->tx_ltb_ptr out of bounds and pass arbitrary pointers
> to ibmveth_free_tx_ltb()?
*
Good catch — pre-existing, but we’ll fix it while touching
set_channels in v4 (initialize i / don’t use it uninitialized on
TX scale-down failure).
*
>> @@ -2580,7 +2630,7 @@ static int ibmveth_set_channels(struct net_device *netdev,
>>
>> netif_tx_wake_all_queues(netdev);
>>
>> - return rc;
>> + return 0;
> [Severity: High]
> Does this unconditional return of 0 mask TX queue configuration failures?
>
> If applying the new TX queue count via netif_set_real_num_tx_queues() fails,
> the code handles it locally, but the function exits with 0 regardless. Will
> this mislead userspace into believing the TX channel count was successfully
> modified?
*
Agreed — that return 0 is a regression versus returning rc. Will
restore proper error reporting in v4 (and be careful about partial
RX-success / TX-failure).
*
*
Thanks for your review feedback.
Mingming
*
^ permalink raw reply
* Re: Proposal: module for optional /net directory for network data
From: Cong Wang @ 2026-07-17 2:52 UTC (permalink / raw)
To: Jon Maser; +Cc: netdev
In-Reply-To: <CAF=mWJMErgOuTML7hFy6gEH5zqACOdZU62Xh=bR55=VbB4fJ2g@mail.gmail.com>
On Tue, Jun 16, 2026 at 06:13:51PM -0700, Jon Maser wrote:
> A little under the weather but hopefully this comes across well lol
>
> This may not be for the sensitive. and yeah I do have a mental
> disorder as well, and I'm not an expert
Any idea is welcome!
>
> But it would be nice for network operations to be aided by a /net
> directory, where devices can have full access to network data,
> including hardcore bit by bit access, complete control of data coming
> in,and out, shell access to network data, you can easily cache network
> operations for forensics, you can enhance firewall technology, even
> with hardware firewalls by giving vendors time to adapt to a high
> level access of network data
>
> It needs to be a module to be a true unix imho
>
> It can be as easy as cat sendack.ns > /net/0/in && cat /dev/eth0
>
> Its also easy to write a firewall in shell script
Linux networking subsystem is ruled by netlink, devices are less
preferred interfaces, because netlink is binary-rich and flexible.
Of course, you can always write out-of-tree modules without
arguing with the upstream community. :)
Regards,
Cong
^ permalink raw reply
* Re: [PATCH net-next v3 13/15] ibmveth: Implement incremental MQ RX queue resize
From: mingming cao @ 2026-07-17 2:40 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bjking1, haren, ricklind, kuba, edumazet, pabeni,
linuxppc-dev, maddy, mpe, davemarq
In-Reply-To: <20260714130344.1841551-3-horms@kernel.org>
On 7/14/26 6:03 AM, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> Date: Mon Jul 6 19:36:01 2026 +0000
>
> ibmveth: Implement incremental MQ RX queue resize
>
> Add helpers to register/deregister individual RX queues and scale
> queue count up or down while the netdev stays up. Surviving queues
> keep PHYP handles, buffer pools, and IRQ state across resize.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index ecc472ee8f71f..ac4d89a66a8db 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
> [ ... ]
>
>> @@ -1080,6 +1132,138 @@ static void ibmveth_free_buffer_pools(struct ibmveth_adapter *adapter)
>> +static int
>> +ibmveth_alloc_single_rx_queue(struct ibmveth_adapter *adapter, int queue_idx,
>> + int rxq_entries)
>> +{
> [ ... ]
>
>> + for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++) {
>> + adapter->rx_buff_pool[queue_idx][i].size =
>> + adapter->rx_buff_pool[0][i].size;
>> + adapter->rx_buff_pool[queue_idx][i].buff_size =
>> + adapter->rx_buff_pool[0][i].buff_size;
>> + adapter->rx_buff_pool[queue_idx][i].threshold =
>> + adapter->rx_buff_pool[0][i].threshold;
>> + adapter->rx_buff_pool[queue_idx][i].active =
>> + adapter->rx_buff_pool[0][i].active;
>> + }
> [Severity: Critical]
> Does this loop miss initializing pool->index?
>
> If pool->index remains 0 for all buffer pools on the new queue, when
> replenishing, 0 is shifted into the correlator.
>
> Then when receiving, ibmveth_remove_buffer_from_pool() will extract pool=0,
> which fetches from the wrong pool and could corrupt the free map of pool 0,
> leading to a use-after-free or leak.
Thanks — this was a real bug. We discovered this issue while doing
stress tests, and identified
this issue, Agreed copies
*
pool->index when cloning pools for incrementally added queues; I have
verified the fix. Thanks again,
*
>
> [ ... ]
>
>> @@ -1192,6 +1376,49 @@ static int ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter,
>> +static int
>> +ibmveth_drain_rx_queue(struct ibmveth_adapter *adapter, int queue_index)
>> +{
> [ ... ]
>
>> + while (drained < limit &&
>> + ibmveth_rxq_pending_buffer(adapter, queue_index)) {
>> + rc = ibmveth_rxq_harvest_buffer(adapter, queue_index, true);
> Simon says: I think we can consider the issue below in the context of
> possible follow-up, because I believe the use of this pattern
> predates this patch.
>
> [Severity: High]
> Is a read memory barrier needed between reading the toggle bit in
> ibmveth_rxq_pending_buffer() and reading the correlator in
> ibmveth_rxq_harvest_buffer()?
>
> Since the hypervisor could be actively writing new descriptors while this is
> called, could a weakly-ordered CPU reorder the correlator load before the
> toggle bit load, causing us to recycle the wrong buffer?
>
> [ ... ]
Ah, *
as this toggle/correlator ordering pattern
**
pre-dates the resize work. I’ll treat adding an explicit barrier
in the drain path in v4
*
>> @@ -1491,6 +1718,175 @@ ibmveth_deregister_single_rx_queue(struct ibmveth_adapter *adapter,
>> +static int
>> +ibmveth_resize_rx_queues_incremental(struct ibmveth_adapter *adapter,
>> + int new_count, int rxq_entries)
>> +{
> [ ... ]
>
>> + rc = ibmveth_enable_irq(adapter, i);
>> + if (rc) {
>> + netdev_err(netdev,
>> + "Failed to enable IRQ for queue %d: %d\n",
>> + i, rc);
>> + ibmveth_cleanup_single_rx_interrupt(adapter, i);
>> + ibmveth_deregister_single_rx_queue(adapter, i);
>> + ibmveth_free_single_rx_queue(adapter, i);
>> + goto cleanup_new_queues;
>> + }
>> +
>> + napi_enable(&adapter->napi[i]);
>> + }
>> +
>> + adapter->num_rx_queues = new_count;
> [Severity: High]
> What happens if an interrupt fires on the newly added queue before
> adapter->num_rx_queues is updated?
*agreed, v3 published the new queue count too late.*
> If an interrupt fires between ibmveth_enable_irq() and the update of
> adapter->num_rx_queues, ibmveth_interrupt() might evaluate:
> WARN_ON(qindex < 0 || qindex >= adapter->num_rx_queues)
> to true and return IRQ_NONE without masking the interrupt.
>
> Could this lead to an unhandled interrupt storm?
*
possible
**
I will work on in v4 so that each new queue is published and replenished
**
before PHYP enable and napi_enable(), so ibmveth_interrupt() will not
**
return IRQ_NONE on a queue we have not published yet, and NAPI
does not run on an empty queue.
*
>
> [ ... ]
>
>> + } else {
>> + netdev_dbg(netdev, "Scale-down: removing queues %d-%d\n",
>> + new_count, old_count - 1);
>> +
>> + for (i = new_count; i < old_count; i++)
>> + napi_disable(&adapter->napi[i]);
>> +
>> + for (i = new_count; i < old_count; i++)
>> + ibmveth_drain_rx_queue(adapter, i);
>> +
>> + synchronize_net();
> [Severity: High]
> Can disabling NAPI before disabling the hardware interrupts create an
> interrupt storm window?
*
Agreed — with the handler only masking on successful NAPI
schedule, napi_disable before PHYP mask can storm during drain.
*
>
> If the hypervisor asserts an interrupt during synchronize_net(), the hardware
> IRQ handler runs. Since NAPI is disabled, it returns IRQ_HANDLED without
> masking the interrupt source at the hypervisor, leading immediately to an
> IRQ storm and CPU lockup.
*
That is a load-dependent race (tests can pass and still miss it).
In v4 I will disable_irq + synchronize_irq before
napi_disable/drain on scale-down (and on scale-up fail cleanup).
*
>> +
>> + rc = netif_set_real_num_rx_queues(netdev, new_count);
>> + if (rc) {
>> + netdev_err(netdev, "Failed to set real RX queues to %d: %d\n",
>> + new_count, rc);
>> + for (i = new_count; i < old_count; i++)
>> + napi_enable(&adapter->napi[i]);
>> + return rc;
>> + }
> [Severity: High]
> Is it possible for this error path to permanently stall the RX queues?
>
> It calls napi_enable() but doesn't call ibmveth_replenish_task(). Since the
> queues were completely drained of their buffers by ibmveth_drain_rx_queue(),
> will the hypervisor have any buffers to place incoming packets?
>
> Without buffers, no interrupts will fire for these queues, and NAPI will
> never run again.
*
Good catch — after drain, that set_real_num_rx failure path must
replenish before re-enabling IRQ/NAPI, or those queues stall with
empty pools. Real rollback bug (rare path). Will fix in v4.
*
Thanks,
Mingming
^ permalink raw reply
* [PATCH bpf v2] bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
From: Jose Fernandez (Anthropic) @ 2026-07-17 2:33 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrii Nakryiko,
Yonghong Song, Martin KaFai Lau
Cc: netdev, linux-kernel, bpf, Daniel Borkmann, Jiayuan Chen,
Emil Tsalapatis, Jose Fernandez (Anthropic)
reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto
the ehash chain, drops the bucket lock, and only afterwards sets
rsk_refcnt to 3.
Lockless readers such as __inet_lookup_established() handle this with
refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain
sock_hold() while holding the bucket lock, on the assumption that the
lock guarantees sk_refcnt > 0. That assumption does not hold for
request_sock:
CPU 0 CPU 1
----- -----
tcp_conn_request()
reqsk_queue_hash_req()
inet_ehash_insert(req)
spin_lock(bucket)
__sk_nulls_add_node_rcu(req) // rsk_refcnt == 0
spin_unlock(bucket)
bpf_iter_tcp_established_batch()
spin_lock(bucket)
sock_hold(req) <-- addition on 0
spin_unlock(bucket)
refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value
which surfaces as:
refcount_t: addition on 0; use-after-free.
WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1
Call Trace:
bpf_iter_tcp_established_batch+0x14e/0x170
bpf_iter_tcp_batch+0x53/0x200
bpf_iter_tcp_seq_next+0x27/0x70
bpf_seq_read+0x107/0x410
vfs_read+0xb9/0x380
The iterator's stolen reference is lost when the publishing CPU's
refcount_set() overwrites the count, leaving the socket one reference
short. When the last legitimate owner drops its reference the reqsk is
freed while still reachable, leading to use-after-free.
This reproduces in seconds with tcp_syncookies=0, a handful of threads
doing connect()/close() to a local listener while others read an
iter/tcp link in a tight loop.
Use refcount_inc_not_zero() and skip the socket on failure. A skipped
socket is still part of the bucket, so keep counting it in expected.
The reallocations are sized from expected, and a request sock whose
refcount gets published while the lock is held across the last realloc
must already have room.
A skipped socket is counted in expected but never batched, so end_sk
can be short of expected on a batch that is actually complete. Decide
completeness by whether the walk left any socket behind instead. The
WARN after the locked realloc checks the same, replacing an
end_sk == expected check that could not hold on that path since
cdec67a489d4.
If every matching socket in a bucket is mid-init (refcount 0), end_sk
stays 0. Advance to the next bucket rather than returning a batch entry
that was never filled this round.
Fixes: 04c7820b776f ("bpf: tcp: Bpf iter batching and lock_sock")
Assisted-by: Claude:unspecified
Signed-off-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev>
---
Changes in v2:
- Count expected right after seq_sk_match() so the batch reallocations
are sized for the whole bucket, including request socks whose
refcount is not yet published (Kuniyuki)
- Signal batch completeness by the walk leaving no leftover socket
instead of end_sk == expected, and check the same condition in the
WARN after the locked reallocation
- Drop the Reviewed-by tags given the code changes
- Rebase onto bpf/master
- Link to v1: https://lore.kernel.org/bpf/20260620-bpf-iter-tcp-refcnt-v1-1-883bf9e69495@linux.dev
The pre-existing double-put on the realloc failure path (raised in the
v1 thread) will be addressed in a separate follow-up patch.
---
net/ipv4/tcp_ipv4.c | 44 +++++++++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 209ef7522508..d8640d114c0d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -3073,24 +3073,24 @@ static unsigned int bpf_iter_tcp_established_batch(struct seq_file *seq,
{
struct bpf_tcp_iter_state *iter = seq->private;
struct hlist_nulls_node *node;
- unsigned int expected = 1;
- struct sock *sk;
+ unsigned int expected = 0;
+ struct sock *sk = *start_sk;
- sock_hold(*start_sk);
- iter->batch[iter->end_sk++].sk = *start_sk;
-
- sk = sk_nulls_next(*start_sk);
*start_sk = NULL;
sk_nulls_for_each_from(sk, node) {
- if (seq_sk_match(seq, sk)) {
- if (iter->end_sk < iter->max_sk) {
- sock_hold(sk);
- iter->batch[iter->end_sk++].sk = sk;
- } else if (!*start_sk) {
- /* Remember where we left off. */
- *start_sk = sk;
- }
- expected++;
+ if (!seq_sk_match(seq, sk))
+ continue;
+ expected++;
+ if (iter->end_sk < iter->max_sk) {
+ /* reqsk_queue_hash_req() inserts with sk_refcnt == 0
+ * and refcount_set()s it after the bucket lock drops.
+ */
+ if (unlikely(!refcount_inc_not_zero(&sk->sk_refcnt)))
+ continue;
+ iter->batch[iter->end_sk++].sk = sk;
+ } else if (!*start_sk) {
+ /* Remember where we left off. */
+ *start_sk = sk;
}
}
@@ -3128,12 +3128,14 @@ static struct sock *bpf_iter_tcp_batch(struct seq_file *seq)
struct sock *sk;
int err;
+again:
sk = bpf_iter_tcp_resume(seq);
if (!sk)
return NULL; /* Done */
expected = bpf_iter_fill_batch(seq, &sk);
- if (likely(iter->end_sk == expected))
+ /* sk carries the first socket that did not fit in the batch. */
+ if (likely(!sk))
goto done;
/* Batch size was too small. */
@@ -3149,7 +3151,7 @@ static struct sock *bpf_iter_tcp_batch(struct seq_file *seq)
return NULL; /* Done */
expected = bpf_iter_fill_batch(seq, &sk);
- if (likely(iter->end_sk == expected))
+ if (likely(!sk))
goto done;
/* Batch size was still too small. Hold onto the lock while we try
@@ -3162,10 +3164,14 @@ static struct sock *bpf_iter_tcp_batch(struct seq_file *seq)
return ERR_PTR(err);
}
- expected = bpf_iter_fill_batch(seq, &sk);
- WARN_ON_ONCE(iter->end_sk != expected);
+ bpf_iter_fill_batch(seq, &sk);
+ WARN_ON_ONCE(sk);
done:
bpf_iter_tcp_unlock_bucket(seq);
+ if (unlikely(!iter->end_sk)) {
+ ++iter->state.bucket;
+ goto again;
+ }
return iter->batch[0].sk;
}
---
base-commit: 7cbd0c4cebe4c9f678d15e6b9ba975e1155a107f
change-id: 20260619-bpf-iter-tcp-refcnt-107d52b238da
Best regards,
--
Jose Fernandez (Anthropic) <jose.fernandez@linux.dev>
^ permalink raw reply related
* [PATCH net-next v2] net/rds: use krealloc_array() for iovector growth
From: Weimin Xiong @ 2026-07-17 2:25 UTC (permalink / raw)
To: netdev
Cc: linux-rdma, rds-devel, linux-kernel, davem, edumazet, kuba,
pabeni, horms
Use krealloc_array() for growing the RDS iovector array. This makes the
array allocation overflow-safe and derives the element size from the
array pointer.
Reviewed-by: Allison Henderson <achender@kernel.org>
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
---
net/rds/send.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 68be1bf0e..a567c97a 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -971,11 +971,8 @@ static int rds_rm_size(struct msghdr *msg, int num_sgs,
return -EINVAL;
if (vct->indx >= vct->len) {
vct->len += vct->incr;
- tmp_iov =
- krealloc(vct->vec,
- vct->len *
- sizeof(struct rds_iov_vector),
- GFP_KERNEL);
+ tmp_iov = krealloc_array(vct->vec, vct->len,
+ sizeof(*vct->vec), GFP_KERNEL);
if (!tmp_iov) {
vct->len -= vct->incr;
return -ENOMEM;
--
2.39.3
^ permalink raw reply related
* [PATCH net-next v2] net/rds: use krealloc_array() for iovector growth
From: Weimin Xiong @ 2026-07-17 2:25 UTC (permalink / raw)
To: netdev
Cc: linux-rdma, rds-devel, linux-kernel, davem, edumazet, kuba,
pabeni, horms, achender
Use krealloc_array() for growing the RDS iovector array. This makes the
array allocation overflow-safe and derives the element size from the
array pointer.
Reviewed-by: Allison Henderson <achender@kernel.org>
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
---
net/rds/send.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 68be1bf0e..a567c97a 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -971,11 +971,8 @@ static int rds_rm_size(struct msghdr *msg, int num_sgs,
return -EINVAL;
if (vct->indx >= vct->len) {
vct->len += vct->incr;
- tmp_iov =
- krealloc(vct->vec,
- vct->len *
- sizeof(struct rds_iov_vector),
- GFP_KERNEL);
+ tmp_iov = krealloc_array(vct->vec, vct->len,
+ sizeof(*vct->vec), GFP_KERNEL);
if (!tmp_iov) {
vct->len -= vct->incr;
return -ENOMEM;
--
2.39.3
^ permalink raw reply related
* RE: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Jiawen Wu @ 2026-07-17 2:22 UTC (permalink / raw)
To: 'Coia Prant', 'Andrew Lunn'
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, robh, krzk+dt,
heiko, netdev, linux-rockchip, devicetree, linux-arm-kernel,
linux-phy, 'Mengyuan Lou'
In-Reply-To: <CALj3r0jdkDEjpO+7NOTGs+wgukKvD=fzFn4ewpurxxPswCE5GA@mail.gmail.com>
On Wed, Jul 15, 2026 7:05 AM, Coia Prant wrote:
> Andrew Lunn <andrew@lunn.ch> 于2026年7月15日周三 06:44写道：
> >
> > On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> > > Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> >
> > You do not appear to Cc: the Wangxun NIC people. It would be good to
> > have there comments on this change.
>
> I apologize; the output from get_maintainer.pl is very long. I’ve
> heard that having too many recipients can cause the PATCH to be
> rejected by the LKML mail server.
>
> I have added Wangxun maintainer (Jiawen Wu <jiawenwu@trustnetic.com>
> and Mengyuan Lou <mengyuanlou@net-swift.com>) to the CC list.
>
> > > Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > > Signed-off-by: Coia Prant <coiaprant@gmail.com>
> >
> > Please don't mix fixed and new code. Is this a real fix? Should it be
> > back ported to stable?
>
> I am not sure if this is a specific characteristic of Wangxun NICs, as
> I do not have any available for testing.
>
> The behavior of the Rockchip DW XPCS IP core matches what is described
> in the commit message (even though phylink brings the link to down
> based on the phydev link status).
>
> This appears to be a bug (at least on Rockchip platforms) or Wangxun
> NICs features.
>
> However, I cannot confirm whether Wangxun NICs behave the same way.
> Therefore, I have kept their code as is for now.
>
> Could a Wangxun NICs maintainer provide some feedback based on testing?
>
> If we can confirm that this is indeed a bug, I can submit a separate fix.
>
> I would greatly appreciate it.
>
> Thanks.
Hi Coia,
I have tested this patch and it works on Wangxun NICs, thanks.
The commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
is too long ago for me to recall exactly what that thought was.
The log shows:
"On this device, CL37_ANSGM_STS (bit[4:1] of VR_MII_AN_INTR_STS) indicates
the status received from remote link during the auto-negotiation, and
self-clear after the auto-negotiation is complete.
Meanwhile, CL37_ANCMPLT_INTR will be set to 1, to indicate CL37 AN is
complete. So add another way to get the state for CL37 SGMII."
I tried to reproduce this issue, but it didn't seem to exist.
In the current logic:
link up -> read status from CL37_ANSGM_STS -> CL37_ANCMPLT_INTR not clear
link down -> read status from BMCR -> CL37_ANCMPLT_INTR clear
It also works, although CL37_ANCMPLT_INTR is not cleared every time, and AN
restart is absent. But BMCR looks like it only wants to be return as 0, it is
weird.
So I think Wangxun NICs also can be applied to general code as well, for
getting state in C37 SGMII mode.
However, I am wondering whether CL37_ANCMPLT_INTR clear and ANRESTART are
necessary.
^ permalink raw reply
* [PATCH net] net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller
From: Chenguang Zhao @ 2026-07-17 2:23 UTC (permalink / raw)
To: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno
Cc: netdev, linux-mediatek, linux-arm-kernel, chenguang.zhao,
Chenguang Zhao
From: Chenguang Zhao <zhaochenguang@kylinos.cn>
mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq
cookie), but mtk_poll_controller incorrectly passed the net_device *.
Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled
would then crash.
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5d291e50a47b..351444fb4871 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -3467,7 +3467,7 @@ static void mtk_poll_controller(struct net_device *dev)
mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
mtk_rx_irq_disable(eth, eth->soc->rx.irq_done_mask);
- mtk_handle_irq_rx(eth->irq[MTK_FE_IRQ_RX], dev);
+ mtk_handle_irq_rx(eth->irq[MTK_FE_IRQ_RX], eth);
mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
mtk_rx_irq_enable(eth, eth->soc->rx.irq_done_mask);
}
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v2] net/rds: use krealloc_array() for iovector growth
From: Weimin Xiong @ 2026-07-17 2:23 UTC (permalink / raw)
To: netdev; +Cc: linux-rdma
Use krealloc_array() for growing the RDS iovector array. This makes the
array allocation overflow-safe and derives the element size from the
array pointer.
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
Reviewed-by: Allison Henderson <achender@kernel.org>
---
net/rds/send.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 68be1bf0e..a567c97a 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -971,11 +971,8 @@ static int rds_rm_size(struct msghdr *msg, int num_sgs,
return -EINVAL;
if (vct->indx >= vct->len) {
vct->len += vct->incr;
- tmp_iov =
- krealloc(vct->vec,
- vct->len *
- sizeof(struct rds_iov_vector),
- GFP_KERNEL);
+ tmp_iov = krealloc_array(vct->vec, vct->len,
+ sizeof(*vct->vec), GFP_KERNEL);
if (!tmp_iov) {
vct->len -= vct->incr;
return -ENOMEM;
--
2.39.3
^ permalink raw reply related
* Re: Re: [PATCH] vhost-vdpa: propagate set_map error to caller
From: Weimin Xiong @ 2026-07-17 2:17 UTC (permalink / raw)
To: eperezma; +Cc: virtualization, mst, jasowangio, netdev, kvm, xiongweimin
In-Reply-To: <CAJaqyWeNJwVNUihL8MAEH+-a5OsoaDGsgaPnP0BqQd6YH4ZhYg@mail.gmail.com>
From: xiongweimin <xiongweimin@kylinos.cn>
Hi Eugenio,
Thanks for your review!
You are right. My original patch has an issue with the `break` statement,
which skips the `v->in_batch = false` assignment when `set_map` fails.
The correct approach is to simply capture the return value without
breaking:
```c
case VHOST_IOTLB_BATCH_END:
if (v->in_batch && ops->set_map)
r = ops->set_map(vdpa, asid, iotlb);
v->in_batch = false;
break;
```
This way:
1. The return value of `set_map` is propagated to the caller
2. `v->in_batch` is always reset, regardless of success or failure
Updated patch attached below.
---
Subject: [PATCH] vhost-vdpa: propagate set_map error to caller
The return value of ops->set_map() is currently ignored when handling
VHOST_IOTLB_BATCH_END. If the backend fails to program the IOTLB,
the VMM incorrectly believes the operation succeeded and may continue
with stale or incorrect mappings.
Propagate the error from ops->set_map() to the caller.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index bb96b1aa5..b52d8d94e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -1298,7 +1298,7 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, u32 asid,
break;
case VHOST_IOTLB_BATCH_END:
if (v->in_batch && ops->set_map)
- ops->set_map(vdpa, asid, iotlb);
+ r = ops->set_map(vdpa, asid, iotlb);
v->in_batch = false;
break;
default:
--
2.39.3
^ permalink raw reply related
* (no subject)
From: Weimin Xiong @ 2026-07-17 2:13 UTC (permalink / raw)
To: eperezma; +Cc: virtualization, mst, jasowangio, netdev, kvm, xiongweimin
In-Reply-To: <CAJaqyWeNJwVNUihL8MAEH+-a5OsoaDGsgaPnP0BqQd6YH4ZhYg@mail.gmail.com>
From: xiongweimin <xiongweimin@kylinos.cn>
Hi Eugenio,
Thanks for your review!
You are right. My original patch has an issue with the `break` statement,
which skips the `v->in_batch = false` assignment when `set_map` fails.
The correct approach is to simply capture the return value without
breaking:
```c
case VHOST_IOTLB_BATCH_END:
if (v->in_batch && ops->set_map)
r = ops->set_map(vdpa, asid, iotlb);
v->in_batch = false;
break;
```
This way:
1. The return value of `set_map` is propagated to the caller
2. `v->in_batch` is always reset, regardless of success or failure
Updated patch attached below.
---
Subject: [PATCH] vhost-vdpa: propagate set_map error to caller
The return value of ops->set_map() is currently ignored when handling
VHOST_IOTLB_BATCH_END. If the backend fails to program the IOTLB,
the VMM incorrectly believes the operation succeeded and may continue
with stale or incorrect mappings.
Propagate the error from ops->set_map() to the caller.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index bb96b1aa5..b52d8d94e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -1298,7 +1298,7 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, u32 asid,
break;
case VHOST_IOTLB_BATCH_END:
if (v->in_batch && ops->set_map)
- ops->set_map(vdpa, asid, iotlb);
+ r = ops->set_map(vdpa, asid, iotlb);
v->in_batch = false;
break;
default:
--
2.39.3
^ permalink raw reply related
* Re: [PATCH net-next v3 12/15] ibmveth: Expose per-queue buffer pool details via sysfs
From: mingming cao @ 2026-07-17 1:54 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bjking1, haren, ricklind, kuba, edumazet, pabeni,
linuxppc-dev, maddy, mpe, davemarq
In-Reply-To: <20260714130142.1841365-1-horms@kernel.org>
On 7/14/26 6:01 AM, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> ibmveth: Expose per-queue buffer pool details via sysfs
>
> This commit adds a read-only sysfs attribute buffer_pools to the VIO device
> to expose per-queue buffer pool details dynamically. It outputs runtime per-queue
> buffer pressure metrics like size, active, and available buffers.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index 4e3f49b6346fd..ecc472ee8f71f 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
>> @@ -2896,6 +2896,52 @@ static const struct net_device_ops ibmveth_netdev_ops = {
> [ ... ]
>> +static ssize_t buffer_pools_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct net_device *netdev = dev_get_drvdata(dev);
>> + struct ibmveth_adapter *adapter = netdev_priv(netdev);
>> + int len = 0;
>> + int i, j;
>> +
>> + len += scnprintf(buf + len, PAGE_SIZE - len,
>> + "Queue Pool Size BuffSize Active Available\n");
>> + len += scnprintf(buf + len, PAGE_SIZE - len,
>> + "----- ---- ---- -------- ------ ---------\n");
> [Severity: Medium]
> Does this buffer_pools_show() implementation violate the sysfs "one value
> per file" design rule?
>
> The attribute appears to dump a complex, multi-line ASCII table with headers
> and columns rather than exposing a single value per sysfs file.
*
Agreed this is more of a diagnostic dump than a sysfs one-value
attribute. In v4 I’ll move it to debugfs ?
*
>
> [ ... ]
>> @@ -3056,6 +3102,14 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
>>
>> netdev_dbg(netdev, "registered\n");
>>
>> + rc = sysfs_create_group(&dev->dev.kobj, &ibmveth_attr_group);
>> + if (rc) {
>> + netdev_err(netdev, "failed to create sysfs attributes rc=%d\n", rc);
>> + unregister_netdev(netdev);
>> + free_netdev(netdev);
>> + return rc;
>> + }
> [Severity: High]
> If userspace brings up the interface immediately after register_netdev()
> succeeds, could adapter->work be scheduled before sysfs_create_group() fails?
>
> If this race occurs, unregister_netdev() does not synchronously cancel the
> work.
>
> Could the global workqueue execute the pending adapter->work item on freed
> memory after free_netdev() is called in this ibmveth_probe() error path?
*
Good catch. remove() cancels the work, but this probe error path
did not. Will cancel_work_sync() (and clean pool kobjects) before
free_netdev() in v4.
*
> [Severity: High]
> This is a pre-existing issue in older error paths of ibmveth_probe(), but it
> is duplicated here: does this error path leak the adapter->rx_buff_pool
> kobjects?
>
> Since kobject_put() is not called on the pool kobjects before free_netdev()
> is executed, the kobjects remain attached to the VIO device with dangling
> pointers to the freed adapter memory.
>
> Could subsequent sysfs accesses to those pool kobjects trigger a
> use-after-free?
*
Yes — that path (and some older probe failure paths) skip
kobject_put() on the pool objects. I’ll add a common probe
cleanup helper in v4 so pool kobjects and the reset work are
always torn down before free_netdev().
*
Thanks,
Mingming
^ permalink raw reply
* Re: [PATCH net-next v3 11/15] ibmveth: Add per-queue RX and TX statistics collection and reporting
From: mingming cao @ 2026-07-17 1:39 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bjking1, haren, ricklind, kuba, edumazet, pabeni,
linuxppc-dev, maddy, mpe, davemarq
In-Reply-To: <20260714125948.1841205-1-horms@kernel.org>
On 7/14/26 5:59 AM, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> ibmveth: Add per-queue RX and TX statistics collection and reporting
>
> This commit introduces per-queue statistics tracking for both receive and
> transmit paths in the ibmveth driver. The counters are aggregated for legacy
> interfaces and exposed individually via ethtool stringsets.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> index 863e5c68b42c7..4e3f49b6346fd 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
> [ ... ]
>> @@ -1655,6 +1655,10 @@ static int ibmveth_open(struct net_device *netdev)
>> if (rc)
>> goto out_cleanup_rx_interrupts;
>>
>> + rc = ibmveth_alloc_tx_qstats(adapter);
>> + if (rc)
>> + goto out_free_tx_resources;
>> +
>> netif_tx_start_all_queues(netdev);
>>
>> netdev_dbg(netdev, "open complete\n");
> [ ... ]
>> out_cleanup_rx_interrupts:
>> ibmveth_cleanup_rx_interrupts(adapter);
>> out_free_tx_resources:
>> ibmveth_free_tx_resources(adapter);
> [Severity: High]
> Does the goto out_free_tx_resources on ibmveth_alloc_tx_qstats() failure
> bypass the cleanup for RX interrupts?
>
> Since out_free_tx_resources is physically below out_cleanup_rx_interrupts in
> ibmveth_open(), failing here leaves the IRQs requested and NAPI enabled. If
> an interrupt subsequently fires, could the handler access the freed RX queue
> memory and cause a kernel panic?
>
> [ ... ]
*
Confirmed — that goto skips RX interrupt cleanup. Will fix the
open() unwind order in v4 so TX-stat allocation failure still
disables NAPI and frees IRQs before tearing down queues.
*
>> @@ -1699,6 +1699,7 @@ static int ibmveth_close(struct net_device *netdev)
>> }
>> }
>>
>> + ibmveth_free_tx_qstats(adapter);
>> ibmveth_free_tx_resources(adapter);
>> ibmveth_cleanup_rx_interrupts(adapter);
>> ibmveth_update_rx_no_buffer(adapter);
> [ ... ]
>> ibmveth_free_rx_qstats(adapter);
> [Severity: High]
> If ibmveth_close() is called to bring down the interface, does this
> unconditionally free adapter->tx_qstats and adapter->rx_qstats without a
> grace period?
Confirmed.
>
> Since ibmveth_get_stats64() can be called concurrently under RCU, and
> ibmveth_start_xmit() can run concurrently if the datapath is not completely
> synchronized, could this lead to a use-after-free or NULL pointer dereference
> when these functions access the freed arrays?
>
> [ ... ]
*
Good point. ndo_get_stats64 can run without RTNL. In v4 I’ll give
the qstat arrays adapter lifetime (probe/remove) instead of
open/close, so close cannot free them under concurrent readers.
*
>> @@ -1967,22 +1967,107 @@ static int ibmveth_set_features(struct net_device *dev,
> [ ... ]
>> +static void ibmveth_aggregate_rx_qstats(struct ibmveth_adapter *adapter)
>> +{
>> + u64 total_invalid = 0;
>> + u64 total_large = 0;
>> + int i;
>> +
>> + if (!adapter->rx_qstats)
>> + return;
>> +
>> + for (i = 0; i < adapter->num_rx_queues; i++) {
>> + total_invalid += adapter->rx_qstats[i].invalid_buffers;
>> + total_large += adapter->rx_qstats[i].large_packets;
>> + }
>> +
>> + adapter->rx_invalid_buffer = total_invalid;
>> + adapter->rx_large_packets = total_large;
>> +}
> [Severity: High]
> Does overwriting adapter->rx_invalid_buffer and other persistent global
> counters with the dynamically allocated adapter->rx_qstats values cause a
> permanent loss of interface statistics?
yes
> When the interface is brought down and back up, ibmveth_close() frees the
> queue stats arrays and ibmveth_open() reallocates them as zeroed. Will this
> cause all historical statistics to be wiped out on every interface reset,
> breaking standard persistence behavior?
>
> [ ... ]
*
Agreed this regresses persistence vs pre-MQ.
**
In v4 per-queue qstats will stay for the adapter lifetime, and adapter-level
ethtool strings are summed on read (ibmvnic-style). No dual-updating
globals on the hot path, and no aggregate_* that wipes history on reopen.
*
>> +static void ibmveth_get_strings(struct net_device *dev, u32 stringset, u8 *data)
>> +{
> [ ... ]
>> + for (i = 0; i < adapter->num_rx_queues; i++) {
>> + ethtool_sprintf(&p, "rx%d_packets", i);
>> + ethtool_sprintf(&p, "rx%d_bytes", i);
> [Severity: Low]
> Are these private ethtool stringsets duplicating standard kernel statistics?
>
> According to the subsystem guidelines, per-queue packet and byte statistics
> that have a standard UAPI representation (like struct netdev_queue_stats_rx
> exported via netlink) should not be duplicated as private ethtool strings.
*
Thanks — **
*I can move those to standard*
*
netdev queue stats and drop the ethtool duplicates in a follow-up. For
now I'll keep device-specific counters (interrupts, polls, invalid, …)
as private ethtool strings.
*
*
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.h b/drivers/net/ethernet/ibm/ibmveth.h
>> index f7b20fd01acb5..390c660af979e 100644
>> --- a/drivers/net/ethernet/ibm/ibmveth.h
>> +++ b/drivers/net/ethernet/ibm/ibmveth.h
>> @@ -316,9 +316,21 @@ struct ibmveth_rx_queue_stats {
>> u64 no_buffer_drops;
>> };
>>
>> +struct ibmveth_tx_queue_stats {
>> + u64 packets;
>> + u64 bytes;
>> + u64 large_packets;
>> + u64 dropped_packets;
>> + u64 send_failures;
>> + u64 checksum_offload;
>> +};
> [Severity: Medium]
> Will this structure layout prevent cache line false sharing?
>
> The commit message mentions tracking transmit counters per TX queue to avoid
> cache line contention, but struct ibmveth_tx_queue_stats appears to be
> exactly 48 bytes and lacks cacheline alignment annotations like
> ____cacheline_aligned. When allocated as a contiguous array, will multiple
> CPUs processing different queues end up writing to the same hardware
> cacheline?
*Will add cacheline alignment for the per-queue stats structs in v4*
*Thanks again for your valuable feedback!*
*Mingming*
^ permalink raw reply
* Re: Please backport: DSA taggers OOB read on PACKET_QDISC_BYPASS TX
From: Sasha Levin @ 2026-07-17 1:37 UTC (permalink / raw)
To: stable
Cc: Sasha Levin, olteanv, andrew, f.fainelli, davem, edumazet, kuba,
pabeni, netdev, Doruk Tan Ozturk
In-Reply-To: <20260714164633.75135-1-doruk@0sec.ai>
On Tue, Jul 14, 2026 at 06:46:33PM +0200, Doruk Tan Ozturk wrote:
> eabb1494c9f2 ("net: dsa: tag_ocelot: do not rely on skb_mac_header() for VLAN xmit")
> 499b2491d550 ("net: dsa: tag_ksz: do not rely on skb_mac_header() in TX paths")
> f9346f00b5af ("net: dsa: tag_sja1105: don't rely on skb_mac_header() in TX paths")
> 0bcf2e4aca6c ("net: dsa: tag_ocelot: call only the relevant portion of __skb_vlan_pop() on TX")
I've queued the tag_ksz fix (499b2491d550) for 6.1 and 5.15; 6.6 and
newer already have it.
I'm holding off on the ocelot and sja1105 commits (and their
skb_vlan_eth_hdr() prerequisite), as well as on 5.10 entirely - the
backports there diverge more from upstream than I'm comfortable
carrying without more soak time.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] vhost: reject zero-size IOTLB INVALIDATE
From: Weimin Xiong @ 2026-07-17 1:29 UTC (permalink / raw)
To: Eugenio Perez Martin
Cc: virtualization, mst, jasowangio, netdev, kvm, xiongweimin
In-Reply-To: <CAJaqyWfW9n5o+ojrEjK-m+6cwH_TSxWckjkvEXowZA8r=vDmdQ@mail.gmail.com>
From: xiongweimin <xiongweimin@kylinos.cn>
Hi Eugenio,
Thank you for your review and suggestion!
I've updated the patch to v2, moving the check to vhost_chr_write_iter
as you suggested. The existing check for VHOST_IOTLB_UPDATE is now extended
to also cover VHOST_IOTLB_INVALIDATE.
Thanks for your Acked-by!
Best regards,
Weimin Xiong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox