* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 15:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <CANn89iLV9pyCKU4vyNMzW5FFv4=Xcq_pgvZaFhzJHAAbCK0h7w@mail.gmail.com>
On 2026/7/15 23:30, Eric Dumazet wrote:
> On Wed, Jul 15, 2026 at 5:26 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> On 2026/7/15 23:15, Eric Dumazet wrote:
>>> On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> [...]
>>
>>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>>> index 61045a8886e4..4f1027173e95 100644
>>>> --- a/net/ipv4/tcp_input.c
>>>> +++ b/net/ipv4/tcp_input.c
>>>> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
>>>> /* When we get a reset we do this. */
>>>> void tcp_reset(struct sock *sk, struct sk_buff *skb)
>>>> {
>>>> + const struct net *net = sock_net(sk);
>>>> int err;
>>>>
>>>> trace_tcp_receive_reset(sk);
>>>> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
>>>> err = ECONNREFUSED;
>>>> break;
>>>> case TCP_CLOSE_WAIT:
>>>> + /* RFC9293 3.10.7.4. Other States
>>>> + * Second, check the RST bit:
>>>> + * CLOSE-WAIT STATE
>>>> + *
>>>> + * If the RST bit is set, then any outstanding RECEIVEs and
>>>> + * SEND should receive "reset" responses. All segment queues
>>>> + * should be flushed. Users should also receive an unsolicited
>>>> + * general "connection reset" signal. Enter the CLOSED state,
>>>> + * delete the TCB, and return.
>>>> + *
>>>> + * If net.ipv4.tcp_purge_receive_queue is enabled,
>>>> + * sk_receive_queue will be flushed too.
>>>> + */
>>>> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
>>>> + struct tcp_sock *tp = tcp_sk(sk);
>>>> +
>>>> + skb_queue_purge(&sk->sk_receive_queue);
>>>> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
>>>> + WRITE_ONCE(tp->urg_data, 0);
>>>> + sk_set_peek_off(sk, -1);
>>>> + }
>>>> err = EPIPE;
>>>> break;
>>>> case TCP_CLOSE:
>>>> --
>>>> 2.55.0
>>>>
>>>
>>> My thoughts are:
>>>
>>> out_of_order_queue has been forgotten. skbs could be there and still
>>> 'block devmem'
>>>
>>> WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
>>> read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
>>> So the application will not know a RST was received :/
>>>
>>> I think that BSD and linux implementations have historically retained
>>> acknowledged,
>>> buffered receive data upon RST to allow applications to drain data
>>> already ACKed prior to the reset.
>>>
>>> Adding a narrow sysctl specifically for CLOSE_WAIT creates
>>> inconsistent behavior across TCP states.
>>
>>
>> Got it. I won't pursue this sysctl approach in the future. Thanks for
>> the review.
>
> My intention was not to kill your proposal, only to start a conversation...
Thanks for clarifying. I agree this approach needs more thought.
Thanks,
Leon
^ permalink raw reply
* Re: ipv4: icmp: icmp_route_lookup() relookups pick wrong netdev with policy routing + strict rp_filter
From: Eric Dumazet @ 2026-07-15 15:43 UTC (permalink / raw)
To: Muhammad Ziad
Cc: netdev, David Ahern, Jakub Kicinski, Paolo Abeni, David S. Miller,
linux-kernel
In-Reply-To: <CAOAwikA60AYKdFr_UDLyja3oU4hqyAE7uFZWqum5uRdaQsgRYg@mail.gmail.com>
On Wed, Jul 15, 2026 at 5:30 PM Muhammad Ziad <muhzi100@gmail.com> wrote:
>
> Hello,
>
> There appears to be a bug in mainline Linux in ICMP reverse-path
> relookup logic inside icmp_route_lookup() (called by __icmp_send())
> when strict rp_filter setting is in place.
>
> When Linux forwards a packet between two interfaces and needs to
> generate an ICMP error, icmp_route_lookup() performs a "secondary"
> reverse-path lookup to find a suitable route back towards the original
> source via ip_route_input(). To simulate the reverse path, the kernel
> derives the incoming netdev by calling ip_route_output_key() with a
> decoy flow that has *only* daddr assigned in it:
>
> struct flowi4 fl4_2 = {};
> fl4_2.daddr = fl4_dec.saddr;
> rt2 = ip_route_output_key(net, &fl4_2); /* no saddr */
> ...
> ip_route_input(skb_in, fl4_dec.daddr, fl4_dec.saddr,
> dscp, rt2->dst.dev);
>
> This can lead to a mismatch between rt2->dst.dev and the netdev the
> real reverse packet would use once routing policy rules are in
> effect. With strict rp_filter, passing the wrong netdev to
> ip_route_input() causes the relookup to fail and a "martian source"
> message to be logged, after which icmp_route_lookup() falls back to
> the earlier output route lookup (relookup_failed).
>
> In such a scenario, I would expect the relookup to use a canonical
> netdev and the kernel to not produce spurious "martian source" log
> messages as a result. This suggests the decoy flow would possibly
> need to carry saddr too so that ip_route_output_key() is able to
> resolve the right netdev.
>
> I tested this on: Ubuntu kernel 6.17.0-35-generic.
>
> Here is a reproducer script that sets up two net namespaces: a
> "forwarder" with two routes to the same dst in separate routing tables
> picked according to saddr, and a "sender" netns behind it which sends
> a ping with ttl=1 via the forwarder forcing it to generate an ICMP
> error as a response which leads to the result explained above:
>
> #!/bin/bash
>
> if [ "${forwarder_ns:-}" != "1" ]; then
> exec env forwarder_ns=1 unshare -Urn bash "$0" "$@"
> fi
>
> SRC=10.0.1.2
> DST=198.51.100.5
>
> # Current netns is the "forwarder".
> # Create a second namespace for the sender.
> unshare -n sleep 120 &
> cpid=$!
> trap 'kill "$cpid" 2>/dev/null || true' EXIT
> in_ns() { nsenter -t "$cpid" -n "$@"; }
>
> # veth r0(router) <-> s0(src)
> ip link add s0 type veth peer name r0
> ip link set s0 netns "$cpid"
> ip link set lo up
> ip link set r0 up
> ip addr add 10.0.1.1/24 dev r0
> ip link add dumA type dummy
> ip addr add 203.0.113.1/24 dev dumA
> ip link set dumA up
> ip link add dumB type dummy
> ip addr add 192.0.2.1/24 dev dumB
> ip link set dumB up
>
> sysctl -q -w net.ipv4.ip_forward=1
> for c in all default r0 dumA dumB; do
> sysctl -q -w "net.ipv4.conf.$c.rp_filter=1"
> sysctl -q -w "net.ipv4.conf.$c.log_martians=1"
> done
>
> # Destination reachable two ways.
> # Policy rule diverts traffic FROM src to dumB
> ip route add 198.51.100.0/24 dev dumA
> ip route add 198.51.100.0/24 dev dumB table 100
> ip rule add from "$SRC" lookup 100
>
> # sender namespace setup.
> in_ns ip link set lo up
> in_ns ip link set s0 up
> in_ns ip addr add 10.0.1.2/24 dev s0
> in_ns ip route add default via 10.0.1.1
>
> # This will trigger a "martian source" log.
> in_ns ping -q -c1 -W2 -t1 "$DST" &>/dev/null
>
>
> Happy to test patches or provide additional traces, if needed.
>
> Thank you,
> Mohamed Ghazy
Thanks for the report.
It seems we are lacking more than saddr setting :/
Could you test
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 23e921d313b36b00d8ae5e14846527220c9db32b..6277e1bf85f304678ff167e8fd2b9239f155ce42
100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -548,10 +548,17 @@ static struct rtable *icmp_route_lookup(struct
net *net, struct flowi4 *fl4,
if (IS_ERR(rt2))
err = PTR_ERR(rt2);
} else {
- struct flowi4 fl4_2 = {};
+ /* TODO: populate
+ .flowi4_dscp = dscp,
+ .flowi4_mark = mark,
+ .flowi4_uid = sock_net_uid(net, NULL),
+ */
+ struct flowi4 fl4_2 = {
+ .daddr = fl4_dec.saddr,
+ .saddr = fl4_dec.daddr,
+ };
unsigned long orefdst;
- fl4_2.daddr = fl4_dec.saddr;
rt2 = ip_route_output_key(net, &fl4_2);
if (IS_ERR(rt2)) {
err = PTR_ERR(rt2);
^ permalink raw reply
* RE: Ethtool : PRBS feature
From: Das, Shubham @ 2026-07-15 15:38 UTC (permalink / raw)
To: Lee Trager, Srinivasan, Vijay, Andrew Lunn
Cc: Alexander Duyck, Maxime Chevallier, netdev@vger.kernel.org,
mkubecek@suse.cz, D H, Siddaraju, Chintalapalle, Balaji,
Lindberg, Magnus, niklas.damberg@ericsson.com, Wirandi, Jonas
In-Reply-To: <46f714b7-ec6e-4b26-9ff8-b7f27f11fe33@trager.us>
Hi,
> > + name: lane
> > + type: u32
> > + doc: PHY lane index to target for the test operation
> This could be a mask to allow starting and stopping the same test on multiple
> lanes at once.
Yes, changed to bitmask for multi lane port operation.
+ name: lane
+ type: u32
+ doc: |
+ Bitmask of PHY lanes to target for the test operation.
+ Each bit corresponds to a lane index (bit 0 = lane 0,
+ bit 1 = lane 1, etc.). Multiple lanes can be selected
+ simultaneously.
+
+ For phy-test-act (set): required. The operation is applied
+ to each lane indicated in the mask.
+
+ For phy-test-get (show): optional. When omitted, status is
+ returned for all lanes. When specified, only the indicated
+ lanes are queried.
+ Examples:
+ # Single lane
+ ethtool --phy-test eth1 lane 0 tx-pattern prbs7
+ ethtool --phy-test eth2 lane 0 rx-pattern prbs7
+ ethtool --phy-test eth2 lane 0 bert start
+
+ # Multiple lanes (comma-separated)
+ ethtool --phy-test eth1 lane 0,1,2,3 tx-pattern prbs31
> > + name: ber-total-bits-sent
> > + type: u64
> > + doc: BERT total bits sent
> nit: Hardware engineers I spoke to expect BER to be a floating point number
> which is calculated as errors / total. I dropped "BER" from everything kernel
> related to avoid confusion. I provided an awk script which did the calculation and
> provided a floating point.
Removed BER prefix from lock, error-count and total-bits-sent parameter and added required description.
+ name: checker-lock
+ type: u8
+ doc: |
+ Indicates when receiver side checker is aligned and locked
+ to expected pattern. Lock is a prerequisite for valid BERT
+ (Bit Error Ratio Testing) results.
+ Checker lock status (1=locked, 0=not locked).
+ -
+ name: error-count
+ type: u64
+ doc: |
+ Number of bit errors detected by the PRBS checker during
+ BERT (Bit Error Ratio Testing). This is the raw error count
+ accumulated since bert start. To compute Bit Error Ratio,
+ divide error-count by total-bits-sent
+ (e.g., BER = error-count / total-bits-sent).
+ -
+ name: total-bits-sent
+ type: u64
+ doc: |
+ Total number of bits processed by the PRBS checker
+ during BERT (Bit Error Ratio Testing). Accumulated since
+ bert start. Used together with error-count to calculate
+ Bit Error Ratio: BER = error-count / total-bits-sent.
> I think it would be good to follow what existing tools do. Lane is optional when
> not given all lanes are assumed. When specified it can be one or more comma
> separated lanes.
Lane can be optional for the get operation. If it is not specified, the driver can iterate
over all lanes based on the port configuration and return the corresponding results.
For the set phy-test operation, however, we believe the lane should be mandatory.
Depending on the PHY implementation, error checkers may either be shared across
all lanes or instantiated per lane. Requiring an explicit lane avoids ambiguity
and ensures that the test configuration is applied to the intended lane.
> Lane should be a mask. This way userspace can poll stats while testing is running
> which would only require one call.
Yes, lane is changed to bitmask field.
- Shubham
> -----Original Message-----
> From: Lee Trager <lee@trager.us>
> Sent: 09 July 2026 06:29
> To: Das, Shubham <shubham.das@intel.com>; Srinivasan, Vijay
> <vijay.srinivasan@intel.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: Alexander Duyck <alexander.duyck@gmail.com>; Maxime Chevallier
> <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com; Wirandi,
> Jonas <jonas.wirandi@ericsson.com>
> Subject: Re: Ethtool : PRBS feature
>
> On 7/7/26 2:06 AM, Das, Shubham wrote:
>
> > Thanks Andrew, Lee for the feedback.
> >
> > Lee,
> > I don't see prbs11.0, prbs11.1, prbs11.2, prbs11.3, prbs13.0, prbs13.1, prbs13.2,
> prbs13.3, prbs16 and prbs32 in IEEE 802.3 2022 standard.
> > Is this specific to fnic based on base PRBS pattern or it is mentioned in some
> other standard ?
> Those were from the fbnic spec, I'm not sure where they originate from.
> I suppose we can drop those for now but its good to keep in mind more tests may
> be added in the future.
> >
> > Each lane and each direction is a completely separate test with its
> > own test of
> >> statistics. The test is actually verified on the Rx side, Tx is your
> >> generator so you won't have data to collect. So when you run PRBS
> >> testing on a 2 lane NIC you are actually running 4 independent tests.
> >> While its fine to have a shortcut to run the same test on all lanes
> >> we absolutely need a way to run tests per lane and the ability to choose Rx, Tx,
> or both.
> > - Agree, we need lane parameter in commands, Updated command.
> >
> >
> >> I wouldn't consider stats a phy-test action. It shouldn't change the
> >> state of the NIC at all. I would just add phy-test-stats as set of standard
> ethtool statistics.
> > Yes moved under separate command.
> >
> > Below are the updated UAPI, data structures, and Netlink messages to support
> PRBS/BERT and test pattern configuration.
> >
> > diff --git a/Documentation/netlink/specs/ethtool.yaml
> > b/Documentation/netlink/specs/ethtool.yaml
> > index 5e9135e3774f..113005a5f80a 100644
> > --- a/Documentation/netlink/specs/ethtool.yaml
> > +++ b/Documentation/netlink/specs/ethtool.yaml
> > @@ -30,6 +30,35 @@ definitions:
> > + -
> > + name: phy-test-pattern
> > + enum-name: phy-test-pattern
> > + type: enum
> > + name-prefix: phy-test-pattern-
> > + doc: PRBS and other PHY test patterns
> > + entries:
> > + - off
> > + - prbs7
> > + - prbs9
> > + - prbs11
> > + - prbs13
> > + - prbs15
> > + - prbs23
> > + - prbs31
> > + - ssprq
> > + - prbs13q
> > + - prbs31q
> > + - square8
> >
> > + name: phy-test-action
> > + enum-name: phy-test-action
> > + type: enum
> > + name-prefix: phy-test-action-
> > + doc: Actions for PHY BERT test control
> > + entries:
> > + - none
> > + - start
> > + - stop
> >
> > + name: phy-test
> > + attr-cnt-name: __ethtool-a-phy-test-cnt
> > + doc: |
> > + PHY test configuration for pattern generation/checking,
> > + BERT (Bit Error Rate Test), and statistics.
> > + attributes:
> > + -
> > + name: unspec
> > + type: unused
> > + value: 0
> > + -
> > + name: header
> > + type: nest
> > + nested-attributes: header
> > + -
> > + name: lane
> > + type: u32
> > + doc: PHY lane index to target for the test operation
> This could be a mask to allow starting and stopping the same test on multiple
> lanes at once.
> > + -
> > + name: tx-pattern
> > + type: u32
> > + doc: TX test pattern type (PRBS or square8 wave)
> > + enum: phy-test-pattern
> > + -
> > + name: rx-pattern
> > + type: u32
> > + doc: RX checker pattern type (PRBS or square8 wave)
> > + enum: phy-test-pattern
> > + -
> > + name: bert-action
> > + type: u32
> > + doc: BERT test start/stop
> > + enum: phy-test-action
> > + -
> > + name: inject-error-count
> > + type: u32
> > + doc: |
> > + Inject a specified number of bit errors into the PHY transmit data
> > + stream for diagnostic verification purposes.
> > +
> > + Context and Purpose:
> > + When performing Bit Error Ratio Testing (BERT), the receiving side
> > + runs a PRBS checker that monitors for bit errors. Before relying
> > + on a zero-error BERT result, operators need to confirm Checker
> > + state and configuration to qualify result as TRUE.
> > + A checker that is broken or misconfigured would also report
> > + zero errors, giving a FALSE pass. Error injection provides this
> > + confirmation by deliberately introducing a known number of errors
> > + on the transmit side and verifying they appear on the receive side.
> > +
> > + Note:
> > + Receiver under test maybe in the same port as the transmitter
> > + (loopback mode) or a different port in the same device or another
> > + device connected to the transmitting port (non-loopback mode).
> > +
> > + Layer and Mechanism:
> > + Error injection operates at the PMA/PMD boundary. This is
> > + bit-level injection in the serial data stream, not frame-level.
> > + The SerDes Built-In Self Test (BIST) block inverts the specified
> > + number of bits in the outgoing serial stream. The injection does
> > + not distinguish between data frames and test patterns; it
> > + corrupts raw bits at the physical layer regardless of what the
> > + stream carries.
> > +
> > + Mode of Operation:
> > + This command implements "one-shot" injection: a single burst of
> > + N bit errors injected immediately. The PHY inverts exactly N
> > + consecutive bits in the serial transmit stream at the PMA/PMD
> > + layer, then resumes clean transmission. No continuous/fixed-rate
> > + injection mode is provided.
> > +
> > + Prerequisites:
> > + - A PRBS test pattern must be active on the transmitting port
> > + (tx-pattern != off).
> > + - The receiving port must have the matching rx-pattern configured
> > + and ber-lock-status must be "locked" (indicating the checker
> > + has synchronized to the incoming pattern).
> > + - BERT must be running on the receiving port (bert start issued).
> > +
> > + Note:
> > + Availability of BIST mode test pattern generator, checker and
> > + lock indication is IP dependent.
> > +
> > + Semantics:
> > + - Fire-and-forget: the command completes immediately. No
> > + persistent state is created. Each invocation is an independent
> > + injection event.
> > + - The command may be issued multiple times. Each invocation
> > + injects an additional burst of errors (counts accumulate on
> > + the receiver's ber-error-count across invocations).
> > + - If no test pattern is active, the behaviour is
> > + implementation-defined (hardware may silently ignore the
> > + request or return an error).
> > +
> > + Expected Outcome:
> > + After injecting N errors on the TX port, the far-end receiver's
> > + ber-error-count (read via --show-phy-test) should increment by
> > + exactly N (within hardware counter precision). This confirms:
> > + 1. The PRBS checker is locked and actively counting errors.
> > + 2. The data path between TX and RX is intact.
> > + 3. The BERT counters are functioning correctly.
> > +
> > + Example Workflow:
> > + # Configure TX pattern on port A
> > + ethtool --phy-test eth1 lane 0 tx-pattern prbs31
> > + # Configure RX checker on port B, start BERT
> > + ethtool --phy-test eth2 lane 0 rx-pattern prbs31
> > + ethtool --phy-test eth2 lane 0 bert start
> > + # Verify lock
> > + ethtool --show-phy-test eth2 lane 0
> > + # -> ber-lock-status: locked, ber-error-count: 0
> > + # Inject 5 errors from TX side
> > + ethtool --phy-test eth1 lane 0 inject-errors 5
> > + # Confirm errors were detected
> > + ethtool --show-phy-test eth2 lane 0
> > + # -> ber-error-count: 5
> > + -
> > + name: ber-lock-status
> > + type: u8
> > + doc: PRBS lock status (1=locked, 0=not locked)
> > + -
> > + name: ber-error-count
> > + type: u64
> > + doc: BERT bit error count
> > + -
> > + name: ber-total-bits-sent
> > + type: u64
> > + doc: BERT total bits sent
> nit: Hardware engineers I spoke to expect BER to be a floating point number
> which is calculated as errors / total. I dropped "BER" from everything kernel
> related to avoid confusion. I provided an awk script which did the calculation and
> provided a floating point.
> > + -
> > + name: supported-test-patterns
> > + type: u32
> > + doc: Bitmask of supported test patterns
> >
> > + -
> > + name: phy-test-act
> > + doc: |
> > + Configure PHY test parameters. Each attribute is optional and only
> > + specified attributes are applied. TX/RX patterns are set on the
> > + local port. BERT and error injection operate on the receiver port.
> > + Typical workflow:
> > + ethtool --phy-test eth1 lane 0 tx-pattern prbs7 (TX side)
> > + ethtool --phy-test eth2 lane 0 rx-pattern prbs7 (RX side)
> > + ethtool --phy-test eth2 lane 0 bert start (start BERT on RX)
> > + ethtool --phy-test eth1 lane 0 inject-errors 10 (inject 10 errors on TX)
> > + ethtool --show-phy-test eth2 lane 0 (read counters, expect +10)
> > + ethtool --phy-test eth2 lane 0 bert stop (stop BERT)
>
> I think it would be good to follow what existing tools do. Lane is optional when
> not given all lanes are assumed. When specified it can be one or more comma
> separated lanes.
>
> https://networking-docs.nvidia.com/mftswum/43018lts/mlxlink-utility
>
> > +
> > + attribute-set: phy-test
> > +
> > + do:
> > + request:
> > + attributes:
> > + - header
> > + - lane
> > + - tx-pattern
> > + - rx-pattern
> > + - bert-action
> > + - inject-error-count
> > + -
> > + name: phy-test-get
> > + doc: |
> > + Get PHY test configuration status, supported patterns, and BERT
> > + statistics (lock status, error count, total bits).
> > +
> > + attribute-set: phy-test
> > +
> > + do:
> > + request:
> > + attributes:
> > + - header
> > + - lane
> Lane should be a mask. This way userspace can poll stats while testing is running
> which would only require one call.
> > + reply:
> > + attributes:
> > + - header
> > + - lane
> > + - tx-pattern
> > + - rx-pattern
> > + - supported-test-patterns
> > + - ber-lock-status
> > + - ber-error-count
> > + - ber-total-bits-sent
> >
> > mcast-groups:
> > list:
> >
> > - Shubham D
> >
> > From: Srinivasan, Vijay <vijay.srinivasan@intel.com>
> > Sent: 02 July 2026 05:19
> > To: Lee Trager <lee@trager.us>; Andrew Lunn <andrew@lunn.ch>
> > Cc: Das, Shubham <shubham.das@intel.com>; Alexander Duyck
> > <alexander.duyck@gmail.com>; Maxime Chevallier
> > <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
> > mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>;
> > Chintalapalle, Balaji <balaji.chintalapalle@intel.com>; Lindberg,
> > Magnus <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com;
> > Wirandi, Jonas <jonas.wirandi@ericsson.com>
> > Subject: Re: Ethtool : PRBS feature
> >
> > All good points and noted.
> > Will write the specification in general terms with full description of context,
> usage, configuration, expected outcome etc.
> >
> > Vijay
> >
> > ________________________________________
> > From: Lee Trager <mailto:lee@trager.us>
> > Sent: Wednesday, July 1, 2026 4:28 PM
> > To: Andrew Lunn <mailto:andrew@lunn.ch>; Srinivasan, Vijay
> > <mailto:vijay.srinivasan@intel.com>
> > Cc: Das, Shubham <mailto:shubham.das@intel.com>; Alexander Duyck
> > <mailto:alexander.duyck@gmail.com>; Maxime Chevallier
> > <mailto:maxime.chevallier@bootlin.com>; mailto:netdev@vger.kernel.org
> > <mailto:netdev@vger.kernel.org>; mailto:mkubecek@suse.cz
> > <mailto:mkubecek@suse.cz>; D H, Siddaraju
> > <mailto:siddaraju.dh@intel.com>; Chintalapalle, Balaji
> > <mailto:balaji.chintalapalle@intel.com>; Lindberg, Magnus
> > <mailto:magnus.k.lindberg@ericsson.com>;
> > mailto:niklas.damberg@ericsson.com
> > <mailto:niklas.damberg@ericsson.com>; Wirandi, Jonas
> > <mailto:jonas.wirandi@ericsson.com>
> > Subject: Re: Ethtool : PRBS feature
> >
> > On 7/1/26 3:02 PM, Andrew Lunn wrote:
> >
> >> On Wed, Jul 01, 2026 at 09:38:08PM +0000, Srinivasan, Vijay wrote:
> >>> Hi Andrew,
> >>> I think there is a disconnect here.
> >> Which proves my point. The specification is not sufficient if you
> >> have to keep correcting me.
> >>
> >> The kAPI should be understandable by somebody who has a general
> >> networking background. Please write a specification with that
> >> assumption in mind. Don't assume the reader is a test engineer who
> >> has used PRBS for half his life. Assume it is a brand new test
> >> engineer who is hearing PRBS for the first time. That is what most
> >> engineers on the netdev list are. Me included.
> > I think part of the disconnect is that PRBS testing is a signal
> > integrity test, not a network test. In this case the phy happens to be
> > Ethernet but it could just as easily be PCIE or USB. That is why it
> > was heavily suggested to me at netdev 0x19 that this should be done on
> > the generic phy layer, not netdev.
> >
> > Lee
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Eric Dumazet @ 2026-07-15 15:30 UTC (permalink / raw)
To: Leon Hwang
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <2dc3d52b-ce4a-411d-9c30-934318ee98b0@linux.dev>
On Wed, Jul 15, 2026 at 5:26 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> On 2026/7/15 23:15, Eric Dumazet wrote:
> > On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> [...]
>
> >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> >> index 61045a8886e4..4f1027173e95 100644
> >> --- a/net/ipv4/tcp_input.c
> >> +++ b/net/ipv4/tcp_input.c
> >> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
> >> /* When we get a reset we do this. */
> >> void tcp_reset(struct sock *sk, struct sk_buff *skb)
> >> {
> >> + const struct net *net = sock_net(sk);
> >> int err;
> >>
> >> trace_tcp_receive_reset(sk);
> >> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
> >> err = ECONNREFUSED;
> >> break;
> >> case TCP_CLOSE_WAIT:
> >> + /* RFC9293 3.10.7.4. Other States
> >> + * Second, check the RST bit:
> >> + * CLOSE-WAIT STATE
> >> + *
> >> + * If the RST bit is set, then any outstanding RECEIVEs and
> >> + * SEND should receive "reset" responses. All segment queues
> >> + * should be flushed. Users should also receive an unsolicited
> >> + * general "connection reset" signal. Enter the CLOSED state,
> >> + * delete the TCB, and return.
> >> + *
> >> + * If net.ipv4.tcp_purge_receive_queue is enabled,
> >> + * sk_receive_queue will be flushed too.
> >> + */
> >> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
> >> + struct tcp_sock *tp = tcp_sk(sk);
> >> +
> >> + skb_queue_purge(&sk->sk_receive_queue);
> >> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
> >> + WRITE_ONCE(tp->urg_data, 0);
> >> + sk_set_peek_off(sk, -1);
> >> + }
> >> err = EPIPE;
> >> break;
> >> case TCP_CLOSE:
> >> --
> >> 2.55.0
> >>
> >
> > My thoughts are:
> >
> > out_of_order_queue has been forgotten. skbs could be there and still
> > 'block devmem'
> >
> > WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
> > read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
> > So the application will not know a RST was received :/
> >
> > I think that BSD and linux implementations have historically retained
> > acknowledged,
> > buffered receive data upon RST to allow applications to drain data
> > already ACKed prior to the reset.
> >
> > Adding a narrow sysctl specifically for CLOSE_WAIT creates
> > inconsistent behavior across TCP states.
>
>
> Got it. I won't pursue this sysctl approach in the future. Thanks for
> the review.
My intention was not to kill your proposal, only to start a conversation...
^ permalink raw reply
* ipv4: icmp: icmp_route_lookup() relookups pick wrong netdev with policy routing + strict rp_filter
From: Muhammad Ziad @ 2026-07-15 15:30 UTC (permalink / raw)
To: netdev
Cc: David Ahern, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David S. Miller, linux-kernel
Hello,
There appears to be a bug in mainline Linux in ICMP reverse-path
relookup logic inside icmp_route_lookup() (called by __icmp_send())
when strict rp_filter setting is in place.
When Linux forwards a packet between two interfaces and needs to
generate an ICMP error, icmp_route_lookup() performs a "secondary"
reverse-path lookup to find a suitable route back towards the original
source via ip_route_input(). To simulate the reverse path, the kernel
derives the incoming netdev by calling ip_route_output_key() with a
decoy flow that has *only* daddr assigned in it:
struct flowi4 fl4_2 = {};
fl4_2.daddr = fl4_dec.saddr;
rt2 = ip_route_output_key(net, &fl4_2); /* no saddr */
...
ip_route_input(skb_in, fl4_dec.daddr, fl4_dec.saddr,
dscp, rt2->dst.dev);
This can lead to a mismatch between rt2->dst.dev and the netdev the
real reverse packet would use once routing policy rules are in
effect. With strict rp_filter, passing the wrong netdev to
ip_route_input() causes the relookup to fail and a "martian source"
message to be logged, after which icmp_route_lookup() falls back to
the earlier output route lookup (relookup_failed).
In such a scenario, I would expect the relookup to use a canonical
netdev and the kernel to not produce spurious "martian source" log
messages as a result. This suggests the decoy flow would possibly
need to carry saddr too so that ip_route_output_key() is able to
resolve the right netdev.
I tested this on: Ubuntu kernel 6.17.0-35-generic.
Here is a reproducer script that sets up two net namespaces: a
"forwarder" with two routes to the same dst in separate routing tables
picked according to saddr, and a "sender" netns behind it which sends
a ping with ttl=1 via the forwarder forcing it to generate an ICMP
error as a response which leads to the result explained above:
#!/bin/bash
if [ "${forwarder_ns:-}" != "1" ]; then
exec env forwarder_ns=1 unshare -Urn bash "$0" "$@"
fi
SRC=10.0.1.2
DST=198.51.100.5
# Current netns is the "forwarder".
# Create a second namespace for the sender.
unshare -n sleep 120 &
cpid=$!
trap 'kill "$cpid" 2>/dev/null || true' EXIT
in_ns() { nsenter -t "$cpid" -n "$@"; }
# veth r0(router) <-> s0(src)
ip link add s0 type veth peer name r0
ip link set s0 netns "$cpid"
ip link set lo up
ip link set r0 up
ip addr add 10.0.1.1/24 dev r0
ip link add dumA type dummy
ip addr add 203.0.113.1/24 dev dumA
ip link set dumA up
ip link add dumB type dummy
ip addr add 192.0.2.1/24 dev dumB
ip link set dumB up
sysctl -q -w net.ipv4.ip_forward=1
for c in all default r0 dumA dumB; do
sysctl -q -w "net.ipv4.conf.$c.rp_filter=1"
sysctl -q -w "net.ipv4.conf.$c.log_martians=1"
done
# Destination reachable two ways.
# Policy rule diverts traffic FROM src to dumB
ip route add 198.51.100.0/24 dev dumA
ip route add 198.51.100.0/24 dev dumB table 100
ip rule add from "$SRC" lookup 100
# sender namespace setup.
in_ns ip link set lo up
in_ns ip link set s0 up
in_ns ip addr add 10.0.1.2/24 dev s0
in_ns ip route add default via 10.0.1.1
# This will trigger a "martian source" log.
in_ns ping -q -c1 -W2 -t1 "$DST" &>/dev/null
Happy to test patches or provide additional traces, if needed.
Thank you,
Mohamed Ghazy
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 15:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <CANn89iLyeAPNV2VHTM3w0-zpzjZNFy3aJDsVUERYyniLN4ub7A@mail.gmail.com>
On 2026/7/15 23:15, Eric Dumazet wrote:
> On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
[...]
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 61045a8886e4..4f1027173e95 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
>> /* When we get a reset we do this. */
>> void tcp_reset(struct sock *sk, struct sk_buff *skb)
>> {
>> + const struct net *net = sock_net(sk);
>> int err;
>>
>> trace_tcp_receive_reset(sk);
>> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
>> err = ECONNREFUSED;
>> break;
>> case TCP_CLOSE_WAIT:
>> + /* RFC9293 3.10.7.4. Other States
>> + * Second, check the RST bit:
>> + * CLOSE-WAIT STATE
>> + *
>> + * If the RST bit is set, then any outstanding RECEIVEs and
>> + * SEND should receive "reset" responses. All segment queues
>> + * should be flushed. Users should also receive an unsolicited
>> + * general "connection reset" signal. Enter the CLOSED state,
>> + * delete the TCB, and return.
>> + *
>> + * If net.ipv4.tcp_purge_receive_queue is enabled,
>> + * sk_receive_queue will be flushed too.
>> + */
>> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
>> + struct tcp_sock *tp = tcp_sk(sk);
>> +
>> + skb_queue_purge(&sk->sk_receive_queue);
>> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
>> + WRITE_ONCE(tp->urg_data, 0);
>> + sk_set_peek_off(sk, -1);
>> + }
>> err = EPIPE;
>> break;
>> case TCP_CLOSE:
>> --
>> 2.55.0
>>
>
> My thoughts are:
>
> out_of_order_queue has been forgotten. skbs could be there and still
> 'block devmem'
>
> WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
> read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
> So the application will not know a RST was received :/
>
> I think that BSD and linux implementations have historically retained
> acknowledged,
> buffered receive data upon RST to allow applications to drain data
> already ACKed prior to the reset.
>
> Adding a narrow sysctl specifically for CLOSE_WAIT creates
> inconsistent behavior across TCP states.
Got it. I won't pursue this sysctl approach in the future. Thanks for
the review.
Leon
^ permalink raw reply
* Re: [PATCH net] mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n
From: David Ahern @ 2026-07-15 15:24 UTC (permalink / raw)
To: Xiang Mei, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, bestswngs
In-Reply-To: <20260712220903.3131568-1-xmei5@asu.edu>
On 7/12/26 4:09 PM, Xiang Mei wrote:
> On CONFIG_INET=n, mpls_valid_fib_dump_req()'s local strict-check loop
> enters the RTA_OIF arm on the index alone and calls nla_get_u32(tb[i]).
> Since nlmsg_parse_deprecated_strict() leaves tb[i] NULL for any omitted
> attribute, a dump without RTA_OIF dereferences NULL and oopses.
>
> Skip unset attributes before dispatching on the index, mirroring
> ip_valid_fib_dump_req().
>
> Oops: general protection fault, probably for non-canonical address
> 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189)
> Call Trace:
> mpls_dump_routes (net/mpls/af_mpls.c:2236)
> netlink_dump (net/netlink/af_netlink.c:2331)
> __netlink_dump_start (net/netlink/af_netlink.c:2446)
> rtnetlink_rcv_msg (net/core/rtnetlink.c:7041)
> netlink_rcv_skb (net/netlink/af_netlink.c:2556)
> netlink_unicast (net/netlink/af_netlink.c:1345)
> netlink_sendmsg (net/netlink/af_netlink.c:1900)
> __sock_sendmsg (net/socket.c:790)
> ____sys_sendmsg (net/socket.c:2684)
> ___sys_sendmsg (net/socket.c:2738)
> __sys_sendmsg (net/socket.c:2770)
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> Kernel panic - not syncing: Fatal exception
>
> Fixes: 196cfebf8972 ("net/mpls: Handle kernel side filtering of route dumps")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> net/mpls/af_mpls.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
> index ca504d9626cf..1ad07df89d5b 100644
> --- a/net/mpls/af_mpls.c
> +++ b/net/mpls/af_mpls.c
> @@ -2185,13 +2185,16 @@ static int mpls_valid_fib_dump_req(struct net *net, const struct nlmsghdr *nlh,
> for (i = 0; i <= RTA_MAX; ++i) {
> int ifindex;
>
> + if (!tb[i])
> + continue;
> +
> if (i == RTA_OIF) {
> ifindex = nla_get_u32(tb[i]);
> filter->dev = dev_get_by_index_rcu(net, ifindex);
> if (!filter->dev)
> return -ENODEV;
> filter->filter_set = 1;
> - } else if (tb[i]) {
> + } else {
> NL_SET_ERR_MSG_MOD(extack, "Unsupported attribute in dump request");
> return -EINVAL;
> }
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
From: Ayoub Kaanich @ 2026-07-15 15:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Russell King, netdev@vger.kernel.org, Dr. Lars Völker
In-Reply-To: <259dbf46-5d93-4fc4-bf67-a7356a70ed26@lunn.ch>
Hi,
I suppose a bit of context is required here.
We develop SFP modules on top of automotive PHYs, the SFP module takes care of all what's needed for the PHY to function correctly (it has a mini embedded processor).
The NIC firmware does not need to know the details of the PHY and how it operates, we take care of that in the SFP.
The SFP modules we develop, are not meant to go in the car, they are meant to go into PC test-benches that communicate and validated the embedded devices.
This is the reason we are interested in the Intel cards in particular (and not embedded systems)
The issue is that automotive PHYs have extra functions, not available in standard SFP 1000BASET/Fiber modules.
Namely:
* 1000BASET1 PHY needs to be assigned a role (either master or slave), a standard NIC have no concept of this.
* The PHY have multiple operational speeds, for example 100BASET1 and 1000BASET1
Example of how it looks like, can be found in table 9: https://flex-product.com/assets/produkte/fl3x_sfp_1000base-t1/instruction_for_use_fl3x_sfp_1000base-t1.pdf
In order to set those configurations, we need to send an I2C command to the SFP module; to inform it in which mode the user wants it to work (the entire config is just few bytes of data)
This pattern is common in automotive SFPs, where SFP behaves as close as possible to a Fiber/RJ45 SFP so "it just works".
We made workarounds using DIP-Switches in the SFP module body so far, but that's won't scale for the next generation of automotive features:
* Configuring the PHY Macsec certificates
* Automotive TC10 (sleep/wakeup commands)
To make those features work, the only interface available between the PC and SFP, is the I2C bus controlled by the NIC driver.
Since this bus is already exposed for other operations (like read EEPROM and flash EEPROM), it would be nice if the kernel was able to expose the I2C bus to third party drivers, so that SFP manufactures can develop SFP drivers.
Best Regards.
Ayoub Kaanich
Principal Software Engineer
Engineering Department
________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 15, 2026 04:49 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Dr. Lars Völker <lars.voelker@technica-engineering.de>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> That does not sound reasonable, given that the only interface needed
> to the SFP/PHY is the I2C bus which the kernel could access directly
> (to read EEPROM for example)
The MAC driver needs to know what the PHY has negotiated. Should it be
sending packets at 10Mbps half duplex, or 1G full duplex. Has the PHY
negotiated pause? sync or async pause? The configuration API via
netlink is via the top of the MAC driver. So the MAC driver needs to
ask the PHY to advertise what the user wants it to advertise. Enabling
loopback again comes via the MAC driver. There are all sorts of APIs
between the MAC and the PHY. The firmware needs to implement all
these. You cannot drive the PHY independent of the MAC.
And when you consider this is an SFP, ideally you need access to the
GPIO lines. You want to know when a module is inserted. For a copper
SFP, LOS has less meaning, so you can probably do without it. You
could maybe use TX_ENABLE to save power when the MAC is admin down.
I'm actually surprised you are interested in ice. You seem to be
targeting automotive. I would of expected a more embedded SoC,
probably ARM based, and those do tend to have Linux driving the
hardware.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next] ip: display DPLL pin information in link details
From: patchwork-bot+netdevbpf @ 2026-07-15 15:20 UTC (permalink / raw)
To: Ivan Vecera; +Cc: netdev, jiri, poros, dsahern, stephen
In-Reply-To: <20260713092119.1536385-1-ivecera@redhat.com>
Hello:
This patch was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Mon, 13 Jul 2026 11:21:19 +0200 you wrote:
> Parse the IFLA_DPLL_PIN nested attribute and display the associated
> DPLL pin ID in 'ip link show' detail output. This allows users to see
> which DPLL recovered clock pin is associated with a network interface
> without having to cross-reference with 'dpll pin show'.
>
> Example output:
> $ ip -d link show eth0
> ... parentbus pci parentdev 0000:51:00.0 dpll-pin 4
>
> [...]
Here is the summary with links:
- [iproute2-next] ip: display DPLL pin information in link details
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=20e860c632e3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Eric Dumazet @ 2026-07-15 15:15 UTC (permalink / raw)
To: Leon Hwang
Cc: netdev, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-2-leon.hwang@linux.dev>
On Wed, Jul 15, 2026 at 4:54 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
> address an unreleased SKBs issue related to TCP sockets.
>
> Issue:
> When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
> current implementation does not clear the socket's receive queue. This
> causes SKBs in the queue to remain allocated until the socket is
> explicitly closed by the application. As a consequence:
>
> 1. The page pool pages held by these SKBs are not released.
> 2. The associated page pool cannot be freed.
>
> RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
> CLOSE_WAIT state, "all segment queues should be flushed." However, the
> current implementation does not flush the receive queue.
>
> Solution:
> Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
> when enabled, causes the kernel to purge the receive queue when a RST
> packet is received in CLOSE_WAIT state. This allows immediate release
> of SKBs and their associated memory resources.
>
> The feature is disabled by default to maintain backward compatibility
> with existing behavior.
>
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> ---
> Documentation/networking/ip-sysctl.rst | 18 +++++++++++++++
> .../net_cachelines/netns_ipv4_sysctl.rst | 1 +
> include/net/netns/ipv4.h | 1 +
> net/ipv4/sysctl_net_ipv4.c | 9 ++++++++
> net/ipv4/tcp_input.c | 22 +++++++++++++++++++
> 5 files changed, 51 insertions(+)
>
> diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
> index 208f46967ee5..abbee0326f15 100644
> --- a/Documentation/networking/ip-sysctl.rst
> +++ b/Documentation/networking/ip-sysctl.rst
> @@ -1448,6 +1448,24 @@ tcp_rto_max_ms - INTEGER
>
> Default: 120,000
>
> +tcp_purge_receive_queue - BOOLEAN
> + When a socket in the TCP_CLOSE_WAIT state receives a RST packet, the
> + default behavior is to not clear its receive queue. As a result,
> + any SKBs in the queue are not freed until the socket is closed.
> + Consequently, the pages held by these SKBs are not released, which
> + can also prevent the associated page pool from being freed.
> +
> + If enabled, the receive queue is purged upon receiving the RST,
> + allowing the SKBs and their associated memory to be released
> + promptly.
> +
> + Possible values:
> +
> + - 0 (disabled)
> + - 1 (enabled)
> +
> + Default: 0 (disabled)
> +
> UDP variables
> =============
>
> diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> index 3dc03bff739e..2945de40ad78 100644
> --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
> @@ -126,6 +126,7 @@ unsigned_long sysctl_tcp_comp_sack_delay_ns
> unsigned_long sysctl_tcp_comp_sack_slack_ns __tcp_ack_snd_check
> int sysctl_max_syn_backlog
> int sysctl_tcp_fastopen
> +u8 sysctl_tcp_purge_receive_queue
> struct_tcp_congestion_ops tcp_congestion_control init_cc
> struct_tcp_fastopen_context tcp_fastopen_ctx
> unsigned_int sysctl_tcp_fastopen_blackhole_timeout
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index cb7f8bf15671..ab9b92807d9f 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -222,6 +222,7 @@ struct netns_ipv4 {
> u8 sysctl_tcp_nometrics_save;
> u8 sysctl_tcp_no_ssthresh_metrics_save;
> u8 sysctl_tcp_workaround_signed_windows;
> + u8 sysctl_tcp_purge_receive_queue;
> int sysctl_tcp_challenge_ack_limit;
> u8 sysctl_tcp_min_tso_segs;
> u8 sysctl_tcp_reflect_tos;
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index ca1180dba1de..82412fd98e0e 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -1652,6 +1652,15 @@ static struct ctl_table ipv4_net_table[] = {
> .extra1 = SYSCTL_ONE_THOUSAND,
> .extra2 = &tcp_rto_max_max,
> },
> + {
> + .procname = "tcp_purge_receive_queue",
> + .data = &init_net.ipv4.sysctl_tcp_purge_receive_queue,
> + .maxlen = sizeof(u8),
> + .mode = 0644,
> + .proc_handler = proc_dou8vec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_ONE,
> + },
> };
>
> static __net_init int ipv4_sysctl_init_net(struct net *net)
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 61045a8886e4..4f1027173e95 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
> /* When we get a reset we do this. */
> void tcp_reset(struct sock *sk, struct sk_buff *skb)
> {
> + const struct net *net = sock_net(sk);
> int err;
>
> trace_tcp_receive_reset(sk);
> @@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
> err = ECONNREFUSED;
> break;
> case TCP_CLOSE_WAIT:
> + /* RFC9293 3.10.7.4. Other States
> + * Second, check the RST bit:
> + * CLOSE-WAIT STATE
> + *
> + * If the RST bit is set, then any outstanding RECEIVEs and
> + * SEND should receive "reset" responses. All segment queues
> + * should be flushed. Users should also receive an unsolicited
> + * general "connection reset" signal. Enter the CLOSED state,
> + * delete the TCB, and return.
> + *
> + * If net.ipv4.tcp_purge_receive_queue is enabled,
> + * sk_receive_queue will be flushed too.
> + */
> + if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + skb_queue_purge(&sk->sk_receive_queue);
> + WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
> + WRITE_ONCE(tp->urg_data, 0);
> + sk_set_peek_off(sk, -1);
> + }
> err = EPIPE;
> break;
> case TCP_CLOSE:
> --
> 2.55.0
>
My thoughts are:
out_of_order_queue has been forgotten. skbs could be there and still
'block devmem'
WRITE_ONCE(tp->copied_seq, tp->rcv_nxt) is certainly wrong, because
read() will return 0, instead of -1 (errno = EPIPE or ECONNRESET)
So the application will not know a RST was received :/
I think that BSD and linux implementations have historically retained
acknowledged,
buffered receive data upon RST to allow applications to drain data
already ACKed prior to the reset.
Adding a narrow sysctl specifically for CLOSE_WAIT creates
inconsistent behavior across TCP states.
Thanks.
^ permalink raw reply
* Re: [PATCH iproute2-next v6 2/2] rdma: display resource limits in curr/max format
From: David Ahern @ 2026-07-15 15:11 UTC (permalink / raw)
To: Tao Cui, leonro; +Cc: linux-rdma, netdev, Tao Cui
In-Reply-To: <20260713131238.955962-3-cui.tao@linux.dev>
On 7/13/26 7:12 AM, Tao Cui wrote:
> @@ -55,7 +55,26 @@ static int res_print_summary(struct nlattr **tb)
>
> name = mnl_attr_get_str(nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_NAME]);
> curr = mnl_attr_get_u64(nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR]);
> - res_print_u64(name, curr, nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR]);
> + if (nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]) {
> + uint64_t max;
> + char max_name[64];
> +
> + max = mnl_attr_get_u64(
> + nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]);
> + snprintf(max_name, sizeof(max_name), "%s-max", name);
> + print_u64(PRINT_JSON, name, NULL, curr);
> + print_u64(PRINT_JSON, max_name, NULL, max);
> + if (!is_json_context()) {
> + char buf[64];
> +
> + snprintf(buf, sizeof(buf), "%s %" PRIu64 "/%" PRIu64 " ",
> + name, curr, max);
> + pr_out("%s", buf);
claude review:
The feature and backward-compat approach look correct. A couple of
nits below.
> + if (nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]) {
> + uint64_t max;
> + char max_name[64];
> +
> + max = mnl_attr_get_u64(
> +
nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]);
> + snprintf(max_name, sizeof(max_name), "%s-max",
name);
> + print_u64(PRINT_JSON, name, NULL, curr);
> + print_u64(PRINT_JSON, max_name, NULL, max);
> + if (!is_json_context()) {
> + char buf[64];
> +
> + snprintf(buf, sizeof(buf), "%s %" PRIu64
"/%" PRIu64 " ",
> + name, curr, max);
> + pr_out("%s", buf);
> + }
The intermediate buf[] is unnecessary; pr_out() accepts a format string
directly. The snprintf -> pr_out("%s") dance also silently truncates if
`name` is unusually long, since two u64 values and a slash can consume
up to 42 bytes, leaving only 22 bytes in a 64-byte buffer for the name.
While current RDMA resource names are short, the kernel is the source of
`name`, so it is better not to rely on that.
if (!is_json_context())
pr_out("%s %" PRIu64 "/%" PRIu64 " ", name, curr, max);
Similarly, the max_name[] buffer for the JSON key has the same size
concern; a 64-byte buffer with snprintf("%s-max", name) silently
truncates for any name longer than 59 characters. Again unlikely in
practice, but worth noting if this pattern is copied elsewhere.
No functional issue with the netlink policy addition in utils.c or the
backward-compatible fallback to res_print_u64().
###
in addition, please provide json output in the commit message.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: add DAPU Telecom DAP8210R(I) Gigabit Ethernet PHY driver
From: Artem Shimko @ 2026-07-15 15:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Heiner Kallweit, Russell King, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, devicetree
In-Reply-To: <5c95a7cd-d5d7-4998-8641-7dee1e34078b@lunn.ch>
Hi Andrew,
On Wed, Jul 15, 2026 at 12:25 AM Andrew Lunn <andrew@lunn.ch> wrote:
> Please drop all this. Many PHYs have this sort of facility. We want
> one generic API, probably via ethtool, which all PHYs can follow, not
> N different incompatible APIs.
Got it. I have dropped the entire debugfs interface in v2.
> This can be simplified.
>
> First off, there probably too many phydev_dbg() messages, specially
> for normal case things, using defaults, etc.
Okay.
> of_property_read_u32_array() is documented as not touching the results
> value, if it does not find the property. So you can do:
>
> u32 ps = DAP8211R_DEFAULT_DELAY_PS;
> of_property_read_u32(np, prop_name, &ps);
>
> return dap8211r_delay_ps_to_sel(phydev, ps);
Agree. I will simplify the function as suggested.
> This is one of the less well defined areas. PHY_INTERFACE_MODE_RGMII
> would mean either the PCB is adding the delay, or the MAC. There is no
> reason however why the PHY cannot perform fine tuning, adding a small
> delay, say 150ps. So you should respect the rx-internal-delay-ps and
> tx-internal-delay-ps delays here.
Understood.
Thank you for your review!
--
Best regards,
Artem
^ permalink raw reply
* Re: [PATCH iproute2-next] ipmaddr: use RTM_GETMULTICAST to list multicast addresses
From: David Ahern @ 2026-07-15 15:02 UTC (permalink / raw)
To: Yuyang Huang; +Cc: netdev
In-Reply-To: <20260711030733.48567-1-sigefriedhyy@gmail.com>
On 7/10/26 9:07 PM, Yuyang Huang wrote:
> +static int accept_maddr(struct nlmsghdr *n, void *arg)
> +{
> + struct maddr_dump_ctx *ctx = arg;
> + struct ifaddrmsg *ifm = NLMSG_DATA(n);
> + int len = n->nlmsg_len - NLMSG_LENGTH(sizeof(*ifm));
> + struct rtattr *tb[IFA_MAX + 1];
> + struct ma_info *ma;
> +
> + if (n->nlmsg_type != RTM_GETMULTICAST &&
> + n->nlmsg_type != RTM_NEWMULTICAST)
> + return 0;
From claude (and I agree with the finding)
> +static int accept_maddr(struct nlmsghdr *n, void *arg)
> +{
> ...
> + if (n->nlmsg_type != RTM_GETMULTICAST &&
> + n->nlmsg_type != RTM_NEWMULTICAST)
> + return 0;
The kernel replies to a RTM_GETMULTICAST dump request with
RTM_NEWMULTICAST messages — it never sends RTM_GETMULTICAST in a
response. Including RTM_GETMULTICAST in the guard is dead code and is
confusing; it inverts the usual convention used everywhere else in
iproute2 (e.g. ipaddress.c always checks RTM_NEW* / RTM_DEL*, never
RTM_GET*).
Should be:
if (n->nlmsg_type != RTM_NEWMULTICAST)
return 0;
^ permalink raw reply
* [RFC PATCH net-next v2 2/2] selftests/net: packetdrill: Add two tcp_purge_receive_queue tests
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-1-leon.hwang@linux.dev>
Run the tests:
# ./ksft_runner.sh ./tcp_purge_receive_queue_disabled.pkt
TAP version 13
1..3
ok 1 ipv4
ok 2 ipv6
ok 3 ipv4-mapped-ipv6
# Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
# ./ksft_runner.sh ./tcp_purge_receive_queue_enabled.pkt
TAP version 13
1..3
ok 1 ipv4
ok 2 ipv6
ok 3 ipv4-mapped-ipv6
# Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
Assisted-by: Codex:gpt-5.5
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
.../tcp_purge_receive_queue_disabled.pkt | 40 ++++++++++++++++++
.../tcp_purge_receive_queue_enabled.pkt | 42 +++++++++++++++++++
2 files changed, 82 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
diff --git a/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
new file mode 100644
index 000000000000..a46f93eaab1f
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+// Test: with tcp_purge_receive_queue disabled (default), receiving RST
+// in CLOSE_WAIT state does NOT purge the receive queue.
+// The unread data in the receive queue is still accessible to the
+// application.
+
+`./defaults.sh
+./set_sysctls.py /proc/sys/net/ipv4/tcp_purge_receive_queue=0`
+
+// Establish a connection (server side).
+ 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+ +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+ +0 bind(3, ..., ...) = 0
+ +0 listen(3, 1) = 0
+
+ +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+ +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
+ +.1 < . 1:1(0) ack 1 win 257
+
+ +0 accept(3, ..., ...) = 4
+
+// Remote sends 4KiB data so that receive queue is populated.
+ +.1 < . 1:4097(4096) ack 1 win 257
+ +0 > . 1:1(0) ack 4097
+
+// Remote sends FIN -> socket enters CLOSE_WAIT.
+ +.1 < F. 4097:4097(0) ack 1 win 257
+ +0~+.04 > . 1:1(0) ack 4098
+
+// Inject RST directly while in CLOSE_WAIT.
+ +.1 < R. 4098:4098(0) ack 1 win 257
+
+// With tcp_purge_receive_queue=0, the receive queue is NOT purged.
+// Data is still in the receive queue; read returns data.
+ +0 read(4, ..., 1) = 1
+
+ +0 close(4) = 0
+
+// Restore sysctls.
+`/tmp/sysctl_restore_${PPID}.sh`
diff --git a/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
new file mode 100644
index 000000000000..b1d1dff28f50
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+// Test: with tcp_purge_receive_queue enabled, receiving RST in
+// CLOSE_WAIT state purges the receive queue immediately.
+// The unread data is discarded, so read() observes EOF.
+//
+// RFC 9293 Section 3.10.7.4:
+// "all segment queues should be flushed"
+
+`./defaults.sh
+./set_sysctls.py /proc/sys/net/ipv4/tcp_purge_receive_queue=1`
+
+// Establish a connection (server side).
+ 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+ +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+ +0 bind(3, ..., ...) = 0
+ +0 listen(3, 1) = 0
+
+ +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+ +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
+ +.1 < . 1:1(0) ack 1 win 257
+
+ +0 accept(3, ..., ...) = 4
+
+// Remote sends 4KiB data so that receive queue is populated.
+ +.1 < . 1:4097(4096) ack 1 win 257
+ +0 > . 1:1(0) ack 4097
+
+// Remote sends FIN -> socket enters CLOSE_WAIT.
+ +.1 < F. 4097:4097(0) ack 1 win 257
+ +0~+.04 > . 1:1(0) ack 4098
+
+// Inject RST directly while in CLOSE_WAIT.
+ +.1 < R. 4098:4098(0) ack 1 win 257
+
+// With tcp_purge_receive_queue=1, the receive queue IS purged.
+// Queue was purged by RST handler; read returns EOF.
+ +0 read(4, ..., 1) = 0
+
+ +0 close(4) = 0
+
+// Restore sysctls.
+`/tmp/sysctl_restore_${PPID}.sh`
--
2.55.0
^ permalink raw reply related
* [RFC PATCH net-next v2 0/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
address an unreleased SKBs issue related to TCP sockets.
Issue:
When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
current implementation does not clear the socket's receive queue. This
causes SKBs in the queue to remain allocated until the socket is
explicitly closed by the application. As a consequence:
1. The page pool pages held by these SKBs are not released.
2. The associated page pool cannot be freed.
RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
CLOSE_WAIT state, "all segment queues should be flushed." However, the
current implementation does not flush the receive queue.
Solution:
Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
when enabled, causes the kernel to purge the receive queue when a RST
packet is received in CLOSE_WAIT state. This allows immediate release
of SKBs and their associated memory resources.
The feature is disabled by default to maintain backward compatibility
with existing behavior.
Note: the user-space issue, the root cause of the unreleased SKBs, has
been fixed by https://github.com/IBM/sarama/pull/3384.
Changes:
v1 -> v2:
* Update 'tp->copied_seq', 'tp->urg_data', and 'sk->sk_peek_off' like
'tcp_disconnect()'.
* Drop "memory leak" words in commit msg. (per Eric)
* Add two packetdrill tests. (per Eric)
* v1: https://lore.kernel.org/netdev/20260225074633.149590-1-leon.huangfu@shopee.com/
Leon Hwang (2):
tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
selftests/net: packetdrill: Add two tcp_purge_receive_queue tests
Documentation/networking/ip-sysctl.rst | 18 ++++++++
.../net_cachelines/netns_ipv4_sysctl.rst | 1 +
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 ++++
net/ipv4/tcp_input.c | 22 ++++++++++
.../tcp_purge_receive_queue_disabled.pkt | 40 ++++++++++++++++++
.../tcp_purge_receive_queue_enabled.pkt | 42 +++++++++++++++++++
7 files changed, 133 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_disabled.pkt
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_purge_receive_queue_enabled.pkt
--
2.55.0
^ permalink raw reply
* [RFC PATCH net-next v2 1/2] tcp: Add net.ipv4.tcp_purge_receive_queue sysctl
From: Leon Hwang @ 2026-07-15 14:53 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Neal Cardwell,
Kuniyuki Iwashima, Ido Schimmel, Ilpo Järvinen, Leon Hwang,
Chia-Yu Chang, Yung Chih Su, Wyatt Feng, Jason Xing, Lance Yang,
Jiayuan Chen, linux-doc, linux-kernel, linux-kselftest
In-Reply-To: <20260715145328.54597-1-leon.hwang@linux.dev>
Introduce a new sysctl knob, net.ipv4.tcp_purge_receive_queue, to
address an unreleased SKBs issue related to TCP sockets.
Issue:
When a TCP socket in the CLOSE_WAIT state receives a RST packet, the
current implementation does not clear the socket's receive queue. This
causes SKBs in the queue to remain allocated until the socket is
explicitly closed by the application. As a consequence:
1. The page pool pages held by these SKBs are not released.
2. The associated page pool cannot be freed.
RFC 9293 Section 3.10.7.4 specifies that when a RST is received in
CLOSE_WAIT state, "all segment queues should be flushed." However, the
current implementation does not flush the receive queue.
Solution:
Add a per-namespace sysctl (net.ipv4.tcp_purge_receive_queue) that,
when enabled, causes the kernel to purge the receive queue when a RST
packet is received in CLOSE_WAIT state. This allows immediate release
of SKBs and their associated memory resources.
The feature is disabled by default to maintain backward compatibility
with existing behavior.
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
Documentation/networking/ip-sysctl.rst | 18 +++++++++++++++
.../net_cachelines/netns_ipv4_sysctl.rst | 1 +
include/net/netns/ipv4.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 9 ++++++++
net/ipv4/tcp_input.c | 22 +++++++++++++++++++
5 files changed, 51 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 208f46967ee5..abbee0326f15 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1448,6 +1448,24 @@ tcp_rto_max_ms - INTEGER
Default: 120,000
+tcp_purge_receive_queue - BOOLEAN
+ When a socket in the TCP_CLOSE_WAIT state receives a RST packet, the
+ default behavior is to not clear its receive queue. As a result,
+ any SKBs in the queue are not freed until the socket is closed.
+ Consequently, the pages held by these SKBs are not released, which
+ can also prevent the associated page pool from being freed.
+
+ If enabled, the receive queue is purged upon receiving the RST,
+ allowing the SKBs and their associated memory to be released
+ promptly.
+
+ Possible values:
+
+ - 0 (disabled)
+ - 1 (enabled)
+
+ Default: 0 (disabled)
+
UDP variables
=============
diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
index 3dc03bff739e..2945de40ad78 100644
--- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
+++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
@@ -126,6 +126,7 @@ unsigned_long sysctl_tcp_comp_sack_delay_ns
unsigned_long sysctl_tcp_comp_sack_slack_ns __tcp_ack_snd_check
int sysctl_max_syn_backlog
int sysctl_tcp_fastopen
+u8 sysctl_tcp_purge_receive_queue
struct_tcp_congestion_ops tcp_congestion_control init_cc
struct_tcp_fastopen_context tcp_fastopen_ctx
unsigned_int sysctl_tcp_fastopen_blackhole_timeout
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index cb7f8bf15671..ab9b92807d9f 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -222,6 +222,7 @@ struct netns_ipv4 {
u8 sysctl_tcp_nometrics_save;
u8 sysctl_tcp_no_ssthresh_metrics_save;
u8 sysctl_tcp_workaround_signed_windows;
+ u8 sysctl_tcp_purge_receive_queue;
int sysctl_tcp_challenge_ack_limit;
u8 sysctl_tcp_min_tso_segs;
u8 sysctl_tcp_reflect_tos;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index ca1180dba1de..82412fd98e0e 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -1652,6 +1652,15 @@ static struct ctl_table ipv4_net_table[] = {
.extra1 = SYSCTL_ONE_THOUSAND,
.extra2 = &tcp_rto_max_max,
},
+ {
+ .procname = "tcp_purge_receive_queue",
+ .data = &init_net.ipv4.sysctl_tcp_purge_receive_queue,
+ .maxlen = sizeof(u8),
+ .mode = 0644,
+ .proc_handler = proc_dou8vec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ },
};
static __net_init int ipv4_sysctl_init_net(struct net *net)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 61045a8886e4..4f1027173e95 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4853,6 +4853,7 @@ void tcp_done_with_error(struct sock *sk, int err)
/* When we get a reset we do this. */
void tcp_reset(struct sock *sk, struct sk_buff *skb)
{
+ const struct net *net = sock_net(sk);
int err;
trace_tcp_receive_reset(sk);
@@ -4869,6 +4870,27 @@ void tcp_reset(struct sock *sk, struct sk_buff *skb)
err = ECONNREFUSED;
break;
case TCP_CLOSE_WAIT:
+ /* RFC9293 3.10.7.4. Other States
+ * Second, check the RST bit:
+ * CLOSE-WAIT STATE
+ *
+ * If the RST bit is set, then any outstanding RECEIVEs and
+ * SEND should receive "reset" responses. All segment queues
+ * should be flushed. Users should also receive an unsolicited
+ * general "connection reset" signal. Enter the CLOSED state,
+ * delete the TCB, and return.
+ *
+ * If net.ipv4.tcp_purge_receive_queue is enabled,
+ * sk_receive_queue will be flushed too.
+ */
+ if (unlikely(READ_ONCE(net->ipv4.sysctl_tcp_purge_receive_queue))) {
+ struct tcp_sock *tp = tcp_sk(sk);
+
+ skb_queue_purge(&sk->sk_receive_queue);
+ WRITE_ONCE(tp->copied_seq, tp->rcv_nxt);
+ WRITE_ONCE(tp->urg_data, 0);
+ sk_set_peek_off(sk, -1);
+ }
err = EPIPE;
break;
case TCP_CLOSE:
--
2.55.0
^ permalink raw reply related
* Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
From: Andrew Lunn @ 2026-07-15 14:49 UTC (permalink / raw)
To: Ayoub Kaanich; +Cc: Russell King, netdev@vger.kernel.org, Dr. Lars Völker
In-Reply-To: <AS4PR08MB80219505FEC2334B503C55DCB7F82@AS4PR08MB8021.eurprd08.prod.outlook.com>
> That does not sound reasonable, given that the only interface needed
> to the SFP/PHY is the I2C bus which the kernel could access directly
> (to read EEPROM for example)
The MAC driver needs to know what the PHY has negotiated. Should it be
sending packets at 10Mbps half duplex, or 1G full duplex. Has the PHY
negotiated pause? sync or async pause? The configuration API via
netlink is via the top of the MAC driver. So the MAC driver needs to
ask the PHY to advertise what the user wants it to advertise. Enabling
loopback again comes via the MAC driver. There are all sorts of APIs
between the MAC and the PHY. The firmware needs to implement all
these. You cannot drive the PHY independent of the MAC.
And when you consider this is an SFP, ideally you need access to the
GPIO lines. You want to know when a module is inserted. For a copper
SFP, LOS has less meaning, so you can probably do without it. You
could maybe use TX_ENABLE to save power when the MAC is admin down.
I'm actually surprised you are interested in ice. You seem to be
targeting automotive. I would of expected a more embedded SoC,
probably ARM based, and those do tend to have Linux driving the
hardware.
Andrew
^ permalink raw reply
* [PATCH nf] netfilter: conntrack: prevent helper extension relocation
From: Jaeyeong Lee @ 2026-07-15 14:48 UTC (permalink / raw)
To: netfilter-devel; +Cc: pablo, fw, phil, sveyret, coreteam, netdev
nf_ct_ext_add() may relocate an unconfirmed conntrack's extension blob
when the current allocation is too small. struct nf_conn_help embeds the
hlist head for the master's expectations. The first expectation's
lnode.pprev therefore points into that extension blob.
An nftables CT expectation object can link an expectation before a later
NAT expression adds extensions to the same unconfirmed conntrack. If an
addition relocates the blob, the copied hlist head still points to the
expectation, but the expectation's pprev continues to point into the
freed old blob. Removing the expectation later executes hlist_del_rcu()
and writes through this stale pointer.
Reserve enough storage for every extension whenever the helper extension
is added. Account for the alignment padding that may be required between
extensions so the reservation is independent of their addition order.
No expectation can be linked before its master has a helper extension,
so subsequent additions fit in the existing allocation and cannot
invalidate expectation list pointers. Conntracks without helpers are
unaffected.
Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support")
Cc: stable@vger.kernel.org
Signed-off-by: Jaeyeong Lee <iostreampy@proton.me>
---
net/netfilter/nf_conntrack_extend.c | 31 +++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index 0da105e1ded..e5e04e0ec40 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -54,35 +54,38 @@ static const u8 nf_ct_ext_type_len[NF_CT_EXT_NUM] = {
#endif
};
+#define NF_CT_EXT_TYPE_SIZE(type) \
+ ALIGN(sizeof(type), __alignof__(struct nf_ct_ext))
+
static __always_inline unsigned int total_extension_size(void)
{
/* remember to add new extensions below */
BUILD_BUG_ON(NF_CT_EXT_NUM > 10);
return sizeof(struct nf_ct_ext) +
- sizeof(struct nf_conn_help)
+ NF_CT_EXT_TYPE_SIZE(struct nf_conn_help)
#if IS_ENABLED(CONFIG_NF_NAT)
- + sizeof(struct nf_conn_nat)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_nat)
#endif
- + sizeof(struct nf_conn_seqadj)
- + sizeof(struct nf_conn_acct)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_seqadj)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_acct)
#ifdef CONFIG_NF_CONNTRACK_EVENTS
- + sizeof(struct nf_conntrack_ecache)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conntrack_ecache)
#endif
#ifdef CONFIG_NF_CONNTRACK_TIMESTAMP
- + sizeof(struct nf_conn_tstamp)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_tstamp)
#endif
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
- + sizeof(struct nf_conn_timeout)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_timeout)
#endif
#ifdef CONFIG_NF_CONNTRACK_LABELS
- + sizeof(struct nf_conn_labels)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_labels)
#endif
#if IS_ENABLED(CONFIG_NETFILTER_SYNPROXY)
- + sizeof(struct nf_conn_synproxy)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_synproxy)
#endif
#if IS_ENABLED(CONFIG_NET_ACT_CT)
- + sizeof(struct nf_conn_act_ct_ext)
+ + NF_CT_EXT_TYPE_SIZE(struct nf_conn_act_ct_ext)
#endif
;
}
@@ -112,6 +115,14 @@ void *nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
newlen = newoff + nf_ct_ext_type_len[id];
alloc = max(newlen, NF_CT_EXT_PREALLOC);
+ /*
+ * nf_conn_help contains the expectation list head. Once an
+ * expectation is linked, its lnode.pprev points into this allocation,
+ * so later extension additions must not be allowed to relocate it.
+ */
+ if (id == NF_CT_EXT_HELPER)
+ alloc = max(alloc, total_extension_size());
+
new = krealloc(ct->ext, alloc, gfp);
if (!new)
return NULL;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next 13/15] net/mlx5e: psp: Make PSP steering config dynamic
From: Simon Horman @ 2026-07-15 14:42 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Tariq Toukan, Rahul Rameshbabu, Boris Pismenny,
willemdebruijn.kernel@gmail.com, andrew+netdev@lunn.ch,
daniel.zahka@gmail.com, Jianbo Liu, davem@davemloft.net,
leon@kernel.org, linux-kernel@vger.kernel.org, pabeni@redhat.com,
edumazet@google.com, linux-rdma@vger.kernel.org, Raed Salem,
Chris Mi, Dragos Tatulea, sdf.kernel@gmail.com, kuba@kernel.org,
Mark Bloch, sdf@fomichev.me, Saeed Mahameed,
netdev@vger.kernel.org, aleksandr.loktionov@intel.com,
Gal Pressman, Lama Kayal, jacob.e.keller@intel.com
In-Reply-To: <a7f3a36f058d7ee1298c8f3f5d5c65c1aa7863b6.camel@nvidia.com>
On Tue, Jul 14, 2026 at 08:05:39PM +0000, Cosmin Ratiu wrote:
> On Tue, 2026-07-14 at 18:30 +0100, 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
> > ---
> > --- Patch [13]: [PATCH net-next 13/15] net/mlx5e: psp: Make PSP
> > steering config dynamic ---
> > commit 133d9a32cbf9c1b939ae4ca8473c41624c313951
> > Author: Cosmin Ratiu <cratiu@nvidia.com>
> >
> > net/mlx5e: psp: Make PSP steering config dynamic
> >
> > This commit changes PSP steering tables to only be created when PSP
> > configuration is enabled on a device, instead of at device
> > initialization
> > time. This avoids imposing steering overhead on all UDP packets when
> > PSP
> > is not being used.
> >
> > > diff --git
> > > a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
> > > b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
> > > index b526b3898c22e..3f212e46fc2f9 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/en_accel.h
> > > @@ -220,18 +220,7 @@ static inline void
> > > mlx5e_accel_tx_finish(struct mlx5e_txqsq *sq,
> > >
> > > static inline int mlx5e_accel_init_rx(struct mlx5e_priv *priv)
> > > {
> > > - int err;
> > > -
> > > - err = mlx5_accel_psp_fs_init_rx_tables(priv);
> > > - if (err)
> > > - goto out;
> > > -
> > > - err = mlx5e_ktls_init_rx(priv);
> > > - if (err)
> > > - mlx5_accel_psp_fs_cleanup_rx_tables(priv);
> > > -
> > > -out:
> > > - return err;
> > > + return mlx5e_ktls_init_rx(priv);
> > > }
> > >
> > > static inline void mlx5e_accel_cleanup_rx(struct mlx5e_priv *priv)
> > > @@ -242,12 +231,6 @@ static inline void
> > > mlx5e_accel_cleanup_rx(struct mlx5e_priv *priv)
> > >
> > > static inline int mlx5e_accel_init_tx(struct mlx5e_priv *priv)
> > > {
> > > - int err;
> > > -
> > > - err = mlx5_accel_psp_fs_init_tx_tables(priv);
> > > - if (err)
> > > - return err;
> > > -
> > > return mlx5e_ktls_init_tx(priv);
> > > }
> >
> > [Severity: Critical]
> > Does removing the unconditional table creation here prevent PSP
> > tables
> > from being restored on device attach or resume?
> >
> > Since mlx5_accel_psp_fs_cleanup_tx_tables() is still called during
> > device
> > detach or suspend, the PSP steering tables are destroyed. However,
> > because
> > mlx5e_accel_init_tx() no longer recreates them, the tables appear to
> > remain
> > missing after a suspend/resume or detach/attach cycle.
> >
> > Because software psp_assoc structures remain bound to active sockets,
> > could
> > this leave the device in a state where the hardware TX steering table
> > (which
> > contains the CRYPTO_ENCRYPT action) is missing?
> >
> > If so, would this cause egress traffic to bypass encryption and be
> > transmitted in plaintext?
>
> When the device is suspended, 1. all TX keys are released and 2.
> steering rules are removed. 3. psp state is completely freed, including
> the configuration intention.
>
> When the device is resumed, psp is reinitialized to a blank state.
>
> Before these changes, psp was also reset to a blank state (no keys, but
> with steering rules readded). This also broke existing PSP connections.
>
> I guess fixing this behavior during suspend is outside the scope of
> this series. I don't like it, we should do something about it, but not
> in this series.
Thanks, point taken.
I think we can leave this problem for another time.
^ permalink raw reply
* Re: [PATCH net-next 15/15] net/mlx5e: psp: Report PSP dev registration errors
From: Simon Horman @ 2026-07-15 14:42 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Tariq Toukan, Rahul Rameshbabu, Boris Pismenny,
willemdebruijn.kernel@gmail.com, andrew+netdev@lunn.ch,
daniel.zahka@gmail.com, Jianbo Liu, davem@davemloft.net,
leon@kernel.org, linux-kernel@vger.kernel.org, pabeni@redhat.com,
edumazet@google.com, linux-rdma@vger.kernel.org, Raed Salem,
Chris Mi, Dragos Tatulea, sdf.kernel@gmail.com, kuba@kernel.org,
Mark Bloch, sdf@fomichev.me, Saeed Mahameed,
netdev@vger.kernel.org, aleksandr.loktionov@intel.com,
Gal Pressman, Lama Kayal, jacob.e.keller@intel.com
In-Reply-To: <ac799bee802e02b17f5f27e227c84df396d1e1c3.camel@nvidia.com>
On Tue, Jul 14, 2026 at 08:08:03PM +0000, Cosmin Ratiu wrote:
> On Tue, 2026-07-14 at 18:31 +0100, 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
> > ---
> > --- Patch [15]: [PATCH net-next 15/15] net/mlx5e: psp: Report PSP dev
> > registration errors ---
> > commit 76afe7de4d1e708e7c01d267ef1fb9cf946de937
> > Author: Cosmin Ratiu <cratiu@nvidia.com>
> >
> > net/mlx5e: psp: Report PSP dev registration errors
> >
> > This commit updates mlx5e_psp_register() to return an error code
> > instead
> > of void when psp_dev_create() fails. The caller, mlx5e_nic_enable(),
> > is
> > also updated to check this return value and abort if PSP registration
> > fails.
> >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > @@ -6199,7 +6199,9 @@ static int mlx5e_nic_enable(struct mlx5e_priv
> > > *priv)
> > >
> > > mlx5e_fs_init_l2_addr(priv->fs, netdev);
> > > mlx5e_ipsec_init(priv);
> > > - mlx5e_psp_register(priv);
> > > + err = mlx5e_psp_register(priv);
> > > + if (err)
> > > + goto out_ipsec_cleanup;
> >
> > [Severity: High]
> > Could propagating this error cause the entire network interface to
> > fail if
> > the optional PSP offload fails to register?
> >
> > If psp_dev_create() fails (e.g., due to memory pressure or ID
> > exhaustion
> > in xa_alloc_cyclic), mlx5e_nic_enable() will now abort, resulting in
> > a
> > complete loss of networking capability for the device.
> >
> > Notice how the code immediately following this handles MACsec
> > initialization
> > failures by logging the error and allowing the NIC to continue
> > operating:
> >
> > err = mlx5e_macsec_init(priv);
> > if (err)
> > mlx5_core_err(mdev, "MACsec initialization failed,
> > %d\n", err);
> >
> > Should PSP registration failure fall back gracefully and allow the
> > core NIC
> > to function without the offload, similar to how MACsec is handled?
> >
> > >
> > > err = mlx5e_macsec_init(priv);
> > > if (err)
> > > mlx5_core_err(mdev, "MACsec initialization failed,
> > > %d\n", err);
>
> This is an intentional change, as discussed in this thread with Jakub:
>
> https://lore.kernel.org/netdev/20260417050201.192070-1-tariqt@nvidia.com/t/#u
>
> We carefully chose to fail device init on the very unlikely event PSP
> dev creation fails.
Thanks, sorry for not noticing that discussion earlier.
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Simon Schippers @ 2026-07-15 14:32 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, lkp, Brett Sheffield, netdev, linux-kernel, ltp,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Michael S . Tsirkin, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer, linux-doc
In-Reply-To: <202607151550.5d829a99-lkp@intel.com>
On 7/15/26 16:01, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed "ltp.ioctl03.fail" on:
ioctl03.c does not know about IFF_BACKPRESSURE which is introduced here,
consequently it fails.
See [1] where it compares TUN features with known_flags.
Thanks.
[1] Link: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioctl/ioctl03.c#L82
>
> commit: 09154ff2072e36b86ba2d92d436b7f27df153ed1 ("[PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE")
> url: https://github.com/intel-lab-lkp/linux/commits/Simon-Schippers/tun-tap-vhost-net-make-qdisc-backpressure-opt-in-via-IFF_BACKPRESSURE/20260709-181234
> base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git fabb881df322da25442f98d23f5fa371e3c78ec4
> patch link: https://lore.kernel.org/all/20260709095511.168235-1-simon.schippers@tu-dortmund.de/
> patch subject: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
>
> in testcase: ltp
> version:
> with following parameters:
>
> disk: 1HDD
> fs: ext4
> test: syscalls-03
>
>
>
> config: x86_64-rhel-9.4-ltp
> compiler: gcc-14
> test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202607151550.5d829a99-lkp@intel.com
>
>
> ....
>
> ^[[1;37mgetuid03: ^[[0m^[[1;32mpass^[[0m (0.028s)
> ^[[1;37mioctl03: ^[[0m^[[1;31mfail^[[0m (0.047s) <-----
> ^[[1;37mioctl05: ^[[0m^[[1;32mpass^[[0m (0.471s)
>
> ....
>
> Execution time: 3m 35s
>
> Disconnecting from SUT: default
>
> Target information
> ──────────────────
> Kernel: Linux 7.2.0-rc1+ #1 SMP PREEMPT_DYNAMIC Sun Jul 12 07:25:38 CST 2026
> Cmdline: ip=::::lkp-ivb-d04::dhcp
> root=/dev/ram0
> RESULT_ROOT=/result/ltp/1HDD-ext4-syscalls-03/lkp-ivb-d04/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/0
> BOOT_IMAGE=/pkg/linux/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/vmlinuz-7.2.0-rc1+
> branch=linux-devel/devel-hourly-20260709-190759
> job=/lkp/jobs/scheduled/lkp-ivb-d04/ltp-1HDD-ext4-syscalls-03-debian-13-x86_64-20250902.cgz-09154ff2072e-20260712-19649-tc8bu6-0.yaml
> user=lkp
> ARCH=x86_64
> kconfig=x86_64-rhel-9.4-ltp
> commit=09154ff2072e36b86ba2d92d436b7f27df153ed1
> intremap=posted_msi
> max_uptime=7200
> LKP_SERVER=internal-lkp-server
> nokaslr
> selinux=0
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> net.ifnames=0
> printk.devkmsg=on
> panic=-1
> softlockup_panic=1
> nmi_watchdog=panic
> oops=panic
> load_ramdisk=2
> prompt_ramdisk=0
> drbd.minor_count=8
> systemd.log_level=err
> ignore_loglevel
> console=tty0
> earlyprintk=ttyS0,115200
> console=ttyS0,115200
> vga=normal
> rw
> keep_initrds=/osimage/pkg/debian-13-x86_64-20250902.cgz/ltp-x86_64-ed2758122-1_20260711.cgz
> acpi_rsdp=0x000f0490
> Machine: unknown
> Arch: x86_64
> RAM: 6895596 kB
> Swap: 0 kB
> Distro: debian 13
>
> ────────────────────────
> TEST SUMMARY
> ────────────────────────
> Suite: syscalls-03
> Runtime: 3m 24s
> Runs: 183
>
> Results:
> Passed: 2144
> Failed: 1
> Broken: 0
> Skipped: 222
> Warnings: 0
>
> ^[[1;31mFailures:^[[0m
> • ioctl03
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260715/202607151550.5d829a99-lkp@intel.com
>
>
>
^ permalink raw reply
* [PATCH] net: selftests: fix typo in ip_defrag comment
From: deepakraog @ 2026-07-15 14:35 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, netdev, linux-kselftest, linux-kernel
Correct "thourough" to "thorough" in a comment describing the
non-overlap reassembly test loop.
Signed-off-by: deepakraog <gaikwad.dcg@gmail.com>
---
tools/testing/selftests/net/ip_defrag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/ip_defrag.c b/tools/testing/selftests/net/ip_defrag.c
index f9ed749fd..146f2a2a5 100644
--- a/tools/testing/selftests/net/ip_defrag.c
+++ b/tools/testing/selftests/net/ip_defrag.c
@@ -378,7 +378,7 @@ static void run_test(struct sockaddr *addr, socklen_t alen, bool ipv6)
} else {
/* Without overlaps, each packet reassembly (== one
* send/receive pair below) takes very little time to
- * run, so we can easily afford more thourough testing
+ * run, so we can easily afford more thorough testing
* with a nested loop: the full non-overlap test takes
* less than one second).
*/
--
Deepak Rao Gaikwad
^ permalink raw reply related
* Re: [PATCH net-next v3 06/15] net: macb: allocate tieoff descriptor once across device lifetime
From: Nicolai Buchwitz @ 2026-07-15 14:12 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni,
Maxime Chevallier
In-Reply-To: <DJZ6XCJDMFE8.PPNN42W2TGSQ@bootlin.com>
Hi Théo
On July 15, 2026 3:48:18 PM GMT+02:00, "Théo Lebrun" <theo.lebrun@bootlin.com> wrote:
>On Mon Jul 13, 2026 at 2:00 PM CEST, Théo Lebrun wrote:
>> On Thu Jul 2, 2026 at 12:54 PM CEST, Nicolai Buchwitz wrote:
>>> On 1.7.2026 17:59, Théo Lebrun wrote:
>>>> The tieoff descriptor is a RX DMA descriptor ring of size one. It gets
>>>> configured onto queues for Wake-on-LAN during system-wide suspend when
>>>> hardware does not support disabling individual queues
>>>> (MACB_CAPS_QUEUE_DISABLE).
>>>>
>>>> MACB/GEM driver allocates it alongside the main RX ring
>>>> inside macb_alloc() at open. Free is done by macb_free() at close.
>>>>
>>>> Change to allocate once at probe and free on probe failure or device
>>>> removal. This makes the tieoff descriptor lifetime much longer,
>>>> avoiding repeating coherent buffer allocation on each open/close cycle.
>>>>
>>>> Main benefit: we dissociate its lifetime from the main ring's lifetime.
>>>> That way there is less work to be doing on resources (re)alloc. This
>>>> currently happens on close/open, but will soon also happen on context
>>>> swap operations (set_ringparam, change_mtu, set_channels, etc).
>>>>
>>>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>>>> ---
>>>> drivers/net/ethernet/cadence/macb_main.c | 75
>>>> +++++++++++++++++---------------
>>>> 1 file changed, 41 insertions(+), 34 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>>>> b/drivers/net/ethernet/cadence/macb_main.c
>>>> index 8b52122bc134..951a7f080225 100644
>>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>>
>>>> [...]
>>>
>>>> static void macb_init_rings(struct macb *bp)
>>>> @@ -2832,8 +2801,6 @@ static void macb_init_rings(struct macb *bp)
>>>> bp->queues[0].tx_head = 0;
>>>> bp->queues[0].tx_tail = 0;
>>>> desc->ctrl |= MACB_BIT(TX_WRAP);
>>>> -
>>>> - macb_init_tieoff(bp);
>>>> }
>>>>
>>>> static void macb_reset_hw(struct macb *bp)
>>>> @@ -5518,6 +5485,38 @@ static int eyeq5_init(struct platform_device
>>>> *pdev)
>>>> return ret;
>>>> }
>>>>
>>>> +static int macb_alloc_tieoff(struct macb *bp)
>>>> +{
>>>> + /* Tieoff is a workaround in case HW cannot disable queues, for PM.
>>>> */
>>>> + if (bp->caps & MACB_CAPS_QUEUE_DISABLE)
>>>> + return 0;
>>>
>>> Before, the tieoff was allocated in macb_alloc(), which the at91ether
>>> path
>>> never called. Now it's allocated from macb_probe() for all variants,
>>> gated only
>>> on MACB_CAPS_QUEUE_DISABLE, so EMAC gets a coherent descriptor it never
>>> uses.
>>>
>>> Add MACB_CAPS_MACB_IS_EMAC to the if statement?
>>
>> Clearly. That EMAC distinction keeps being annoying.
>
>Well well well. Under AT91 with WOL active there is nothing preventing
>the tieoff from being used in macb_suspend(). Meaning the tieoff is
>being used zero-initialised. Not advisable.
>
>So I withdraw my previous comment: we won't shield macb_alloc_tieoff()
>from IS_EMAC and maybe it will fix a bug.
Sounds reasonable.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Thanks,
Nicolai
>
>Thanks,
>
>--
>Théo Lebrun, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
>
^ permalink raw reply
* Re: [PATCH] dpaa2-switch: put MAC endpoint device on disconnect
From: Simon Horman @ 2026-07-15 14:10 UTC (permalink / raw)
To: Guangshuo Li
Cc: Ioana Ciornei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260708111025.749311-1-lgs201920130244@gmail.com>
On Wed, Jul 08, 2026 at 07:10:25PM +0800, Guangshuo Li wrote:
> fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
> taken through device_find_child(). The switch port connect path stores
> that device in mac->mc_dev and keeps it for the lifetime of the connected
> MAC object.
>
> However, the disconnect path only closes the MAC and frees the dpaa2_mac
> object. It does not drop the endpoint device reference stored in
> mac->mc_dev, so every successful connect leaks that device reference when
> the MAC is later disconnected.
>
> Drop the endpoint device reference before freeing the dpaa2_mac object.
>
> Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: kernel test robot @ 2026-07-15 14:01 UTC (permalink / raw)
To: Simon Schippers
Cc: oe-lkp, lkp, Brett Sheffield, netdev, linux-kernel, ltp,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Michael S . Tsirkin, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer, linux-doc,
Simon Schippers, oliver.sang
In-Reply-To: <20260709095511.168235-1-simon.schippers@tu-dortmund.de>
Hello,
kernel test robot noticed "ltp.ioctl03.fail" on:
commit: 09154ff2072e36b86ba2d92d436b7f27df153ed1 ("[PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE")
url: https://github.com/intel-lab-lkp/linux/commits/Simon-Schippers/tun-tap-vhost-net-make-qdisc-backpressure-opt-in-via-IFF_BACKPRESSURE/20260709-181234
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git fabb881df322da25442f98d23f5fa371e3c78ec4
patch link: https://lore.kernel.org/all/20260709095511.168235-1-simon.schippers@tu-dortmund.de/
patch subject: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
in testcase: ltp
version:
with following parameters:
disk: 1HDD
fs: ext4
test: syscalls-03
config: x86_64-rhel-9.4-ltp
compiler: gcc-14
test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202607151550.5d829a99-lkp@intel.com
....
^[[1;37mgetuid03: ^[[0m^[[1;32mpass^[[0m (0.028s)
^[[1;37mioctl03: ^[[0m^[[1;31mfail^[[0m (0.047s) <-----
^[[1;37mioctl05: ^[[0m^[[1;32mpass^[[0m (0.471s)
....
Execution time: 3m 35s
Disconnecting from SUT: default
Target information
──────────────────
Kernel: Linux 7.2.0-rc1+ #1 SMP PREEMPT_DYNAMIC Sun Jul 12 07:25:38 CST 2026
Cmdline: ip=::::lkp-ivb-d04::dhcp
root=/dev/ram0
RESULT_ROOT=/result/ltp/1HDD-ext4-syscalls-03/lkp-ivb-d04/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/0
BOOT_IMAGE=/pkg/linux/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/vmlinuz-7.2.0-rc1+
branch=linux-devel/devel-hourly-20260709-190759
job=/lkp/jobs/scheduled/lkp-ivb-d04/ltp-1HDD-ext4-syscalls-03-debian-13-x86_64-20250902.cgz-09154ff2072e-20260712-19649-tc8bu6-0.yaml
user=lkp
ARCH=x86_64
kconfig=x86_64-rhel-9.4-ltp
commit=09154ff2072e36b86ba2d92d436b7f27df153ed1
intremap=posted_msi
max_uptime=7200
LKP_SERVER=internal-lkp-server
nokaslr
selinux=0
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw
keep_initrds=/osimage/pkg/debian-13-x86_64-20250902.cgz/ltp-x86_64-ed2758122-1_20260711.cgz
acpi_rsdp=0x000f0490
Machine: unknown
Arch: x86_64
RAM: 6895596 kB
Swap: 0 kB
Distro: debian 13
────────────────────────
TEST SUMMARY
────────────────────────
Suite: syscalls-03
Runtime: 3m 24s
Runs: 183
Results:
Passed: 2144
Failed: 1
Broken: 0
Skipped: 222
Warnings: 0
^[[1;31mFailures:^[[0m
• ioctl03
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260715/202607151550.5d829a99-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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