* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Umang Chheda @ 2026-04-06 11:58 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel, netdev
In-Reply-To: <7r6373fo56alzqa4e2zzdnsgwfhgdkmbhxe4cvdo4p7fg3zren@eyiml4uedfbn>
On 4/5/2026 1:09 AM, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 04:15:54PM +0530, Umang Chheda wrote:
>>
>>
>> On 4/4/2026 1:58 AM, Dmitry Baryshkov wrote:
>>> On Fri, Apr 03, 2026 at 04:14:28PM +0530, Umang Chheda wrote:
>>>> Hello Dmitry,
>>>>
>>>> On 4/1/2026 5:06 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
>>>>>> Introduce bindings for the monaco-evk-ac IoT board, which is
>>>>>> based on the monaco-ac (QCS8300-AC) SoC variant.
>>>>>
>>>>> If it is a different SoC SKU, should it be reflected in the SoC compat
>>>>> strings?
>>>>
>>>> Monaco‑AC does not introduce any S/W differences compared to Monaco SoC
>>>> -- All IP blocks and bindings remain identical from S/W PoV, Hence
>>>> haven't included the SoC SKU in the SoC compat strings.
>>>>
>>>> Hope this is okay ? Your view on this ?
>>>
>>> You are descibing -AC as the main difference between the kits, but then
>>> you say that -AC doesn't bring new software interfaces. What is the
>>> difference then between monako-evk and the -ac variant?
>>>
>>
>> The major difference between monaco-evk and monaco-ac-evk boards is that
>> of power grid. monaco-evk requires 4 PMICs (2x PM8650AU + Maxim MAX20018
>> + TI TPS6594) to support higher power requirements of monaco-AA variant
>> of SoC which supports upto 40 TOPS of NPU - whereas this board
>> "monaco-ac-evk" supports 20 TOPS of NPU and has lesser power
>> requirements hence 2 PMICs suffice the power requirements (2x PM8650AU).
>
> Is that the only difference? Is the PCB the same? Should we have a
> single common file for those two variants?
Yes, the major differences b/w 2 boards are:
1. Monaco-AA version of SoC in monaco-evk v/s Monaco-AC version of SoC
in monaco-ac-evk board.
2. 4 PMICs (2x PM8650AU + Maxim MAX20018 + TI TPS6594) in monaco-evk
board v/s 2 PMICs (2x PM8650AU) in monaco-ac-evk board.
PCB is different for both of the boards.
Can I restructure as below to avoid code duplication ?
"monaco-evk-common.dtsi" --> This will add/enable all the common
peripherals of monaco-evk and monaco-ac-evk.
monaco-evk.dts --> Include "monaco-evk-common.dtsi" and enable
monaco-evk specific changes.
monaco-ac-evk.dts --> Include "monaco-evk-common.dtsi" and enable
monaco-ac specific changes
Does the above file re-structuring looks good ?
>
>>
>>
>>> Also, from the naming point of view, it is monako-ac-evk, not the other
>>> way.
>>
>> Ack, will change this to "monaco-ac-evk" in the next version.
>>
>> Also, should I change DT name "monaco-ac-sku.dts" instead of current
>> "monaco-evk-ac-sku" ?
>
> monako-ac-evk.dtsi.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> index ca880c105f3b..c76365a89687 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> @@ -918,6 +918,7 @@ properties:
>>>>>> - enum:
>>>>>> - arduino,monza
>>>>>> - qcom,monaco-evk
>>>>>> + - qcom,monaco-evk-ac
>>>>>> - qcom,qcs8300-ride
>>>>>> - const: qcom,qcs8300
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 2.34.1
>>>>>>
>>>>>
>>>>
>>>> Thanks,
>>>> Umang
>>>
>>
>> Thanks,
>> Umang
>>
>>
>
Thanks,
Umang
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-06 11:59 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <willemdebruijn.kernel.2ff565d2f9e7f@gmail.com>
On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Jason Xing wrote:
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > The patch is the 1/2 part of push-level granularity feature.
> >
> > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > though it might not carry the last byte of the sendmsg.
> >
> > Prior to the patch, BPF timestamping cannot cover this case:
> > The following steps reproduce this:
> > 1) skb A is the current last skb before entering wait_for_space process
> > 2) tcp_push() pushes A without any tag
> > 3) A is transmitted from TCP to driver without putting any skb carrying
> > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > error code. Note that the socket lock is released.
> > 5) skb A finally gets acked and removed from the rtx queue.
> > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > 'do_error' label and then 'out' label.
> > 7) at this moment, skb A turns out to be the last one in this send
> > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > before the final tcp_push()
> > 8) BPF script fails to see any timestamps this time
> >
> > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > ---
> > net/ipv4/tcp.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index c603b90057f6..7d030a11d004 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > wait_for_space:
> > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > tcp_remove_empty_skb(sk);
> > - if (copied)
> > + if (copied) {
> > + tcp_bpf_tx_timestamp(sk);
> > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > TCP_NAGLE_PUSH, size_goal);
>
> Now the number of skbs that will be tracked will be unpredictable,
> varying based on memory pressure.
Right, I put some effort into writing a selftests to check how many
push functions get called at one time and failed to do so.
>
> That sounds hard to use to me. Especially if these extra pushes
> cannot be identified as such.
>
> Perhaps if all skbs from the same sendmsg call can be identified,
> that would help explain pattern in data resulting from these
> uncommon extra data points.
You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
close to packet basis without considering fragmentation of skb :)
Thanks,
Jason
^ permalink raw reply
* [PATCH v2] net: sfp: add quirks for GPON ONT SFP sticks
From: John Pavlick @ 2026-04-06 12:17 UTC (permalink / raw)
To: linux
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, John Pavlick, Marcin Nita
Several GPON ONT SFP sticks based on Realtek RTL960x report
1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
On hosts with serdes fixed at 2.5Gbase-X (e.g. Banana Pi R3 / MT7986),
the kernel rejects them with 'no common interface modes'.
Add quirks for:
- Hisense-Leox LXT-010S-H
- Hisense ZNID-GPON-2311NA
- HSGQ HSGQ-XPON-Stick
Each quirk advertises 2500base-X and ignores TX_FAULT during the
module's ~40s Linux boot time.
Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed
2.5Gbps link and full throughput with flow offloading.
Suggested-by: Marcin Nita <marcin.nita@leolabs.pl>
Signed-off-by: John Pavlick <jspavlick@posteo.net>
---
Changes in v2:
- Add Suggested-by tag for Marcin Nita <marcin.nita@leolabs.pl>, who
suggested investigating sfp.c quirks as a solution rather than
attempting to edit the EEPROM data directly on the module.
drivers/net/phy/sfp.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f1070eb0a0bb..bd970f753beb 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -543,6 +543,22 @@ static const struct sfp_quirk sfp_quirks[] = {
SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex,
sfp_fixup_ignore_tx_fault_and_los),
+ // Hisense LXT-010S-H is a GPON ONT SFP (sold as LEOX LXT-010S-H) that
+ // can operate at 2500base-X, but reports 1000BASE-LX / 1300MBd in its
+ // EEPROM
+ SFP_QUIRK("Hisense-Leox", "LXT-010S-H", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // Hisense ZNID-GPON-2311NA can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("Hisense", "ZNID-GPON-2311NA", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // HSGQ HSGQ-XPON-Stick can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("HSGQ", "HSGQ-XPON-Stick", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
// Lantech 8330-262D-E and 8330-265D can operate at 2500base-X, but
// incorrectly report 2500MBd NRZ in their EEPROM.
// Some 8330-265D modules have inverted LOS, while all of them report
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Andrew Lunn @ 2026-04-06 12:22 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Carlo Szelinsky, Kory Maincent, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <adN9Ha5FgJ8sp6gj@pengutronix.de>
> The core question, do we need PSE for PHY functionality?
I don't think the PHY should require PSE in order to send/receive
frames. If the PSE is not supplying power, the link peer is probably
off, but that is not so different from the cable being unplugged.
> We can make a step back and re-evaluate - what functionality and what
> order is actually required to find potentially better implementation.
>
> We have a lot of current flowing over wires, budget and port
> prioritization issues, things which may damage HW if done not correctly.
> With other word, if we do not have properly operational environment
> providing system specific policies, it is better to run safe
> configuration - all ports/regulators are off.
>
> This means:
> - PSE controller driver should be registered as early as possible,
> without caring about existence of PHYs, ports or network interfaces.
> And configure ports in to default safe operation - off. Accept we
> have some controller/firmware which would care about safety.
Don't most PSE have I2C or SPI interfaces? So they have a different
life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
within a PHY, on an MDIO bus, will have a closely linked life
cycle. But do such devices exist?
As soon as the PSE probes with all the resources it needs, and can
impose a safe default setting. And that can be independent of PHY and
netdev. I _think_ we only need the netdev for configuration, since
ethtool addresses netdev's. There would only be issues with user
space listening to udev creation events, it knows the PSE exists, but
it has no way to access it until the netdev is created.
> - as soon as we have all needed components, we can start provide
> controllable interfaces to serve external consumers.
Yep.
> If we decouple PSE and PHY registration (and we probably will need to do
> it some day), we would need to have own implementation of deferred
> probing in the PSE core. Event driven or by polling - which sounds not
> like very good idea. Pick your poison...
I don't see why. Maybe i'm missing something. We have two cases:
1) PSE probes first. When the PHY looks up the PSE, it exists, and it
is passed a handle to the PSE.
2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
will try again later.
I don't think there is any chicken/egg problems.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] bpf-timestamp: convert to push-level granularity
From: Jason Xing @ 2026-04-06 12:25 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing
In-Reply-To: <willemdebruijn.kernel.2053d6bde1d3d@gmail.com>
On Mon, Apr 6, 2026 at 10:17 AM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Jason Xing wrote:
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > 1. Design of send-level granularity
> > Originally, socket timestamping was designed to support tracing each
> > sendmsg instead of per packet because application needs to issue
> > multiple extra recvmsg() calls to get the skbs carrying the timestamp
> > one by one if application chooses tag with different tags(SCHED/DRV/ACK).
> > It's an obvious huge burden if the application expects to see a finer
> > grained behavior.
> > Another point I mentioned a bit in Netdev 0x19[1], supposing the amount of
> > data that application tries to transfer at one time is split into 100
> > smaller packets, recording the last skb's timestamps (SCHED/DRV/HARDWARE)
> > is no longer meaningful because at the moment timestamping only records
> > 1/100 packets. In this case, only the delta between when to send and when
> > to ack matters.
> >
> > 2. Known missing tag issues in TCP
> > A critically important thing is that we can miss tagging the last packet
> > in a few conditions as the patch 3/4 explains. That means we lose track
> > of the send syscall. Digging into more into how tcp_sendmsg_locked works,
> > I found it's not feasible to successfully identify the last skb before
> > push functions get called. With that said, if we want to make the feature
> > better to cover all of these cases, we inevitably needs to place
> > tcp_bpf_tx_timestamp() function before each push function.
> >
> > 3. Practice at Tencent
> > In production, we have a version that applies the packet basis policy to
> > do the exhaustive profiling of each flow for months in order to:
> > 1) 100% make sure to capture the jitter event. No sampling.
> > 2) observe the performance, find the bottleneck and improve it.
> > We're still collecting data and investigating how it helps us in all the
> > potential aspects before upstreaming. My personal perspective on this is
> > to replace tcpdump eventually. It's worth mentioning tcpdump no longer
> > satisfies our micro observation in modern data center.
> >
> > 4. The tendency toward finer-grained observability
> > As we're aware that there are already many various bpf scripts trying to
> > implement the fine grained monitor of the packets, it's an unstoppable
> > tendency for the future observability. We're faced with so many latency
> > reports (like jitter, perf degradation) on a daily basis. Getting the
> > root cause of each report is exactly what we pursue.
> > After we know which request causes the problem, if it belongs to kernel,
> > we will dig into the packet behavior with more useful information
> > included. This is the process of tracing down the jitter problem.
> > Likewise, in BPF timestamping that mitigates the impact of calling extra
> > syscalls, breaking the coarse granularity into smaller ones is a first
> > good way to go. It shouldn't be the burden like before especially it's
> > independent of application.
> >
> > 5. Details of the series
> > Now it's time to convert BPF timestamping feature into push-level
> > granularity by only recording the last skb in each push function, which
> > is quite similar to how we previously treat each send syscall.
> > Regarding each push function as a whole, we only care about
> > the last skb from each push since the skb can be chunked into different
> > smaller packets. BPF scripts like progs/net_timestamping.c has the
> > ability to trace each tagged skb and calculate the latency:
> > 1) delta between send and each tagged skb in tcp_sendmsg_locked()
> > 2) delta between SCHED/DRV/ACK. Three timestamps are also correlated
> > with the sendmsg time.
> >
> > In conclusion, push-level is more of a compromise approach which covers
> > those corner cases and further enhances the capabilities (like a finer
> > grained observation of jitter and performance issues).
>
> # push-level design
>
> It it significantly less intuitive than per-syscall, which is under
> user control. Or even than per-packet. As a fix for missing timestamps
> I understand these two extensions, even with the unintended side
> effect of reporting many unnecessary extra skbs in the common case.
> As a model to advocate for, less so.
Thanks for your review!
Fair enough. One mode of our internal kernel module directly hijacks
tcp_skb_entail() that handles the last skb of this skb if
fragmentation happens.
>
> Would it help if all skbs from the same sendmsg() can still be
> identified as common from the same syscall? That allows the user
I have to add more comments about push level:
the last skb from each push function will always be correlated with
its own sendmsg. With the help of BPF_SOCK_OPS_TSTAMP_SENDMSG_CB, bpf
script can do so.
> to discard all but the last one (if they wish)
Oh, I just replied with another reply. Let's start the discussion here.
It would be great if we have a definite finer grained observability.
>
>
> # ABI changes
>
> For SO_TIMESTAMPING we would not be able to make this change
> unconditionally as the behavior change would break existing
> application expectations.
Right.
>
> That is why historically we have guarded new behabvior behind new
> TS options flags.
>
> The same may be true for BPF.
How about adding a socket option for a per packet mode, say,
BPF_SOCK_OPS_TSTAMP_TCP_PACKET_CB around tcp_skb_entail() which works
very similarly to
BPF_SOCK_OPS_TSTAMP_SENDMSG_CB. After that, users have a standalone
option to decide whether to trace all the skbs from the sendmsg.
If so, the origin BPF timestamping that works exactly like socket
timestamping is the best effort (we don't 100% guarantee the timestamping
feature captures every sendmsg call). With the new socket option
involved, we provide a finer grained vision without harming users who
favor the origin design with those two issues resolved.
A kind reminder is that if the skb is fragmented, for instance, due to
TSO being disabled, only the last smaller/child one will be monitored.
>
>
> # SO_TIMESTAMPING and BPF timestamping differences
>
> A related point is that this breaks the 1:1 relationship between
> SO_TIMESTAMPING and BPF timestamping. As said before, I think that
> is fine as BPF timestamping can be cheaper. But we should avoid the
> two forking in incompatible ways. I suggest that BPF timestamping
> becomes a superset of SO_TIMESTAMPING: it must have all features
> of SO_TIMESTAMPING, and may offer more.
Thanks for your insight. I agree with you! A new socket option should
be fine, I suppose.
>
>
> # Documentation and testing
>
> Please also expand Documentation and include a test.
Will update the doc in the next version.
Sorry, a test for push-level is a bit difficult. Let me complete it
after we reach a consensus on how we use it :)
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net 3/3] iavf: drop netdev lock while waiting for MAC change completion
From: Kohei Enju @ 2026-04-06 12:29 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: netdev, intel-wired-lan, jesse.brandeburg, anthony.l.nguyen,
davem, edumazet, kuba, pabeni, stable
In-Reply-To: <20260406112057.906685-4-jtornosm@redhat.com>
On 04/06 13:20, Jose Ignacio Tornos Martinez wrote:
> After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
> operations"), iavf_set_mac() is called with the netdev instance lock
> already held.
>
> The function queues a MAC address change request and then waits for
> completion while holding this lock. However, the watchdog task that
> processes admin queue commands (including MAC changes) also needs to
> acquire the netdev lock to run.
>
> This creates a lock contention scenario:
> 1. iavf_set_mac() holds netdev lock and waits for MAC change
> 2. Watchdog needs netdev lock to process the MAC change request
> 3. Watchdog blocks waiting for lock
> 4. MAC change times out after 2.5 seconds
> 5. iavf_set_mac() returns -EAGAIN
>
> This particularly affects VFs during initialization when enslaved to a
> bond. The first VF typically succeeds as it's already fully initialized,
> but subsequent VFs fail as they're still progressing through their state
> machine and need the watchdog to advance.
>
> Fix by temporarily dropping the netdev lock before waiting for MAC change
> completion, allowing the watchdog to run and process the request, then
> re-acquiring the lock before returning.
>
> This is safe because:
> - The MAC change request is already queued before we drop the lock
> - iavf_is_mac_set_handled() just checks filter state, doesn't modify it
> - We re-acquire the lock before checking results and returning
>
> Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
> cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index dad001abc908..6281858e6f3c 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -1068,10 +1068,14 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
> if (ret)
> return ret;
>
> + netdev_unlock(netdev);
> +
> ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
> iavf_is_mac_set_handled(netdev, addr->sa_data),
> msecs_to_jiffies(2500));
>
> + netdev_lock(netdev);
> +
Hi Jose, thank you for the fix and detailed explanation.
I don't have a great solution for this issue, but dropping the netdev
lock taken by the networking core in the driver callback might not look
acceptable.
FYI, Petr reported the same type of locking issue in
ndo_change_mtu(), and the v1 approach was really similar to this one.
https://lore.kernel.org/intel-wired-lan/20260202155813.3f8fbc27@kernel.org/
IIUC, the issue was eventually fixed by completing the reset
synchronously in the same context as ndo_change_mtu(), instead of
dropping the netdev lock and waiting for reset_task.
https://lore.kernel.org/intel-wired-lan/20260211191855.1532226-1-poros@redhat.com/
If that applies here as well, maybe iavf_set_mac() needs a similar
approach, e.g. progressing the relevant virtchnl request/completion
synchronously with the netdev lock held, rather than dropping the lock
here?
> /* If ret < 0 then it means wait was interrupted.
> * If ret == 0 then it means we got a timeout.
> * else it means we got response for set MAC from PF,
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Andrew Lunn @ 2026-04-06 12:42 UTC (permalink / raw)
To: Carlo Szelinsky
Cc: Kory Maincent, Oleksij Rempel, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260405185730.3937952-1-github@szelinsky.de>
On Sun, Apr 05, 2026 at 08:57:30PM +0200, Carlo Szelinsky wrote:
> Hi Andrew,
>
> So I went and looked at whether we can just let EPROBE_DEFER do its
> thing here, like you suggested.
>
> >From what I can tell, the issue is where it happens.
> fwnode_mdiobus_register_phy() gets called during the MDIO bus scan in
> __of_mdiobus_parse_phys(), and if any PHY returns -EPROBE_DEFER there,
> the whole scan bails out - none of the PHYs on that bus get registered.
> So you'd lose all networking on that bus just because one PHY's PSE
> controller isn't ready yet.
Something does not sounds correct here. The MDIO bus, and the devices
on the bus should have different life cycles.
If the MDIO bus itself is missing resources it needs, it can return
EPROBE_DEFFER. A typical example of this would be the MDIO bus reset,
which applies to all devices on the bus. If that GPIO is missing, the
probe of the MDIO bus will unwind.
I would expect PHYs on the bus to be just devices in the device
model. They can return EPROBE_DEFER, and the driver core will probe
them again later. This could be a per PHY reset signal, reset
controller, etc, or the PSE. If such a resource is missing, just the
PHY should fail probing, not the whole MDIO bus.
> I also dug into the timing question you raised. Correct me if I'm
> wrong, but from what I see the deferred probe timeout is 10s and
> regulator_late_cleanup fires at 30s, so the ordering would actually
> work out - the consumer would get to claim the regulator before
> cleanup kills it. It's more the bus level collateral damage that
> seemed like the real problem to me.
Your patch 0/X says:
> When a PSE controller driver is built as a module, it may not be
> probed yet when PHYs are registered on the MDIO bus. This causes
> of_pse_control_get() to return -EPROBE_DEFER, destroying the PHY
> device. Later, regulator_late_cleanup disables the unclaimed PSE
> regulators, permanently killing PoE.
How are we getting to time t=30 without the PSE probing?
If the PSE controller is a module, and missing from the file system,
so cannot be loaded, then turning off the regulators actually seems
like a good safety policy. But if the module is there, but never gets
loaded, it sounds like we have a different sort of problem, some
cyclic dependency we need to break?
Andrew
^ permalink raw reply
* Re: [PATCH net] net: stmmac: dwmac-motorcomm: fix eFUSE MAC address read failure
From: Yao Zi @ 2026-04-06 12:42 UTC (permalink / raw)
To: Johan Alvarado, davem, kuba, pabeni, edumazet
Cc: ggo, andrew+netdev, netdev, linux-kernel
In-Reply-To: <4aaa214c-4286-4c24-ab5c-b17a3a1a8f1e@smtp-relay.sendinblue.com>
On Mon, Apr 06, 2026 at 07:44:25AM +0000, Johan Alvarado wrote:
>
> This patch fixes an issue where reading the MAC address from the eFUSE
> fails due to a race condition.
>
> The root cause was identified by comparing the driver's behavior with a
> custom U-Boot port. In U-Boot, the MAC address was read successfully
> every time because the driver was loaded later in the boot process, giving
> the hardware ample time to initialize. In Linux, reading the eFUSE
> immediately returns all zeros, resulting in a fallback to a random MAC address.
>
> Hardware cold-boot testing revealed that the eFUSE controller requires a
> short settling time to load its internal data. Adding a 2000-5000us
> delay after the reset ensures the hardware is fully ready, allowing the
> native MAC address to be read consistently.
Sounds like a reasonable explanation. The vendor driver reads MAC
address from eFuse before issuing a system reset, which explains why
this doesn't reproduce on it. However, I'd prefer your approach which
ensures a clean hardware state before any operations are performed.
I'm currently on travel thus couldn't verify it against real hardware,
but here's mine tag,
Reviewed-by: Yao Zi <me@ziyao.cc>
Much thanks for investigating into it.
Best regards,
Yao Zi
> Fixes: 02ff155ea281 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller")
> Reported-by: Georg Gottleuber <ggo@tuxedocomputers.com>
> Closes: https://lore.kernel.org/all/24cfefff-1233-4745-8c47-812b502d5d19@tuxedocomputers.com/
> Signed-off-by: Johan Alvarado <contact@c127.dev>
^ permalink raw reply
* Re: [PATCH] net: sfp: add quirks for GPON ONT SFP sticks
From: Daniel Golle @ 2026-04-06 12:48 UTC (permalink / raw)
To: John Pavlick
Cc: linux, andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <20260406114352.69168-1-jspavlick@posteo.net>
On Mon, Apr 06, 2026 at 11:44:05AM +0000, John Pavlick wrote:
> Several GPON ONT SFP sticks based on Realtek RTL960x report
> 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
> On hosts with serdes fixed at 2.5Gbase-X (e.g. Banana Pi R3 / MT7986),
> the kernel rejects them with 'no common interface modes'.
While the quirks themselves may be correct, the statement above is wrong.
The BananaPi R3 (and all MediaTek router SoCs) *do* support also
1000Base-X and SGMII, the SerDes is *not* "fixed at 2.5GBase-X". This
can easily be verified by plugging a random 1Gbps SFP module into the
board (eg. ubiquitous copper modules based on Marvell 88E1111 PHY).
Also you have to make sure to not break support for those modules on
boards which do not support 2500Base-X and need the module to operate
at 1000Base-X (eg. older MikroTik QCA9xxx-based MIPS boards).
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Andrew Lunn @ 2026-04-06 13:17 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Florian Fainelli,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <20260406-devel-autonomous-eee-v1-0-b335e7143711@tipi-net.de>
On Mon, Apr 06, 2026 at 09:13:06AM +0200, Nicolai Buchwitz wrote:
> Some PHYs implement autonomous EEE where the PHY manages EEE
> independently
I suppose we should discuss naming. As far as i know, IEEE 802.3 does
not include this feature, so it does not provide a guide to how we
should name it.
In the past we have used SmartEEE, but that is Atheros's vendor
name. Broadcom seem to call it AutoGrEEEn.
Autonomous EEE seems like a reasonable name, and appears to be vendor
agnostic. Are we happy with this?
What i guess is unclear is what part of the network stack is acting
autonomously. In the context of a PHY driver op,
.disable_autonomous_eee is clear. But when we go further to actually
making use of it, do we need to report to user space if we are using
IEEE 802.3 EEE or "autonomous EEE". But i guess it is no worse than
SmartEEE or AutoGrEEEn which also make no indication where EEE is
happening.
Thoughts?
Andrew
^ permalink raw reply
* [PATCH net 1/1] batman-adv: hold claim backbone gateways by reference
From: Ao Zhou @ 2026-04-06 13:17 UTC (permalink / raw)
To: b.a.t.m.a.n, netdev
Cc: Marek Lindner, Simon Wunderlich, Antonio Quartulli,
Sven Eckelmann, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Andrew Lunn, Yifan Wu, Juefei Pu,
Yuan Tan, Xin Liu, Ao Zhou, Haoze Xie
In-Reply-To: <cover.1775301426.git.royenheart@gmail.com>
From: Haoze Xie <royenheart@gmail.com>
batadv_bla_add_claim() can replace claim->backbone_gw and drop the old
gateway's last reference while readers still follow the pointer.
The netlink claim dump path dereferences claim->backbone_gw->orig and
takes claim->backbone_gw->crc_lock without pinning the underlying
backbone gateway. batadv_bla_check_claim() still has the same naked
pointer access pattern.
Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate
on a stable gateway reference until the read-side work is complete.
This keeps the dump and claim-check paths aligned with the lifetime
rules introduced for the other BLA claim readers.
Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
Fixes: 04f3f5bf1883 ("batman-adv: add B.A.T.M.A.N. Dump BLA claims via netlink")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
---
net/batman-adv/bridge_loop_avoidance.c | 27 +++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 49ae92b9a152..247d8502c90b 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -2129,6 +2129,7 @@ batadv_bla_claim_dump_entry(struct sk_buff *msg, u32 portid,
struct batadv_hard_iface *primary_if,
struct batadv_bla_claim *claim)
{
+ struct batadv_bla_backbone_gw *backbone_gw;
const u8 *primary_addr = primary_if->net_dev->dev_addr;
u16 backbone_crc;
bool is_own;
@@ -2145,32 +2146,35 @@ batadv_bla_claim_dump_entry(struct sk_buff *msg, u32 portid,
genl_dump_check_consistent(cb, hdr);
- is_own = batadv_compare_eth(claim->backbone_gw->orig,
- primary_addr);
+ backbone_gw = batadv_bla_claim_get_backbone_gw(claim);
+
+ is_own = batadv_compare_eth(backbone_gw->orig, primary_addr);
- spin_lock_bh(&claim->backbone_gw->crc_lock);
- backbone_crc = claim->backbone_gw->crc;
- spin_unlock_bh(&claim->backbone_gw->crc_lock);
+ spin_lock_bh(&backbone_gw->crc_lock);
+ backbone_crc = backbone_gw->crc;
+ spin_unlock_bh(&backbone_gw->crc_lock);
if (is_own)
if (nla_put_flag(msg, BATADV_ATTR_BLA_OWN)) {
genlmsg_cancel(msg, hdr);
- goto out;
+ goto put_backbone_gw;
}
if (nla_put(msg, BATADV_ATTR_BLA_ADDRESS, ETH_ALEN, claim->addr) ||
nla_put_u16(msg, BATADV_ATTR_BLA_VID, claim->vid) ||
nla_put(msg, BATADV_ATTR_BLA_BACKBONE, ETH_ALEN,
- claim->backbone_gw->orig) ||
+ backbone_gw->orig) ||
nla_put_u16(msg, BATADV_ATTR_BLA_CRC,
backbone_crc)) {
genlmsg_cancel(msg, hdr);
- goto out;
+ goto put_backbone_gw;
}
genlmsg_end(msg, hdr);
ret = 0;
+put_backbone_gw:
+ batadv_backbone_gw_put(backbone_gw);
out:
return ret;
}
@@ -2448,6 +2452,7 @@ int batadv_bla_backbone_dump(struct sk_buff *msg, struct netlink_callback *cb)
bool batadv_bla_check_claim(struct batadv_priv *bat_priv,
u8 *addr, unsigned short vid)
{
+ struct batadv_bla_backbone_gw *backbone_gw;
struct batadv_bla_claim search_claim;
struct batadv_bla_claim *claim = NULL;
struct batadv_hard_iface *primary_if = NULL;
@@ -2470,9 +2475,13 @@ bool batadv_bla_check_claim(struct batadv_priv *bat_priv,
* return false.
*/
if (claim) {
- if (!batadv_compare_eth(claim->backbone_gw->orig,
+ backbone_gw = batadv_bla_claim_get_backbone_gw(claim);
+
+ if (!batadv_compare_eth(backbone_gw->orig,
primary_if->net_dev->dev_addr))
ret = false;
+
+ batadv_backbone_gw_put(backbone_gw);
batadv_claim_put(claim);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] net: sfp: add quirks for GPON ONT SFP sticks
From: John Pavlick @ 2026-04-06 13:23 UTC (permalink / raw)
To: Daniel Golle
Cc: linux, andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <adOri4VEQl8ezm24@makrotopia.org>
Thank you for the review.
You are correct that the commit message was inaccurate — the Banana Pi R3 / MT7986 SerDes is not fixed at 2500base-X and does support 1000base-X and SGMII as well. I apologize for the
misleading description. I will send a v3 with a corrected commit message.
Regarding the concern about breaking 1G support on boards that do not support 2500base-X: sfp_quirk_2500basex only adds 2500base-X to the module's advertised capabilities via
linkmode_set_bit — it does not remove the 1000BASE-LX capability reported by the EEPROM. The kernel should still be able to negotiate 1G on boards that do not support 2500base-X. That
said, I do not have access to older MikroTik QCA9xxx-based hardware to test this, so I welcome any additional guidance.
> On 6 Apr 2026, at 14:48, Daniel Golle <daniel@makrotopia.org> wrote:
>
> On Mon, Apr 06, 2026 at 11:44:05AM +0000, John Pavlick wrote:
>> Several GPON ONT SFP sticks based on Realtek RTL960x report
>> 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
>> On hosts with serdes fixed at 2.5Gbase-X (e.g. Banana Pi R3 / MT7986),
>> the kernel rejects them with 'no common interface modes'.
>
> While the quirks themselves may be correct, the statement above is wrong.
> The BananaPi R3 (and all MediaTek router SoCs) *do* support also
> 1000Base-X and SGMII, the SerDes is *not* "fixed at 2.5GBase-X". This
> can easily be verified by plugging a random 1Gbps SFP module into the
> board (eg. ubiquitous copper modules based on Marvell 88E1111 PHY).
>
> Also you have to make sure to not break support for those modules on
> boards which do not support 2500Base-X and need the module to operate
> at 1000Base-X (eg. older MikroTik QCA9xxx-based MIPS boards).
^ permalink raw reply
* [PATCH v3] net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules
From: John Pavlick @ 2026-04-06 13:23 UTC (permalink / raw)
To: linux
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, John Pavlick, Marcin Nita
Several GPON ONT SFP sticks based on Realtek RTL960x report
1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the
kernel negotiates only 1G because it trusts the incorrect EEPROM data.
Add quirks for:
- Hisense-Leox LXT-010S-H
- Hisense ZNID-GPON-2311NA
- HSGQ HSGQ-XPON-Stick
Each quirk advertises 2500base-X and ignores TX_FAULT during the
module's ~40s Linux boot time.
Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed
2.5Gbps link and full throughput with flow offloading.
Suggested-by: Marcin Nita <marcin.nita@leolabs.pl>
Signed-off-by: John Pavlick <jspavlick@posteo.net>
---
Changes in v3:
- Fix inaccurate commit message: the MT7986 SerDes is not fixed at
2500base-X; it also supports 1000base-X and SGMII. Corrected to
state that the kernel negotiates only 1G because it trusts the
incorrect EEPROM data.
Changes in v2:
- Add Suggested-by tag for Marcin Nita <marcin.nita@leolabs.pl>, who
suggested investigating sfp.c quirks as a solution rather than
attempting to edit the EEPROM data directly on the module.
drivers/net/phy/sfp.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f1070eb0a0bb..bd970f753beb 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -543,6 +543,22 @@ static const struct sfp_quirk sfp_quirks[] = {
SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex,
sfp_fixup_ignore_tx_fault_and_los),
+ // Hisense LXT-010S-H is a GPON ONT SFP (sold as LEOX LXT-010S-H) that
+ // can operate at 2500base-X, but reports 1000BASE-LX / 1300MBd in its
+ // EEPROM
+ SFP_QUIRK("Hisense-Leox", "LXT-010S-H", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // Hisense ZNID-GPON-2311NA can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("Hisense", "ZNID-GPON-2311NA", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // HSGQ HSGQ-XPON-Stick can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("HSGQ", "HSGQ-XPON-Stick", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
// Lantech 8330-262D-E and 8330-265D can operate at 2500base-X, but
// incorrectly report 2500MBd NRZ in their EEPROM.
// Some 8330-265D modules have inverted LOS, while all of them report
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v10 net-next 2/5] psp: add new netlink cmd for dev-assoc and dev-disassoc
From: Daniel Zahka @ 2026-04-06 13:27 UTC (permalink / raw)
To: Wei Wang, netdev, Jakub Kicinski, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman
Cc: Wei Wang
In-Reply-To: <20260405055853.3285534-3-weibunny.kernel@gmail.com>
On 4/5/26 1:58 AM, Wei Wang wrote:
> From: Wei Wang <weibunny@fb.com>
>
> The main purpose of this cmd is to be able to associate a
> non-psp-capable device (e.g. veth or netkit) with a psp device.
> One use case is if we create a pair of veth/netkit, and assign 1 end
> inside a netns, while leaving the other end within the default netns,
> with a real PSP device, e.g. netdevsim or a physical PSP-capable NIC.
> With this command, we could associate the veth/netkit inside the netns
> with PSP device, so the virtual device could act as PSP-capable device
> to initiate PSP connections, and performs PSP encryption/decryption on
> the real PSP device.
>
> Signed-off-by: Wei Wang <weibunny@fb.com>
> ---
> Documentation/netlink/specs/psp.yaml | 67 +++++-
> include/net/psp/types.h | 15 ++
> include/uapi/linux/psp.h | 13 ++
> net/psp/psp-nl-gen.c | 32 +++
> net/psp/psp-nl-gen.h | 2 +
> net/psp/psp_main.c | 20 ++
> net/psp/psp_nl.c | 319 ++++++++++++++++++++++++++-
> 7 files changed, 457 insertions(+), 11 deletions(-)
>
...
>
> +/**
> + * Admin version of psp_device_get_locked() where it returns psd only if
> + * current netns is the same as psd->main_netdev's netns.
> + */
> int psp_device_get_locked_admin(const struct genl_split_ops *ops,
> struct sk_buff *skb, struct genl_info *info)
> {
> return __psp_device_get_locked(ops, skb, info, true);
> }
>
> +/**
> + * Non-admin version of psp_device_get_locked() where it returns psd in netns
> + * for not only psd->main_netdev but all netdevs in psd->assoc_dev_list.
> + */
> int psp_device_get_locked(const struct genl_split_ops *ops,
> struct sk_buff *skb, struct genl_info *info)
> {
> @@ -103,11 +179,74 @@ psp_device_unlock(const struct genl_split_ops *ops, struct sk_buff *skb,
> sockfd_put(socket);
> }
There's a warning that these comments have the kdoc open sequence, but
are not proper kdoc comments.
> +
> static int
> psp_nl_dev_fill(struct psp_dev *psd, struct sk_buff *rsp,
> const struct genl_info *info)
> {
> + struct net *cur_net;
> void *hdr;
> + int err;
> +
> + cur_net = genl_info_net(info);
> +
> + /* Skip this device if we're in an associated netns but have no
> + * associated devices in cur_net
> + */
> + if (cur_net != dev_net(psd->main_netdev) &&
> + !psp_has_assoc_dev_in_ns(psd, cur_net))
> + return 0;
>
Is this branch dead code given we either arrived here via
psp_dev_check_access(), or psp_nl_build_dev_ntf() which should only use
associated netns's?
>
> +int psp_nl_dev_assoc_doit(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct psp_dev *psd = info->user_ptr[0];
> + struct psp_assoc_dev *psp_assoc_dev;
> + struct net_device *assoc_dev;
> + struct sk_buff *rsp;
> + u32 assoc_ifindex;
> + struct net *net;
> + int nsid;
> +
> + if (GENL_REQ_ATTR_CHECK(info, PSP_A_DEV_IFINDEX))
> + return -EINVAL;
> +
> + if (info->attrs[PSP_A_DEV_NSID]) {
> + nsid = nla_get_s32(info->attrs[PSP_A_DEV_NSID]);
> +
> + net = get_net_ns_by_id(genl_info_net(info), nsid);
> + if (!net) {
> + NL_SET_BAD_ATTR(info->extack,
> + info->attrs[PSP_A_DEV_NSID]);
> + return -EINVAL;
> + }
> + } else {
> + net = get_net(genl_info_net(info));
> + }
> +
> + psp_assoc_dev = kzalloc(sizeof(*psp_assoc_dev), GFP_KERNEL);
> + if (!psp_assoc_dev) {
> + put_net(net);
> + return -ENOMEM;
> + }
> +
> + assoc_ifindex = nla_get_u32(info->attrs[PSP_A_DEV_IFINDEX]);
> + assoc_dev = netdev_get_by_index(net, assoc_ifindex,
> + &psp_assoc_dev->dev_tracker,
> + GFP_KERNEL);
> + if (!assoc_dev) {
> + put_net(net);
> + kfree(psp_assoc_dev);
> + NL_SET_BAD_ATTR(info->extack, info->attrs[PSP_A_DEV_IFINDEX]);
> + return -ENODEV;
> + }
> +
> + /* Check if device is already associated with a PSP device */
> + if (cmpxchg(&assoc_dev->psp_dev, NULL, RCU_INITIALIZER(psd))) {
> + NL_SET_ERR_MSG(info->extack,
> + "Device already associated with a PSP device");
> + netdev_put(assoc_dev, &psp_assoc_dev->dev_tracker);
> + put_net(net);
> + kfree(psp_assoc_dev);
> + return -EBUSY;
> + }
> +
> + psp_assoc_dev->assoc_dev = assoc_dev;
> + rsp = psp_nl_reply_new(info);
> + if (!rsp) {
> + rcu_assign_pointer(assoc_dev->psp_dev, NULL);
> + netdev_put(assoc_dev, &psp_assoc_dev->dev_tracker);
> + put_net(net);
> + kfree(psp_assoc_dev);
> + return -ENOMEM;
> + }
> +
> + list_add_tail(&psp_assoc_dev->dev_list, &psd->assoc_dev_list);
> +
> + put_net(net);
> +
> + psp_nl_notify_dev(psd, PSP_CMD_DEV_CHANGE_NTF);
> +
> + return psp_nl_reply_send(rsp, info);
> +}
> +
This function could probably benefit from a goto style cleanup chain,
given the overlapping set of actions to unwind at each error.
>
> int psp_assoc_device_get_locked(const struct genl_split_ops *ops,
> @@ -320,7 +617,9 @@ int psp_assoc_device_get_locked(const struct genl_split_ops *ops,
>
> psd = psp_dev_get_for_sock(socket->sk);
> if (psd) {
> + mutex_lock(&psd->lock);
> err = psp_dev_check_access(psd, genl_info_net(info), false);
> + mutex_unlock(&psd->lock);
This looks like a "TOCTOU" issue on the mutable assoc_dev_list, but I
think it ends up being a benign race.
> if (err) {
> psp_dev_put(psd);
> psd = NULL;
Some minor comments, but otherwise:
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
^ permalink raw reply
* [PATCH net v2 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: Ao Zhou @ 2026-04-06 13:28 UTC (permalink / raw)
To: netdev, David Ahern
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Ido Schimmel, Jiri Pirko, Yifan Wu, Juefei Pu,
Yuan Tan, Xin Liu, Ao Zhou, Haoze Xie
In-Reply-To: <cover.1775062214.git.royenheart@gmail.com>
From: Haoze Xie <royenheart@gmail.com>
l3mdev_fib_table_rcu() assumes that any upper device observed for
an IFF_L3MDEV_SLAVE device is an L3 master and dereferences
master->l3mdev_ops unconditionally.
VRF slave setup sets IFF_L3MDEV_SLAVE before the upper link is fully
switched, so readers can transiently observe a non-L3 upper such as a
bridge and follow a NULL l3mdev_ops pointer. Require the current upper
to still be an L3 master before consulting its FIB table.
Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
---
changes in v2:
- point Fixes to the VRF slave ordering change identified by David Ahern
- add David Ahern's Reviewed-by trailer
net/l3mdev/l3mdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/l3mdev/l3mdev.c b/net/l3mdev/l3mdev.c
index 5432a5f2dfc8..b8a3030cb2c4 100644
--- a/net/l3mdev/l3mdev.c
+++ b/net/l3mdev/l3mdev.c
@@ -177,7 +177,7 @@ u32 l3mdev_fib_table_rcu(const struct net_device *dev)
const struct net_device *master;
master = netdev_master_upper_dev_get_rcu(_dev);
- if (master &&
+ if (master && netif_is_l3_master(master) &&
master->l3mdev_ops->l3mdev_fib_table)
tb_id = master->l3mdev_ops->l3mdev_fib_table(master);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Nicolai Buchwitz @ 2026-04-06 13:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Florian Fainelli,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <a1cf8f6a-b338-4dd7-aced-7e19e4d0fdb7@lunn.ch>
On 6.4.2026 15:17, Andrew Lunn wrote:
> On Mon, Apr 06, 2026 at 09:13:06AM +0200, Nicolai Buchwitz wrote:
>> Some PHYs implement autonomous EEE where the PHY manages EEE
>> independently
>
> I suppose we should discuss naming. As far as i know, IEEE 802.3 does
> not include this feature, so it does not provide a guide to how we
> should name it.
>
> In the past we have used SmartEEE, but that is Atheros's vendor
> name. Broadcom seem to call it AutoGrEEEn.
>
> Autonomous EEE seems like a reasonable name, and appears to be vendor
> agnostic. Are we happy with this?
"Autonomous EEE" works for me (obviously). It kinda describes what
happens (the PHY acts autonomously) without being tied to a specific
vendor's marketing name.
That said, I feel Russell's argument that it doesn't type well. But
even after some walks in the woods I wasn't able to come up with a
better name yet.
>
> What i guess is unclear is what part of the network stack is acting
> autonomously. In the context of a PHY driver op,
> .disable_autonomous_eee is clear. But when we go further to actually
> making use of it, do we need to report to user space if we are using
> IEEE 802.3 EEE or "autonomous EEE". But i guess it is no worse than
> SmartEEE or AutoGrEEEn which also make no indication where EEE is
> happening.
I think for now it's fine to not expose this. From the user's
perspective,
EEE is either on or off. Whether the PHY or MAC manages LPI is an
implementation detail. ethtool --set-eee should just do the right thing:
- MAC supports LPI: use MAC-managed EEE
- MAC doesn't, but PHY has autonomous EEE: use that instead
- Neither: EOPNOTSUPP
I don't think there's a meaningful use case for letting users choose
between the two. Or is there?
>
> Thoughts?
>
> Andrew
Nicolai
^ permalink raw reply
* Re: [PATCH] rxrpc/proc: size address buffers for %pISpc output
From: Pengpeng Hou @ 2026-04-06 9:00 UTC (permalink / raw)
To: David Howells, Marc Dionne
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-afs, netdev, linux-kernel, pengpeng
In-Reply-To: <20260404190004.4-rxrpc-proc-pengpeng@iscas.ac.cn>
Hi,
Thanks for confirming that.
That is very helpful. It matches the current-tree ISATAP case in
lib/vsprintf.c and confirms that the formatter ends up writing 51 bytes
including the trailing NUL into the existing 50-byte stack buffer.
I'll resend the patch with the changelog corrected to frame the proof
around the ISATAP case explicitly.
Thanks,
Pengpeng
^ permalink raw reply
* [PATCH v2] rxrpc/proc: size address buffers for %pISpc output
From: Pengpeng Hou @ 2026-04-06 8:40 UTC (permalink / raw)
To: David Howells, Marc Dionne
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-afs, netdev, linux-kernel, pengpeng
In-Reply-To: <20260404190004.4-rxrpc-proc-pengpeng@iscas.ac.cn>
The AF_RXRPC procfs helpers format local and remote socket addresses into
fixed 50-byte stack buffers with "%pISpc".
That is too small for the longest current-tree IPv6-with-port form the
formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a
dotted-quad tail not only for v4mapped addresses, but also for ISATAP
addresses via ipv6_addr_is_isatap().
As a result, a case such as
[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535
is possible with the current formatter. That is 50 visible characters, so
51 bytes including the trailing NUL, which does not fit in the existing
char[50] buffers used by net/rxrpc/proc.c.
Size the buffers from the formatter's maximum textual form and switch the
call sites to scnprintf().
Changes since v1:
- correct the changelog to cite the actual maximum current-tree case
explicitly
- frame the proof around the ISATAP formatting path instead of the earlier
mapped-v4 example
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
net/rxrpc/proc.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/net/rxrpc/proc.c b/net/rxrpc/proc.c
index 59292f7f9205..7925d4569776 100644
--- a/net/rxrpc/proc.c
+++ b/net/rxrpc/proc.c
@@ -10,6 +10,10 @@
#include <net/af_rxrpc.h>
#include "ar-internal.h"
+#define RXRPC_PROC_ADDRBUF_SIZE \
+ (sizeof("[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:255.255.255.255]") + \
+ sizeof(":12345"))
+
static const char *const rxrpc_conn_states[RXRPC_CONN__NR_STATES] = {
[RXRPC_CONN_UNUSED] = "Unused ",
[RXRPC_CONN_CLIENT_UNSECURED] = "ClUnsec ",
@@ -53,7 +57,7 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
enum rxrpc_call_state state;
rxrpc_seq_t tx_bottom;
- char lbuff[50], rbuff[50];
+ char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
long timeout = 0;
if (v == &rxnet->calls) {
@@ -69,11 +73,11 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
local = call->local;
if (local)
- sprintf(lbuff, "%pISpc", &local->srx.transport);
+ scnprintf(lbuff, sizeof(lbuff), "%pISpc", &local->srx.transport);
else
strcpy(lbuff, "no_local");
- sprintf(rbuff, "%pISpc", &call->dest_srx.transport);
+ scnprintf(rbuff, sizeof(rbuff), "%pISpc", &call->dest_srx.transport);
state = rxrpc_call_state(call);
if (state != RXRPC_CALL_SERVER_PREALLOC)
@@ -142,7 +146,7 @@ static int rxrpc_connection_seq_show(struct seq_file *seq, void *v)
struct rxrpc_connection *conn;
struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
const char *state;
- char lbuff[50], rbuff[50];
+ char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
if (v == &rxnet->conn_proc_list) {
seq_puts(seq,
@@ -161,8 +165,8 @@ static int rxrpc_connection_seq_show(struct seq_file *seq, void *v)
goto print;
}
- sprintf(lbuff, "%pISpc", &conn->local->srx.transport);
- sprintf(rbuff, "%pISpc", &conn->peer->srx.transport);
+ scnprintf(lbuff, sizeof(lbuff), "%pISpc", &conn->local->srx.transport);
+ scnprintf(rbuff, sizeof(rbuff), "%pISpc", &conn->peer->srx.transport);
print:
state = rxrpc_is_conn_aborted(conn) ?
rxrpc_call_completions[conn->completion] :
@@ -228,7 +232,7 @@ static int rxrpc_bundle_seq_show(struct seq_file *seq, void *v)
{
struct rxrpc_bundle *bundle;
struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
- char lbuff[50], rbuff[50];
+ char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
if (v == &rxnet->bundle_proc_list) {
seq_puts(seq,
@@ -242,8 +246,8 @@ static int rxrpc_bundle_seq_show(struct seq_file *seq, void *v)
bundle = list_entry(v, struct rxrpc_bundle, proc_link);
- sprintf(lbuff, "%pISpc", &bundle->local->srx.transport);
- sprintf(rbuff, "%pISpc", &bundle->peer->srx.transport);
+ scnprintf(lbuff, sizeof(lbuff), "%pISpc", &bundle->local->srx.transport);
+ scnprintf(rbuff, sizeof(rbuff), "%pISpc", &bundle->peer->srx.transport);
seq_printf(seq,
"UDP %-47.47s %-47.47s %4x %3u %3d"
" %c%c%c %08x | %08x %08x %08x %08x %08x\n",
@@ -279,7 +283,7 @@ static int rxrpc_peer_seq_show(struct seq_file *seq, void *v)
{
struct rxrpc_peer *peer;
time64_t now;
- char lbuff[50], rbuff[50];
+ char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
if (v == SEQ_START_TOKEN) {
seq_puts(seq,
@@ -290,9 +294,9 @@ static int rxrpc_peer_seq_show(struct seq_file *seq, void *v)
peer = list_entry(v, struct rxrpc_peer, hash_link);
- sprintf(lbuff, "%pISpc", &peer->local->srx.transport);
+ scnprintf(lbuff, sizeof(lbuff), "%pISpc", &peer->local->srx.transport);
- sprintf(rbuff, "%pISpc", &peer->srx.transport);
+ scnprintf(rbuff, sizeof(rbuff), "%pISpc", &peer->srx.transport);
now = ktime_get_seconds();
seq_printf(seq,
@@ -401,7 +405,7 @@ const struct seq_operations rxrpc_peer_seq_ops = {
static int rxrpc_local_seq_show(struct seq_file *seq, void *v)
{
struct rxrpc_local *local;
- char lbuff[50];
+ char lbuff[RXRPC_PROC_ADDRBUF_SIZE];
if (v == SEQ_START_TOKEN) {
seq_puts(seq,
@@ -412,7 +416,7 @@ static int rxrpc_local_seq_show(struct seq_file *seq, void *v)
local = hlist_entry(v, struct rxrpc_local, link);
- sprintf(lbuff, "%pISpc", &local->srx.transport);
+ scnprintf(lbuff, sizeof(lbuff), "%pISpc", &local->srx.transport);
seq_printf(seq,
"UDP %-47.47s %3u %3u %3u\n",
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Mark Brown @ 2026-04-06 13:39 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Fernando Fernandez Mancera, Linux Kernel Mailing List,
Linux Next Mailing List, Yiqi Sun
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/icmp.c
between commit:
fde29fd934932 ("ipv4: icmp: fix null-ptr-deref in icmp_build_probe()")
from the net tree and commit:
d98adfbdd5c01 ("ipv4: drop ipv6_stub usage and use direct function calls")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc net/ipv4/icmp.c
index 4e2a6c70dcd84,2f4fac22d1aba..0000000000000
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@@ -1345,14 -1342,7 +1342,15 @@@ bool icmp_build_probe(struct sk_buff *s
case ICMP_AFI_IP6:
if (iio->ident.addr.ctype3_hdr.addrlen != sizeof(struct in6_addr))
goto send_mal_query;
- dev = ipv6_stub->ipv6_dev_find(net, &iio->ident.addr.ip_addr.ipv6_addr, dev);
+ dev = ipv6_dev_find(net, &iio->ident.addr.ip_addr.ipv6_addr, dev);
++
+ /*
+ * If IPv6 identifier lookup is unavailable, silently
+ * discard the request instead of misreporting NO_IF.
+ */
+ if (IS_ERR(dev))
+ return false;
+
dev_hold(dev);
break;
#endif
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: stmmac: dwmac-motorcomm: fix eFUSE MAC address read failure
From: Andrew Lunn @ 2026-04-06 13:41 UTC (permalink / raw)
To: Johan Alvarado
Cc: me, davem, kuba, pabeni, edumazet, ggo, andrew+netdev, netdev,
linux-kernel
In-Reply-To: <fc5992a4-9532-49c3-8ec1-c2f8c5b84ca1@smtp-relay.sendinblue.com>
> motorcomm_reset(priv);
>
> + /*
> + * After system reset, the eFuse controller needs time to load
> + * its internal data. Without this delay, eFuse reads return
> + * all zeros, causing MAC address detection to fail.
> + */
> + usleep_range(2000, 5000);
> +
This seems reasonable. My only comment is maybe this should be inside
motorcomm_reset(). But i don't have a strong opinion.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v2] mptcp: fix slab-use-after-free in __inet_lookup_established
From: Matthieu Baerts @ 2026-04-06 13:42 UTC (permalink / raw)
To: Jiayuan Chen
Cc: stable, Mat Martineau, Geliang Tang, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, netdev,
linux-kernel, mptcp
In-Reply-To: <20260406031512.189159-1-jiayuan.chen@linux.dev>
Hi Jiayuan,
On 06/04/2026 05:15, Jiayuan Chen wrote:
> The ehash table lookups are lockless and rely on
> SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability
> during RCU read-side critical sections. Both tcp_prot and
> tcpv6_prot have their slab caches created with this flag
> via proto_register().
>
> However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into
> tcpv6_prot_override during inet_init() (fs_initcall, level 5),
> before inet6_init() (module_init/device_initcall, level 6) has
> called proto_register(&tcpv6_prot). At that point,
> tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab
> remains NULL permanently.
>
> This causes MPTCP v6 subflow child sockets to be allocated via
> kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab
> cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so
> when these sockets are freed without SOCK_RCU_FREE (which is
> cleared for child sockets by design), the memory can be
> immediately reused. Concurrent ehash lookups under
> rcu_read_lock can then access freed memory, triggering a
> slab-use-after-free in __inet_lookup_established.
>
> Fix this by splitting the IPv6-specific initialization out of
> mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called
> from mptcp_proto_v6_init() before protocol registration. This
> ensures tcpv6_prot_override.slab correctly inherits the
> SLAB_TYPESAFE_BY_RCU slab cache.
Thank you for this v2, it looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
@Netdev maintainers: this patch can be applied in 'net' directly.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG
From: Simon Horman @ 2026-04-06 13:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Kuniyuki Iwashima,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <20260403022443.3480770-1-edumazet@google.com>
On Fri, Apr 03, 2026 at 02:24:43AM +0000, Eric Dumazet wrote:
> ipvlan and macvlan use queues to process broadcast or multicast packets
> from a work queue.
>
> Under attack these queues can drop packets.
>
> Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
>
> Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
>
> Also change ipvlan_rcv_frame() to use SKB_DROP_REASON_DEV_READY
> when the device is not UP.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net 1/1] batman-adv: hold claim backbone gateways by reference
From: Sven Eckelmann @ 2026-04-06 13:50 UTC (permalink / raw)
To: b.a.t.m.a.n, netdev, Ao Zhou
Cc: Marek Lindner, Simon Wunderlich, Antonio Quartulli,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn, Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu,
Ao Zhou, Haoze Xie
In-Reply-To: <4a58d2daef70ac17bb9be1f244a182439d5c4d63.1775301426.git.royenheart@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Monday, 6 April 2026 15:17:28 CEST Ao Zhou wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> batadv_bla_add_claim() can replace claim->backbone_gw and drop the old
> gateway's last reference while readers still follow the pointer.
>
> The netlink claim dump path dereferences claim->backbone_gw->orig and
> takes claim->backbone_gw->crc_lock without pinning the underlying
> backbone gateway. batadv_bla_check_claim() still has the same naked
> pointer access pattern.
>
> Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate
> on a stable gateway reference until the read-side work is complete.
> This keeps the dump and claim-check paths aligned with the lifetime
> rules introduced for the other BLA claim readers.
>
> Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
> Fixes: 04f3f5bf1883 ("batman-adv: add B.A.T.M.A.N. Dump BLA claims via netlink")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Signed-off-by: Haoze Xie <royenheart@gmail.com>
> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> ---
> net/batman-adv/bridge_loop_avoidance.c | 27 +++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
Applied, thanks!
[1/1] batman-adv: hold claim backbone gateways by reference
https://git.open-mesh.org/linux-merge.git/commit/?h=batadv/net&id=82d8701b2c930d0e96b0dbc9115a218d791cb0d2
Best regards,
---
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Ren Wei @ 2026-04-06 13:53 UTC (permalink / raw)
To: netdev
Cc: kuniyu, davem, edumazet, kuba, pabeni, horms, xemul, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, wangjiexun2025, n05ec
In-Reply-To: <cover.1775207252.git.wangjiexun2025@gmail.com>
From: Jiexun Wang <wangjiexun2025@gmail.com>
Exact UNIX diag lookups hold a reference to the socket, but not to
u->path. Meanwhile, unix_release_sock() clears u->path under
unix_state_lock() and drops the path reference after unlocking.
Read the inode and device numbers for UNIX_DIAG_VFS while holding
unix_state_lock(), then emit the netlink attribute after dropping the
lock.
This keeps the VFS data stable while the reply is being built.
Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/unix/diag.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/unix/diag.c b/net/unix/diag.c
index ca3473026151..76b2c48137dd 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -28,18 +28,23 @@ static int sk_diag_dump_name(struct sock *sk, struct sk_buff *nlskb)
static int sk_diag_dump_vfs(struct sock *sk, struct sk_buff *nlskb)
{
- struct dentry *dentry = unix_sk(sk)->path.dentry;
+ struct dentry *dentry;
+ struct unix_diag_vfs uv;
+ bool have_vfs = false;
+ unix_state_lock(sk);
+ dentry = unix_sk(sk)->path.dentry;
if (dentry) {
- struct unix_diag_vfs uv = {
- .udiag_vfs_ino = d_backing_inode(dentry)->i_ino,
- .udiag_vfs_dev = dentry->d_sb->s_dev,
- };
-
- return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
+ uv.udiag_vfs_ino = d_backing_inode(dentry)->i_ino;
+ uv.udiag_vfs_dev = dentry->d_sb->s_dev;
+ have_vfs = true;
}
+ unix_state_unlock(sk);
- return 0;
+ if (!have_vfs)
+ return 0;
+
+ return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
}
static int sk_diag_dump_peer(struct sock *sk, struct sk_buff *nlskb)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Andrew Lunn @ 2026-04-06 13:56 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Florian Fainelli,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <9272c5dd653039b3def8caaea3e631c5@tipi-net.de>
> "Autonomous EEE" works for me (obviously). It kinda describes what
> happens (the PHY acts autonomously) without being tied to a specific
> vendor's marketing name.
>
> That said, I feel Russell's argument that it doesn't type well. But
> even after some walks in the woods I wasn't able to come up with a
> better name yet.
Yes, naming is hard.
> I don't think there's a meaningful use case for letting users choose
> between the two. Or is there?
This has come up before, in other context. PTP is one example, where
both the MAC and the PHY can implement it. Ideally, you want it to
happen at the PHY, it gives higher accuracy. But there are systems
where the PHY implementation is somewhat broken, and the MAC PTP gives
better results. So defaulting to PHY PTP is not always the best
option.
I would expect IEEE 802.3 EEE, with both the MAC and PHY cooperating
is better than just PHY level EEE, the system as a whole has a better
picture of what is going on, so using 802.3 EEE should be the
preference/default. But are we going to run into oddball systems where
autonomous EEE is actually better than using a somewhat broke MAC?
Andrew
^ 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