* Re: [PATCH net,v2 00/11] Netfilter/IPVS fixes for net
From: Florian Westphal @ 2026-04-16 21:16 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, horms
In-Reply-To: <20260416131453.308611-1-pablo@netfilter.org>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> v2: Keep back patches that have lengthy feedback by AI, they might
> need more work.
sashiko findings response:
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 01/11] netfilter: arp_tables: fix IEEE1394 ARP payload parsing in arp_packet_match()
yes, arpt_mangle.c has same bug pattern, will follow up.
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 02/11] netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 03/11] netfilter: nft_osf: restrict it to ipv4
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 04/11] netfilter: nfnetlink_osf: fix null-ptr-deref in nf_osf_ttl
yes, osf has more issues, I asked Fernando to investigate. Brief glance
the reports are accurate but these are NOT new issues added by these 3
fixes.
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 07/11] netfilter: nat: use kfree_rcu to release ops
shashiko wants /kfree/kfree_rcu/ in error unwind path and I think we
should just do it. Its an error path so it makes no practical
difference. Also, with upcoming -next patch to dump the nat
hooks too it would be required.
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 11/11] netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase
report is accurate BUT this issue is already known and not a regression
added here.
The fix for this bug was in v1 PR but it needs more work and will come
in a followup batch.
If you don't want to take this v2 because of above issues, please
consider at least applying
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 08/11] ipvs: fix MTU check for GSO packets in tunnel mode
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 09/11] netfilter: nf_tables: use list_del_rcu for netlink hooks
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 10/11] rculist: add list_splice_rcu() for private lists
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 05/11] netfilter: conntrack: remove sprintf usage
↳ [2026-04-16] Pablo Neira Ayuso <pablo@netfilter.org>: [PATCH net 06/11] netfilter: xtables: restrict several matches to inet family
manually. nf:main always tracks net:main, applying them manually
doesn't cause issues.
I hope we get shashiko to also digest netfilter-devel;
otherwise this situation will persist forever or can
dissolve nf-devel and spam netdev@ directly :-|
^ permalink raw reply
* Re: [PATCH net 1/1] mptcp: hold subflow request owners when cloning reqsk
From: Matthieu Baerts @ 2026-04-16 21:18 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: Ren Wei, netdev, mptcp, davem, edumazet, kuba, pabeni, horms,
ncardwell, dsahern, martineau, geliang, daniel, kafai, yuantan098,
yifanwucs, tomapufckgml, bird, caoruide123, enjou1224z
In-Reply-To: <CAAVpQUDzh-dGsQpBCZjN3rUsoDc2QjzWh-o5yVWoBWDQNXbjmQ@mail.gmail.com>
Hi Kuniyuki,
Thank you for your reply!
16 Apr 2026 20:48:58 Kuniyuki Iwashima <kuniyu@google.com>:
> On Thu, Apr 16, 2026 at 10:45 AM Matthieu Baerts <matttbe@kernel.org> wrote:
>>
>> Hi Ren,
>>
>> On 15/04/2026 11:31, Ren Wei wrote:
>>> From: Ruide Cao <caoruide123@gmail.com>
>>>
>>> TCP request migration clones pending request sockets with
>>> inet_reqsk_clone(). For MPTCP MP_JOIN requests this raw-copies
>>> subflow_req->msk, but the cloned request does not take a new reference.
>>>
>>> Both the original and the cloned request can later drop the same msk in
>>> subflow_req_destructor(), and a migrated request may keep a dangling msk
>>> pointer after the original owner has already been released.
>>>
>>> Add a request_sock clone callback and let MPTCP grab a reference for cloned
>>> subflow requests that carry an msk. This keeps ownership balanced across
>>> both successful migrations and failed clone/insert paths without changing
>>> other protocols.
(...)
>>> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
>>> index e961936b6be7..140a9e96ad58 100644
>>> --- a/net/ipv4/inet_connection_sock.c
>>> +++ b/net/ipv4/inet_connection_sock.c
>>> @@ -954,6 +954,9 @@ static struct request_sock *inet_reqsk_clone(struct request_sock *req,
>>> if (sk->sk_protocol == IPPROTO_TCP && tcp_rsk(nreq)->tfo_listener)
>>> rcu_assign_pointer(tcp_sk(nreq->sk)->fastopen_rsk, nreq);
>>
>> (Maybe TCP with fastopen could be this other user to call
>> rcu_assign_pointer()? (net-next material))
>>
>>> + if (req->rsk_ops->init_clone)
>>> + req->rsk_ops->init_clone(req, nreq);
>
> I think a simple direct call is better.
>
> #ifdef CONFIG_MPTCP
> if (tcp_rsk(req)->is_mptcp)
> mptcp_reqsk_clone(nreq);
> #endif
Fine by me!
I guess it is needed to check the protocol, similar to what is fine with
TFO above:
if (sk->sk_protocol == IPPROTO_TCP) {
if TFO
...
if MPTCP (+ifdef)
...
}
Cheers,
Matt
^ permalink raw reply
* Re: [PATCH v3 1/4] rust: netlink: add raw netlink abstraction
From: Andrew Lunn @ 2026-04-16 21:19 UTC (permalink / raw)
To: Matthew Maurer
Cc: Alice Ryhl, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, Jakub Kicinski,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos,
Christian Brauner, Carlos Llamas, linux-kernel, rust-for-linux,
netdev
In-Reply-To: <CAGSQo03b4tTQW=bXiRrmjvF8NympD_dcJX=2jwPdMmguXLfifQ@mail.gmail.com>
On Thu, Apr 16, 2026 at 01:06:42PM -0700, Matthew Maurer wrote:
> > + /// Sends the generic netlink message as a multicast message.
> > + #[inline]
> > + pub fn multicast(
> > + self,
> > + family: &'static Family,
> > + portid: u32,
> > + group: u32,
> > + flags: alloc::Flags,
> > + ) -> Result {
> > + let me = ManuallyDrop::new(self);
> > + // SAFETY: The `skb` and `family` pointers are valid. We pass ownership of the `skb` to
> > + // `genlmsg_multicast` by not dropping `self`.
Hi Matthew
Please trim when replying, to just the needed context.
> I think if genlmsg_multicast returns an error code we may need to drop
> to avoid leaking. Specifically, there is at least this path:
> 1. Set group to a large number (that's an unconstrained public parameter)
> 2. We suppress drop
> 3. We call genlmsg_multicast
> 4. We call genlmsg_multicast_netns
> 4. We call genlmsg_multicast_netns_filtered, which does an inbounds
> check for the `group`. If it is too large, it returns EINVAL without
> consuming the SKB - include/net/genetlink.h:493
> 5. We leak the skb
>
> However, at the same time, if we pass that check and descend into
> `netlink_broadcast_filtered`, it will unconditionally consume the SKB,
> and possibly return an error code in other situations.
A quick grep of the code suggests very few callers of
genlmsg_multicast look at the return code.
drivers/scsi/pmcraid.c prints an error message, but does nothing with
the skb.
drivers/regulator/event.c returns the error code to its caller, which
discards is, and the skb is leaked.
net/ieee802154/netlink.c returns the error code up the call stack but
leaks the skb.
net/nfc/netlink.c returns the error code up the call stack but leaks
the skb.
So i would agree with you, freeing it on error somewhere within
genlmsg_multicast() would make sense.
Andrew
^ permalink raw reply
* [PATCH net] virtio_net: sync rss_trailer.max_tx_vq on queue_pairs change via VQ_PAIRS_SET
From: Brett Creeley @ 2026-04-16 21:21 UTC (permalink / raw)
To: mst, jasowang, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev
Cc: brett.creeley
When netif_is_rxfh_configured() is true (i.e., the user has explicitly
configured the RSS indirection table), virtnet_set_queues() skips the
RSS update path and falls through to the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
command to change the number of queue pairs. However, it does not update
vi->rss_trailer.max_tx_vq to reflect the new queue_pairs value.
This causes a mismatch between vi->curr_queue_pairs and
vi->rss_trailer.max_tx_vq. Any subsequent RSS reconfiguration (e.g.,
via ethtool -X) calls virtnet_commit_rss_command(), which sends the
stale max_tx_vq to the device, silently reverting the queue count.
Reproduction:
1. User configured RSS
ethtool -X eth0 equal 8
2. VQ_PAIRS_SET path; max_tx_vq stays 16
ethtool -L eth0 combined 12
3. RSS commit uses max_tx_vq=16 instead of 12
ethtool -X eth0 equal 4
Fix this by updating vi->rss_trailer.max_tx_vq after a successful
VQ_PAIRS_SET command when RSS is enabled, keeping it in sync with
curr_queue_pairs.
Fixes: 50bfcaedd78e ("virtio_net: Update rss when set queue")
Assisted-by: Claude: claude-opus-4.6
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
---
drivers/net/virtio_net.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index bfb566fecb92..f4adcfee7a80 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3759,6 +3759,12 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs)
queue_pairs);
return -EINVAL;
}
+
+ /* Keep max_tx_vq in sync so that a later RSS command does not
+ * revert queue_pairs to a stale value.
+ */
+ if (vi->has_rss)
+ vi->rss_trailer.max_tx_vq = cpu_to_le16(queue_pairs);
succ:
vi->curr_queue_pairs = queue_pairs;
if (dev->flags & IFF_UP) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] rust: netlink: add raw netlink abstraction
From: Matthew Maurer @ 2026-04-16 21:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alice Ryhl, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Donald Hunter, Jakub Kicinski,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos,
Christian Brauner, Carlos Llamas, linux-kernel, rust-for-linux,
netdev
In-Reply-To: <845b36ba-7b3a-41f2-acb2-b284f253e2ca@lunn.ch>
>
> So i would agree with you, freeing it on error somewhere within
> genlmsg_multicast() would make sense.
>
> Andrew
If this should be fixed separately, then for the rust part:
Reviewed-by: Matthew Maurer <mmaurer@google.com>
with the caveat that documentation is added to the two `const_new`
functions to indicate that they are expected to panic on error, and
should only be used at const time.
^ permalink raw reply
* Re: [PATCH net] eth: fbnic: fix double-free of PCS on phylink creation failure
From: Bobby Eshleman @ 2026-04-16 21:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Russell King, netdev,
linux-kernel, Bobby Eshleman
In-Reply-To: <1873b5ba-419f-4247-ab92-1b5e899458e8@lunn.ch>
On Thu, Apr 16, 2026 at 11:00:01PM +0200, Andrew Lunn wrote:
> On Thu, Apr 16, 2026 at 12:31:39PM -0700, Bobby Eshleman wrote:
> > From: Bobby Eshleman <bobbyeshleman@meta.com>
> >
> > fbnic_phylink_create() stores the newly allocated PCS in fbn->pcs before
> > calling phylink_create(). When phylink_create() fails the error path
> > calls xpcs_destroy_pcs(pcs) to release the PCS, but neglects to clear
> > fbn->pcs.
> >
> > The caller, fbnic_netdev_alloc(), responds to the failure by calling
> > fbnic_netdev_free() which in turn calls fbnic_phylink_destroy().
>
> Isn't the real problem here? fbnic_phylink_create() failed, and it
> correctly did its cleanup. Because it failed, you should not be
> calling fbnic_phylink_destroy(). You only call the _destroy() if the
> previous _create() was successful.
>
> Andrew
>
> ---
> pw-bot: cr
True, the real issue is the _create/_destroy call asymmetry.
How about something like this (untested)?:
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
index e3ca5fcfabef..2a6a73393732 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
@@ -818,7 +818,8 @@ struct net_device *fbnic_netdev_alloc(struct fbnic_dev *fbd)
netif_tx_stop_all_queues(netdev);
if (fbnic_phylink_create(netdev)) {
- fbnic_netdev_free(fbd);
+ free_netdev(netdev);
+ fbd->netdev = NULL;
return NULL;
}
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c b/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
index 09c5225111be..50240e6c2ee9 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
@@ -237,6 +237,7 @@ int fbnic_phylink_create(struct net_device *netdev)
dev_err(netdev->dev.parent,
"Failed to create Phylink interface, err: %d\n", err);
xpcs_destroy_pcs(pcs);
+ fbn->pcs = NULL;
return err;
}
I think we still probably want to be NULL-ing the pcs, even if it won't
necessarily matter anymore.
Best,
Bobby
^ permalink raw reply related
* [PATCH] Document TCP_DEFER_ACCEPT rounding
From: Josh Triplett @ 2026-04-16 21:57 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man, netdev
In-Reply-To: <aeAAXdBe1f2THR2N@devuan>
[-- Attachment #1: Type: text/plain, Size: 15 bytes --]
Patch attached.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-TCP_DEFER_ACCEPT-rounding.patch --]
[-- Type: text/x-patch; name="0001-Document-TCP_DEFER_ACCEPT-rounding.patch", Size: 885 bytes --]
From ad2b798376326d40944f6998270a755f61c57815 Mon Sep 17 00:00:00 2001
Message-ID: <ad2b798376326d40944f6998270a755f61c57815.1776374539.git.josh@joshtriplett.org>
From: Josh Triplett <josh@joshtriplett.org>
Date: Thu, 16 Apr 2026 14:21:34 -0700
Subject: [PATCH] Document `TCP_DEFER_ACCEPT` rounding
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
man/man7/tcp.7 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/man/man7/tcp.7 b/man/man7/tcp.7
index ff46ea7bc..26a99b879 100644
--- a/man/man7/tcp.7
+++ b/man/man7/tcp.7
@@ -1091,6 +1091,8 @@ Allow a listener to be awakened only when data arrives on the socket.
Takes an integer value (seconds), this can
bound the maximum number of attempts TCP will make to
complete the connection.
+The kernel will round this value up to the next larger TCP retransmit
+duration.
.IP
On a client socket,
if nonzero,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net v2] RDS: Fix memory leak in rds_rdma_extra_size()
From: Allison Henderson @ 2026-04-16 22:18 UTC (permalink / raw)
To: Xiaobo Liu, Paolo Abeni
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
netdev, linux-rdma, rds-devel, linux-kernel
In-Reply-To: <CAJeqHv+kCScdMLYgOPG0TaRwTH5-Vo-=HEPs+oX24OprbmtbwA@mail.gmail.com>
On Thu, 2026-04-16 at 18:00 +0800, Xiaobo Liu wrote:
> The internal addition of kfree and setting the pointer to NULL in
> rds_rdma_extra_size makes the function more self‑consistent and secure.
> After applying this patch, kfree(NULL) in rds_sendmsg is also safe and will
> not cause a double‑free.
Hi Xiaobo,
Paolo makes a good point that I had missed in that rds_sendmsg owns the
cleanup. So even though iov->iov isn't freed here, it isn't leaked
either. Self-consistency is fair as a style point, but it's not
strong enough to justify the change on its own since it isn't a bug
fix. That said, thank you for taking the time to look at this area;
we appreciate the effort to help track down and fix bugs.
Thanks,
Allison
>
> On 4/16/2616:20 Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > On 4/13/26 9:00 AM, Xiaobo Liu wrote:
> > > @@ -595,11 +600,20 @@ int rds_rdma_extra_size(struct rds_rdma_args
> *args,
> > > * nr_pages for one entry is limited to
> (UINT_MAX>>PAGE_SHIFT)+1,
> > > * so tot_pages cannot overflow without first going
> negative.
> > > */
> > > - if (tot_pages < 0)
> > > - return -EINVAL;
> > > + if (tot_pages < 0) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > }
> > >
> > > - return tot_pages * sizeof(struct scatterlist);
> > > + ret = tot_pages * sizeof(struct scatterlist);
> > > +
> > > +out:
> > > + if (ret < 0) {
> > > + kfree(iov->iov);
> > > + iov->iov = NULL;
> >
> > Is this really needed?!? AFAICS rds_rdma_extra_size() is invoked only
> > via: rds_sendmsg() -> rds_rm_size() -> rds_rdma_extra_size(), and the
> > rds_sendmsg() error path already frees any non NULL iov.
> >
> > /P
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-net] i40e: set supported_extts_flags for rising edge
From: Jacob Keller @ 2026-04-16 22:27 UTC (permalink / raw)
To: Przemyslaw Korba, intel-wired-lan
Cc: netdev, anthony.l.nguyen, przemyslaw.kitszel,
Arkadiusz Kubalewski, Aleksandr Loktionov
In-Reply-To: <20260415102511.1560665-1-przemyslaw.korba@intel.com>
On 4/15/2026 3:25 AM, Przemyslaw Korba wrote:
> The i40e driver always supported only rising edge detection, so
> advertise PTP_RISING_EDGE, and PTP_STRICT_FLAGS to ensure the
> PTP core properly validates user requests.
>
> Fixes: 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info")
> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Thanks! This is the correct fix for net, then we can update i40e to
support all modes in the future as a next feature implementation.
Thanks,
Jake
^ permalink raw reply
* [PATCH RFC 0/4] net: ipa: add support for Eliza SoC (IPA 5.5)
From: Alexander Koskovich @ 2026-04-16 22:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: linux-arm-msm, netdev, devicetree, linux-kernel,
Alexander Koskovich
This series adds support to the IPA driver for the Eliza SoC (IPA 5.5).
Wanted some feedback on how best to handle the difference in the Q6 FNR
counters between Eliza & SM8550/SM8650, since it also changes the memory
layout [1].
I was thinking about something like checking firmware version after
loading IPA firmware and if above X version, use increased FnR counters
but I am not sure what firmware version this was introduced in.
For now I am just doing it with a seperate Eliza compatible but this
feels kind of meh. I'm also not sure if it's possible there's some Eliza
variant out there that actually has firmware that is too old, and then
68 for FnR counters is too much.
I also wanted some clarification on the general need to pass hw filter
stats info, downstream this is marked as "optional", but seems very
much needed for Eliza.
Is this actually optional and there is just some other misconfiguration
or is firmware broken? Hard to debug what modem wants since system does
a complete halt shortly after starting IPA if I don't pass this.
[1]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/dataipa/-/commit/0a3c432e4fd294eba6def56378acb6fa39feb400
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Alexander Koskovich (4):
dt-bindings: net: qcom,ipa: document Eliza compatible
net: ipa: fix IPA v5.5 configuration data
net: ipa: add new QMI request for HW filter stats info
net: ipa: add Eliza configuration data
.../devicetree/bindings/net/qcom,ipa.yaml | 1 +
drivers/net/ipa/data/ipa_data-v4.5.c | 1 +
drivers/net/ipa/data/ipa_data-v4.7.c | 1 +
drivers/net/ipa/data/ipa_data-v4.9.c | 1 +
drivers/net/ipa/data/ipa_data-v5.0.c | 1 +
drivers/net/ipa/data/ipa_data-v5.5.c | 180 ++++++++++++++++++++-
drivers/net/ipa/ipa.h | 3 +
drivers/net/ipa/ipa_data.h | 4 +
drivers/net/ipa/ipa_main.c | 4 +
drivers/net/ipa/ipa_mem.c | 2 +
drivers/net/ipa/ipa_qmi.c | 18 +++
drivers/net/ipa/ipa_qmi_msg.c | 58 +++++++
drivers/net/ipa/ipa_qmi_msg.h | 15 +-
13 files changed, 280 insertions(+), 9 deletions(-)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260416-eliza-ipa-c26a88213ff3
Best regards,
--
Alexander Koskovich <akoskovich@pm.me>
^ permalink raw reply
* [PATCH RFC 1/4] dt-bindings: net: qcom,ipa: document Eliza compatible
From: Alexander Koskovich @ 2026-04-16 22:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: linux-arm-msm, netdev, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260416-eliza-ipa-v1-0-f4109a8e43c4@pm.me>
Document the IPA on the Eliza Platform which uses version 5.5.1,
which is a minor revision of v5.5 found on SM8550, thus we can
use the SM8550 bindings as fallback since it shares the same
register mappings.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index fdeaa81b9645..38a5a337c34f 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -60,6 +60,7 @@ properties:
- const: qcom,sc7180-ipa
- items:
- enum:
+ - qcom,eliza-ipa
- qcom,sm8650-ipa
- const: qcom,sm8550-ipa
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 2/4] net: ipa: fix IPA v5.5 configuration data
From: Alexander Koskovich @ 2026-04-16 22:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: linux-arm-msm, netdev, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260416-eliza-ipa-v1-0-f4109a8e43c4@pm.me>
struct ipa_qmb_outstanding {
u16 ot_reads;
u16 ot_writes;
u16 ot_read_beats;
};
[IPA_5_5][IPA_QMB_INSTANCE_DDR] = {16, 12, 0},
[IPA_5_5][IPA_QMB_INSTANCE_PCIE] = {16, 8, 0},
IPA_ENDPOINT_AP_LAN_RX:
[IPA_5_5][IPA_CLIENT_APPS_LAN_CONS] = {
true, IPA_v5_5_GROUP_UL,
false,
IPA_DPS_HPS_SEQ_TYPE_INVALID,
QMB_MASTER_SELECT_DDR,
{ 17, 14, 9, 9, IPA_EE_AP, GSI_ESCAPE_BUF_ONLY, 0 },
IPA_TX_INSTANCE_UL },
IPA_ENDPOINT_AP_MODEM_RX:
[IPA_5_5][IPA_CLIENT_APPS_WAN_CONS] = {
true, IPA_v5_5_GROUP_DL,
false,
IPA_DPS_HPS_SEQ_TYPE_INVALID,
QMB_MASTER_SELECT_DDR,
{ 24, 1, 9, 9, IPA_EE_AP, GSI_SMART_PRE_FETCH, 3 },
IPA_TX_INSTANCE_DL },
IPA_ENDPOINT_MODEM_AP_RX:
[IPA_5_5][IPA_CLIENT_Q6_WAN_CONS] = {
true, IPA_v5_5_GROUP_UL,
false,
IPA_DPS_HPS_SEQ_TYPE_INVALID,
QMB_MASTER_SELECT_DDR,
{ 22, 7, 9, 9, IPA_EE_Q6, GSI_ESCAPE_BUF_ONLY, 0 },
IPA_TX_INSTANCE_UL },
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
drivers/net/ipa/data/ipa_data-v5.5.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ipa/data/ipa_data-v5.5.c b/drivers/net/ipa/data/ipa_data-v5.5.c
index 741ae21d9d78..f6ba3b944700 100644
--- a/drivers/net/ipa/data/ipa_data-v5.5.c
+++ b/drivers/net/ipa/data/ipa_data-v5.5.c
@@ -50,13 +50,13 @@ enum ipa_rsrc_group_id {
/* QSB configuration data for an SoC having IPA v5.5 */
static const struct ipa_qsb_data ipa_qsb_data[] = {
[IPA_QSB_MASTER_DDR] = {
- .max_writes = 0, /* Unlimited */
- .max_reads = 12,
+ .max_writes = 12,
+ .max_reads = 0, /* Unlimited */
.max_reads_beats = 0,
},
[IPA_QSB_MASTER_PCIE] = {
- .max_writes = 0, /* Unlimited */
- .max_reads = 8,
+ .max_writes = 8,
+ .max_reads = 0, /* Unlimited */
.max_reads_beats = 0,
},
};
@@ -86,8 +86,8 @@ static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
},
[IPA_ENDPOINT_AP_LAN_RX] = {
.ee_id = GSI_EE_AP,
- .channel_id = 13,
- .endpoint_id = 16,
+ .channel_id = 14,
+ .endpoint_id = 17,
.toward_ipa = false,
.channel = {
.tre_count = 256,
@@ -135,7 +135,7 @@ static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
[IPA_ENDPOINT_AP_MODEM_RX] = {
.ee_id = GSI_EE_AP,
.channel_id = 1,
- .endpoint_id = 23,
+ .endpoint_id = 24,
.toward_ipa = false,
.channel = {
.tre_count = 256,
@@ -168,7 +168,7 @@ static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
[IPA_ENDPOINT_MODEM_AP_RX] = {
.ee_id = GSI_EE_MODEM,
.channel_id = 7,
- .endpoint_id = 21,
+ .endpoint_id = 22,
.toward_ipa = false,
},
[IPA_ENDPOINT_MODEM_DL_NLO_TX] = {
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 3/4] net: ipa: add new QMI request for HW filter stats info
From: Alexander Koskovich @ 2026-04-16 22:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: linux-arm-msm, netdev, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260416-eliza-ipa-v1-0-f4109a8e43c4@pm.me>
Some IPA firmware versions on IPA 5.5 require ipa_filter_stats_info in
the init_modem_driver QMI request. For example on Eliza, if this is not
passed then shortly after IPA init the system will halt and reboot
shortly after.
Downstream this is marked as optional but does not seem to be the case
on newer IPA firmware versions.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
drivers/net/ipa/data/ipa_data-v4.5.c | 1 +
drivers/net/ipa/data/ipa_data-v4.7.c | 1 +
drivers/net/ipa/data/ipa_data-v4.9.c | 1 +
drivers/net/ipa/data/ipa_data-v5.0.c | 1 +
drivers/net/ipa/data/ipa_data-v5.5.c | 1 +
drivers/net/ipa/ipa.h | 3 ++
drivers/net/ipa/ipa_data.h | 3 ++
drivers/net/ipa/ipa_mem.c | 2 ++
drivers/net/ipa/ipa_qmi.c | 18 +++++++++++
drivers/net/ipa/ipa_qmi_msg.c | 58 ++++++++++++++++++++++++++++++++++++
drivers/net/ipa/ipa_qmi_msg.h | 15 +++++++++-
11 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipa/data/ipa_data-v4.5.c b/drivers/net/ipa/data/ipa_data-v4.5.c
index 730d8c43a45c..25eceffdd9f7 100644
--- a/drivers/net/ipa/data/ipa_data-v4.5.c
+++ b/drivers/net/ipa/data/ipa_data-v4.5.c
@@ -419,6 +419,7 @@ static const struct ipa_mem_data ipa_mem_data = {
.imem_addr = 0x14688000,
.imem_size = 0x00003000,
.smem_size = 0x00009000,
+ .fnr_idx_cnt = 52,
};
/* Interconnect rates are in 1000 byte/second units */
diff --git a/drivers/net/ipa/data/ipa_data-v4.7.c b/drivers/net/ipa/data/ipa_data-v4.7.c
index 5e1d9049c62b..ef4695ee1b2d 100644
--- a/drivers/net/ipa/data/ipa_data-v4.7.c
+++ b/drivers/net/ipa/data/ipa_data-v4.7.c
@@ -361,6 +361,7 @@ static const struct ipa_mem_data ipa_mem_data = {
.imem_addr = 0x146a8000,
.imem_size = 0x00002000,
.smem_size = 0x00009000,
+ .fnr_idx_cnt = 52,
};
/* Interconnect rates are in 1000 byte/second units */
diff --git a/drivers/net/ipa/data/ipa_data-v4.9.c b/drivers/net/ipa/data/ipa_data-v4.9.c
index da472a2a2e29..0e2e521d98bb 100644
--- a/drivers/net/ipa/data/ipa_data-v4.9.c
+++ b/drivers/net/ipa/data/ipa_data-v4.9.c
@@ -417,6 +417,7 @@ static const struct ipa_mem_data ipa_mem_data = {
.imem_addr = 0x146bd000,
.imem_size = 0x00002000,
.smem_size = 0x00009000,
+ .fnr_idx_cnt = 52,
};
/* Interconnect rates are in 1000 byte/second units */
diff --git a/drivers/net/ipa/data/ipa_data-v5.0.c b/drivers/net/ipa/data/ipa_data-v5.0.c
index bc5722e4b053..9f7aaf37b8fd 100644
--- a/drivers/net/ipa/data/ipa_data-v5.0.c
+++ b/drivers/net/ipa/data/ipa_data-v5.0.c
@@ -443,6 +443,7 @@ static const struct ipa_mem_data ipa_mem_data = {
.imem_addr = 0x14688000,
.imem_size = 0x00003000,
.smem_size = 0x00009000,
+ .fnr_idx_cnt = 52,
};
/* Interconnect rates are in 1000 byte/second units */
diff --git a/drivers/net/ipa/data/ipa_data-v5.5.c b/drivers/net/ipa/data/ipa_data-v5.5.c
index f6ba3b944700..44a9df7346b7 100644
--- a/drivers/net/ipa/data/ipa_data-v5.5.c
+++ b/drivers/net/ipa/data/ipa_data-v5.5.c
@@ -449,6 +449,7 @@ static const struct ipa_mem_data ipa_mem_data = {
.imem_addr = 0x14688000,
.imem_size = 0x00002000,
.smem_size = 0x0000b000,
+ .fnr_idx_cnt = 52,
};
/* Interconnect rates are in 1000 byte/second units */
diff --git a/drivers/net/ipa/ipa.h b/drivers/net/ipa/ipa.h
index 7ef10a4ff35e..d2ceaea31635 100644
--- a/drivers/net/ipa/ipa.h
+++ b/drivers/net/ipa/ipa.h
@@ -69,6 +69,7 @@ struct ipa_smp2p;
* @modem_state: State of modem (stopped, running)
* @modem_netdev: Network device structure used for modem
* @qmi: QMI information
+ * @fnr_idx_cnt: Number of FnR counters
*/
struct ipa {
struct gsi gsi;
@@ -129,6 +130,8 @@ struct ipa {
atomic_t modem_state; /* enum ipa_modem_state */
struct net_device *modem_netdev;
struct ipa_qmi qmi;
+
+ u8 fnr_idx_cnt;
};
/**
diff --git a/drivers/net/ipa/ipa_data.h b/drivers/net/ipa/ipa_data.h
index 3eb9dc2ce339..f7566c8edabd 100644
--- a/drivers/net/ipa/ipa_data.h
+++ b/drivers/net/ipa/ipa_data.h
@@ -181,6 +181,7 @@ struct ipa_resource_data {
* @imem_addr: physical address of IPA region within IMEM
* @imem_size: size in bytes of IPA IMEM region
* @smem_size: size in bytes of the IPA SMEM region
+ * @fnr_idx_cnt: Number of FnR counters
*/
struct ipa_mem_data {
u32 local_count;
@@ -193,6 +194,8 @@ struct ipa_mem_data {
u32 imem_size; /* DEPRECATED */
u32 smem_size;
+
+ u8 fnr_idx_cnt;
};
/**
diff --git a/drivers/net/ipa/ipa_mem.c b/drivers/net/ipa/ipa_mem.c
index 078d32a18dbf..fb04f953bf7a 100644
--- a/drivers/net/ipa/ipa_mem.c
+++ b/drivers/net/ipa/ipa_mem.c
@@ -631,6 +631,8 @@ int ipa_mem_init(struct ipa *ipa, struct platform_device *pdev,
ipa->mem_count = mem_data->local_count;
ipa->mem = mem_data->local;
+ ipa->fnr_idx_cnt = mem_data->fnr_idx_cnt;
+
/* Check the route and filter table memory regions */
if (!ipa_table_mem_valid(ipa, false))
return -EINVAL;
diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
index d771f3a71f94..a5a5572c9ccd 100644
--- a/drivers/net/ipa/ipa_qmi.c
+++ b/drivers/net/ipa/ipa_qmi.c
@@ -74,6 +74,8 @@
#define IPA_MODEM_SERVICE_INS_ID 2
#define IPA_MODEM_SVC_VERS 1
+#define IPA_MODEM_FNR_IDX_START 128
+
#define QMI_INIT_DRIVER_TIMEOUT 60000 /* A minute in milliseconds */
/* Send an INIT_COMPLETE indication message to the modem */
@@ -394,6 +396,22 @@ init_modem_driver_req(struct ipa_qmi *ipa_qmi)
}
}
+ if (ipa->version >= IPA_VERSION_4_5 && ipa->fnr_idx_cnt) {
+ mem = ipa_mem_find(ipa, IPA_MEM_STATS_FILTER_ROUTE);
+ if (mem && mem->size) {
+ req.hw_stats_filter_info_valid = 1;
+ req.hw_stats_filter_info.start_addr =
+ ipa->mem_offset + mem->offset;
+ req.hw_stats_filter_info.size =
+ ipa->fnr_idx_cnt * 16;
+ req.hw_stats_filter_info.start_index =
+ IPA_MODEM_FNR_IDX_START;
+ req.hw_stats_filter_info.end_index =
+ IPA_MODEM_FNR_IDX_START +
+ ipa->fnr_idx_cnt - 1;
+ }
+ }
+
return &req;
}
diff --git a/drivers/net/ipa/ipa_qmi_msg.c b/drivers/net/ipa/ipa_qmi_msg.c
index 51dc13a577a5..160c0d207691 100644
--- a/drivers/net/ipa/ipa_qmi_msg.c
+++ b/drivers/net/ipa/ipa_qmi_msg.c
@@ -250,6 +250,43 @@ const struct qmi_elem_info ipa_mem_range_ei[] = {
},
};
+/* QMI message structure definition for struct ipa_stats_filter */
+const struct qmi_elem_info ipa_stats_filter_ei[] = {
+ {
+ .data_type = QMI_UNSIGNED_4_BYTE,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_stats_filter, start_addr),
+ .offset = offsetof(struct ipa_stats_filter,
+ start_addr),
+ },
+ {
+ .data_type = QMI_UNSIGNED_4_BYTE,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_stats_filter, size),
+ .offset = offsetof(struct ipa_stats_filter, size),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_stats_filter, start_index),
+ .offset = offsetof(struct ipa_stats_filter,
+ start_index),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_stats_filter, end_index),
+ .offset = offsetof(struct ipa_stats_filter, end_index),
+ },
+ {
+ .data_type = QMI_EOTI,
+ },
+};
+
/* QMI message structure definition for struct ipa_init_modem_driver_req */
const struct qmi_elem_info ipa_init_modem_driver_req_ei[] = {
{
@@ -640,6 +677,27 @@ const struct qmi_elem_info ipa_init_modem_driver_req_ei[] = {
.offset = offsetof(struct ipa_init_modem_driver_req,
hw_stats_drop_size),
},
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_init_modem_driver_req,
+ hw_stats_filter_info_valid),
+ .tlv_type = 0x23,
+ .offset = offsetof(struct ipa_init_modem_driver_req,
+ hw_stats_filter_info_valid),
+ },
+ {
+ .data_type = QMI_STRUCT,
+ .elem_len = 1,
+ .elem_size =
+ sizeof_field(struct ipa_init_modem_driver_req,
+ hw_stats_filter_info),
+ .tlv_type = 0x23,
+ .offset = offsetof(struct ipa_init_modem_driver_req,
+ hw_stats_filter_info),
+ .ei_array = ipa_stats_filter_ei,
+ },
{
.data_type = QMI_EOTI,
},
diff --git a/drivers/net/ipa/ipa_qmi_msg.h b/drivers/net/ipa/ipa_qmi_msg.h
index 644b8c27108b..3a2205c213d1 100644
--- a/drivers/net/ipa/ipa_qmi_msg.h
+++ b/drivers/net/ipa/ipa_qmi_msg.h
@@ -27,7 +27,7 @@
*/
#define IPA_QMI_INDICATION_REGISTER_REQ_SZ 20 /* -> server handle */
#define IPA_QMI_INDICATION_REGISTER_RSP_SZ 7 /* <- server handle */
-#define IPA_QMI_INIT_DRIVER_REQ_SZ 162 /* client handle -> */
+#define IPA_QMI_INIT_DRIVER_REQ_SZ 186 /* client handle -> */
#define IPA_QMI_INIT_DRIVER_RSP_SZ 25 /* client handle <- */
#define IPA_QMI_INIT_COMPLETE_IND_SZ 7 /* <- server handle */
#define IPA_QMI_DRIVER_INIT_COMPLETE_REQ_SZ 4 /* -> server handle */
@@ -119,6 +119,13 @@ struct ipa_mem_range {
u32 size;
};
+struct ipa_stats_filter {
+ u32 start_addr;
+ u32 size;
+ u8 start_index;
+ u8 end_index;
+};
+
/* The message for the IPA_QMI_INIT_DRIVER request contains information
* from the AP that affects modem initialization.
*/
@@ -216,6 +223,11 @@ struct ipa_init_modem_driver_req {
u32 hw_stats_drop_base_addr;
u8 hw_stats_drop_size_valid;
u32 hw_stats_drop_size;
+
+ /* Hardware filter statistics information. (IPA v4.5 and above)
+ */
+ u8 hw_stats_filter_info_valid;
+ struct ipa_stats_filter hw_stats_filter_info;
};
/* The response to a IPA_QMI_INIT_DRIVER request begins with a standard
@@ -256,6 +268,7 @@ extern const struct qmi_elem_info ipa_init_complete_ind_ei[];
extern const struct qmi_elem_info ipa_mem_bounds_ei[];
extern const struct qmi_elem_info ipa_mem_array_ei[];
extern const struct qmi_elem_info ipa_mem_range_ei[];
+extern const struct qmi_elem_info ipa_stats_filter_ei[];
extern const struct qmi_elem_info ipa_init_modem_driver_req_ei[];
extern const struct qmi_elem_info ipa_init_modem_driver_rsp_ei[];
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 4/4] net: ipa: add Eliza configuration data
From: Alexander Koskovich @ 2026-04-16 22:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: linux-arm-msm, netdev, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260416-eliza-ipa-v1-0-f4109a8e43c4@pm.me>
Add the configuration data required for Eliza, which uses IPA v5.5. The
difference over other platforms that use IPA 5.5 is the Q6 FnR counters
have been increased on the firmware version it uses, which results in a
different memory layout.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
drivers/net/ipa/data/ipa_data-v5.5.c | 163 +++++++++++++++++++++++++++++++++++
drivers/net/ipa/ipa_data.h | 1 +
drivers/net/ipa/ipa_main.c | 4 +
3 files changed, 168 insertions(+)
diff --git a/drivers/net/ipa/data/ipa_data-v5.5.c b/drivers/net/ipa/data/ipa_data-v5.5.c
index 44a9df7346b7..e1454454bde9 100644
--- a/drivers/net/ipa/data/ipa_data-v5.5.c
+++ b/drivers/net/ipa/data/ipa_data-v5.5.c
@@ -288,6 +288,148 @@ static const struct ipa_resource_data ipa_resource_data = {
.resource_dst = ipa_resource_dst,
};
+/* IPA-resident memory region data for the Eliza SoC */
+static const struct ipa_mem ipa_mem_local_data_eliza[] = {
+ {
+ .id = IPA_MEM_UC_EVENT_RING,
+ .offset = 0x0000,
+ .size = 0x1000,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_UC_SHARED,
+ .offset = 0x1000,
+ .size = 0x0080,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_UC_INFO,
+ .offset = 0x1080,
+ .size = 0x0200,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_V4_FILTER_HASHED,
+ .offset = 0x1288,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_FILTER,
+ .offset = 0x1308,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_FILTER_HASHED,
+ .offset = 0x1388,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_FILTER,
+ .offset = 0x1408,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_ROUTE_HASHED,
+ .offset = 0x1488,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_ROUTE,
+ .offset = 0x1528,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_ROUTE_HASHED,
+ .offset = 0x15c8,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_ROUTE,
+ .offset = 0x1668,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_MODEM_HEADER,
+ .offset = 0x1708,
+ .size = 0x0240,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_AP_HEADER,
+ .offset = 0x1948,
+ .size = 0x01e0,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_MODEM_PROC_CTX,
+ .offset = 0x1b40,
+ .size = 0x0b20,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_AP_PROC_CTX,
+ .offset = 0x2660,
+ .size = 0x0200,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_QUOTA_MODEM,
+ .offset = 0x2868,
+ .size = 0x0060,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_STATS_QUOTA_AP,
+ .offset = 0x28c8,
+ .size = 0x0048,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_TETHERING,
+ .offset = 0x2910,
+ .size = 0x03c0,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_FILTER_ROUTE,
+ .offset = 0x2cd0,
+ .size = 0x0c40,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_STATS_DROP,
+ .offset = 0x3910,
+ .size = 0x0020,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_MODEM,
+ .offset = 0x3938,
+ .size = 0x0d48,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_NAT_TABLE,
+ .offset = 0x4680,
+ .size = 0x0900,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_PDN_CONFIG,
+ .offset = 0x4f88,
+ .size = 0x0050,
+ .canary_count = 2,
+ },
+};
+
/* IPA-resident memory region data for an SoC having IPA v5.5 */
static const struct ipa_mem ipa_mem_local_data[] = {
{
@@ -442,6 +584,14 @@ static const struct ipa_mem ipa_mem_local_data[] = {
},
};
+/* Memory configuration data for the Eliza SoC */
+static const struct ipa_mem_data ipa_mem_data_eliza = {
+ .local_count = ARRAY_SIZE(ipa_mem_local_data_eliza),
+ .local = ipa_mem_local_data_eliza,
+ .smem_size = 0x0000b000,
+ .fnr_idx_cnt = 68,
+};
+
/* Memory configuration data for an SoC having IPA v5.5 */
static const struct ipa_mem_data ipa_mem_data = {
.local_count = ARRAY_SIZE(ipa_mem_local_data),
@@ -486,3 +636,16 @@ const struct ipa_data ipa_data_v5_5 = {
.mem_data = &ipa_mem_data,
.power_data = &ipa_power_data,
};
+
+/* Configuration data for the Eliza SoC (IPA v5.5). */
+const struct ipa_data ipa_data_v5_5_eliza = {
+ .version = IPA_VERSION_5_5,
+ .qsb_count = ARRAY_SIZE(ipa_qsb_data),
+ .qsb_data = ipa_qsb_data,
+ .modem_route_count = 11,
+ .endpoint_count = ARRAY_SIZE(ipa_gsi_endpoint_data),
+ .endpoint_data = ipa_gsi_endpoint_data,
+ .resource_data = &ipa_resource_data,
+ .mem_data = &ipa_mem_data_eliza,
+ .power_data = &ipa_power_data,
+};
diff --git a/drivers/net/ipa/ipa_data.h b/drivers/net/ipa/ipa_data.h
index f7566c8edabd..da01fc84edac 100644
--- a/drivers/net/ipa/ipa_data.h
+++ b/drivers/net/ipa/ipa_data.h
@@ -258,5 +258,6 @@ extern const struct ipa_data ipa_data_v4_11;
extern const struct ipa_data ipa_data_v5_0;
extern const struct ipa_data ipa_data_v5_2;
extern const struct ipa_data ipa_data_v5_5;
+extern const struct ipa_data ipa_data_v5_5_eliza;
#endif /* _IPA_DATA_H_ */
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index 788dd99af2a4..981be8b538d0 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -637,6 +637,10 @@ static int ipa_firmware_load(struct device *dev)
}
static const struct of_device_id ipa_match[] = {
+ {
+ .compatible = "qcom,eliza-ipa",
+ .data = &ipa_data_v5_5_eliza,
+ },
{
.compatible = "qcom,msm8998-ipa",
.data = &ipa_data_v3_1,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v10 08/12] kvm: Define EXPORT_STATIC_CALL_FOR_KVM()
From: Sean Christopherson @ 2026-04-16 22:44 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260414-vmscape-bhb-v10-8-efa924abae5f@linux.intel.com>
On Tue, Apr 14, 2026, Pawan Gupta wrote:
> EXPORT_SYMBOL_FOR_KVM() exists to export symbols to KVM modules. Static
> calls need the same treatment when the core kernel defines a static_call
> that KVM needs access to (e.g. from a VM-exit path).
>
> Define EXPORT_STATIC_CALL_FOR_KVM() as the static_call analogue of
> EXPORT_SYMBOL_FOR_KVM(). The same three-way logic applies:
>
> - KVM_SUB_MODULES defined: export to "kvm," plus all sub-modules
> - KVM=m, no sub-modules: export to "kvm" only
> - KVM built-in: no export needed (noop)
>
> As with EXPORT_SYMBOL_FOR_KVM(), allow architectures to override the
> definition (e.g. to suppress the export when kvm.ko itself will not be
> built despite CONFIG_KVM=m). Add the x86 no-op override in
> arch/x86/include/asm/kvm_types.h for that case.
>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/include/asm/kvm_types.h | 1 +
> include/linux/kvm_types.h | 13 ++++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kvm_types.h b/arch/x86/include/asm/kvm_types.h
> index d7c704ed1be9..bceeaed2940e 100644
> --- a/arch/x86/include/asm/kvm_types.h
> +++ b/arch/x86/include/asm/kvm_types.h
> @@ -15,6 +15,7 @@
> * at least one vendor module is enabled.
> */
> #define EXPORT_SYMBOL_FOR_KVM(symbol)
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
> #endif
>
> #define KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE 40
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index a568d8e6f4e8..c81f4fdba625 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -13,6 +13,8 @@
> EXPORT_SYMBOL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
> #define EXPORT_SYMBOL_FOR_KVM(symbol) \
> EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol) \
> + EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
> #else
> #define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol)
> /*
> @@ -27,7 +29,16 @@
> #define EXPORT_SYMBOL_FOR_KVM(symbol)
> #endif /* IS_MODULE(CONFIG_KVM) */
> #endif /* EXPORT_SYMBOL_FOR_KVM */
> -#endif
> +
> +#ifndef EXPORT_STATIC_CALL_FOR_KVM
> +#if IS_MODULE(CONFIG_KVM)
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol) EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm")
> +#else
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
> +#endif /* IS_MODULE(CONFIG_KVM) */
> +#endif /* EXPORT_STATIC_CALL_FOR_KVM */
> +
> +#endif /* KVM_SUB_MODULES */
I think I'd prefer to require EXPORT_SYMBOL_FOR_KVM and EXPORT_STATIC_CALL_FOR_KVM
to come as a pair from arch code. I can't think of a scenario where arch code
should override one but not the other. The end result is slightly less ugly :-)
---
arch/x86/include/asm/kvm_types.h | 1 +
include/linux/kvm_types.h | 10 +++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_types.h b/arch/x86/include/asm/kvm_types.h
index d7c704ed1be9..bceeaed2940e 100644
--- a/arch/x86/include/asm/kvm_types.h
+++ b/arch/x86/include/asm/kvm_types.h
@@ -15,6 +15,7 @@
* at least one vendor module is enabled.
*/
#define EXPORT_SYMBOL_FOR_KVM(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
#endif
#define KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE 40
diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index a568d8e6f4e8..be602d3f287e 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -13,6 +13,8 @@
EXPORT_SYMBOL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
#define EXPORT_SYMBOL_FOR_KVM(symbol) \
EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) \
+ EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
#else
#define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol)
/*
@@ -23,11 +25,17 @@
#ifndef EXPORT_SYMBOL_FOR_KVM
#if IS_MODULE(CONFIG_KVM)
#define EXPORT_SYMBOL_FOR_KVM(symbol) EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm")
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm")
#else
#define EXPORT_SYMBOL_FOR_KVM(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
#endif /* IS_MODULE(CONFIG_KVM) */
+#else
+#ifndef EXPORT_STATIC_CALL_FOR_KVM
+#error Must #define EXPORT_STATIC_CALL_FOR_KVM if #defining EXPORT_SYMBOL_FOR_KVM
+#endif
#endif /* EXPORT_SYMBOL_FOR_KVM */
-#endif
+#endif /* KVM_SUB_MODULES */
#ifndef __ASSEMBLER__
base-commit: 56b7ace84970ff647b095849e80bc36c094760aa
--
^ permalink raw reply related
* Re: [PATCH v10 09/12] x86/vmscape: Use static_call() for predictor flush
From: Sean Christopherson @ 2026-04-16 22:45 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260414-vmscape-bhb-v10-9-efa924abae5f@linux.intel.com>
On Tue, Apr 14, 2026, Pawan Gupta wrote:
> Adding more mitigation options at exit-to-userspace for VMSCAPE would
> usually require a series of checks to decide which mitigation to use. In
> this case, the mitigation is done by calling a function, which is decided
> at boot. So, adding more feature flags and multiple checks can be avoided
> by using static_call() to the mitigating function.
>
> Replace the flag-based mitigation selector with a static_call(). This also
> frees the existing X86_FEATURE_IBPB_EXIT_TO_USER.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Tested-by: Jon Kohler <jon@nutanix.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
For the KVM change,
Acked-by: Sean Christopherson <seanjc@google.com>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 45d7cfedc507..5582056b2fa1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11463,7 +11463,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> * set for the CPU that actually ran the guest, and not the CPU that it
> * may migrate to.
> */
> - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> + if (static_call_query(vmscape_predictor_flush))
> this_cpu_write(x86_predictor_flush_exit_to_user, true);
>
> /*
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net v3 5/5] iavf: refactor virtchnl polling into single function
From: Jacob Keller @ 2026-04-16 23:09 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, aleksandr.loktionov
Cc: anthony.l.nguyen, davem, edumazet, intel-wired-lan,
jesse.brandeburg, kuba, netdev, pabeni, przemyslaw.kitszel
In-Reply-To: <20260416055141.19127-1-jtornosm@redhat.com>
On 4/15/2026 10:51 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Aleksandr,
>
> Thank you for your comments.
> I wanted to link this patch in some way with patch 3/5, but you are right,
> perhaps as a refactoring, better for net-next.
The cleanup makes sense as next material, but the other patches fix bugs
that could (should?) still target net, right?
> Anyway, I am going to wait for Przemek and
> "iavf: add iavf_poll_virtchnl_response()" merge, after that I will rebase
> and I will create another version of the series, dropping this for now.
>
> Best regards
> Jose Ignacio
>
I'll drop this version from the Intel Wired LAN patchwork then.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v10 08/12] kvm: Define EXPORT_STATIC_CALL_FOR_KVM()
From: Pawan Gupta @ 2026-04-16 23:12 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <aeFmYd1ybZnVlAYW@google.com>
On Thu, Apr 16, 2026 at 03:44:49PM -0700, Sean Christopherson wrote:
> I think I'd prefer to require EXPORT_SYMBOL_FOR_KVM and EXPORT_STATIC_CALL_FOR_KVM
> to come as a pair from arch code. I can't think of a scenario where arch code
> should override one but not the other.
Right, will change as you suggested.
^ permalink raw reply
* Re: [PATCH v11 net-next 2/5] psp: add new netlink cmd for dev-assoc and dev-disassoc
From: Wei Wang @ 2026-04-16 23:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jakub Kicinski, Daniel Zahka, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman,
Wei Wang
In-Reply-To: <CAGqc4nVZA+XSPbeO5_0OUvXzG1TMtqScrzNaUpuK0rVnR2ZFng@mail.gmail.com>
On Wed, Apr 15, 2026 at 8:55 PM Wei Wang <weibunny.kernel@gmail.com> wrote:
>
> On Mon, Apr 13, 2026 at 3:37 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> >
> >
> > On 4/9/26 1:14 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>
> > > Reviewed-by: Daniel Zahka <daniel.zahka@gmail.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 | 325 ++++++++++++++++++++++++++-
> > > 7 files changed, 462 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/Documentation/netlink/specs/psp.yaml b/Documentation/netlink/specs/psp.yaml
> > > index c54e1202cbe0..3d1b7223e084 100644
> > > --- a/Documentation/netlink/specs/psp.yaml
> > > +++ b/Documentation/netlink/specs/psp.yaml
> > > @@ -13,6 +13,17 @@ definitions:
> > > hdr0-aes-gmac-128, hdr0-aes-gmac-256]
> > >
> > > attribute-sets:
> > > + -
> > > + name: assoc-dev-info
> > > + attributes:
> > > + -
> > > + name: ifindex
> > > + doc: ifindex of an associated network device.
> > > + type: u32
> > > + -
> > > + name: nsid
> > > + doc: Network namespace ID of the associated device.
> > > + type: s32
> > > -
> > > name: dev
> > > attributes:
> > > @@ -24,7 +35,9 @@ attribute-sets:
> > > min: 1
> > > -
> > > name: ifindex
> > > - doc: ifindex of the main netdevice linked to the PSP device.
> > > + doc: |
> > > + ifindex of the main netdevice linked to the PSP device,
> > > + or the ifindex to associate with the PSP device.
> > > type: u32
> > > -
> > > name: psp-versions-cap
> > > @@ -38,6 +51,28 @@ attribute-sets:
> > > type: u32
> > > enum: version
> > > enum-as-flags: true
> > > + -
> > > + name: assoc-list
> > > + doc: List of associated virtual devices.
> > > + type: nest
> > > + nested-attributes: assoc-dev-info
> > > + multi-attr: true
> > > + -
> > > + name: nsid
> > > + doc: |
> > > + Network namespace ID for the device to associate/disassociate.
> > > + Optional for dev-assoc and dev-disassoc; if not present, the
> > > + device is looked up in the caller's network namespace.
> > > + type: s32
> > > + -
> > > + name: by-association
> > > + doc: |
> > > + Flag indicating the PSP device is an associated device from a
> > > + different network namespace.
> > > + Present when in associated namespace, absent when in primary/host
> > > + namespace.
> > > + type: flag
> > > +
> > > -
> > > name: assoc
> > > attributes:
> > > @@ -170,6 +205,8 @@ operations:
> > > - ifindex
> > > - psp-versions-cap
> > > - psp-versions-ena
> > > + - assoc-list
> > > + - by-association
> > > pre: psp-device-get-locked
> > > post: psp-device-unlock
> > > dump:
> > > @@ -279,6 +316,34 @@ operations:
> > > post: psp-device-unlock
> > > dump:
> > > reply: *stats-all
> > > + -
> > > + name: dev-assoc
> > > + doc: Associate a network device with a PSP device.
> > > + attribute-set: dev
> > > + do:
> > > + request:
> > > + attributes:
> > > + - id
> > > + - ifindex
> > > + - nsid
> > > + reply:
> > > + attributes: []
> > > + pre: psp-device-get-locked
> > > + post: psp-device-unlock
> > > + -
> > > + name: dev-disassoc
> > > + doc: Disassociate a network device from a PSP device.
> > > + attribute-set: dev
> > > + do:
> > > + request:
> > > + attributes:
> > > + - id
> > > + - ifindex
> > > + - nsid
> > > + reply:
> > > + attributes: []
> > > + pre: psp-device-get-locked
> > > + post: psp-device-unlock
> > >
> > > mcast-groups:
> > > list:
> > > diff --git a/include/net/psp/types.h b/include/net/psp/types.h
> > > index 25a9096d4e7d..4bd432ed107a 100644
> > > --- a/include/net/psp/types.h
> > > +++ b/include/net/psp/types.h
> > > @@ -5,6 +5,7 @@
> > >
> > > #include <linux/mutex.h>
> > > #include <linux/refcount.h>
> > > +#include <net/net_trackers.h>
> > >
> > > struct netlink_ext_ack;
> > >
> > > @@ -43,9 +44,22 @@ struct psp_dev_config {
> > > u32 versions;
> > > };
> > >
> > > +/**
> > > + * struct psp_assoc_dev - wrapper for associated net_device
> > > + * @dev_list: list node for psp_dev::assoc_dev_list
> > > + * @assoc_dev: the associated net_device
> > > + * @dev_tracker: tracker for the net_device reference
> > > + */
> > > +struct psp_assoc_dev {
> > > + struct list_head dev_list;
> > > + struct net_device *assoc_dev;
> > > + netdevice_tracker dev_tracker;
> > > +};
> > > +
> > > /**
> > > * struct psp_dev - PSP device struct
> > > * @main_netdev: original netdevice of this PSP device
> > > + * @assoc_dev_list: list of psp_assoc_dev entries associated with this PSP device
> > > * @ops: driver callbacks
> > > * @caps: device capabilities
> > > * @drv_priv: driver priv pointer
> > > @@ -67,6 +81,7 @@ struct psp_dev_config {
> > > */
> > > struct psp_dev {
> > > struct net_device *main_netdev;
> > > + struct list_head assoc_dev_list;
> > >
> > > struct psp_dev_ops *ops;
> > > struct psp_dev_caps *caps;
> > > diff --git a/include/uapi/linux/psp.h b/include/uapi/linux/psp.h
> > > index a3a336488dc3..1c8899cd4da5 100644
> > > --- a/include/uapi/linux/psp.h
> > > +++ b/include/uapi/linux/psp.h
> > > @@ -17,11 +17,22 @@ enum psp_version {
> > > PSP_VERSION_HDR0_AES_GMAC_256,
> > > };
> > >
> > > +enum {
> > > + PSP_A_ASSOC_DEV_INFO_IFINDEX = 1,
> > > + PSP_A_ASSOC_DEV_INFO_NSID,
> > > +
> > > + __PSP_A_ASSOC_DEV_INFO_MAX,
> > > + PSP_A_ASSOC_DEV_INFO_MAX = (__PSP_A_ASSOC_DEV_INFO_MAX - 1)
> > > +};
> > > +
> > > enum {
> > > PSP_A_DEV_ID = 1,
> > > PSP_A_DEV_IFINDEX,
> > > PSP_A_DEV_PSP_VERSIONS_CAP,
> > > PSP_A_DEV_PSP_VERSIONS_ENA,
> > > + PSP_A_DEV_ASSOC_LIST,
> > > + PSP_A_DEV_NSID,
> > > + PSP_A_DEV_BY_ASSOCIATION,
> > >
> > > __PSP_A_DEV_MAX,
> > > PSP_A_DEV_MAX = (__PSP_A_DEV_MAX - 1)
> > > @@ -74,6 +85,8 @@ enum {
> > > PSP_CMD_RX_ASSOC,
> > > PSP_CMD_TX_ASSOC,
> > > PSP_CMD_GET_STATS,
> > > + PSP_CMD_DEV_ASSOC,
> > > + PSP_CMD_DEV_DISASSOC,
> > >
> > > __PSP_CMD_MAX,
> > > PSP_CMD_MAX = (__PSP_CMD_MAX - 1)
> > > diff --git a/net/psp/psp-nl-gen.c b/net/psp/psp-nl-gen.c
> > > index 1f5e73e7ccc1..114299c64423 100644
> > > --- a/net/psp/psp-nl-gen.c
> > > +++ b/net/psp/psp-nl-gen.c
> > > @@ -53,6 +53,20 @@ static const struct nla_policy psp_get_stats_nl_policy[PSP_A_STATS_DEV_ID + 1] =
> > > [PSP_A_STATS_DEV_ID] = NLA_POLICY_MIN(NLA_U32, 1),
> > > };
> > >
> > > +/* PSP_CMD_DEV_ASSOC - do */
> > > +static const struct nla_policy psp_dev_assoc_nl_policy[PSP_A_DEV_NSID + 1] = {
> > > + [PSP_A_DEV_ID] = NLA_POLICY_MIN(NLA_U32, 1),
> > > + [PSP_A_DEV_IFINDEX] = { .type = NLA_U32, },
> > > + [PSP_A_DEV_NSID] = { .type = NLA_S32, },
> > > +};
> > > +
> > > +/* PSP_CMD_DEV_DISASSOC - do */
> > > +static const struct nla_policy psp_dev_disassoc_nl_policy[PSP_A_DEV_NSID + 1] = {
> > > + [PSP_A_DEV_ID] = NLA_POLICY_MIN(NLA_U32, 1),
> > > + [PSP_A_DEV_IFINDEX] = { .type = NLA_U32, },
> > > + [PSP_A_DEV_NSID] = { .type = NLA_S32, },
> > > +};
> > > +
> > > /* Ops table for psp */
> > > static const struct genl_split_ops psp_nl_ops[] = {
> > > {
> > > @@ -119,6 +133,24 @@ static const struct genl_split_ops psp_nl_ops[] = {
> > > .dumpit = psp_nl_get_stats_dumpit,
> > > .flags = GENL_CMD_CAP_DUMP,
> > > },
> > > + {
> > > + .cmd = PSP_CMD_DEV_ASSOC,
> > > + .pre_doit = psp_device_get_locked,
> > > + .doit = psp_nl_dev_assoc_doit,
> > > + .post_doit = psp_device_unlock,
> > > + .policy = psp_dev_assoc_nl_policy,
> > > + .maxattr = PSP_A_DEV_NSID,
> > > + .flags = GENL_CMD_CAP_DO,
> > > + },
> > > + {
> > > + .cmd = PSP_CMD_DEV_DISASSOC,
> > > + .pre_doit = psp_device_get_locked,
> > > + .doit = psp_nl_dev_disassoc_doit,
> > > + .post_doit = psp_device_unlock,
> > > + .policy = psp_dev_disassoc_nl_policy,
> > > + .maxattr = PSP_A_DEV_NSID,
> > > + .flags = GENL_CMD_CAP_DO,
> >
> > Sashiko notes that the above allows deleteing an associations bypassing
> > the netns boundaries. Do you need ADMIN_PERM flag or exlicit checks in
> > the doit cb?
>
> I think the concern is if we are calling this from an assoc_dev's
> netns, it should not allow it to delete any assoc_dev from other
> assoc_dev's netns. Right?
> I will add a check to only allow deletion of assoc_dev from its own
> netns. (except main_dev's netns).
>
Further on this point, I think a cleaner solution is to just reject
user passing in nsid if the user is not in dev_net(psd->main_netdev).
In such situation, we should only do dev-assoc/dev-disassoc within the
current user netns. So no point of passing in nsid.
We only allow nsid to be passed in if the user is in
dev_net(psd->main_netdev), i.e. admin user.
Let me know your thoughts on this. @Daniel Zahka @Paolo Abeni
> >
> > > @@ -292,6 +455,145 @@ int psp_nl_key_rotate_doit(struct sk_buff *skb, struct genl_info *info)
> > > return err;
> > > }
> > >
> > > +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, err;
> > > +
> > > + 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_nl_dev_disassoc_doit() has the same code; perhaps it would be worthy
> > move it in a common helper, called via pre_doit()? It should also
> > simplify the cleanup paths.
> >
>
> Ack.
>
> > > +
> > > + psp_assoc_dev = kzalloc(sizeof(*psp_assoc_dev), GFP_KERNEL);
> > > + if (!psp_assoc_dev) {
> > > + err = -ENOMEM;
> > > + goto alloc_err;
> > > + }
> > > +
> > > + 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) {
> > > + NL_SET_BAD_ATTR(info->extack, info->attrs[PSP_A_DEV_IFINDEX]);
> > > + err = -ENODEV;
> > > + goto assoc_dev_err;
> > > + }
> > > +
> > > + /* 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");
> > > + err = -EBUSY;
> > > + goto cmpxchg_err;
> > > + }
> > > +
> > > + psp_assoc_dev->assoc_dev = assoc_dev;
> > > + rsp = psp_nl_reply_new(info);
> > > + if (!rsp) {
> > > + err = -ENOMEM;
> > > + goto rsp_err;
> > > + }
> > > +
> > > + list_add_tail(&psp_assoc_dev->dev_list, &psd->assoc_dev_list);
> >
> > Sashiko says:
> >
> > ---
> > list_add_tail(&psp_assoc_dev->dev_list, &psd->assoc_dev_list);
> > There doesn't seem to be a limit on the number of devices that can be
> > associated with a single PSP device.
> > If a user repeatedly associates devices, could the generated netlink message
> > in psp_nl_dev_fill() exceed the maximum allowed size (GENLMSG_DEFAULT_SIZE),
> > causing it to fail with -EMSGSIZE and permanently break PSP_CMD_DEV_GET
> > and management notifications for the device?
> > --
>
> Ack. Will enforce a max allowed number on the assoc_dev_list to fit
> into GENLMSG_DEFAULT_SIZE.
>
> >
> > /P
> >
^ permalink raw reply
* Re: [PATCH net] eth: fbnic: fix double-free of PCS on phylink creation failure
From: Andrew Lunn @ 2026-04-16 23:48 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Russell King, netdev,
linux-kernel, Bobby Eshleman
In-Reply-To: <aeFam/KxhZSMl6xq@devvm29614.prn0.facebook.com>
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> index e3ca5fcfabef..2a6a73393732 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
> @@ -818,7 +818,8 @@ struct net_device *fbnic_netdev_alloc(struct fbnic_dev *fbd)
> netif_tx_stop_all_queues(netdev);
>
> if (fbnic_phylink_create(netdev)) {
> - fbnic_netdev_free(fbd);
> + free_netdev(netdev);
> + fbd->netdev = NULL;
Why set it to NULL? Setting pointers to NULL like this often suggests
you are not confident the code is correct and you are being
defensive. It is better to review the code and be sure it does the
correct thing.
> return NULL;
> }
>
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c b/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
> index 09c5225111be..50240e6c2ee9 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
> @@ -237,6 +237,7 @@ int fbnic_phylink_create(struct net_device *netdev)
> dev_err(netdev->dev.parent,
> "Failed to create Phylink interface, err: %d\n", err);
> xpcs_destroy_pcs(pcs);
> + fbn->pcs = NULL;
Why set it to NULL? If it failed, you are unwinding and about to fail
the probe. Nothing should be using it.
I would also say fbnic_phylink_destroy() is wrong or at least whoever
wrote it is not confident in there own code. It should only be called
if fbnic_phylink_create() was successful, so you know fbn->pcs is
valid, so there is no need to test it. The same for fbn->phylink.
Andrew
^ permalink raw reply
* [PATCH net v2 00/12] Intel Wired LAN Driver Updates 2026-04-14 (ice, i40e, iavf, idpf, e1000e)
From: Jacob Keller @ 2026-04-17 0:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, Jacob Keller, Grzegorz Nitka, Aleksandr Loktionov,
Simon Horman, Rinitha S, Zoltan Fodor, Sunitha Mekala,
Guangshuo Li, stable, Michal Schmidt, Paul Greenwalt,
Przemek Kitszel, Keita Morisaki, Kohei Enju, Petr Oros,
Paul Menzel, Rafal Romanowski, Emil Tantilov, Patryk Holda,
Matt Vollrath, Avigail Dahan
Grzegorz updates the logic for adjusting the PTP hardware clock on E830,
fixing a bug that prevented adjustments below S32_MAX/MIN nanoseconds.
Grzegorz and Zoli update the PCS latency settings for E825 devices at 10GbE
and 25GbE, improving the accuracy of timestamps based on data from
production hardware.
Michal Schmidt fixes a double-free that could happen if a particular error
path is taken in ice_xmit_frame_ring().
Guangshuo fixes a double-free that could happen during error paths in the
ice_sf_eth_activate() function.
Paul Greenwalt fixes the PHY link configuration when the link-down-on-close
driver parameter is enabled and new media is inserted.
Paul Greenwalt fixes the ICE_AQ_LINK_SPEED_M macro for 200G, enabling 200G
link speed advertisement.
Keita Morisaki fixes a race condition in the ice Tx timestamp ring cleanup,
preventing a possible NULL pointer dereference.
Kohei Enju fixes a potential NULL pointer dereference in ice_set_ring_param().
Kohei Enju fixes i40e to stop advertising IFF_SUPP_NOFCS, when the driver
does not actually support the feature.
Petr fixes the VLAN L2TAG2 mask when the iAVF VF and a PF negotiate use of
the legacy Rx descriptor format.
Emil fixes a NULL pointer dereference that can happen in the soft reset if
a particular error path is taken.
Matt fixes the unrolling logic for PTP when the e1000e probe fails after
the PTP clock has been registered.
**A note to stable backports**
The patches [7/12] ("ice: fix race condition in TX timestamp ring
cleanup") and [8/12] ("ice: fix potential NULL pointer deref in error
path of ice_set_ringparam()") must be backported together. Otherwise the
fix in patch 8 will not work properly.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
Changes in v2:
- Drop patch 10/13 ("i40e: fix napi_enable/disable skipping ringless
q_vector").
- Link to v1: https://patch.msgid.link/20260414-iwl-net-submission-2026-04-14-v1-0-852f38e7da39@intel.com
---
Emil Tantilov (1):
idpf: fix xdp crash in soft reset error path
Grzegorz Nitka (2):
ice: fix 'adjust' timer programming for E830 devices
ice: update PCS latency settings for E825 10G/25Gb modes
Guangshuo Li (1):
ice: fix double free in ice_sf_eth_activate() error path
Keita Morisaki (1):
ice: fix race condition in TX timestamp ring cleanup
Kohei Enju (2):
ice: fix potential NULL pointer deref in error path of ice_set_ringparam()
i40e: don't advertise IFF_SUPP_NOFCS
Matt Vollrath (1):
e1000e: Unroll PTP in probe error handling
Michal Schmidt (1):
ice: fix double-free of tx_buf skb
Paul Greenwalt (2):
ice: fix PHY config on media change with link-down-on-close
ice: fix ICE_AQ_LINK_SPEED_M for 200G
Petr Oros (1):
iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2
drivers/net/ethernet/intel/iavf/iavf_type.h | 2 +-
drivers/net/ethernet/intel/ice/ice.h | 4 +-
drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 2 +-
drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 12 +--
drivers/net/ethernet/intel/ice/ice_txrx.h | 16 ++--
drivers/net/ethernet/intel/e1000e/netdev.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 1 -
drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 2 +-
drivers/net/ethernet/intel/ice/ice_ethtool.c | 1 +
drivers/net/ethernet/intel/ice/ice_lib.c | 4 +-
drivers/net/ethernet/intel/ice/ice_main.c | 121 ++++++------------------
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 6 +-
drivers/net/ethernet/intel/ice/ice_sf_eth.c | 2 +
drivers/net/ethernet/intel/ice/ice_txrx.c | 29 ++++--
drivers/net/ethernet/intel/idpf/xdp.c | 1 +
drivers/net/ethernet/intel/idpf/xsk.c | 4 +-
16 files changed, 81 insertions(+), 127 deletions(-)
---
base-commit: 52bcb57a4e8a0865a76c587c2451906342ae1b2d
change-id: 20260414-iwl-net-submission-2026-04-14-6203e1860df3
Best regards,
--
Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* [PATCH net v2 01/12] ice: fix 'adjust' timer programming for E830 devices
From: Jacob Keller @ 2026-04-17 0:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, Jacob Keller, Grzegorz Nitka, Aleksandr Loktionov,
Simon Horman, Rinitha S
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
From: Grzegorz Nitka <grzegorz.nitka@intel.com>
Fix incorrect 'adjust the timer' programming sequence for E830 devices
series. Only shadow registers GLTSYN_SHADJ were programmed in the
current implementation. According to the specification [1], write to
command GLTSYN_CMD register is also required with CMD field set to
"Adjust the Time" value, for the timer adjustment to take the effect.
The flow was broken for the adjustment less than S32_MAX/MIN range
(around +/- 2 seconds). For bigger adjustment, non-atomic programming
flow is used, involving set timer programming. Non-atomic flow is
implemented correctly.
Testing hints:
Run command:
phc_ctl /dev/ptpX get adj 2 get
Expected result:
Returned timestamps differ at least by 2 seconds
[1] Intel® Ethernet Controller E830 Datasheet rev 1.3, chapter 9.7.5.4
https://cdrdv2.intel.com/v1/dl/getContent/787353?explicitVersion=true
Fixes: f00307522786 ("ice: Implement PTP support for E830 devices")
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 61c0a0d93ea8..5a5c511ccbb6 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -5381,8 +5381,8 @@ int ice_ptp_write_incval_locked(struct ice_hw *hw, u64 incval)
*/
int ice_ptp_adj_clock(struct ice_hw *hw, s32 adj)
{
+ int err = 0;
u8 tmr_idx;
- int err;
tmr_idx = hw->func_caps.ts_func_info.tmr_index_owned;
@@ -5399,8 +5399,8 @@ int ice_ptp_adj_clock(struct ice_hw *hw, s32 adj)
err = ice_ptp_prep_phy_adj_e810(hw, adj);
break;
case ICE_MAC_E830:
- /* E830 sync PHYs automatically after setting GLTSYN_SHADJ */
- return 0;
+ /* E830 sync PHYs automatically after setting cmd register */
+ break;
case ICE_MAC_GENERIC:
err = ice_ptp_prep_phy_adj_e82x(hw, adj);
break;
--
2.54.0.rc2.531.gaf818d63126a
^ permalink raw reply related
* [PATCH net v2 02/12] ice: update PCS latency settings for E825 10G/25Gb modes
From: Jacob Keller @ 2026-04-17 0:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, Jacob Keller, Grzegorz Nitka, Zoltan Fodor,
Aleksandr Loktionov, Sunitha Mekala
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
From: Grzegorz Nitka <grzegorz.nitka@intel.com>
Update MAC Rx/Tx offset registers settings (PHY_MAC_[RX|TX]_OFFSET
registers) with the data obtained with the latest research. It applies
to PCS latency settings for the following speeds/modes:
* 10Gb NO-FEC
- TX latency changed from 71.25 ns to 73 ns
- RX latency changed from -25.6 ns to -28 ns
* 25Gb NO-FEC
- TX latency changed from 28.17 ns to 33 ns
- RX latency changed from -12.45 ns to -12 ns
* 25Gb RS-FEC
- TX latency changed from 64.5 ns to 69 ns
- RX latency changed from -3.6 ns to -3 ns
The original data came from simulation and pre-production hardware.
The new data measures the actual delays and as such is more accurate.
Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Co-developed-by: Zoltan Fodor <zoltan.fodor@intel.com>
Signed-off-by: Zoltan Fodor <zoltan.fodor@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_consts.h b/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
index 19dddd9b53dd..4d298c27bfb2 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
@@ -78,14 +78,14 @@ struct ice_eth56g_mac_reg_cfg eth56g_mac_cfg[NUM_ICE_ETH56G_LNK_SPD] = {
.blktime = 0x666, /* 3.2 */
.tx_offset = {
.serdes = 0x234c, /* 17.6484848 */
- .no_fec = 0x8e80, /* 71.25 */
+ .no_fec = 0x93d9, /* 73 */
.fc = 0xb4a4, /* 90.32 */
.sfd = 0x4a4, /* 2.32 */
.onestep = 0x4ccd /* 38.4 */
},
.rx_offset = {
.serdes = 0xffffeb27, /* -10.42424 */
- .no_fec = 0xffffcccd, /* -25.6 */
+ .no_fec = 0xffffc7b6, /* -28 */
.fc = 0xfffc557b, /* -469.26 */
.sfd = 0x4a4, /* 2.32 */
.bs_ds = 0x32 /* 0.0969697 */
@@ -118,17 +118,17 @@ struct ice_eth56g_mac_reg_cfg eth56g_mac_cfg[NUM_ICE_ETH56G_LNK_SPD] = {
.mktime = 0x147b, /* 10.24, only if RS-FEC enabled */
.tx_offset = {
.serdes = 0xe1e, /* 7.0593939 */
- .no_fec = 0x3857, /* 28.17 */
+ .no_fec = 0x4266, /* 33 */
.fc = 0x48c3, /* 36.38 */
- .rs = 0x8100, /* 64.5 */
+ .rs = 0x8a00, /* 69 */
.sfd = 0x1dc, /* 0.93 */
.onestep = 0x1eb8 /* 15.36 */
},
.rx_offset = {
.serdes = 0xfffff7a9, /* -4.1697 */
- .no_fec = 0xffffe71a, /* -12.45 */
+ .no_fec = 0xffffe700, /* -12 */
.fc = 0xfffe894d, /* -187.35 */
- .rs = 0xfffff8cd, /* -3.6 */
+ .rs = 0xfffff8cc, /* -3 */
.sfd = 0x1dc, /* 0.93 */
.bs_ds = 0x14 /* 0.0387879, RS-FEC 0 */
}
--
2.54.0.rc2.531.gaf818d63126a
^ permalink raw reply related
* [PATCH net v2 03/12] ice: fix double free in ice_sf_eth_activate() error path
From: Jacob Keller @ 2026-04-17 0:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, Jacob Keller, Guangshuo Li, stable, Aleksandr Loktionov,
Simon Horman
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
From: Guangshuo Li <lgs201920130244@gmail.com>
When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to
aux_dev_uninit and calls auxiliary_device_uninit(&sf_dev->adev).
The device release callback ice_sf_dev_release() frees sf_dev, but
the current error path falls through to sf_dev_free and calls
kfree(sf_dev) again, causing a double free.
Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but
avoid falling through to sf_dev_free after auxiliary_device_uninit().
Fixes: 13acc5c4cdbe ("ice: subfunction activation and base devlink ops")
Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_sf_eth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_sf_eth.c b/drivers/net/ethernet/intel/ice/ice_sf_eth.c
index 2cf04bc6edce..a730aa368c92 100644
--- a/drivers/net/ethernet/intel/ice/ice_sf_eth.c
+++ b/drivers/net/ethernet/intel/ice/ice_sf_eth.c
@@ -305,6 +305,8 @@ ice_sf_eth_activate(struct ice_dynamic_port *dyn_port,
aux_dev_uninit:
auxiliary_device_uninit(&sf_dev->adev);
+ return err;
+
sf_dev_free:
kfree(sf_dev);
xa_erase:
--
2.54.0.rc2.531.gaf818d63126a
^ permalink raw reply related
* [PATCH net v2 04/12] ice: fix double-free of tx_buf skb
From: Jacob Keller @ 2026-04-17 0:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, Jacob Keller, Michal Schmidt
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
From: Michal Schmidt <mschmidt@redhat.com>
If ice_tso() or ice_tx_csum() fail, the error path in
ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points
to it and is marked as valid (ICE_TX_BUF_SKB).
'next_to_use' remains unchanged, so the potential problem will
likely fix itself when the next packet is transmitted and the tx_buf
gets overwritten. But if there is no next packet and the interface is
brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf()
will find the tx_buf and free the skb for the second time.
The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error
path, so that ice_unmap_and_free_tx_buf().
Move the initialization of 'first' up, to ensure it's already valid in
case we hit the linearization error path.
The bug was spotted by AI while I had it looking for something else.
It also proposed an initial version of the patch.
I reproduced the bug and tested the fix by adding code to inject
failures, on a build with KASAN.
I looked for similar bugs in related Intel drivers and did not find any.
Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads")
Assisted-by: Claude:claude-4.6-opus-high Cursor
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index a2cd4cf37734..7be9c062949b 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -2158,6 +2158,9 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_tx_ring *tx_ring)
ice_trace(xmit_frame_ring, tx_ring, skb);
+ /* record the location of the first descriptor for this packet */
+ first = &tx_ring->tx_buf[tx_ring->next_to_use];
+
count = ice_xmit_desc_count(skb);
if (ice_chk_linearize(skb, count)) {
if (__skb_linearize(skb))
@@ -2183,8 +2186,6 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_tx_ring *tx_ring)
offload.tx_ring = tx_ring;
- /* record the location of the first descriptor for this packet */
- first = &tx_ring->tx_buf[tx_ring->next_to_use];
first->skb = skb;
first->type = ICE_TX_BUF_SKB;
first->bytecount = max_t(unsigned int, skb->len, ETH_ZLEN);
@@ -2249,6 +2250,7 @@ ice_xmit_frame_ring(struct sk_buff *skb, struct ice_tx_ring *tx_ring)
out_drop:
ice_trace(xmit_frame_ring_drop, tx_ring, skb);
dev_kfree_skb_any(skb);
+ first->type = ICE_TX_BUF_EMPTY;
return NETDEV_TX_OK;
}
--
2.54.0.rc2.531.gaf818d63126a
^ permalink raw reply related
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