* Re: [Intel-wired-lan] [PATCH iwl-net v5] ice: fix missing dpll notifications for SW pins
From: Jacob Keller @ 2026-04-14 20:46 UTC (permalink / raw)
To: Michal Schmidt, Petr Oros, netdev
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arkadiusz Kubalewski, intel-wired-lan, linux-kernel
In-Reply-To: <68b5cc9d-81d2-4ff5-9d3e-a6d6746dcb3e@redhat.com>
On 4/14/2026 12:16 PM, Michal Schmidt wrote:
> On 4/9/26 12:25, Petr Oros wrote:
>> ---
>> drivers/net/ethernet/intel/ice/ice_dpll.c | 74 +++++++++++++++++++----
>> 1 file changed, 63 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/
>> ethernet/intel/ice/ice_dpll.c
>> index 3f8cd5b8298b57..d817f17dcf1951 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_dpll.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
>> @@ -1154,6 +1154,30 @@ ice_dpll_input_state_get(const struct dpll_pin
>> *pin, void *pin_priv,
>> extack, ICE_DPLL_PIN_TYPE_INPUT);
>> }
>> +/**
>> + * ice_dpll_sw_pin_notify_peer - notify the paired SW pin after a
>> state change
>> + * @d: pointer to dplls struct
>> + * @changed: the SW pin that was explicitly changed (already notified
>> by dpll core)
>> + *
>> + * SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1
>> and
>> + * SMA2/U.FL2). When one pin's routing changes via the PCA9575 GPIO
>> + * expander, the paired pin's state may also change. Send a change
>> + * notification for the peer pin so userspace consumers monitoring the
>> + * peer via dpll netlink learn about the update.
>> + *
>> + * Context: Can be called under pf->dplls.lock, dpll_pin_change_ntf()
>> is safe.
>> + */
>> +static void ice_dpll_sw_pin_notify_peer(struct ice_dplls *d,
>> + struct ice_dpll_pin *changed)
>> +{
>> + struct ice_dpll_pin *peer;
>> +
>> + peer = (changed >= d->sma && changed < d->sma +
>> ICE_DPLL_PIN_SW_NUM) ?
>> + &d->ufl[changed->idx] : &d->sma[changed->idx];
>> + if (peer->pin)
>> + dpll_pin_change_ntf(peer->pin);
>> +}
>> +
>> /**
>> * ice_dpll_sma_direction_set - set direction of SMA pin
>> * @p: pointer to a pin
>> @@ -1233,6 +1257,8 @@ static int ice_dpll_sma_direction_set(struct
>> ice_dpll_pin *p,
>> ret = ice_dpll_pin_state_update(p->pf, target,
>> type, extack);
>> }
>> + if (!ret)
>> + ice_dpll_sw_pin_notify_peer(d, p);
>> return ret;
>> }
>
> ice_dpll_sma_direction_set() runs to process a DPLL_CMD_PIN_SET command
> from userspace. It runs with dpll_lock held - taken in dpll_pin_pre_doit().
> ice_dpll_sw_pin_notify_peer() -> dpll_pin_change_ntf() will take
> dpll_lock again and deadlock.
>
Yep. I think you could use __dpll_pin_change_ntf() which is the version
that assumes the lock is held.. but that function is not exported
outside of drivers/dpll.
Either way, this needs to be fixed somehow before I can apply it.
Thanks,
Jake
> Michal
>
^ permalink raw reply
* Re: [RFC PATCH 2/4] nfs: add NFS_CAP_P2PDMA and detect transport support
From: Chuck Lever @ 2026-04-14 20:59 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Trond Myklebust, Anna Schumaker, davem, Jakub Kicinski, edumazet,
Paolo Abeni, Chuck Lever, Jeff Layton, Tom Talpey,
Olga Kornievskaia, NeilBrown, Dai Ngo, linux-nfs, netdev
In-Reply-To: <ad6bkyA1ItA8ou9i@google.com>
On Tue, Apr 14, 2026, at 12:54 PM, Pranjal Shrivastava wrote:
> On Thu, Apr 02, 2026 at 09:11:04AM -0400, Chuck Lever wrote:
>>
>> On Wed, Apr 1, 2026, at 3:44 PM, Pranjal Shrivastava wrote:
>> > The NFS server capabilities bitmask (server->caps) is currently full,
>> > utilizing all 32 bits of the existing unsigned int. Expand the bitmask
>> > to 64 bits (u64) to allow for new feature flags.
>> >
>> > Introduce a new capability bit, NFS_CAP_P2PDMA, to indicate that the
>> > local mount is backed by hardware and a transport capable of PCI
>> > Peer-to-Peer DMA.
>> >
>> > Update nfs_server_set_init_caps() to query the underlying SunRPC
>> > transport for P2PDMA support during the mount process. If the transport
>> > (e.g., RDMA) signals support, set the NFS_CAP_P2PDMA bit in the mount's
>> > capabilities. This allows the high-performance Direct I/O path to
>> > efficiently determine if it should allow P2P memory buffers.
>>
>> > diff --git a/fs/nfs/client.c b/fs/nfs/client.c
>> > index be02bb227741..f177cf098d44 100644
>> > --- a/fs/nfs/client.c
>> > +++ b/fs/nfs/client.c
>>
>> > @@ -725,6 +727,12 @@ void nfs_server_set_init_caps(struct nfs_server *server)
>> > nfs4_server_set_init_caps(server);
>> > break;
>> > }
>> > +
>> > + rcu_read_lock();
>> > + xprt = rcu_dereference(server->client->cl_xprt);
>> > + if (xprt->ops->supports_p2pdma && xprt->ops->supports_p2pdma(xprt))
>> > + server->caps |= NFS_CAP_P2PDMA;
>> > + rcu_read_unlock();
>> > }
>> > EXPORT_SYMBOL_GPL(nfs_server_set_init_caps);
>>
>> Is the transport even connected when the NFS client does this
>> test? If it isn't, xprtrdma and the RDMA core have not chosen
>> an underlying device yet.
>>
>> Note that, even if this logic /is/ correct, if the transport
>> connection is lost the transport will reconnect automatically,
>> doing the RDMA CM dance again and possibly resolving to a
>> different device. The NFS client layer will be none-the-wiser
>> and the NFS_CAP_P2PDMA flag setting will be stale at that point,
>> and quite possibly incorrect if the new connection's device is
>> not P2P-enabled.
>>
>> (Basically this is what happens when an RDMA device is removed).
>>
>> So this detection has to be done as part of xprtrdma's connection
>> flow, and it needs to set a flag somewhere in the rpc_xprt. The
>> NFS direct I/O code path then has to look for that flag before
>> choosing the mechanism/flags it uses for each iov iter.
>>
>
> Ack. I agree, so should we start with an inital cap and then update it
> in the event of a transport change / disconnect? Or shall we populate
> the cap only when a transport is connected?
IMO this flag does not belong in the NFS server CAPS, as it is a
capability associated with each RPC transport. How should
NFS_CAP_P2PDMA be set if there are two RPC transports, one with
P2PDMA enabled and with it disabled? (Perhaps it should be a flag
in the transport switch instance rather than the transport instance).
Which mechanism to use has to be re-decided every time a dreq is
scheduled because the xprt can change between an original send
and a retransmission (if, say, the COMMIT verifier changes due to
a server reboot).
Trond and Anna will have the final say about how this works.
--
Chuck Lever
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] dpf: fix UAF and double free in idpf_plug_vport_aux_dev() error path
From: Jacob Keller @ 2026-04-14 21:02 UTC (permalink / raw)
To: Guangshuo Li, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Joshua Hay, Tatyana Nikolova, Madhu Chittim, intel-wired-lan,
netdev, linux-kernel, Greg Kroah-Hartman
Cc: stable
In-Reply-To: <20260413112030.2694563-1-lgs201920130244@gmail.com>
On 4/13/2026 4:20 AM, Guangshuo Li wrote:
> If auxiliary_device_add() fails, idpf_plug_vport_aux_dev() calls
> auxiliary_device_uninit(adev), whose release callback
> idpf_vport_adev_release() frees the containing
> struct iidc_rdma_vport_auxiliary_dev.
>
> The current error path then accesses adev->id and later frees iadev
> again, which may lead to a use-after-free and double free.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fix it by storing the allocated auxiliary device id in a local
> variable and avoiding direct freeing of iadev after
> auxiliary_device_uninit().
>
> Fixes: be91128c579c ("idpf: implement RDMA vport auxiliary dev create, init, and destroy")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
This doesn't look right. The commit message analysis seems to match this
fix from Greg KH:
https://lore.kernel.org/intel-wired-lan/2026041432-tapestry-condition-22ff@gregkh/
But the changes do not make any sense to me. It looks like a poorly done
AI-generated "fix" which is not correct. Greg's version does look like
it properly resolves this.
> v2:
> - note that the issue was identified by my static analysis tool
> - and confirmed by manual review
>
What even is this change log?? I see that version was sent and everyone
else was sane enough to just silently reject or ignore the v1...
> drivers/net/ethernet/intel/idpf/idpf_idc.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> index 6dad0593f7f2..2a18907643fc 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> @@ -59,6 +59,7 @@ static int idpf_plug_vport_aux_dev(struct iidc_rdma_core_dev_info *cdev_info,
> char name[IDPF_IDC_MAX_ADEV_NAME_LEN];
> struct auxiliary_device *adev;
> int ret;
> + int adev_id;
>
You create a local variable here...
> iadev = kzalloc(sizeof(*iadev), GFP_KERNEL);
> if (!iadev)
> @@ -74,11 +75,14 @@ static int idpf_plug_vport_aux_dev(struct iidc_rdma_core_dev_info *cdev_info,
> goto err_ida_alloc;
> }
> adev->id = ret;
> + adev->id = adev_id;
adev_is is never initialized, so you assign a random garbage
uninitialized value. This is obviously wrong and will lead to worse
errors than the failed cleanup.
I'm rejecting this patch in favor of the clearly appropriate fix from Greg.
> adev->dev.release = idpf_vport_adev_release;
> adev->dev.parent = &cdev_info->pdev->dev;
> sprintf(name, "%04x.rdma.vdev", cdev_info->pdev->vendor);
> adev->name = name;
>
> + /* iadev is owned by the auxiliary device */
> + iadev = NULL;> ret = auxiliary_device_init(adev);
> if (ret)
> goto err_aux_dev_init;
> @@ -92,7 +96,7 @@ static int idpf_plug_vport_aux_dev(struct iidc_rdma_core_dev_info *cdev_info,
> err_aux_dev_add:
> auxiliary_device_uninit(adev);
> err_aux_dev_init:
> - ida_free(&idpf_idc_ida, adev->id);
> + ida_free(&idpf_idc_ida, adev_id);
> err_ida_alloc:
> vdev_info->adev = NULL;
> kfree(iadev);
^ permalink raw reply
* Re: [PATCH iwl-next v2 2/2] idpf: implement pci error handlers
From: Tantilov, Emil S @ 2026-04-14 21:42 UTC (permalink / raw)
To: Lukas Wunner, Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Kitszel, Przemyslaw, Bhat, Jay, Barrera, Ivan D, Zaremba, Larysa,
Nguyen, Anthony L, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
Lobakin, Aleksander, linux-pci@vger.kernel.org, Chittim, Madhu,
decot@google.com, willemb@google.com, sheenamo@google.com
In-Reply-To: <ad5Y-gNBDvns-WAE@wunner.de>
On 4/14/2026 8:10 AM, Lukas Wunner wrote:
> On Tue, Apr 14, 2026 at 11:09:05AM +0000, Loktionov, Aleksandr wrote:
>>> From: Tantilov, Emil S <emil.s.tantilov@intel.com>
>>> .slot_reset is the callback attempting to restore the device, provided
>>> a PCI reset was initiated by the AER driver.
>
> Just for clarity, those callbacks are invoked by PCI core error handling
> code and are shared by EEH, AER, DPC as well as s390 error recovery flows.
> So it's not only AER.
Understood. I can change the wording to be more generic.
>
>>> +/**
>>> + * idpf_pci_err_resume - Resume operations after PCI error recovery
>>> + * @pdev: PCI device struct
>>> + */
>>> +static void idpf_pci_err_resume(struct pci_dev *pdev) {
>>> + struct idpf_adapter *adapter = pci_get_drvdata(pdev);
>>> +
>>> + /* Force a PFR when resuming from PCI error. */
>>> + if (test_and_set_bit(IDPF_PCI_CB_RESET, adapter->flags))
>>> + adapter->dev_ops.reg_ops.trigger_reset(adapter,
>>> IDPF_HR_FUNC_RESET);
>>
>> You say "Force a PFR", but PFR is only triggered on the AER path,
>> not on the FLR path.
>
> And? idpf_pci_err_resume() is only invoked in the error recovery path
> (aka AER path), not FLR path AFAICS.
The driver calls is in idpf_pci_err_reset_done():
<...>-86378 [009] ..... 342752.746321: idpf_pci_err_reset_prepare
<-pci_dev_save_and_disable
bash-86378 [045] ..... 342756.748148: idpf_pci_err_reset_done
<-pci_reset_function
bash-86378 [045] ..... 342756.748272: idpf_pci_err_resume
<-pci_reset_function
Thanks,
Emil
>
> Thanks,
>
> Lukas
^ permalink raw reply
* Re: [PATCH iwl-next v2 2/2] idpf: implement pci error handlers
From: Tantilov, Emil S @ 2026-04-14 21:43 UTC (permalink / raw)
To: Lukas Wunner
Cc: intel-wired-lan, netdev, przemyslaw.kitszel, jay.bhat,
ivan.d.barrera, aleksandr.loktionov, larysa.zaremba,
anthony.l.nguyen, andrew+netdev, davem, edumazet, kuba, pabeni,
aleksander.lobakin, linux-pci, madhu.chittim, decot, willemb,
sheenamo
In-Reply-To: <ad5ZoDCuSsPW0lKo@wunner.de>
On 4/14/2026 8:13 AM, Lukas Wunner wrote:
> On Mon, Apr 13, 2026 at 08:16:31PM -0700, Emil Tantilov wrote:
>> +static pci_ers_result_t
>> +idpf_pci_err_slot_reset(struct pci_dev *pdev)
>> +{
>> + struct idpf_adapter *adapter = pci_get_drvdata(pdev);
>> +
>> + pci_restore_state(pdev);
>> + pci_set_master(pdev);
>> + pci_wake_from_d3(pdev, false);
>> + if (readl(adapter->reset_reg.rstat) != 0xFFFFFFFF)
>> + return PCI_ERS_RESULT_RECOVERED;
>
> FWIW, there's a PCI_POSSIBLE_ERROR() helper that you may find useful
> to check for an "all ones" MMIO read.
Will check it out.
Thanks,
Emil
>
> Thanks,
>
> Lukas
^ permalink raw reply
* Re: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Jakub Kicinski @ 2026-04-14 21:58 UTC (permalink / raw)
To: Kubalewski, Arkadiusz
Cc: Nitka, Grzegorz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
Oros, Petr, richardcochran@gmail.com, andrew+netdev@lunn.ch,
Kitszel, Przemyslaw, Nguyen, Anthony L,
Prathosh.Satish@microchip.com, Vecera, Ivan, jiri@resnulli.us,
vadim.fedorenko@linux.dev, donald.hunter@gmail.com,
horms@kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com
In-Reply-To: <IA0PR11MB737882B384AE7279EBCD05C79B242@IA0PR11MB7378.namprd11.prod.outlook.com>
On Mon, 13 Apr 2026 08:19:30 +0000 Kubalewski, Arkadiusz wrote:
>> My concern is that I think this is a pretty run of the mill SyncE
>> design. If we need to pretend we have two DPLLs here if we really
>> only have one and a mux - then our APIs are mis-designed :(
>
> Well, the true is that we did not anticipated per-port control of the
> TX clock source, as a single DPLL device could drive multiple of such.
>
> This is not true, that we pretend there is a second PLL - there is a
> PLL on each TX clock, maybe not a full DPLL, but still the loop with
> a control over it's sources is there and it has the same 2 external
> sources + default XO.
Don't we put that MAC PLL into bypass mode if we feed a clock from
the EEC DPLL?
> A mentioned try of adding per port MUX-type pin, just to give some control
> to the user, is where we wanted to simplify things, but in the end the API
> would have to be modified in significant way, various paths related to pin
> registration and keeping correct references, just to make working case
> for the pin_on_pin_register and it's internals. We decided that the burden
> and impact for existing design was to high.
>
> And that is why the TXC approach emerged, the change of DPLL is minimal,
> The model is still correct from user perspective, SyncE SW controller shall
> anticipate possibility that per-port TXC dpll is there
We are starting to push into what was previously the domain of
drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
clock dividers. And cannot be "configured" after chip init / async
reset (which is why I presume you whack a reset in patch 7?).
> This particular device and driver doesn't implement any EEC-type DPLL
> device, the one could think that we can just change the type here and use
> EEC type instead of new one TXC - since we share pins from external dpll
> driver, which is EEC type, and our DPLL device would have different clock_id
> and module. But, further designs, where a single NIC is having control over
> both a EEC DPLL and ability to control each source per-port this would be
> problematic. At least one NIC Port driver would have to have 2 EEC-type DPLLs
> leaving user with extra confusion.
The distinction between TXC and EEC dpll is confusing.
I thought EEC one _was_supposed_to_ drive the Tx clock?
What PPS means is obvious, what EEC means if not driving Tx clock is
unclear to me..
Let me summarize my concerns - we need to navigate the split between
drivers/clk and dpll. We need a distinction on what goes where, because
every ASIC has a bunch of PLLs which until now have been controlled by
device tree (if at all). If the main question we want to answer is
"which clock ref is used to drive internal clock" all we need is a MUX.
If we want to make dpll cover also ASIC PLLs for platforms without
device tree we need a more generic name than TXC, IMHO.
^ permalink raw reply
* Re: [PATCH net v2 1/1] net: hsr: avoid learning unknown senders for local delivery
From: Yuan Tan @ 2026-04-14 23:05 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Felix Maurer, Ao Zhou
Cc: yuantan098, netdev, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Murali Karicheri,
Shaurya Rane, Ingo Molnar, Kees Cook, Yifan Wu, Juefei Pu,
Xin Liu, Yuqi Xu, Haoze Xie
In-Reply-To: <20260414145926.0Lwoa8ca@linutronix.de>
On 4/14/2026 7:59 AM, Sebastian Andrzej Siewior wrote:
> On 2026-04-08 12:40:15 [+0200], Felix Maurer wrote:
>> IMHO, the only real way to prevent excessive resource use on our side is
>> to put a limit on these resources. In this case, limit the size of the
>> node table (bonus: make that limit configurable as Paolo suggested).
> I am slowly catching up. There was no follow-up on this one, right?
Hi,
Thank you for checking in. Please excuse the delay as we are only able
to work on this part-time.
We are still refining the fix approach based on the recent feedback to
ensure the fix is suitable and robust.
Thanks for your patience.
Best,
Yuan
>> Thanks,
>> Felix
> Sebastian
^ permalink raw reply
* [PATCH net] net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops
From: Stanislav Fomichev @ 2026-04-14 23:10 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, andrew, olteanv, horms, sdf,
linux-kernel, Maxime Chevallier
DSA replaces the conduit (master) device's ethtool_ops with its own
wrappers that aggregate stats from both the conduit and DSA switch
ports. Taking the lock again inside the DSA wrappers causes a deadlock.
Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y
(which looks like some kind of testing device that auto-populates the ports
of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero
coverage for DSA stuff with real ops locked devs.
Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from
the DSA conduit ethtool wrappers.
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
Fixes: 2bcf4772e45a ("net: ethtool: try to protect all callback with netdev instance lock")
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
(cherry picked from commit 1538c00ab3212273240112bd53692d54d95f2dd5)
---
net/dsa/conduit.c | 16 +---------------
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/net/dsa/conduit.c b/net/dsa/conduit.c
index a1b044467bd6..8398d72d7e4d 100644
--- a/net/dsa/conduit.c
+++ b/net/dsa/conduit.c
@@ -27,9 +27,7 @@ static int dsa_conduit_get_regs_len(struct net_device *dev)
int len;
if (ops && ops->get_regs_len) {
- netdev_lock_ops(dev);
len = ops->get_regs_len(dev);
- netdev_unlock_ops(dev);
if (len < 0)
return len;
ret += len;
@@ -60,15 +58,11 @@ static void dsa_conduit_get_regs(struct net_device *dev,
int len;
if (ops && ops->get_regs_len && ops->get_regs) {
- netdev_lock_ops(dev);
len = ops->get_regs_len(dev);
- if (len < 0) {
- netdev_unlock_ops(dev);
+ if (len < 0)
return;
- }
regs->len = len;
ops->get_regs(dev, regs, data);
- netdev_unlock_ops(dev);
data += regs->len;
}
@@ -115,10 +109,8 @@ static void dsa_conduit_get_ethtool_stats(struct net_device *dev,
int count, mcount = 0;
if (ops && ops->get_sset_count && ops->get_ethtool_stats) {
- netdev_lock_ops(dev);
mcount = ops->get_sset_count(dev, ETH_SS_STATS);
ops->get_ethtool_stats(dev, stats, data);
- netdev_unlock_ops(dev);
}
list_for_each_entry(dp, &dst->ports, list) {
@@ -149,10 +141,8 @@ static void dsa_conduit_get_ethtool_phy_stats(struct net_device *dev,
if (count >= 0)
phy_ethtool_get_stats(dev->phydev, stats, data);
} else if (ops && ops->get_sset_count && ops->get_ethtool_phy_stats) {
- netdev_lock_ops(dev);
count = ops->get_sset_count(dev, ETH_SS_PHY_STATS);
ops->get_ethtool_phy_stats(dev, stats, data);
- netdev_unlock_ops(dev);
}
if (count < 0)
@@ -176,13 +166,11 @@ static int dsa_conduit_get_sset_count(struct net_device *dev, int sset)
struct dsa_switch_tree *dst = cpu_dp->dst;
int count = 0;
- netdev_lock_ops(dev);
if (sset == ETH_SS_PHY_STATS && dev->phydev &&
(!ops || !ops->get_ethtool_phy_stats))
count = phy_ethtool_get_sset_count(dev->phydev);
else if (ops && ops->get_sset_count)
count = ops->get_sset_count(dev, sset);
- netdev_unlock_ops(dev);
if (count < 0)
count = 0;
@@ -239,7 +227,6 @@ static void dsa_conduit_get_strings(struct net_device *dev, u32 stringset,
struct dsa_switch_tree *dst = cpu_dp->dst;
int count, mcount = 0;
- netdev_lock_ops(dev);
if (stringset == ETH_SS_PHY_STATS && dev->phydev &&
!ops->get_ethtool_phy_stats) {
mcount = phy_ethtool_get_sset_count(dev->phydev);
@@ -253,7 +240,6 @@ static void dsa_conduit_get_strings(struct net_device *dev, u32 stringset,
mcount = 0;
ops->get_strings(dev, stringset, data);
}
- netdev_unlock_ops(dev);
list_for_each_entry(dp, &dst->ports, list) {
if (!dsa_port_is_dsa(dp) && !dsa_port_is_cpu(dp))
--
2.52.0
^ permalink raw reply related
* [PATCH v5] net/mlx5: Fix PTP event stack info leak and NULL ptp_clock use
From: Prathamesh Deshpande @ 2026-04-14 23:19 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, Carolina Jubran
Cc: Jakub Kicinski, David S . Miller, Tariq Toukan, Richard Cochran,
Mark Bloch, netdev, linux-rdma, linux-kernel,
Prathamesh Deshpande
In mlx5_pps_event(), ptp_event is not zero-initialized. Since it contains
a union, partial assignment can leave stale stack data in unused members.
Also, clock->ptp may be NULL if ptp_clock_register() fails.
Fix by zero-initializing ptp_event, using a local timestamp variable for
event data assignment, and guarding ptp_clock_event() with a NULL check.
Fixes: 7c39afb394c7 ("net/mlx5: PTP code migration to driver core section")
Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
---
v5:
- Drop MAX_PIN_NUM check per review.
- Drop pin_config local guard to keep this revision narrowly scoped.
v4:
- Validate pin index against MAX_PIN_NUM instead of n_pins.
v3:
- Fix union corruption by using a local timestamp variable.
- Validate pin index against n_pins with WARN_ON_ONCE.
- Remove redundant pin < 0 check and cleanup TODO comment.
v2:
- Zero-initialize ptp_event to prevent stack information leak.
- Add bounds check for hardware pin index to prevent OOB access.
- Add NULL guard for pin_config to handle initialization failures.
- Add NULL check for clock->ptp as originally intended.
drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index bd4e042077af..77d7b81a0a25 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
@@ -1164,7 +1164,7 @@ static int mlx5_pps_event(struct notifier_block *nb,
pps_nb);
struct mlx5_core_dev *mdev = clock_state->mdev;
struct mlx5_clock *clock = mdev->clock;
- struct ptp_clock_event ptp_event;
+ struct ptp_clock_event ptp_event = {};
struct mlx5_eqe *eqe = data;
int pin = eqe->data.pps.pin;
unsigned long flags;
@@ -1173,7 +1173,7 @@ static int mlx5_pps_event(struct notifier_block *nb,
switch (clock->ptp_info.pin_config[pin].func) {
case PTP_PF_EXTTS:
ptp_event.index = pin;
- ptp_event.timestamp = mlx5_real_time_mode(mdev) ?
+ ns = mlx5_real_time_mode(mdev) ?
mlx5_real_time_cyc2time(clock,
be64_to_cpu(eqe->data.pps.time_stamp)) :
mlx5_timecounter_cyc2time(clock,
@@ -1181,12 +1181,13 @@ static int mlx5_pps_event(struct notifier_block *nb,
if (clock->pps_info.enabled) {
ptp_event.type = PTP_CLOCK_PPSUSR;
ptp_event.pps_times.ts_real =
- ns_to_timespec64(ptp_event.timestamp);
+ ns_to_timespec64(ns);
} else {
ptp_event.type = PTP_CLOCK_EXTTS;
+ ptp_event.timestamp = ns;
}
- /* TODOL clock->ptp can be NULL if ptp_clock_register fails */
- ptp_clock_event(clock->ptp, &ptp_event);
+ if (clock->ptp)
+ ptp_clock_event(clock->ptp, &ptp_event);
break;
case PTP_PF_PEROUT:
if (clock->shared) {
--
2.43.0
^ permalink raw reply related
* DMA issues with the SKGE drivers
From: Benoît Dufour @ 2026-04-14 23:23 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1425 bytes --]
In 2024, I reported a bug about the SKGE driver, you can see it here:
https://bugzilla.kernel.org/show_bug.cgi?id=219270
Basically, the problem is that the Marvell 88E8001 on my ASUS A8V
motherboard can only work with 32bit DMA, and if trying to use 64bit
DMA, the NIC won't work at all and after some time, the operating system
will become completely unresponsive (on screen tty will stop refresh,
keyboard and mouse input will stop working too).
The fix is quite easy:
At the very end of the SKGE driver source code, the ASUS A8V motherboard
(as well as many other boards like the ASUS A8V Deluxe) should be added
to the list of 32bit DMA boards:
https://github.com/torvalds/linux/blob/508fed6795411f5ab277fd1edc0d7adca4946f23/drivers/net/ethernet/marvell/skge.c#L4150
In the bug report I posted in 2024, I also posted a test case:
https://bugzilla.kernel.org/attachment.cgi?id=306873&action=diff
but actually I guess a better fix would be to dynamically testing if the
NIC support only 32bit or 64bit DMA too. If 64bit wouldn't be supported,
this error (or a similar one) should be reported by the card:
PCI error cmd=0x117 status=0x22b0
Do you think it would be doable?
p.s.:
I know that NIC and those motherboards are very old, but I really wish
those kinds of bugs should be fixed at some point.
--
Benoît Dufour
Unfortunately still a student in Computer Science
[-- Attachment #1.1.1.2: Type: text/html, Size: 2430 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3317 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v9 01/10] net: phy: phy_link_topology: Add a helper for opportunistic alloc
From: Andrew Lunn @ 2026-04-14 23:23 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, Jakub Kicinski, Eric Dumazet, Paolo Abeni, Russell King,
Heiner Kallweit, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <20260403123755.175742-2-maxime.chevallier@bootlin.com>
On Fri, Apr 03, 2026 at 02:37:45PM +0200, Maxime Chevallier wrote:
> The phy_link_topology structure stores information about the PHY-related
> components connected to a net_device. It is opportunistically allocated,
> when we add the first item to the topology, as this is not relevant for
> all kinds of net_devices.
>
> In preparation for the addition of phy_port tracking in the topology,
> let's make a dedicated helper for that allocation sequence.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [RFC PATCH net-next 0/2] udp: fix FOU/GUE over multicast
From: Anton Danilov @ 2026-04-14 23:24 UTC (permalink / raw)
To: netdev
Cc: willemdebruijn.kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, shuah, linux-kselftest
UDP encapsulation (FOU, GUE) has never worked correctly with multicast
destination addresses. When a FOU-encapsulated packet arrives at a
multicast address, it enters __udp4_lib_mcast_deliver() which calls
consume_skb() on packets that need resubmission to the inner protocol
handler, silently dropping them instead.
The unicast delivery path and the GSO segmentation path both handle
this correctly, but the multicast path was never updated to support
UDP encapsulation resubmit.
This causes silent packet loss for FOU/GRETAP tunnels configured with
multicast remote addresses. The loss ratio depends on the early demux
cache hit rate - packets that hit early demux bypass the multicast path
and work correctly, masking the issue.
Reproducing the issue:
ip netns add ns_a && ip netns add ns_b
ip link add veth0 type veth peer name veth1
ip link set veth0 netns ns_a && ip link set veth1 netns ns_b
ip -n ns_a addr add 10.0.0.1/24 dev veth0 && ip -n ns_a link set veth0 up
ip -n ns_b addr add 10.0.0.2/24 dev veth1 && ip -n ns_b link set veth1 up
# Disable early demux to expose the bug (otherwise it's partially masked)
ip netns exec ns_b sysctl -w net.ipv4.ip_early_demux=0
# Join multicast group
ip -n ns_b addr add 239.0.0.1/32 dev veth1 autojoin
# FOU + GRETAP with multicast remote
ip netns exec ns_b ip fou add port 4797 ipproto 47
ip -n ns_b link add eoudp0 type gretap \
remote 239.0.0.1 local 10.0.0.2 \
encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1
ip -n ns_b link set eoudp0 up
# Send FOU/GRE packets to 239.0.0.1:4797 from ns_a
# -> without this fix: 0 packets received on eoudp0
# -> with this fix: all packets received on eoudp0
AI assistance (Claude, claude-opus-4-6) was used during root cause
analysis of the kernel source code (tracing the call chain from
udp_queue_rcv_skb through encap_rcv to ip_protocol_deliver_rcu,
comparing unicast/GSO/multicast paths) and during patch and selftest
authoring. The fix approach was identified by observing that the
unicast path (udp_unicast_rcv_skb) and the GSO path
(udp_queue_rcv_skb) both already handle encap resubmit correctly,
while the multicast path did not.
Anton Danilov (2):
udp: fix encapsulation packet resubmit in multicast deliver
selftests: net: add FOU multicast encapsulation resubmit test
net/ipv4/udp.c | 13 +-
net/ipv6/udp.c | 13 +-
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/fou_mcast_encap.sh | 150 ++++++++++++++++++
4 files changed, 169 insertions(+), 8 deletions(-)
create mode 100755 tools/testing/selftests/net/fou_mcast_encap.sh
--
2.47.3
^ permalink raw reply
* [RFC PATCH net-next 1/2] udp: fix encapsulation packet resubmit in multicast deliver
From: Anton Danilov @ 2026-04-14 23:27 UTC (permalink / raw)
To: netdev
Cc: willemdebruijn.kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, shuah, linux-kselftest
In-Reply-To: <ad7MsSJOuUU6EGwS@dau-home-pc>
When a UDP encapsulation socket (e.g., FOU) receives a multicast
packet, __udp4_lib_mcast_deliver() and __udp6_lib_mcast_deliver()
incorrectly call consume_skb() when udp_queue_rcv_skb() returns a
positive value. A positive return value from udp_queue_rcv_skb()
indicates that the encap_rcv handler (e.g., fou_udp_recv) has
consumed the UDP header and wants the packet to be resubmitted to
the IP protocol handler for further processing (e.g., as a GRE
packet).
The unicast path in udp_unicast_rcv_skb() handles this correctly by
returning -ret, which propagates up to ip_protocol_deliver_rcu() for
resubmission. The GSO path in udp_queue_rcv_skb() also handles this
correctly by calling ip_protocol_deliver_rcu() directly. However, the
multicast path destroys the packet via consume_skb() instead of
resubmitting it, causing silent packet loss.
This bug affects any UDP encapsulation (FOU, GUE) combined with
multicast destination addresses. In practice, it causes ~50% packet
loss on FOU/GRETAP tunnels configured with multicast remote addresses,
with the exact ratio depending on the early demux cache hit rate
(packets that hit early demux take the unicast path and are handled
correctly).
Fix this by calling ip_protocol_deliver_rcu() (IPv4) or
ip6_protocol_deliver_rcu() (IPv6) instead of consume_skb() when the
return value is positive, matching the behavior of the GSO path.
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Assisted-by: Claude:claude-opus-4-6
---
net/ipv4/udp.c | 13 +++++++++----
net/ipv6/udp.c | 13 +++++++++----
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index e9e2ce9522ef..8c2d4367cba2 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2467,6 +2467,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct udp_hslot *hslot;
struct sk_buff *nskb;
bool use_hash2;
+ int ret;
hash2_any = 0;
hash2 = 0;
@@ -2500,8 +2501,10 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
__UDP_INC_STATS(net, UDP_MIB_INERRORS);
continue;
}
- if (udp_queue_rcv_skb(sk, nskb) > 0)
- consume_skb(nskb);
+ ret = udp_queue_rcv_skb(sk, nskb);
+ if (ret > 0)
+ ip_protocol_deliver_rcu(dev_net(nskb->dev), nskb,
+ ret);
}
/* Also lookup *:port if we are using hash2 and haven't done so yet. */
@@ -2511,8 +2514,10 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
}
if (first) {
- if (udp_queue_rcv_skb(first, skb) > 0)
- consume_skb(skb);
+ ret = udp_queue_rcv_skb(first, skb);
+ if (ret > 0)
+ ip_protocol_deliver_rcu(dev_net(skb->dev), skb,
+ ret);
} else {
kfree_skb(skb);
__UDP_INC_STATS(net, UDP_MIB_IGNOREDMULTI);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 15e032194ecc..f74935d9f7d7 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -949,6 +949,7 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct udp_hslot *hslot;
struct sk_buff *nskb;
bool use_hash2;
+ int ret;
hash2_any = 0;
hash2 = 0;
@@ -987,8 +988,10 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
continue;
}
- if (udpv6_queue_rcv_skb(sk, nskb) > 0)
- consume_skb(nskb);
+ ret = udpv6_queue_rcv_skb(sk, nskb);
+ if (ret > 0)
+ ip6_protocol_deliver_rcu(dev_net(nskb->dev), nskb,
+ ret, true);
}
/* Also lookup *:port if we are using hash2 and haven't done so yet. */
@@ -998,8 +1001,10 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
}
if (first) {
- if (udpv6_queue_rcv_skb(first, skb) > 0)
- consume_skb(skb);
+ ret = udpv6_queue_rcv_skb(first, skb);
+ if (ret > 0)
+ ip6_protocol_deliver_rcu(dev_net(skb->dev), skb,
+ ret, true);
} else {
kfree_skb(skb);
__UDP6_INC_STATS(net, UDP_MIB_IGNOREDMULTI);
--
2.47.3
^ permalink raw reply related
* [RFC PATCH net-next 2/2] selftests: net: add FOU multicast encapsulation resubmit test
From: Anton Danilov @ 2026-04-14 23:28 UTC (permalink / raw)
To: netdev
Cc: willemdebruijn.kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, shuah, linux-kselftest
In-Reply-To: <ad7MsSJOuUU6EGwS@dau-home-pc>
Add a selftest to verify that FOU-encapsulated packets addressed to a
multicast destination are correctly resubmitted to the inner protocol
handler (GRE) via the UDP multicast delivery path.
The test creates two network namespaces connected by a veth pair. The
receiver namespace has a FOU/GRETAP tunnel with a multicast remote
address (239.0.0.1). The sender crafts GRE-over-UDP packets and sends
them to the multicast address.
The early demux optimization (net.ipv4.ip_early_demux) is disabled on
the receiver to force packets through __udp4_lib_mcast_deliver(),
which is the code path that was previously broken.
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Assisted-by: Claude:claude-opus-4-6
---
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/fou_mcast_encap.sh | 150 ++++++++++++++++++
2 files changed, 151 insertions(+)
create mode 100755 tools/testing/selftests/net/fou_mcast_encap.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index a275ed584026..9b2a573e4af2 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -38,6 +38,7 @@ TEST_PROGS := \
fib_rule_tests.sh \
fib_tests.sh \
fin_ack_lat.sh \
+ fou_mcast_encap.sh \
fq_band_pktlimit.sh \
gre_gso.sh \
gre_ipv6_lladdr.sh \
diff --git a/tools/testing/selftests/net/fou_mcast_encap.sh b/tools/testing/selftests/net/fou_mcast_encap.sh
new file mode 100755
index 000000000000..d4737d674862
--- /dev/null
+++ b/tools/testing/selftests/net/fou_mcast_encap.sh
@@ -0,0 +1,150 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Test that UDP encapsulation (FOU) correctly handles packet resubmit
+# when packets are delivered via the multicast UDP delivery path.
+#
+# When a FOU-encapsulated packet arrives with a multicast destination IP,
+# __udp4_lib_mcast_deliver() must resubmit it to the inner protocol
+# handler (e.g., GRE) rather than consuming it. This test verifies that
+# by creating a FOU/GRETAP tunnel with a multicast remote address, sending
+# encapsulated packets, and checking that they are correctly decapsulated.
+#
+# The early demux optimization can mask this issue by routing packets via
+# the unicast path (udp_unicast_rcv_skb), so we disable it to force
+# packets through __udp4_lib_mcast_deliver().
+
+source lib.sh
+
+NSENDER=""
+NRECV=""
+
+cleanup() {
+ cleanup_all_ns
+}
+
+trap cleanup EXIT
+
+setup() {
+ setup_ns NSENDER NRECV
+
+ ip link add veth_s type veth peer name veth_r
+ ip link set veth_s netns "$NSENDER"
+ ip link set veth_r netns "$NRECV"
+
+ ip -n "$NSENDER" addr add 10.0.0.1/24 dev veth_s
+ ip -n "$NSENDER" link set veth_s up
+
+ ip -n "$NRECV" addr add 10.0.0.2/24 dev veth_r
+ ip -n "$NRECV" link set veth_r up
+
+ # Disable early demux to force multicast delivery path
+ ip netns exec "$NRECV" sysctl -wq net.ipv4.ip_early_demux=0
+
+ # Join multicast group on receiver
+ ip -n "$NRECV" addr add 239.0.0.1/32 dev veth_r autojoin
+
+ # Multicast routes
+ ip -n "$NRECV" route add 239.0.0.0/8 dev veth_r
+ ip -n "$NSENDER" route add 239.0.0.0/8 dev veth_s
+
+ # FOU listener
+ ip netns exec "$NRECV" ip fou add port 4797 ipproto 47
+
+ # GRETAP with multicast remote - this triggers __udp4_lib_mcast_deliver
+ ip -n "$NRECV" link add eoudp0 type gretap \
+ remote 239.0.0.1 local 10.0.0.2 \
+ encap fou encap-sport 4797 encap-dport 4797 \
+ key 239.0.0.1
+ ip -n "$NRECV" link set eoudp0 up
+ ip -n "$NRECV" addr add 192.168.99.2/24 dev eoudp0
+}
+
+send_fou_gre_packets() {
+ local count=$1
+
+ ip netns exec "$NSENDER" python3 -c "
+import socket, struct
+
+# GRE header: key flag set, proto=0x6558 (transparent ethernet bridging)
+gre_key = socket.inet_aton('239.0.0.1')
+gre_hdr = struct.pack('!HH', 0x2000, 0x6558) + gre_key
+
+# Inner Ethernet frame
+dst_mac = b'\xff\xff\xff\xff\xff\xff'
+src_mac = b'\x02\x00\x00\x00\x00\x01'
+eth_hdr = dst_mac + src_mac + struct.pack('!H', 0x0800)
+
+# Inner IP: 192.168.99.1 -> 192.168.99.2, ICMP echo
+inner_ip_src = socket.inet_aton('192.168.99.1')
+inner_ip_dst = socket.inet_aton('192.168.99.2')
+
+# ICMP echo request
+icmp_payload = b'TESTFOU!' * 4
+icmp_hdr = struct.pack('!BBHHH', 8, 0, 0, 0x1234, 1) + icmp_payload
+csum = 0
+for i in range(0, len(icmp_hdr), 2):
+ if i + 1 < len(icmp_hdr):
+ csum += (icmp_hdr[i] << 8) + icmp_hdr[i+1]
+ else:
+ csum += icmp_hdr[i] << 8
+while csum >> 16:
+ csum = (csum & 0xffff) + (csum >> 16)
+csum = ~csum & 0xffff
+icmp_hdr = struct.pack('!BBHHH', 8, 0, csum, 0x1234, 1) + icmp_payload
+
+# Inner IP header
+ip_len = 20 + len(icmp_hdr)
+ip_hdr = struct.pack('!BBHHHBBH', 0x45, 0, ip_len, 0x1234, 0, 64, 1, 0)
+ip_hdr += inner_ip_src + inner_ip_dst
+csum = 0
+for i in range(0, 20, 2):
+ csum += (ip_hdr[i] << 8) + ip_hdr[i+1]
+while csum >> 16:
+ csum = (csum & 0xffff) + (csum >> 16)
+csum = ~csum & 0xffff
+ip_hdr = ip_hdr[:10] + struct.pack('!H', csum) + ip_hdr[12:]
+
+payload = gre_hdr + eth_hdr + ip_hdr + icmp_hdr
+
+sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+for _ in range($count):
+ sock.sendto(payload, ('239.0.0.1', 4797))
+sock.close()
+"
+}
+
+get_rx_packets() {
+ ip -n "$NRECV" -s link show eoudp0 | awk '/RX:/{getline; print $2}'
+}
+
+test_fou_mcast_encap() {
+ local count=100
+ local rx_before
+ local rx_after
+ local rx_delta
+
+ rx_before=$(get_rx_packets)
+ send_fou_gre_packets $count
+ sleep 1
+ rx_after=$(get_rx_packets)
+
+ rx_delta=$((rx_after - rx_before))
+
+ if [ "$rx_delta" -ge "$count" ]; then
+ echo "PASS: received $rx_delta/$count packets via multicast FOU/GRETAP"
+ return "$ksft_pass"
+ elif [ "$rx_delta" -gt 0 ]; then
+ echo "FAIL: only $rx_delta/$count packets received (partial delivery)"
+ return "$ksft_fail"
+ else
+ echo "FAIL: 0/$count packets received (multicast encap resubmit broken)"
+ return "$ksft_fail"
+ fi
+}
+
+echo "TEST: FOU/GRETAP multicast encapsulation resubmit"
+
+setup
+test_fou_mcast_encap
+exit $?
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net-next v9 01/10] net: phy: phy_link_topology: Add a helper for opportunistic alloc
From: Andrew Lunn @ 2026-04-14 23:28 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, Jakub Kicinski, Eric Dumazet, Paolo Abeni, Russell King,
Heiner Kallweit, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <20260403123755.175742-2-maxime.chevallier@bootlin.com>
On Fri, Apr 03, 2026 at 02:37:45PM +0200, Maxime Chevallier wrote:
> The phy_link_topology structure stores information about the PHY-related
> components connected to a net_device. It is opportunistically allocated,
> when we add the first item to the topology, as this is not relevant for
> all kinds of net_devices.
>
> In preparation for the addition of phy_port tracking in the topology,
> let's make a dedicated helper for that allocation sequence.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v9 02/10] net: phy: phy_link_topology: Track ports in phy_link_topology
From: Andrew Lunn @ 2026-04-14 23:31 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, Jakub Kicinski, Eric Dumazet, Paolo Abeni, Russell King,
Heiner Kallweit, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <20260403123755.175742-3-maxime.chevallier@bootlin.com>
On Fri, Apr 03, 2026 at 02:37:46PM +0200, Maxime Chevallier wrote:
> phy_port is aimed at representing the various physical interfaces of a
> net_device. They can be controlled by various components in the link,
> such as the Ethernet PHY, the Ethernet MAC, and SFP module, etc.
>
> Let's therefore make so we keep track of all the ports connected to a
> netdev in phy_link_topology. The only ports added for now are phy-driven
> ports.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net v3 0/4] nfc: fix multiple parsing vulnerabilities reachable from RF
From: Lekë Hapçiu @ 2026-04-14 23:35 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, stable,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
This series fixes four RF-reachable parsing vulnerabilities in the NFC
stack. All four are triggerable from an NFC peer within ~4 cm of the
victim, before any pairing or authentication.
Patch 1 fixes a u8 underflow in nci_store_general_bytes_nfc_dep() where
a short ATR_RES/ATR_REQ causes (atr_res_len - NFC_ATR_RES_GT_OFFSET) to
wrap in u8 arithmetic, producing a bogus remote_gb_len that copies up
to 47 bytes beyond the valid activation parameter data.
Patch 2 hardens nfc_llcp_parse_gb_tlv() and
nfc_llcp_parse_connection_tlv(). The loop guard does not prove that
two header bytes can be read, and the peer-controlled `length` field
is used to advance `tlv` without bounds checking. An 8-bit `offset`
against a 16-bit `tlv_array_len` compounds the issue in
parse_connection_tlv() where the TLV array can exceed 255 bytes.
Patch 3 fixes nfc_llcp_recv_snl(). The SNL handler accesses skb->data
before verifying skb->len, and its inner TLV loop has the same two
weaknesses as patch 2. SDREQ handling additionally requires
length >= 2 because both tid (tlv[2]) and the start of service_name
(tlv[3]) are read.
Patch 4 fixes nfc_llcp_recv_dm() which reads skb->data[2] (the DM
reason byte) without checking skb->len >= 3.
Changes in v3:
- Restore the u8 -> u16 `offset` promotion in patch 2. v2 split this
into a separate v1 patch and did not re-send it; v3 combines the
promotion and the bounds checks in a single patch (Paolo Abeni).
- Return -EINVAL from nci_store_general_bytes_nfc_dep() and propagate
the error out of nci_rf_intf_activated_ntf_packet() rather than
silently accepting the malformed packet (Paolo Abeni).
- Drop the style-only paren removal in patch 1 (Paolo Abeni).
- Condense commit message in patch 2 (Paolo Abeni).
- Consolidate the length >= 1 checks before the switch in patch 2,
keeping length >= 2 only for the llcp_tlv16() accessors (Paolo Abeni).
- Tighten SDREQ length check from >=1 to >=2 in patch 3; the handler
reads both tlv[2] and tlv[3] (Sashiko).
- Add patch 4 for nfc_llcp_recv_dm().
- Send as a fresh thread rather than In-Reply-To v2 (Paolo Abeni).
Lekë Hapçiu (4):
nfc: nci: fix u8 underflow in nci_store_general_bytes_nfc_dep
nfc: llcp: fix TLV parsing in parse_gb_tlv and parse_connection_tlv
nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
net/nfc/llcp_commands.c | 24 ++++++++++++++++++++++--
net/nfc/llcp_core.c | 16 ++++++++++++++++
net/nfc/nci/ntf.c | 10 +++++++++-
3 files changed, 47 insertions(+), 3 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH net v3 1/4] nfc: nci: fix u8 underflow in nci_store_general_bytes_nfc_dep
From: Lekë Hapçiu @ 2026-04-14 23:35 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, stable,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
nci_store_general_bytes_nfc_dep() computes the General Bytes length by
subtracting a fixed header offset from the peer-supplied atr_res_len
(POLL) or atr_req_len (LISTEN) field:
ndev->remote_gb_len = min_t(__u8,
atr_res_len - NFC_ATR_RES_GT_OFFSET, /* offset = 15 */
NFC_ATR_RES_GB_MAXSIZE);
Both length fields are __u8. When a malicious NFC-DEP peer sends an
ATR_RES/ATR_REQ whose length is smaller than the fixed offset (< 15
or < 14 respectively), the subtraction wraps:
atr_res_len = 0 -> (u8)(0 - 15) = 241
min_t(__u8, 241, NFC_ATR_RES_GB_MAXSIZE=47) = 47
The subsequent memcpy then reads 47 bytes beyond the valid activation
parameter data into ndev->remote_gb[]. This buffer is later fed to
nfc_llcp_parse_gb_tlv() as a TLV array.
Reject the frame with NCI_STATUS_RF_PROTOCOL_ERROR when the length is
below the required offset, and propagate the error out of
nci_rf_intf_activated_ntf_packet() instead of silently accepting the
malformed packet.
Reachable from any NFC peer within ~4 cm during RF activation, prior
to any pairing.
Fixes: c4fbb6515709 ("NFC: NCI: Add NFC-DEP support to NCI data exchange")
Cc: stable@vger.kernel.org
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/nci/ntf.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
index c96512bb8..eb8c6e5a1 100644
--- a/net/nfc/nci/ntf.c
+++ b/net/nfc/nci/ntf.c
@@ -631,6 +631,9 @@ static int nci_store_general_bytes_nfc_dep(struct nci_dev *ndev,
switch (ntf->activation_rf_tech_and_mode) {
case NCI_NFC_A_PASSIVE_POLL_MODE:
case NCI_NFC_F_PASSIVE_POLL_MODE:
+ if (ntf->activation_params.poll_nfc_dep.atr_res_len <
+ NFC_ATR_RES_GT_OFFSET)
+ return NCI_STATUS_RF_PROTOCOL_ERROR;
ndev->remote_gb_len = min_t(__u8,
(ntf->activation_params.poll_nfc_dep.atr_res_len
- NFC_ATR_RES_GT_OFFSET),
@@ -643,6 +646,9 @@ static int nci_store_general_bytes_nfc_dep(struct nci_dev *ndev,
case NCI_NFC_A_PASSIVE_LISTEN_MODE:
case NCI_NFC_F_PASSIVE_LISTEN_MODE:
+ if (ntf->activation_params.listen_nfc_dep.atr_req_len <
+ NFC_ATR_REQ_GT_OFFSET)
+ return NCI_STATUS_RF_PROTOCOL_ERROR;
ndev->remote_gb_len = min_t(__u8,
(ntf->activation_params.listen_nfc_dep.atr_req_len
- NFC_ATR_REQ_GT_OFFSET),
@@ -842,8 +848,10 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev,
/* store general bytes to be reported later in dep_link_up */
if (ntf.rf_interface == NCI_RF_INTERFACE_NFC_DEP) {
err = nci_store_general_bytes_nfc_dep(ndev, &ntf);
- if (err != NCI_STATUS_OK)
+ if (err != NCI_STATUS_OK) {
pr_err("unable to store general bytes\n");
+ return -EINVAL;
+ }
}
/* store ATS to be reported later in nci_activate_target */
--
2.51.0
^ permalink raw reply related
* [PATCH net v3 2/4] nfc: llcp: fix TLV parsing in parse_gb_tlv and parse_connection_tlv
From: Lekë Hapçiu @ 2026-04-14 23:35 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, stable,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() walk TLV
arrays whose length and content come from a peer-supplied frame. The
parsing loop has three weaknesses:
1. `offset` is declared u8 while `tlv_array_len` is u16. In
parse_connection_tlv() the TLV array can reach ~2173 bytes (MIUX
up to 0x7FF), so 128 zero-length TLVs wrap `offset` back to 0 and
the loop never terminates while `tlv` advances past the buffer.
2. The guard `offset < tlv_array_len` only proves one byte is
available, but the body reads tlv[0] (type) and tlv[1] (length).
When one byte remains, tlv[1] is out of bounds.
3. `length` is read from peer data and used to advance `tlv` without
being checked against the remaining array space. A crafted length
walks `tlv` past the buffer; the next iteration reads tlv[0]/tlv[1]
from adjacent memory.
The llcp_tlv8() and llcp_tlv16() accessors additionally read tlv[2]
and tlv[2..3]; a zero-length TLV makes those reads out of bounds.
Fix: promote `offset` to u16; add two per-iteration guards, one for
the TLV header and one for the TLV value; require length >= 1 for all
TLVs before the type dispatch and length >= 2 for the llcp_tlv16()
accessors (MIUX, WKS). Return -EINVAL on malformed input.
Reached on ATR_RES (parse_gb_tlv) and on CONNECT/CC PDUs before a
connection is established (parse_connection_tlv). Both are
triggerable from any NFC peer within ~4 cm, without authentication.
Reported-by: Simon Horman <horms@kernel.org>
Fixes: d646960f7986 ("NFC: Add LLCP sockets")
Cc: stable@vger.kernel.org
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/llcp_commands.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 291f26fac..b6dcfb2d1 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -193,7 +193,8 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
@@ -201,8 +202,14 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local,
return -ENODEV;
while (offset < tlv_array_len) {
+ if (tlv_array_len - offset < 2)
+ return -EINVAL;
type = tlv[0];
length = tlv[1];
+ if (tlv_array_len - offset - 2 < length)
+ return -EINVAL;
+ if (length < 1)
+ return -EINVAL;
pr_debug("type 0x%x length %d\n", type, length);
@@ -211,9 +218,13 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local,
local->remote_version = llcp_tlv_version(tlv);
break;
case LLCP_TLV_MIUX:
+ if (length < 2)
+ return -EINVAL;
local->remote_miu = llcp_tlv_miux(tlv) + 128;
break;
case LLCP_TLV_WKS:
+ if (length < 2)
+ return -EINVAL;
local->remote_wks = llcp_tlv_wks(tlv);
break;
case LLCP_TLV_LTO:
@@ -243,7 +254,8 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock *sock,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
@@ -251,13 +263,21 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock *sock,
return -ENOTCONN;
while (offset < tlv_array_len) {
+ if (tlv_array_len - offset < 2)
+ return -EINVAL;
type = tlv[0];
length = tlv[1];
+ if (tlv_array_len - offset - 2 < length)
+ return -EINVAL;
+ if (length < 1)
+ return -EINVAL;
pr_debug("type 0x%x length %d\n", type, length);
switch (type) {
case LLCP_TLV_MIUX:
+ if (length < 2)
+ return -EINVAL;
sock->remote_miu = llcp_tlv_miux(tlv) + 128;
break;
case LLCP_TLV_RW:
--
2.51.0
^ permalink raw reply related
* [PATCH net v3 3/4] nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
From: Lekë Hapçiu @ 2026-04-14 23:35 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, stable,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
nfc_llcp_recv_snl() has four problems when handling a hostile peer:
1. nfc_llcp_dsap()/nfc_llcp_ssap() dereference skb->data[0..1] without
verifying skb->len; a 0- or 1-byte frame leads to an OOB read.
Additionally tlv_len = skb->len - LLCP_HEADER_SIZE wraps when
skb->len < 2, causing the following loop to run far past the
buffer.
2. The per-iteration loop guard `offset < tlv_len` only proves one
byte is available, but the body reads tlv[0] and tlv[1].
3. The peer-supplied `length` field is used to advance `tlv` without
being checked against the remaining array space.
4. The SDREQ handler previously only required length >= 1 but reads
both tid (tlv[2]) and the first byte of service_name (tlv[3], via
the pr_debug("%.16s") print and the service_name_len = length - 1
string usage), so length >= 2 is required.
Fix: reject frames smaller than LLCP_HEADER_SIZE up front; add TLV
header and TLV value guards at the top of each iteration; bump the
SDREQ minimum length to 2.
Reachable from any NFC peer within ~4 cm once an LLCP link is up.
Fixes: 7a06f0ee2823 ("NFC: llcp: Service Name Lookup implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/llcp_core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 366d75663..efe228f96 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1282,6 +1282,11 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
size_t sdres_tlvs_len;
HLIST_HEAD(nl_sdres_list);
+ if (skb->len < LLCP_HEADER_SIZE) {
+ pr_err("Malformed SNL PDU\n");
+ return;
+ }
+
dsap = nfc_llcp_dsap(skb);
ssap = nfc_llcp_ssap(skb);
@@ -1298,11 +1303,17 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
sdres_tlvs_len = 0;
while (offset < tlv_len) {
+ if (tlv_len - offset < 2)
+ break;
type = tlv[0];
length = tlv[1];
+ if (tlv_len - offset - 2 < length)
+ break;
switch (type) {
case LLCP_TLV_SDREQ:
+ if (length < 2)
+ break;
tid = tlv[2];
service_name = (char *) &tlv[3];
service_name_len = length - 1;
--
2.51.0
^ permalink raw reply related
* [PATCH net v3 4/4] nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
From: Lekë Hapçiu @ 2026-04-14 23:35 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, stable,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
nfc_llcp_recv_dm() reads skb->data[2] (the DM reason byte) without
first verifying that skb->len is at least LLCP_HEADER_SIZE + 1. A DM
PDU carrying only the 2-byte LLCP header from a rogue peer therefore
triggers a 1-byte OOB read.
Add the minimum-length guard at function entry, matching the pattern
used by nfc_llcp_recv_snl() and nfc_llcp_recv_agf().
Reachable from any NFC peer within ~4 cm once an LLCP link is up.
Fixes: d646960f7986 ("NFC: Add LLCP sockets")
Cc: stable@vger.kernel.org
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/llcp_core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index efe228f96..6baf2fc6b 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1237,6 +1237,11 @@ static void nfc_llcp_recv_dm(struct nfc_llcp_local *local,
struct sock *sk;
u8 dsap, ssap, reason;
+ if (skb->len < LLCP_HEADER_SIZE + 1) {
+ pr_err("Malformed DM PDU\n");
+ return;
+ }
+
dsap = nfc_llcp_dsap(skb);
ssap = nfc_llcp_ssap(skb);
reason = skb->data[2];
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next v9 03/10] net: phylink: Register a phy_port for MAC-driven SFP busses
From: Andrew Lunn @ 2026-04-14 23:38 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, Jakub Kicinski, Eric Dumazet, Paolo Abeni, Russell King,
Heiner Kallweit, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <20260403123755.175742-4-maxime.chevallier@bootlin.com>
> This phy_port represents the SFP cage itself, and not the module
> +static int phylink_create_sfp_port(struct phylink *pl)
I'm thinking about naming here. If this represent the cage, why not
call this phylink_create_sfp_cage_port(). I assume as some point there
is going to be something for the module, and it seem like the naming
is going to be confusing.
> +{
> + struct phy_port *port;
> + int ret = 0;
> +
> + if (!pl->netdev || !pl->sfp_bus)
> + return 0;
> +
> + port = phy_port_alloc();
> + if (!port)
> + return -ENOMEM;
> +
> + port->is_sfp = true;
> + port->is_mii = true;
> + port->active = true;
If this is a cage, not a module, does is_sfp = true make sense?
And what does an active cage mean?
Andrew
^ permalink raw reply
* Re: [PATCH] vsock/virtio: fix accept queue count leak on transport mismatch in recv_listen
From: kernel test robot @ 2026-04-14 23:40 UTC (permalink / raw)
To: Dudu Lu, netdev; +Cc: oe-kbuild-all, stefanha, sgarzare, mst, jasowang, Dudu Lu
In-Reply-To: <20260413085243.73200-1-phx0fer@gmail.com>
Hi Dudu,
kernel test robot noticed the following build errors:
[auto build test ERROR on mst-vhost/linux-next]
[also build test ERROR on net/main net-next/main linus/master horms-ipvs/master v7.0 next-20260414]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Dudu-Lu/vsock-virtio-fix-accept-queue-count-leak-on-transport-mismatch-in-recv_listen/20260414-233232
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
patch link: https://lore.kernel.org/r/20260413085243.73200-1-phx0fer%40gmail.com
patch subject: [PATCH] vsock/virtio: fix accept queue count leak on transport mismatch in recv_listen
config: sparc-randconfig-001-20260415 (https://download.01.org/0day-ci/archive/20260415/202604150747.6LyaJckM-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260415/202604150747.6LyaJckM-lkp@intel.com/reproduce)
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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604150747.6LyaJckM-lkp@intel.com/
All errors (new ones prefixed by >>):
net/vmw_vsock/virtio_transport_common.c:1:2: warning: data definition has no type or storage class
sk_acceptq_added(sk);
^~~~~~~~~~~~~~~~
net/vmw_vsock/virtio_transport_common.c:1:2: error: type defaults to 'int' in declaration of 'sk_acceptq_added' [-Werror=implicit-int]
net/vmw_vsock/virtio_transport_common.c:1:2: warning: parameter names (without types) in function declaration
In file included from include/linux/virtio_vsock.h:7,
from net/vmw_vsock/virtio_transport_common.c:15:
>> include/net/sock.h:1080:20: error: conflicting types for 'sk_acceptq_added'
static inline void sk_acceptq_added(struct sock *sk)
^~~~~~~~~~~~~~~~
net/vmw_vsock/virtio_transport_common.c:1:2: note: previous declaration of 'sk_acceptq_added' was here
sk_acceptq_added(sk);
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/sk_acceptq_added +1080 include/net/sock.h
^1da177e4c3f415 Linus Torvalds 2005-04-16 1079
^1da177e4c3f415 Linus Torvalds 2005-04-16 @1080 static inline void sk_acceptq_added(struct sock *sk)
^1da177e4c3f415 Linus Torvalds 2005-04-16 1081 {
288efe8606b62d0 Eric Dumazet 2019-11-05 1082 WRITE_ONCE(sk->sk_ack_backlog, sk->sk_ack_backlog + 1);
^1da177e4c3f415 Linus Torvalds 2005-04-16 1083 }
^1da177e4c3f415 Linus Torvalds 2005-04-16 1084
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net] hv_sock: Report EOF instead of -EIO for FIN
From: Dexuan Cui @ 2026-04-14 23:43 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, sgarzare, davem, edumazet,
kuba, pabeni, horms, niuxuewei.nxw, linux-hyperv, virtualization,
netdev, linux-kernel
Cc: stable, Ben Hillis, Mitchell Levy
Commit f0c5827d07cb unluckily causes a regression for the FIN packet,
and the final read syscall gets an error rather than 0.
Ideally, we would want to fix hvs_channel_readable_payload() so that it
could return 0 in the FIN scenario, but it's not good for the hv_sock
driver to use the VMBus ringbuffer's cached priv_read_index, which is
internal data in the VMBus driver.
Fix the regression in hv_sock by returning 0 rather than -EIO.
Fixes: f0c5827d07cb ("hv_sock: Return the readable bytes in hvs_stream_has_data()")
Cc: stable@vger.kernel.org
Reported-by: Ben Hillis <Ben.Hillis@microsoft.com>
Reported-by: Mitchell Levy <levymitchell0@gmail.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
net/vmw_vsock/hyperv_transport.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 069386a74557..63d3549125be 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -703,8 +703,22 @@ static s64 hvs_stream_has_data(struct vsock_sock *vsk)
switch (hvs_channel_readable_payload(hvs->chan)) {
case 1:
need_refill = !hvs->recv_desc;
- if (!need_refill)
- return -EIO;
+ if (!need_refill) {
+ /* Here hvs->recv_data_len is 0, so hvs->recv_desc must
+ * be NULL unless it points to the 0-byte-payload FIN
+ * packet: see hvs_update_recv_data().
+ *
+ * Here all the payload has been dequeued, but
+ * hvs_channel_readable_payload() still returns 1,
+ * because the VMBus ringbuffer's read_index is not
+ * updated for the FIN packet: hvs_stream_dequeue() ->
+ * hv_pkt_iter_next() updates the cached priv_read_index
+ * but has no opportunity to update the read_index in
+ * hv_pkt_iter_close() as hvs_stream_has_data() returns
+ * 0 for the FIN packet, so it won't get dequeued.
+ */
+ return 0;
+ }
hvs->recv_desc = hv_pkt_iter_first(hvs->chan);
if (!hvs->recv_desc)
--
2.49.0
^ permalink raw reply related
* Re: [PATCH net-next v9 04/10] net: phy: Create SFP phy_port before registering upstream
From: Andrew Lunn @ 2026-04-14 23:46 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, Jakub Kicinski, Eric Dumazet, Paolo Abeni, Russell King,
Heiner Kallweit, netdev, linux-kernel, thomas.petazzoni,
Christophe Leroy, Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <20260403123755.175742-5-maxime.chevallier@bootlin.com>
On Fri, Apr 03, 2026 at 02:37:48PM +0200, Maxime Chevallier wrote:
> When dealing with PHY-driven SFP, we create a phy_port representing the
> SFP bus when we know we have such a bus.
I'm missing the big picture here.
Do we have three different things represented in the topology:
SFP bus-> SFP cage-> SFP module
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