* [PATCH net 0/4] mptcp: misc fixes for v7.1-rc3
From: Matthieu Baerts (NGI0) @ 2026-05-01 19:35 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal,
Gang Yan, Dmytro Shytyi
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Shardul Bankar, stable
Here are various unrelated fixes:
- Patch 1: increment the right MIB counter. A fix for v5.7.
- Patch 2: set the right MPTCP reset reason. A fix for v5.9.
- Patch 3: fix rx timestamp corruption when on MPTCP passive fastopen. A
fix for v6.2.
- Patch 4: increase sockopt seq after having set TCP_MAXSEG to propagate
it to newer subflows later. A fix for 6.17.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Matthieu Baerts (NGI0) (1):
mptcp: sockopt: increase seq in mptcp_setsockopt_all_sf
Paolo Abeni (1):
mptcp: fix rx timestamp corruption on fastopen
Shardul Bankar (2):
mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
net/mptcp/fastopen.c | 4 +++-
net/mptcp/sockopt.c | 4 ++++
net/mptcp/subflow.c | 4 ++--
3 files changed, 9 insertions(+), 3 deletions(-)
---
base-commit: 85da3965df5e6f1e1c48d2c435e140c5b66625ef
change-id: 20260501-net-mptcp-misc-fixes-7-1-rc3-902fc2a5d499
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* [PATCH net 1/4] mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
From: Matthieu Baerts (NGI0) @ 2026-05-01 19:35 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal,
Gang Yan, Dmytro Shytyi
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Shardul Bankar, stable
In-Reply-To: <20260501-net-mptcp-misc-fixes-7-1-rc3-v1-0-b70118df778e@kernel.org>
From: Shardul Bankar <shardul.b@mpiricsoftware.com>
In subflow_finish_connect(), HMAC validation of the server's HMAC
in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
wrong on ACK + MP_JOIN") on failure. The function processes the
SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
incremented anywhere in the tree.
The mirror site on the server, subflow_syn_recv_sock(), already
uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
at the SYN/ACK validation site so each counter reflects the packet
whose HMAC actually failed.
Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/subflow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e2cb9d23e4a0..bda6862264ca 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -581,7 +581,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
subflow->backup);
if (!subflow_thmac_valid(subflow)) {
- MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINSYNACKMAC);
subflow->reset_reason = MPTCP_RST_EMPTCP;
goto do_reset;
}
--
2.53.0
^ permalink raw reply related
* [PATCH net 2/4] mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
From: Matthieu Baerts (NGI0) @ 2026-05-01 19:35 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal,
Gang Yan, Dmytro Shytyi
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Shardul Bankar, stable
In-Reply-To: <20260501-net-mptcp-misc-fixes-7-1-rc3-v1-0-b70118df778e@kernel.org>
From: Shardul Bankar <shardul.b@mpiricsoftware.com>
When HMAC validation fails on a received ACK + MP_JOIN in
subflow_syn_recv_sock(), the subflow is reset with reason
MPTCP_RST_EPROHIBIT ("Administratively prohibited"). This is
incorrect: HMAC validation failure is an MPTCP protocol-level
error, not an administrative policy denial.
The mirror site on the client, in subflow_finish_connect(), already
uses MPTCP_RST_EMPTCP ("MPTCP-specific error") for the same kind of
HMAC failure on the SYN/ACK + MP_JOIN. Use the same reason on the
server side for symmetry and accuracy.
Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/subflow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index bda6862264ca..d562e149606f 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -908,7 +908,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
if (!subflow_hmac_valid(subflow_req, &mp_opt)) {
SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
- subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
+ subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
goto dispose_child;
}
--
2.53.0
^ permalink raw reply related
* [PATCH net 3/4] mptcp: fix rx timestamp corruption on fastopen
From: Matthieu Baerts (NGI0) @ 2026-05-01 19:35 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal,
Gang Yan, Dmytro Shytyi
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), stable
In-Reply-To: <20260501-net-mptcp-misc-fixes-7-1-rc3-v1-0-b70118df778e@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
The skb cb offset containing the timestamp presence flag is cleared
before loading such information. Cache such value before MPTCP CB
initialization.
Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/fastopen.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c
index 82ec15bcfd7f..082c46c0f50e 100644
--- a/net/mptcp/fastopen.c
+++ b/net/mptcp/fastopen.c
@@ -12,6 +12,7 @@ void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subf
struct sock *sk, *ssk;
struct sk_buff *skb;
struct tcp_sock *tp;
+ bool has_rxtstamp;
/* on early fallback the subflow context is deleted by
* subflow_syn_recv_sock()
@@ -40,12 +41,13 @@ void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subf
*/
tp->copied_seq += skb->len;
subflow->ssn_offset += skb->len;
+ has_rxtstamp = TCP_SKB_CB(skb)->has_rxtstamp;
/* Only the sequence delta is relevant */
MPTCP_SKB_CB(skb)->map_seq = -skb->len;
MPTCP_SKB_CB(skb)->end_seq = 0;
MPTCP_SKB_CB(skb)->offset = 0;
- MPTCP_SKB_CB(skb)->has_rxtstamp = TCP_SKB_CB(skb)->has_rxtstamp;
+ MPTCP_SKB_CB(skb)->has_rxtstamp = has_rxtstamp;
MPTCP_SKB_CB(skb)->cant_coalesce = 1;
mptcp_data_lock(sk);
--
2.53.0
^ permalink raw reply related
* [PATCH net 4/4] mptcp: sockopt: increase seq in mptcp_setsockopt_all_sf
From: Matthieu Baerts (NGI0) @ 2026-05-01 19:35 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal,
Gang Yan, Dmytro Shytyi
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), stable
In-Reply-To: <20260501-net-mptcp-misc-fixes-7-1-rc3-v1-0-b70118df778e@kernel.org>
mptcp_setsockopt_all_sf() was missing a call to sockopt_seq_inc(). This
is required not to cause missing synchronization for newer subflows
created later on.
This helper is called each time a socket option is set on subflows, and
future ones will need to inherit this option after their creation.
Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/sockopt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 0efe40be2fde..1cf608e7357b 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -812,6 +812,10 @@ static int mptcp_setsockopt_all_sf(struct mptcp_sock *msk, int level,
if (ret)
break;
}
+
+ if (!ret)
+ sockopt_seq_inc(msk);
+
return ret;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net 1/1] net/rds: handle zerocopy send cleanup before the message is queued
From: Allison Henderson @ 2026-05-01 19:40 UTC (permalink / raw)
To: Ren Wei, netdev, linux-rdma, rds-devel
Cc: davem, edumazet, kuba, pabeni, horms, santosh.shilimkar,
sowmini.varadhan, willemb, yuantan098, yifanwucs, tomapufckgml,
bird, lx24, tonanli66
In-Reply-To: <d2ea98a6313d5467bac00f7c9fef8c7acddb9258.1777550074.git.tonanli66@gmail.com>
On Fri, 2026-05-01 at 09:08 +0800, Ren Wei wrote:
> From: Nan Li <tonanli66@gmail.com>
>
> A zerocopy send can fail after user pages have been pinned but before
> the message is attached to the sending socket.
>
> The purge path currently infers zerocopy state from rm->m_rs, so an
> unqueued message can be cleaned up as if it owned normal payload pages.
> However, zerocopy ownership is really determined by the presence of
> op_mmp_znotifier, regardless of whether the message has reached the
> socket queue.
>
> Capture op_mmp_znotifier up front in rds_message_purge() and use it as
> the cleanup discriminator. If the message is already associated with a
> socket, keep the existing completion path. Otherwise, drop the pinned
> page accounting directly and release the notifier before putting the
> payload pages.
>
> This keeps early send failure cleanup consistent with the zerocopy
> lifetime rules without changing the normal queued completion path.
>
> Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Co-developed-by: Xiao Liu <lx24@stu.ynu.edu.cn>
> Signed-off-by: Xiao Liu <lx24@stu.ynu.edu.cn>
> Signed-off-by: Nan Li <tonanli66@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
This fix looks fine to me. Thanks Ren Wei!
Reviewed-by: Allison Henderson <achender@kernel.org>
Allison
> ---
> net/rds/message.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/net/rds/message.c b/net/rds/message.c
> index eaa6f22601a4..25fedcb3cd00 100644
> --- a/net/rds/message.c
> +++ b/net/rds/message.c
> @@ -131,24 +131,34 @@ static void rds_rm_zerocopy_callback(struct rds_sock *rs,
> */
> static void rds_message_purge(struct rds_message *rm)
> {
> + struct rds_znotifier *znotifier;
> unsigned long i, flags;
> - bool zcopy = false;
> + bool zcopy;
>
> if (unlikely(test_bit(RDS_MSG_PAGEVEC, &rm->m_flags)))
> return;
>
> spin_lock_irqsave(&rm->m_rs_lock, flags);
> + znotifier = rm->data.op_mmp_znotifier;
> + rm->data.op_mmp_znotifier = NULL;
> + zcopy = !!znotifier;
> +
> if (rm->m_rs) {
> struct rds_sock *rs = rm->m_rs;
>
> - if (rm->data.op_mmp_znotifier) {
> - zcopy = true;
> - rds_rm_zerocopy_callback(rs, rm->data.op_mmp_znotifier);
> + if (znotifier) {
> + rds_rm_zerocopy_callback(rs, znotifier);
> rds_wake_sk_sleep(rs);
> - rm->data.op_mmp_znotifier = NULL;
> }
> sock_put(rds_rs_to_sk(rs));
> rm->m_rs = NULL;
> + } else if (znotifier) {
> + /*
> + * Zerocopy can fail before the message is queued on the
> + * socket, so there is no rs to carry the notification.
> + */
> + mm_unaccount_pinned_pages(&znotifier->z_mmp);
> + kfree(rds_info_from_znotifier(znotifier));
> }
> spin_unlock_irqrestore(&rm->m_rs_lock, flags);
>
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: phy: ncn26000: add support for TS2500 internal PHY
From: Andrew Lunn @ 2026-05-01 19:50 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Piergiorgio Beruto, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CY8PR02MB924929303200D28EDEB66F4783322@CY8PR02MB9249.namprd02.prod.outlook.com>
> +/* clause 45 vendor specific registers */
> +#define NCN26000_REG_PHYCFG1_MMD MDIO_MMD_VEND2
Please use MDIO_MMD_VEND2 rather than obfuscating it.
There is a lot going on in this patch, with no real explanation in the
commit message. Please break it up into a number of smaller commits
with good commit messages.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: ethernet: oa_tc6: hardware timestamp support added
From: Andrew Lunn @ 2026-05-01 19:56 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Piergiorgio Beruto, parthiban.veerasooran@microchip.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CY8PR02MB924976A9160ED3FB0883911583322@CY8PR02MB9249.namprd02.prod.outlook.com>
On Fri, May 01, 2026 at 07:15:35PM +0000, Selvamani Rajagopal wrote:
> mii_bus structure can be allocated/populated from vendor's code
> to accommodate vendor side customization.
>
> Timestamp support implemented following OPEN Alliance 10BASE-T1x
> MACPHY Serial Interface specification.
When i see two items in a commit message it is a good indication the
patch needs splitting up.
We want lots of small patches, which are obviously correct, with good
commit messages.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 3/6] pds_core: add PLDM firmware update support via devlink flash
From: Rao, Nikhil @ 2026-05-01 20:03 UTC (permalink / raw)
To: Jakub Kicinski, Nikhil P. Rao
Cc: Brett Creeley, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Kees Cook, Gustavo A. R. Silva, netdev, linux-kernel,
linux-hardening, eric.joyner
In-Reply-To: <20260430180521.6457e61f@kernel.org>
On 4/30/2026 6:05 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Wed, 29 Apr 2026 08:28:19 +0000 Nikhil P. Rao wrote:
>> +#define PDS_CORE_FW_COMPONENT_LIST_LEN ((PDS_PAGE_SIZE - \
>> + sizeof(struct pds_core_component_list_info)) / \
>> + sizeof(struct pds_core_fw_component_info))
>> +
>> +#if defined(__has_attribute) && !__has_attribute(__counted_by__)
>> +#define __counted_by(member)
>> +#endif
>
> Please don't redefined kernel-level primitives.
> It's a huge pain in the rear to deal with when indexing the code.
>
> This patch also adds a bunch of kdoc warnings.
>
> Last but not least Sashiko points out a number of bugs
Thanks for the review.
We will fix the issues above in v2 and also use Sashiko to review v2 and
future patches before submission.
Nikhil
^ permalink raw reply
* Re: [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Shitalkumar Gandhi @ 2026-05-01 20:08 UTC (permalink / raw)
To: stefan, alex.aring
Cc: miquel.raynal, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-wpan, netdev, linux-kernel, stable
In-Reply-To: <20260421073259.12345-1-shitalkumar.gandhi@cambiumnetworks.com>
Hi Stefan, Alex,
Friendly ping on the patch below. It still applies cleanly to net/master
as of today (verified against torvalds/master), and Miquèl provided
Reviewed-by on Apr 21.
If you would prefer this split into two patches per Markus's suggestion
(one for the leak fix with Fixes:/Cc: stable, one for the misleading
error-string cleanup), please let me know and I will resend as a v2
series.
Thanks,
Shitalkumar
^ permalink raw reply
* Re: [PATCH net-next 4/5] onsemi: ncn260xx: Add driver support for NCN26010 and TS2500 MAC-PHY
From: Andrew Lunn @ 2026-05-01 20:22 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Piergiorgio Beruto, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CY8PR02MB92494A5A16B7AF4EA3A69F2483322@CY8PR02MB9249.namprd02.prod.outlook.com>
> +static int mmd2mms(int mmd)
> +{
> + int ret = -EOPNOTSUPP;
> +
> + switch (mmd) {
> + case MDIO_MMD_PCS:
> + ret = OA_TC6_PHY_C45_PCS_MMS2;
> + break;
> + case MDIO_MMD_PMAPMD:
> + ret = OA_TC6_PHY_C45_PMA_PMD_MMS3;
> + break;
> + case MDIO_MMD_VEND2:
> + ret = OA_TC6_PHY_C45_VS_PLCA_MMS4;
> + break;
> + case MDIO_MMD_VEND1:
> + ret = ONMPH_OA_TC6_VEND1_MMS12;
> + break;
> + default:
> + break;
> + }
> + return ret;
> +}
So you seem to be compliant with the standard. I've not seen anything
use MDIO_MMD_POWER_UNIT so not having that should not be an
issue. MDIO_MMD_AN is used by a number of PHYs, but i assume yours
does not.
802.3 C45 says that if a register does not exist, it should read
0. What would happen if a read was made to
OA_TC6_PHY_C45_AUTO_NEG_MMS5, rather than returning EOPNOTSUPP?
Table 6 says nothing about MMD 30, which you map to 12. 10-15 are
defined as vendor specific, so that is O.K.
But can we simply this. Add something like
void oa_tc6_set_vend1_mms(struct oa_tc6 *tc6, int mms)
{
tc6->vend1_mms = mms;
}
and make oa_tc6_get_phy_c45_mms() look at its value?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010 10BASE-T1S MACPHY
From: Rob Herring (Arm) @ 2026-05-01 20:36 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: edumazet, conor+dt, devicetree, Piergiorgio Beruto, netdev, kuba,
davem, andrew+netdev, krzk+dt, pabeni, linux-kernel
In-Reply-To: <CY8PR02MB9249D083B637477C254F9B0583322@CY8PR02MB9249.namprd02.prod.outlook.com>
On Fri, 01 May 2026 19:15:17 +0000, Selvamani Rajagopal wrote:
> Add YAML device tree binding for the onsemi NCN26010 and TS2500
> IEEE 802.3cg compliant Ethernet transceiver devices.
>
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> ---
> .../bindings/net/onnn,ncn260xx.yaml | 71 +++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/onnn,ncn260xx.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/onnn,ncn260xx.example.dtb: ethernet@0 (onnn,ncn260xx): 'pinctrl-0' is a dependency of 'pinctrl-names'
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-consumer.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/CY8PR02MB9249D083B637477C254F9B0583322@CY8PR02MB9249.namprd02.prod.outlook.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH net-next 5/5] selftests: net: add veth BQL stress test
From: Simon Schippers @ 2026-05-01 20:35 UTC (permalink / raw)
To: Jonas Köppeler, Jesper Dangaard Brouer
Cc: andrew+netdev, davem, edumazet, horms, jhs, jiri, kernel-team,
kuba, netdev, pabeni
In-Reply-To: <a841e7ed-eee0-4069-bd0d-ab043a1509c5@tu-berlin.de>
On 5/1/26 10:43, Jonas Köppeler wrote:
> On 4/30/26 2:31 PM, Jesper Dangaard Brouer wrote:
>>
>>
>> On 30/04/2026 11.45, Simon Schippers wrote:
>>> On 4/30/26 11:17, Jonas Köppeler wrote:
>>>> On 3/28/26 4:19 PM, Simon Schippers wrote:
>>>>> Hi, thanks for your work! I am really interested in this patchset.
>>>>>
>>>>> I am planning to submit a similar patch set (see [1]) for the tun/tap
>>>>> driver, where I am currently implementing qdisc backpressure similar
>>>>> to that used in veth.
>>>>>
>>>>> Can you run pktgen [2] to see if there is a regression?
>>>>> I think that there might be a slowdown due to BQL not choosing a big
>>>>> enough queue size.
>>>> I ran some tests using pktgen by replacing the trafficgen from the
>>>> selftest with samples/pktgen/pktgen_sample01_simple.sh (Patch v3)
>>>> and used --nrules 0. In general the throughput is quite similar:
>>>>
>>>> BQL disabled (using --bql-disable):
>>>> 2378694pps 1141Mb/sec (1141773120bps) errors: 0
>>>> 2400898pps 1152Mb/sec (1152431040bps) errors: 0
>>>> 2358125pps 1131Mb/sec (1131900000bps) errors: 0
>>>> 2402034pps 1152Mb/sec (1152976320bps) errors: 0
>>>> 2362061pps 1133Mb/sec (1133789280bps) errors: 0
>>>> 2416301pps 1159Mb/sec (1159824480bps) errors: 0
>>>> 2398496pps 1151Mb/sec (1151278080bps) errors: 0
>>>> 2415200pps 1159Mb/sec (1159296000bps) errors: 0
>>>> 2375921pps 1140Mb/sec (1140442080bps) errors: 0
>>>> 2427419pps 1165Mb/sec (1165161120bps) errors: 0
>>>> 2382461pps 1143Mb/sec (1143581280bps) errors: 0
>>>>
>>>> mean: 2392510pps
>>>>
>>>> BQL enabled:
>>>> 2159545pps 1036Mb/sec (1036581600bps) errors: 0
>>>> 2321899pps 1114Mb/sec (1114511520bps) errors: 0
>>>> 2477853pps 1189Mb/sec (1189369440bps) errors: 0
>>>> 2447857pps 1174Mb/sec (1174971360bps) errors: 0
>>>> 2400284pps 1152Mb/sec (1152136320bps) errors: 0
>>>> 2442841pps 1172Mb/sec (1172563680bps) errors: 0
>>>> 2442540pps 1172Mb/sec (1172419200bps) errors: 0
>>>> 2410585pps 1157Mb/sec (1157080800bps) errors: 0
>>>> 2395902pps 1150Mb/sec (1150032960bps) errors: 0
>>>> 2393260pps 1148Mb/sec (1148764800bps) errors: 0
>>>> 2401959pps 1152Mb/sec (1152940320bps) errors: 0
>>>>
>>>> mean: 2390411pps
>>>>
>>>> BQL enabled is ~2099pps (~0.09%) lower than BQL disabled.
>>>
>>> Sounds great!
>>>
>>> One more thing:
>>> Could you check what BQL limit settles during the test run using
>>> something like:
>>>
>>> watch -n 0.1 'cat /sys/class/net/XXXXX/queues/tx-0/byte_queue_limits/limit'
>>
>> FYI: The selftest already tracks BQL "limit" and "inflight".
>> - Jonas can just report those BQL inflight logs
>>
>> +print_periodic_stats() {
>> + local elapsed="$1"
>> +
>> + # BQL stats and watchdog counter
>> + WD_CNT=$(cat /sys/class/net/${VETH_A}/queues/tx-0/tx_timeout \
>> + 2>/dev/null) || WD_CNT="?"
>> + if [ -n "$BQL_DIR" ] && [ -d "$BQL_DIR" ]; then
>> + INFLIGHT=$(cat "$BQL_DIR/inflight" 2>/dev/null || echo "?")
>> + LIMIT=$(cat "$BQL_DIR/limit" 2>/dev/null || echo "?")
>> + echo " [${elapsed}s] BQL inflight=${INFLIGHT} limit=${LIMIT}" \
>> + "watchdog=${WD_CNT}"
>> + else
>> + echo " [${elapsed}s] watchdog=${WD_CNT} (no BQL sysfs)"
>> + fi
>>
> Hi, so what I found is that pktgen does not respect
> __QUEUE_STATE_STACK_OFF. So the test data above is invalid, since it
> just sent packets even if the BQL "stopped" the queue. So I patched
> pktgen with the following:
>
> - if (unlikely(netif_xmit_frozen_or_drv_stopped(txq))) {
> + if (unlikely(netif_xmit_frozen_or_stopped(txq))) {
>
> Test run with --nrules 0
>
> BQL disabled (using --bql-disable):
> inflight packets is always around 200 packets and throughput
> 2264138pps 1086Mb/sec (1086786240bps)
>
> BQL enabled:
> inflight packet is always 3 packets (with some exception that
> sometimes its even 0) and throughput is degraded:
> 1813455pps 870Mb/sec (870458400bps)
> limit is 2.
>
> BQL enabled is roughly 20% worse in throughput.
Good findings.
>
> Test run with --nrules 3500
>
> BQL disabled: Inflight ~200, throughput: 27161pps 13Mb/sec
> BQL enabled: Inflight 3 (limit 2), throughput: 26085pps 12Mb/sec
> BQL ~4% worse.
>
> Test run with --nrules 5000
>
> BQL disabled: Inflight ~200, throughput: 19395pps 9Mb/sec
> BQL enabled: Inflight 3 (limit 2), throughput: 20423pps 9Mb/sec
> BQL ~5.3% better.
>
> So it seems that BQL will always steer to a limit of 2. Could this be
> a result of that we call netdev_tx_completed_queue for every packet?
>
> Looking at the comment above netdev_tx_completed_queue in
> include/linux/netdevice.h:
>
> "Must be called at most once per TX completion round (and not per
> individual packet), so that BQL can adjust its limits appropriately."
>
> This is consistent with what Tom Herbert stated in the original BQL
> cover letter [1]:
>
> "BQL accounting is in the transmit path for every packet, and the
> function to recompute the byte limit is run once per transmit
> completion."
Yes, exactly that will be the problem here.
There must be a periodic transmit completion but there is not.
Adding something like a tasklet for calling netdev_tx_completed_queue()
periodically feels wrong. And veth_tx_timeout() is also not suited
for that. And calling it on ptr_ring_empty() is probably also wrong.
I guess there must be a new "BQL" algorithm just for
software interfaces which considers:
1. Context Switching (bigger ring size better)
2. Cache locality (smaller ring size better)
3. Bufferbloat (time limit in ring?)
I think it is a hard problem.
How about first adding a option to modify the VETH_RING_SIZE?
>
> [1] https://lwn.net/Articles/469652/
>
> Jonas
>
>>> I guess it will just choose the ptr_ring size as limit in this case,
>>> but it would be nice if you could briefly verify this :)
>>>
>>> Thanks!
>>>
>>>>
>>>>> Thanks!
>>>>>
>>>>> [1] Link:https://lore.kernel.org/all/20260312130639.138988-1-simon.schippers@tu-dortmund.de/
>>>>> [2] Link:https://www.kernel.org/doc/html/latest/networking/pktgen.html
>>
^ permalink raw reply
* Re: [PATCH v2 1/2] netfilter: ip_tables: guard ipt_unregister_table_pre_exit against NULL ops
From: Tristan Madani @ 2026-05-01 20:41 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, Phil Sutter, netfilter-devel, netdev, stable,
linux-kernel
In-Reply-To: <afPUr2oksLlaMcOj@strlen.de>
On Thu, 1 May 2026 Florian Westphal wrote:
> If we have races between a thread calling ipt_register_table
> and the netns cleanup path there is nothing we could ever do to
> fix it: we are tearing down a live network namespace.
> Something else must be going on.
I agree, this one is unusual. I tried multiple PoC approaches
without success -- all I have is the syzkaller crash I shared,
no reliable reproducer. Syzkaller itself could not minimize it
either.
That said, the crash is real -- KASAN shows ops=NULL in
pre_exit during cleanup_net -- so something is reaching that
path. The V2 guard handles it regardless of the root cause:
if ops is NULL in pre_exit, we should not pass it to
nf_unregister_net_hooks.
I will share any PoC/repro if I get one.
Thanks,
Tristan
^ permalink raw reply
* Re: [PATCH net v1 1/3] net: introduce helper to resolve hardware timestamps from skb
From: Gerhard Engleder @ 2026-05-01 20:25 UTC (permalink / raw)
To: Kohei Enju, netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Jonathan Lemon, Richard Cochran
In-Reply-To: <20260429091632.26509-2-kohei@enjuk.jp>
On 29.04.26 11:16, Kohei Enju wrote:
> Move the logic that resolves a hardware timestamp from an skb, including
> late timestamp resolution via netdev_get_tstamp(), from net/socket.c to
> a common helper.
>
> Let's allow other networking code to reuse the same resolution path.
>
> Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> ---
> include/linux/skbuff.h | 11 +++++++++++
> net/core/skbuff.c | 27 +++++++++++++++++++++++++++
> net/socket.c | 27 +++------------------------
> 3 files changed, 41 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 2bcf78a4de7b..651a5ae8b11c 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -4731,6 +4731,17 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb, const struct sk_buff *ack_skb,
> void skb_tstamp_tx(struct sk_buff *orig_skb,
> struct skb_shared_hwtstamps *hwtstamps);
>
> +/**
> + * skb_get_hwtstamp - resolve a hardware timestamp from an skb
> + * @skb: skb carrying the timestamp
> + * @cycles: true to request the free-running cycle-based timestamp
> + * @if_index: optional return pointer for the originating netdev ifindex
> + *
> + * Return: resolved hardware timestamp, or the stored skb hwtstamp when no
> + * device-specific late timestamp resolution is needed.
> + */
> +ktime_t skb_get_hwtstamp(struct sk_buff *skb, bool cycles, int *if_index);
> +
> /**
> * skb_tx_timestamp() - Driver hook for transmit timestamping
> *
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 7dad68e3b518..d11f4e2e9391 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5729,6 +5729,33 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
> }
> EXPORT_SYMBOL_GPL(skb_tstamp_tx);
>
> +ktime_t skb_get_hwtstamp(struct sk_buff *skb, bool cycles, int *if_index)
> +{
> + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> + struct net_device *orig_dev;
> + ktime_t hwtstamp;
> +
> + if (if_index)
> + *if_index = 0;
if_index is set to 0 here the second time when called from
__sock_recv_timestamp(). IMO you can remove these two
lines, because in skb_get_tx_timestamp() if_index has been
removed by your commit.
> +
> + if (!(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV))
> + return shhwtstamps->hwtstamp;
> +
> + rcu_read_lock();
> + orig_dev = dev_get_by_napi_id(skb_napi_id(skb));
> + if (orig_dev) {
> + if (if_index)
> + *if_index = orig_dev->ifindex;
> + hwtstamp = netdev_get_tstamp(orig_dev, shhwtstamps, cycles);
> + } else {
> + hwtstamp = shhwtstamps->hwtstamp;
> + }
> + rcu_read_unlock();
> +
> + return hwtstamp;
> +}
> +EXPORT_SYMBOL_GPL(skb_get_hwtstamp);
> +
> #ifdef CONFIG_WIRELESS
> void skb_complete_wifi_ack(struct sk_buff *skb, bool acked)
> {
> diff --git a/net/socket.c b/net/socket.c
> index 22a412fdec07..95b21b16a0fc 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -876,21 +876,7 @@ static bool skb_is_swtx_tstamp(const struct sk_buff *skb, int false_tstamp)
> static ktime_t get_timestamp(struct sock *sk, struct sk_buff *skb, int *if_index)
> {
> bool cycles = READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_BIND_PHC;
> - struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> - struct net_device *orig_dev;
> - ktime_t hwtstamp;
> -
> - rcu_read_lock();
> - orig_dev = dev_get_by_napi_id(skb_napi_id(skb));
> - if (orig_dev) {
> - *if_index = orig_dev->ifindex;
> - hwtstamp = netdev_get_tstamp(orig_dev, shhwtstamps, cycles);
> - } else {
> - hwtstamp = shhwtstamps->hwtstamp;
> - }
> - rcu_read_unlock();
> -
> - return hwtstamp;
> + return skb_get_hwtstamp(skb, cycles, if_index);
> }
>
> static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb,
> @@ -940,7 +926,6 @@ int skb_get_tx_timestamp(struct sk_buff *skb, struct sock *sk,
> {
> u32 tsflags = READ_ONCE(sk->sk_tsflags);
> ktime_t hwtstamp;
> - int if_index = 0;
if_index is useless in this function, so it can be removed.
This was introduced with 2410251cde0b. Maybe removing
if_index here could be a separate commit, as this clean up
makes sense on its own.
>
> if ((tsflags & SOF_TIMESTAMPING_SOFTWARE) &&
> ktime_to_timespec64_cond(skb->tstamp, ts))
> @@ -950,10 +935,7 @@ int skb_get_tx_timestamp(struct sk_buff *skb, struct sock *sk,
> skb_is_swtx_tstamp(skb, false))
> return -ENOENT;
>
> - if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV)
> - hwtstamp = get_timestamp(sk, skb, &if_index);
> - else
> - hwtstamp = skb_hwtstamps(skb)->hwtstamp;
> + hwtstamp = get_timestamp(sk, skb, NULL);
>
> if (tsflags & SOF_TIMESTAMPING_BIND_PHC)
> hwtstamp = ptp_convert_timestamp(&hwtstamp,
> @@ -1033,10 +1015,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
> !(tsflags & SOF_TIMESTAMPING_OPT_RX_FILTER))) &&
> !skb_is_swtx_tstamp(skb, false_tstamp)) {
> if_index = 0;
> - if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV)
> - hwtstamp = get_timestamp(sk, skb, &if_index);
> - else
> - hwtstamp = shhwtstamps->hwtstamp;
> + hwtstamp = get_timestamp(sk, skb, &if_index);
>
> if (tsflags & SOF_TIMESTAMPING_BIND_PHC)
> hwtstamp = ptp_convert_timestamp(&hwtstamp,
Gerhard
^ permalink raw reply
* Re: [PATCH net-next 04/12] net: stmmac: dma: create a separate dma_device pointer
From: Andrew Lunn @ 2026-05-01 20:55 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, daniel, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <539b9de3-4a78-44cf-9085-06cd0cab2d17@riscstar.com>
On Fri, May 01, 2026 at 01:06:23PM -0500, Alex Elder wrote:
> On 5/1/26 12:13 PM, Andrew Lunn wrote:
> > > if (priv->dma_cap.host_dma_width) {
> > > - ret = dma_set_mask_and_coherent(device,
> > > - DMA_BIT_MASK(priv->dma_cap.host_dma_width));
> > > + u64 mask = DMA_BIT_MASK(priv->dma_cap.host_dma_width);
> > > +
> > > + ret = dma_set_mask_and_coherent(priv->dma_device, mask);
> >
> > I'm nitpicking, but i don't think you need to introduce mask.
> > DMA_BIT_MASK... is already on a line of its own, and is within the 80
> > limit. Nothing changes here with s/device/priv->dma_device/
> >
> > Andrew
>
> I did this. It was simply to silence a checkpatch.pl warning
> about a long line.
>
> I don't care either way, I'll gladly put it back the way it was.
Please pull checkpatch fixes out into a patch of their own.
Andrew
^ permalink raw reply
* Re: Re: [PATCH net-next v2 1/2] mv88e6xxx: Refactor 6352's serdes functions
From: Fidan Aliyeva @ 2026-05-01 21:00 UTC (permalink / raw)
To: andrew
Cc: olteanv, davem, edumazet, kuba, pabeni, netdev, linux-kernel,
thomas.eckerman.ext, fidan.aliyeva.ext
In-Reply-To: <1a57e151-7fff-41c7-9616-20237c27e935@lunn.ch>
> > @@ -185,7 +200,7 @@ size_t mv88e6352_serdes_get_stats(struct
> > mv88e6xxx_chip *chip, int port,
> >
> > for (i = 0; i < ARRAY_SIZE(mv88e6352_serdes_hw_stats); i++) {
> > stat = &mv88e6352_serdes_hw_stats[i];
> > - value = mv88e6352_serdes_get_stat(chip, stat);
> > + value = mv88e6352_serdes_get_stat(chip,
> > + MV88E6352_ADDR_SERDES, stat);
>
> If you generalise this, you can use the same code for the mv88e6321.
>
> > +void mv88e6352_serdes_get_regs(struct mv88e6xxx_chip *chip, int port,
> > +void *_p) {
> > + int err;
> > +
> > + err = mv88e6352_g2_scratch_port_has_serdes(chip, port);
> > + if (err <= 0)
> > + return;
> > +
> > + mv88e6352_serdes_get_regs_from_lane(chip, MV88E6352_ADDR_SERDES,
> > + _p);
>
> Here as well.
Hi, Andrew. Thank you for your review and feedback on both this and
previous version.
I wanted to make those functions generic and not introduce new functions
other than 6321_serdes_get_lane. However, those functions cannot be
generalised the obvious way because they run with reg_lock already taken
which would cause deadlock in mv88e6352_serdes_get_lane function.
Do you have proposal on how that problem can be avoided to make these
functions generic, too?
Best,
Fidan
^ permalink raw reply
* Re: [PATCH net-next 11/12] misc: tc956x_pci: add TC956x/QPS615 support
From: Andrew Lunn @ 2026-05-01 21:07 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, daniel, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-12-elder@riscstar.com>
> diff --git a/drivers/misc/tc956x_pci.c b/drivers/misc/tc956x_pci.c
> +static inline void chip_reset_assert(const struct tc956x_chip *chip,
> + enum reset_id id)
> +{
> + tc956x_reset_clock_set(chip, true, true, true, (u8)id);
> +}
This is in drivers/misc, where the rules might be different. But in
netdev, we don't like inline functions in .c files. It is better to
let the compiler decide.
> +static void chip_init_state(struct tc956x_chip *chip)
> +{
> + /* The only IP block we currently use is MSIGEN */
> + chip_reset_assert(chip, RESET_MCU);
> + chip_reset_assert(chip, RESET_MCU1);
> + chip_reset_assert(chip, RESET_INTC);
> + chip_reset_assert(chip, RESET_UART0);
> + chip_clock_disable(chip, CLOCK_MCU);
> + chip_clock_disable(chip, CLOCK_SRAM);
> + chip_clock_disable(chip, CLOCK_PLL);
> + chip_clock_disable(chip, CLOCK_SGMII);
With my networking hat on, this one standard out.
> + chip_clock_disable(chip, CLOCK_REFCLK);
The name REFCLK is sometimes used as for the clock signals for RGMII?
> +static int
> +tc956x_function_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> + struct device *dev = &pdev->dev;
> + struct tc956x_chip *chip;
> + unsigned int msigen_irq;
> + int ret;
> +
> + /* Despite being a PCI device, we require devicetree */
> + if (!dev->of_node)
> + return -EINVAL;
Might be worth a dev_err(), since it is unusual.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Andrew Lunn @ 2026-05-01 21:09 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, mohd.anwar,
a0987203069, alexandre.torgue, ast, boon.khai.ng, chenchuangyu,
chenhuacai, daniel, hawk, hkallweit1, inochiama, john.fastabend,
julianbraha, livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-13-elder@riscstar.com>
> + tc956x_emac1_phy: ethernet-phy@1c {
> + compatible = "ethernet-phy-id004d.d101";
> + reg = <0x1c>;
> + reset-gpios = <&tc956x_emac0 1 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <20>;
> + reset-deassert-us = <20>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&qep_irq_pin>;
> + interrupts-extended = <&tlmm 101 IRQ_TYPE_EDGE_FALLING>;
What is probably wrong. PHY interrupts are level, not edge.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next 0/5] netshaper: Extend netshaper support
From: Mohsin Bashir @ 2026-05-01 21:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, dsahern, pabeni, kuba, ernis
In-Reply-To: <20260501081741.0e07ed4f@phoenix.local>
> This helps the compiler with optimization and static analysis.
>
> These are all minor issues in an otherwise well-structured patch series.
> The code properly uses designated initializers, validates input with
> appropriate helpers, and follows the error handling patterns correctly.
>
> With these small fixes, the series would be ready for inclusion.
>
> Best regards
Thanks for the feedback Stephen and David. I'll address these points in V2.
^ permalink raw reply
* Re: [PATCH net-next 2/3] vsock: convert to getsockopt_iter
From: David Laight @ 2026-05-01 21:21 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Breno Leitao, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Stefano Garzarella, Shuah Khan,
sdf.kernel, netdev, linux-kernel, virtualization, linux-kselftest,
kernel-team
In-Reply-To: <afTjvM1P4gjPSvW8@devvm29614.prn0.facebook.com>
On Fri, 1 May 2026 10:32:44 -0700
Bobby Eshleman <bobbyeshleman@gmail.com> wrote:
> On Fri, May 01, 2026 at 08:52:52AM -0700, Breno Leitao wrote:
> > Convert AF_VSOCK's getsockopt implementation to use the new
> > getsockopt_iter callback with sockopt_t. The single
> > vsock_connectible_getsockopt() callback is shared by both
> > vsock_stream_ops and vsock_seqpacket_ops, so both proto_ops are
> > updated to use .getsockopt_iter.
> >
> > Key changes:
> > - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
> > - Use opt->optlen for buffer length (input) and returned size (output)
> > - Use copy_to_iter() instead of put_user()/copy_to_user()
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > net/vmw_vsock/af_vsock.c | 16 +++++++---------
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> > index 44037b066a5ff..d4a97eeb596e6 100644
> > --- a/net/vmw_vsock/af_vsock.c
> > +++ b/net/vmw_vsock/af_vsock.c
> > @@ -155,6 +155,7 @@
> > #include <linux/random.h>
> > #include <linux/skbuff.h>
> > #include <linux/smp.h>
> > +#include <linux/uio.h>
> > #include <linux/socket.h>
> > #include <linux/stddef.h>
> > #include <linux/sysctl.h>
> > @@ -2091,8 +2092,7 @@ static int vsock_connectible_setsockopt(struct socket *sock,
> >
> > static int vsock_connectible_getsockopt(struct socket *sock,
> > int level, int optname,
> > - char __user *optval,
> > - int __user *optlen)
> > + sockopt_t *opt)
> > {
> > struct sock *sk = sock->sk;
> > struct vsock_sock *vsk = vsock_sk(sk);
> > @@ -2110,8 +2110,7 @@ static int vsock_connectible_getsockopt(struct socket *sock,
> > if (level != AF_VSOCK)
> > return -ENOPROTOOPT;
> >
> > - if (get_user(len, optlen))
> > - return -EFAULT;
> > + len = opt->optlen;
> >
> > memset(&v, 0, sizeof(v));
> >
> > @@ -2142,11 +2141,10 @@ static int vsock_connectible_getsockopt(struct socket *sock,
> > return -EINVAL;
> > if (len > lv)
> > len = lv;
> > - if (copy_to_user(optval, &v, len))
> > + if (copy_to_iter(&v, len, &opt->iter_out) != len)
I'd wrap that as copy_to_sockopt(&v, len, opt).
or to make the edits easier: copy_to_sockopt(opt, &v, len).
Then if someone decides to change the implementation none of the call
sites need changing.
-- David
> > return -EFAULT;
> >
> > - if (put_user(len, optlen))
> > - return -EFAULT;
> > + opt->optlen = len;
> >
> > return 0;
> > }
> > @@ -2631,7 +2629,7 @@ static const struct proto_ops vsock_stream_ops = {
> > .listen = vsock_listen,
> > .shutdown = vsock_shutdown,
> > .setsockopt = vsock_connectible_setsockopt,
> > - .getsockopt = vsock_connectible_getsockopt,
> > + .getsockopt_iter = vsock_connectible_getsockopt,
> > .sendmsg = vsock_connectible_sendmsg,
> > .recvmsg = vsock_connectible_recvmsg,
> > .mmap = sock_no_mmap,
> > @@ -2653,7 +2651,7 @@ static const struct proto_ops vsock_seqpacket_ops = {
> > .listen = vsock_listen,
> > .shutdown = vsock_shutdown,
> > .setsockopt = vsock_connectible_setsockopt,
> > - .getsockopt = vsock_connectible_getsockopt,
> > + .getsockopt_iter = vsock_connectible_getsockopt,
> > .sendmsg = vsock_connectible_sendmsg,
> > .recvmsg = vsock_connectible_recvmsg,
> > .mmap = sock_no_mmap,
> >
> > --
> > 2.52.0
> >
>
> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
>
^ permalink raw reply
* RE: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010 10BASE-T1S MACPHY
From: Selvamani Rajagopal @ 2026-05-01 21:21 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: edumazet@google.com, conor+dt@kernel.org,
devicetree@vger.kernel.org, Piergiorgio Beruto,
netdev@vger.kernel.org, kuba@kernel.org, davem@davemloft.net,
andrew+netdev@lunn.ch, krzk+dt@kernel.org, pabeni@redhat.com,
linux-kernel@vger.kernel.org
In-Reply-To: <177766776795.356932.18256256609588920036.robh@kernel.org>
Thanks. I did verify with dt_binding_check. Will update and re-run
Sincerely
Selva
> -----Original Message-----
> From: Rob Herring (Arm) <robh@kernel.org>
> Sent: Friday, May 1, 2026 1:36 PM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> Cc: edumazet@google.com; conor+dt@kernel.org; devicetree@vger.kernel.org;
> Piergiorgio Beruto <Pier.Beruto@onsemi.com>; netdev@vger.kernel.org;
> kuba@kernel.org; davem@davemloft.net; andrew+netdev@lunn.ch; krzk+dt@kernel.org;
> pabeni@redhat.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 1/5] dt-bindings: net: add onsemi's TS2500/NCN26010
> 10BASE-T1S MACPHY
>
>
> This Message Is From an External Sender
> This message came from outside your organization.
>
>
> On Fri, 01 May 2026 19:15:17 +0000, Selvamani Rajagopal wrote:
> > Add YAML device tree binding for the onsemi NCN26010 and TS2500
> > IEEE 802.3cg compliant Ethernet transceiver devices.
> >
> > Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> > ---
> > .../bindings/net/onnn,ncn260xx.yaml | 71 +++++++++++++++++++
> > 1 file changed, 71 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/onnn,ncn260xx.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-
> ci/linux/Documentation/devicetree/bindings/net/onnn,ncn260xx.example.dtb: ethernet@0
> (onnn,ncn260xx): 'pinctrl-0' is a dependency of 'pinctrl-names'
> from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-consumer.yaml
> <https://url.usb.m.mimecastprotect.com/s/VZmaCzqg1RhMKNXAMigiLU9M-
> 1W?domain=devicetree.org>
>
> doc reference errors (make refcheckdocs):
>
> See
> https://patchwork.kernel.org/project/devicetree/patch/CY8PR02MB9249D083B637477C25
> 4F9B0583322@CY8PR02MB9249.namprd02.prod.outlook.com
> <https://patchwork.kernel.org/project/devicetree/patch/CY8PR02MB9249D083B637477C254F9B0583322@CY8PR02MB9249.namprd02.prod.outlook.com
> patchwork.kernel.org>
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 1/2] netfilter: ip_tables: guard ipt_unregister_table_pre_exit against NULL ops
From: Florian Westphal @ 2026-05-01 22:00 UTC (permalink / raw)
To: Tristan Madani
Cc: Pablo Neira Ayuso, Phil Sutter, netfilter-devel, netdev, stable,
linux-kernel
In-Reply-To: <177766806589.1898033.5646188235412407059@gmail.com>
Tristan Madani <tristmd@gmail.com> wrote:
> That said, the crash is real -- KASAN shows ops=NULL in
> pre_exit during cleanup_net -- so something is reaching that
> path. The V2 guard handles it regardless of the root cause:
> if ops is NULL in pre_exit, we should not pass it to
> nf_unregister_net_hooks.
>
> I will share any PoC/repro if I get one.
Thanks. I have a patch series that should close all
races, I need to retest it tomorrow and then I'll post it
so sashiko, syzbot etc. can have a go at it.
I found a few other problems in the general area so it should
be a good improvement over the current state of affairs.
^ permalink raw reply
* Re: Re: [PATCH net-next v2 1/2] mv88e6xxx: Refactor 6352's serdes functions
From: Andrew Lunn @ 2026-05-01 22:10 UTC (permalink / raw)
To: Fidan Aliyeva
Cc: olteanv, davem, edumazet, kuba, pabeni, netdev, linux-kernel,
thomas.eckerman.ext
In-Reply-To: <20260501210036.1675100-1-fidan.aliyeva.ext@ericsson.com>
> I wanted to make those functions generic and not introduce new functions
> other than 6321_serdes_get_lane. However, those functions cannot be
> generalised the obvious way because they run with reg_lock already taken
> which would cause deadlock in mv88e6352_serdes_get_lane function.
Ah, the scratch register. None of the other serdes_get_lane()
functions need to read a register. O.K.
So we don't expect the scratch register to change at runtime do we?
Nope, the value in it is read during reset. After that, it does not
matter what happens to the pin, the value in the scratch register is
fixed. So maybe read it during mv88e6xxx_setup_port() and store the
value in struct mv88e6xxx_port?
Andrew
^ permalink raw reply
* Re: [PATCH 1/1] ovpn: tcp - defer TX from softirq to workqueue
From: Jakub Kicinski @ 2026-05-01 23:12 UTC (permalink / raw)
To: Dao Zhong Ma
Cc: linux-kernel, netdev, antonio, sd, andrew+netdev, davem, edumazet,
pabeni
In-Reply-To: <20260501145425.757147-2-cz1346219@gmail.com>
On Fri, 1 May 2026 22:54:25 +0800 Dao Zhong Ma wrote:
> ovpn_tcp_send_skb() holds sk->sk_lock.slock while performing the full TCP
> send in softirq context. This can hold the spinlock for a long time
> (large skb), blocking lock_sock() users. This can starve the RCU GP
> kthread and trigger RCU stalls warnings and hung tasks.
>
> Defer the TCP send operation to process context:
> - In interrupt context, only enqueue the skb under the spinlock
> schedule tcp_tx_work.
> - In process context, dequeue and flush the send queue under lock_sock()
>
> This reduces the softirq critical section to a short duration, allowing
> lock_sock() users to make progress and preventing RCU stalls.
This appears to break the ovpn selftests
^ 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