* RE: [PATCH v4 net-next 06/14] net: enetc: add support for the "Update" operation to buffer pool table
From: Wei Fang @ 2026-04-08 7:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011731.1795517-1-kuba@kernel.org>
> > @@ -702,5 +708,38 @@ int ntmp_vft_add_entry(struct ntmp_user *user,
> u16 vid,
> > }
> > EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
> >
> > +int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
> > + const struct bpt_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct bpt_req_update),
> > + };
> > + struct bpt_req_update *req;
> > + union netc_cbd cbd;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd_eid(&req->rbe, user->tbl.bpt_ver, 0,
> > + NTMP_GEN_UA_CFGEU | BPT_UA_BPSEU, entry_id);
>
> Does this update action mask match the size of the request buffer?
>
> The mask includes both NTMP_GEN_UA_CFGEU and BPT_UA_BPSEU, which
> instructs
> the hardware to update both the configuration entry and the status entry.
> However, struct bpt_req_update only contains the configuration data,
> omitting the status data.
>
> If the hardware attempts to read the missing BPSE data, could it reject
> the command due to an undersized request length, or read beyond the
> intended payload into zero-initialized DMA padding? This might overwrite
> critical buffer pool tracking variables like amount_used_hwm.
>
> If only the configuration is being updated, should the BPT_UA_BPSEU flag
> be removed?
The BPSE_DATA is a set of statistics and status records kept by the hardware
(internal buffer), and does not require the user to provide additional data to
the hardware for updates. Therefore, for the 'update' operation, the request
buffer does not need to provide BPSE_DATA data.
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: nct6694: Switch to devm_mfd_add_devices() and drop IDA
From: Bartosz Golaszewski @ 2026-04-08 7:25 UTC (permalink / raw)
To: a0282524688
Cc: tmyu0, linusw, linux, andi.shyti, lee, mkl, mailhol,
alexandre.belloni, wim, linux-kernel, linux-gpio, linux-i2c,
linux-can, netdev, linux-watchdog, linux-hwmon, linux-rtc,
linux-usb
In-Reply-To: <20260408053037.1867092-2-a0282524688@gmail.com>
On Wed, Apr 8, 2026 at 7:31 AM <a0282524688@gmail.com> wrote:
>
> From: Ming Yu <a0282524688@gmail.com>
>
> Currently, the nct6694 core driver uses mfd_add_hotplug_devices()
> and an IDA to manage subdevice IDs.
>
> Switch the core implementation to use the managed
> devm_mfd_add_devices() API, which simplifies the error handling and
> device lifecycle management. Concurrently, drop the custom IDA
> implementation and transition to using pdev->id.
>
> Signed-off-by: Ming Yu <a0282524688@gmail.com>
> ---
This does result in a nice code shrink but I'd split this commit into
two: one switching to using MFD_CELL_BASIC() with hard-coded devices
IDs and one completing the transition to devres.
Bart
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-08 7:30 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <CAL+tcoBt1A5GYFvimkcRFUtmy298y13AiF-XFF8b8E8Y6fg8Xw@mail.gmail.com>
On Wed, Apr 8, 2026 at 8:35 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> On Wed, Apr 8, 2026 at 5:17 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > On Tue, Apr 7, 2026 at 11:33 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> > > >
> > > > On Mon, Apr 6, 2026 at 10:37 PM Willem de Bruijn
> > > > <willemdebruijn.kernel@gmail.com> wrote:
> > > > >
> > > > > Jason Xing wrote:
> > > > > > On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
> > > > > > <willemdebruijn.kernel@gmail.com> wrote:
> > > > > > >
> > > > > > > Jason Xing wrote:
> > > > > > > > From: Jason Xing <kernelxing@tencent.com>
> > > > > > > >
> > > > > > > > The patch is the 1/2 part of push-level granularity feature.
> > > > > > > >
> > > > > > > > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > > > > > > > though it might not carry the last byte of the sendmsg.
> > > > > > > >
> > > > > > > > Prior to the patch, BPF timestamping cannot cover this case:
> > > > > > > > The following steps reproduce this:
> > > > > > > > 1) skb A is the current last skb before entering wait_for_space process
> > > > > > > > 2) tcp_push() pushes A without any tag
> > > > > > > > 3) A is transmitted from TCP to driver without putting any skb carrying
> > > > > > > > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > > > > > > > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > > > > > > > error code. Note that the socket lock is released.
> > > > > > > > 5) skb A finally gets acked and removed from the rtx queue.
> > > > > > > > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > > > > > > > 'do_error' label and then 'out' label.
> > > > > > > > 7) at this moment, skb A turns out to be the last one in this send
> > > > > > > > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > > > > > > > before the final tcp_push()
> > > > > > > > 8) BPF script fails to see any timestamps this time
> > > > > > > >
> > > > > > > > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > > > > > ---
> > > > > > > > net/ipv4/tcp.c | 4 +++-
> > > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > > > > > > index c603b90057f6..7d030a11d004 100644
> > > > > > > > --- a/net/ipv4/tcp.c
> > > > > > > > +++ b/net/ipv4/tcp.c
> > > > > > > > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > > > > > > > wait_for_space:
> > > > > > > > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > > > > > > > tcp_remove_empty_skb(sk);
> > > > > > > > - if (copied)
> > > > > > > > + if (copied) {
> > > > > > > > + tcp_bpf_tx_timestamp(sk);
> > > > > > > > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > > > > > > > TCP_NAGLE_PUSH, size_goal);
> > > > > > >
> > > > > > > Now the number of skbs that will be tracked will be unpredictable,
> > > > > > > varying based on memory pressure.
> > > > > >
> > > > > > Right, I put some effort into writing a selftests to check how many
> > > > > > push functions get called at one time and failed to do so.
> > > > > >
> > > > > > >
> > > > > > > That sounds hard to use to me. Especially if these extra pushes
> > > > > > > cannot be identified as such.
> > > > > > >
> > > > > > > Perhaps if all skbs from the same sendmsg call can be identified,
> > > > > > > that would help explain pattern in data resulting from these
> > > > > > > uncommon extra data points.
> > > > > >
> > > > > > You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
> > > > > > close to packet basis without considering fragmentation of skb :)
> > > > >
> > > > > No, I meant somehow in the notification having a way to identify all
> > > > > the skbs belonging to the same sendmsg call, to allow filtering on
> > > > > that. But I also don't immediately see how to do that (without adding
> > > > > yet another counter say).
> > > >
> > > > If we don't build the relationship between skb and sendmsg (just like
> > > > the SENDMSG sock option), we will have no clue on how to calculate. If
> > > > we only take care of the skb from the view of the syscall layer, it's
> > > > fine by moving tcp_bpf_tx_timestamp() before tcp_skb_entail(). But in
> > > > terms of per skb even generated beneath TCP due to gso/tso, there is
> > > > only one way to correlate: adding an additional member in the skb
> > > > structure to store its sendmsg time. This discussion is only suitable
> > > > for use cases like net_timestamping.
> > > >
> > > > Well, my key point is that, I have to admit, the above (including
> > > > existing bpf script net_timestamping) is a less effective way which
> > > > definitely harms the performance because of the extremely frequent
> > > > look-up process. It's not suitable for 7x24 observability in
> > > > production. What we've done internally is make the kernel layer as
> > > > lightweight/easy as possible and let the timestamping feature throw
> > > > each record into a ring buffer that the application can read, sort and
> > > > calculate. This arch survives the performance. But that's simply what
> > > > the design of the kernel module is, given the fast deployment in
> > > > production. I suppose in the future we could build a userspace tool
> > > > like blktrace to monitor efficiently instead of the selftest sample.
> > > > Honestly I don't like look-up action.
> > > >
> > > > Since we're modifying the kernel, how about adding a new member to
> > > > record sendmsg time which bpf script is able to read. The whole
> > > > scenario looks like this:
> > > > 1) in tcp_sendmsg_locked(), record the sendmsg time for each skb
> > > > 2) in either tso_fragment() or tcp_gso_tstamp(), each new skb will get
> > > > a copy of its original skb
> > > > 3) in each stage, bpf script reads the skb's sendmsg time and the
> > > > current time, and then effortlessly do the math.
> > > >
> > > > At this point, what I had in mind is we have two options:
> > > > 1) only handle the skb from the view of the send syscall layer, which
> > > > is, for sure, very simple but not thorough.
> > > > 2) stick to a pure authentic packet basis, then adding a new member
> > > > seems inevitable. so the question would be where to add? The space of
> > > > the skb structure is very precious :(
> > >
> > > Finding a suitable place to put this timestamp is really hard. IIRC,
> > > we can't expand the size of struct skb_shared_info so easily since
> > > it's a global effect.
> > >
> > > I'm wondering if we can turn the per-packet mode into a non-compatible
> > > feature by reusing 'u32 tskey' to store a microsecond timestamp of
> > > sendmsg.
> >
> > Agreed that an extra field is hard. We should avoid that.
>
> Avoiding adding a new one makes the whole work extremely hard. I'm
> wondering since we have hwtstamp in shared info, why not add a
> software one for timestamping use? Then, we would support more
> different protocols in more different stages in a finer grain, which
> is a big coarse picture in my mind.
>
> Adding a software bit will completely reduce the whole complexity and
> be very easy to use. Would you expect to see a draft by adding such a
> bit first?
>
> Or just like I mentioned, repurposing tskey seems an alternative,
> which, however, makes the new feature incompatible.
>
> >
> > If the purpose is to group skbs by sendmsg call (e.g., to filter out
> > all but the last one), it is probably also unnecessary.
> >
> > From a process PoV, since the process knows the sendmsg len and each
> > skb has a tskey in byte offset, it can correlate the skb with a given
> > sendmsg buffer.
> >
> > The BPF program is under control of a third-party admin. So that does
> > not follow directly. But it can be passed additional metadata.
> >
> > I thought about passing the offset of the skb from the start of the
> > sendmsg buffer to identify all consecutive skbs for a sendmsg call,
> > as each new buffer will start with an skb with offset 0 ..
> >
> > .. but that won't work as there is no guarantee that a sendmsg call
> > will not append to an existing outstanding skb.
>
> Right. TCP is way too complex and we indeed see some tough issues when
> trying to deploy the feature. So my humble take is to make the design
> as simple as possible.
>
> >
> > Anyway, the general idea is to pass to the BPF program through
> > bpf_skops_tx_timestamping some relevant signal , without having to
> > expand either skb or sk itself.
> >
> > I hear you on that measuring every skb is too frequent. But is calling
> > the BPF program and letting it decide whether to measure too? BPF
> > program invocation itself should be cheap.
>
> Oh, I was clear enough. Sorry. I meant tracing per skb is definitely
> an awesome way to go. My ultimate goal is to do so. Instead of letting
> people implement various fine grained bpf progs, we can provide a very
> easy/understandable/efficient approach with more samples. It should be
> very beneficial.
>
> >
> > If per-push is preferable, with a filter ability like the above, it
> > seems more useful to me already.
>
> Push-level is a compromise plan. Packet-level is what I always pursue :)
>
> The current series has this ability: the bpf prog noticed it's a
> SENDMSG sock option and will selectively call
> bpf_sock_ops_enable_tx_tstamp() to do so. Only by calling
> bpf_sock_ops_enable_tx_tstamp() could the skb be tracked.
FYI, bpf prog could call bpf_sock_ops_enable_tx_tstamp() to enable the
skb track selectively.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Jorge Ramirez @ 2026-04-08 7:32 UTC (permalink / raw)
To: Trilok Soni
Cc: Sumit Garg, Jorge Ramirez, vikash.garodia, linux-arm-msm,
devicetree, dri-devel, freedreno, linux-media, netdev,
linux-wireless, ath12k, linux-remoteproc, andersson, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
dikshita.agarwal, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier, mukesh.ojha,
pavan.kondeti, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <439f9bbf-1ba1-465f-b5af-01ba0ebb86d4@oss.qualcomm.com>
On 07/04/26 15:14:22, Trilok Soni wrote:
> On 4/6/2026 4:42 AM, Sumit Garg wrote:
> > Hi Jorge,
> >
> > On Fri, Apr 03, 2026 at 11:37:07AM +0200, Jorge Ramirez wrote:
> >> On 27/03/26 18:40:39, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>
> >>> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> >>> TZ service allows to support multiple TZ implementation backends like QTEE
> >>> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> >>> backend service.
> >>
> >> OP-TEE based PAS service relies on the linux driver to configure the
> >> iommu (just as it is done on the no_tz case). This generic patch does
> >> not cover that requirement.
> >
> > That's exactly the reason why the kodiak EL2 dtso disables venus by
> > default in patch #1 due to missing IOMMU configuration.
> >
> >>
> >> Because of that, it is probably better if the commit message doesnt
> >> mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
> >> implement the same restrictions that QTEE (ie, iommu configuration).
> >
> > The scope for this patch is to just adopt the generic PAS layer without
> > affecting the client functionality.
the patchset cover letter + the commit message + the OP-TEE pull request
being referenced gives the ilusion to users that with the current set
they will get something functional (they will get a broken video
platform instead if they try to use OP-TEE).
That was the point I was making: IMO the commit message walks on a thin
line of "completeness"
QTEE and OP-TEE at this time implement different use cases (Venus with
QTEE runs with Linux on EL1 , OP-TEE runs with Linux on EL2). So maybe
worth mentioning this divergence.
> >
> >>
> >> I can send an RFC for OP-TEE support based on the integration work being
> >> carried out here [1]
> >
> > @Vikash may know better details about support for IOMMU configuration
> > for venus since it's a generic functionality missing when Linux runs in
> > EL2 whether it's with QTEE or OP-TEE.
> >
> > However, feel free to propose your work to initiate discussions again.
>
> Vikas and team depends on some of the IOMMU patches to get accepted
> before they enable the EL2 venus support. Please reach out to him
> and Prakash Gupta at Qualcomm.
isn't Vikash in this thread, he can ping me too no :) ? but sure, we'll
synch later
^ permalink raw reply
* [PATCH nf] netfilter: arp_tables: fix IEEE1394 ARP payload parsing in arp_packet_match()
From: Weiming Shi @ 2026-04-08 7:35 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, David S . Miller,
David Ahern, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Phil Sutter, Simon Horman, netfilter-devel, coreteam, netdev,
Xiang Mei, Weiming Shi
arp_packet_match() unconditionally parses the ARP payload assuming two
hardware addresses are present (source and target). However,
IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address
field, and arp_hdr_len() already accounts for this by returning a
shorter length for ARPHRD_IEEE1394 devices.
As a result, on IEEE1394 interfaces arp_packet_match() advances past a
nonexistent target hardware address and reads the wrong bytes for both
the target device address comparison and the target IP address. This
causes arptables rules to match against garbage data, leading to
incorrect filtering decisions: packets that should be accepted may be
dropped and vice versa.
The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already
handles this correctly by skipping the target hardware address for
ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().
Fixes: 6752c8db8e0c ("firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/ipv4/netfilter/arp_tables.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 1cdd9c28ab2da..4b2392bdcd0a6 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -86,7 +86,7 @@ static inline int arp_packet_match(const struct arphdr *arphdr,
const struct arpt_arp *arpinfo)
{
const char *arpptr = (char *)(arphdr + 1);
- const char *src_devaddr, *tgt_devaddr;
+ const char *src_devaddr, *tgt_devaddr = NULL;
__be32 src_ipaddr, tgt_ipaddr;
long ret;
@@ -110,13 +110,23 @@ static inline int arp_packet_match(const struct arphdr *arphdr,
arpptr += dev->addr_len;
memcpy(&src_ipaddr, arpptr, sizeof(u32));
arpptr += sizeof(u32);
- tgt_devaddr = arpptr;
- arpptr += dev->addr_len;
+ switch (dev->type) {
+#if IS_ENABLED(CONFIG_FIREWIRE_NET)
+ case ARPHRD_IEEE1394:
+ break;
+#endif
+ default:
+ tgt_devaddr = arpptr;
+ arpptr += dev->addr_len;
+ break;
+ }
memcpy(&tgt_ipaddr, arpptr, sizeof(u32));
if (NF_INVF(arpinfo, ARPT_INV_SRCDEVADDR,
arp_devaddr_compare(&arpinfo->src_devaddr, src_devaddr,
- dev->addr_len)) ||
+ dev->addr_len)))
+ return 0;
+ if (tgt_devaddr &&
NF_INVF(arpinfo, ARPT_INV_TGTDEVADDR,
arp_devaddr_compare(&arpinfo->tgt_devaddr, tgt_devaddr,
dev->addr_len)))
--
2.43.0
^ permalink raw reply related
* RE: [PATCH v4 net-next 07/14] net: enetc: add support for "Add" and "Delete" operations to IPFT
From: Wei Fang @ 2026-04-08 7:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011734.1795551-1-kuba@kernel.org>
> > +int ntmp_ipft_add_entry(struct ntmp_user *user,
> > + struct ipft_entry_data *entry)
> > +{
> [ ... ]
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd(&req->crd, user->tbl.ipft_ver, NTMP_QA_ENTRY_ID,
> > + NTMP_GEN_UA_CFGEU | NTMP_GEN_UA_STSEU);
> > + req->ak.keye = entry->keye;
> > + req->cfge = entry->cfge;
>
> The request sets NTMP_GEN_UA_STSEU to indicate statistics data is present,
> but struct ipft_req_ua does not appear to contain a match_count or STSE data
> field before cfge.
>
> Since the hardware expects STSE data before CFGE data (as seen in
> struct ipft_resp_query), will this cause the hardware to misinterpret the
> first 8 bytes of cfge as the match_count, and then read the actual filter
> configuration from out-of-bounds or uninitialized memory?
Based on NETC manual, the STSE_DATA is present only for the commands
which perform a query. So for the 'add' command, we do not need to
provide the STSE_DATA buffer. And STSE_DATA is the statistics of the
entry, which is stored in the internal buffer of IPF table. Performing
NTMP_GEN_UA_STSEU is to reset the statistic counter when adding
an entry.
[...]
> > +struct ipft_pld_byte {
> > + u8 data;
> > + u8 mask;
> > +};
> > +
> > +struct ipft_keye_data {
> > + __le16 precedence;
> > + __le16 resv0[3];
> > + __le16 frm_attr_flags;
> > +#define IPFT_FAF_OVLAN BIT(2)
> > +#define IPFT_FAF_IVLAN BIT(3)
> > +#define IPFT_FAF_IP_HDR BIT(7)
> > +#define IPFT_FAF_IP_VER6 BIT(8)
> > +#define IPFT_FAF_L4_CODE GENMASK(11, 10)
> > +#define IPFT_FAF_TCP_HDR 1
> > +#define IPFT_FAF_UDP_HDR 2
> > +#define IPFT_FAF_SCTP_HDR 3
> > +#define IPFT_FAF_WOL_MAGIC BIT(12)
> > + __le16 frm_attr_flags_mask;
> > + __le16 dscp;
> > +#define IPFT_DSCP GENMASK(5, 0)
> > +#define IPFT_DSCP_MASK GENMASK(11, 0)
>
> Does IPFT_DSCP_MASK completely overlap with IPFT_DSCP?
>
> If it is defined as GENMASK(11, 0) instead of GENMASK(11, 6), using
> FIELD_PREP with this mask will not shift the value into the upper bits,
> which might overwrite the actual DSCP value in bits 0-5.
Thanks, this is a bug, I will fix it.
^ permalink raw reply
* RE: [PATCH] net: txgbe: leave space for null terminators on property_entry
From: Jiawen Wu @ 2026-04-08 7:40 UTC (permalink / raw)
To: 'Fabio Baltieri', 'Mengyuan Lou',
'Andrew Lunn', 'David S. Miller',
'Eric Dumazet', 'Jakub Kicinski',
'Paolo Abeni', 'Simon Horman',
'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman'
Cc: netdev, linux-kernel
In-Reply-To: <20260405222013.5347-1-fabio.baltieri@gmail.com>
> Lists of struct property_entry are supposed to be terminated with an
> empty property, this driver currently seems to be allocating exactly the
> amount of entry used.
>
> Change the struct definition to leave an extra element for all
> property_entry.
>
> Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> ---
>
> Hi, bumped into this while studying the code, looks like the struct has
> been allocated without space for terminators, guess the top ones just
> end up using the bottom props as well but I'm surprised this does not
> crash at some point. Build test only, don't have any hardware for this,
> let me know if I'm missing something here.
>
> Cheers,
> Fabio
>
> drivers/net/ethernet/wangxun/txgbe/txgbe_type.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> index 82433e9cb0e3..6b05f32b4a01 100644
> --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> @@ -424,10 +424,10 @@ struct txgbe_nodes {
> char i2c_name[32];
> char sfp_name[32];
> char phylink_name[32];
> - struct property_entry gpio_props[1];
> - struct property_entry i2c_props[3];
> - struct property_entry sfp_props[8];
> - struct property_entry phylink_props[2];
> + struct property_entry gpio_props[2];
> + struct property_entry i2c_props[4];
> + struct property_entry sfp_props[9];
> + struct property_entry phylink_props[3];
> struct software_node_ref_args i2c_ref[1];
> struct software_node_ref_args gpio0_ref[1];
> struct software_node_ref_args gpio1_ref[1];
> --
> 2.47.3
Tested-by: Jiawen Wu <jiawenwu@trustnetic.com>
^ permalink raw reply
* Re: [net-next] net: ethernet: ravb: Suspend and resume the transmission flow
From: Geert Uytterhoeven @ 2026-04-08 7:44 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Yoshihiro Shimoda, Paul Barker, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev,
linux-renesas-soc
In-Reply-To: <20260407185443.GC2551274@ragnatech.se>
Hi Niklas,
On Tue, 7 Apr 2026 at 20:54, Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> On 2026-04-07 11:03:38 +0200, Geert Uytterhoeven wrote:
> > On Wed, 1 Apr 2026 at 20:39, Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > >
> > > From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > >
> > > The current driver does not follow the latest datasheet and does not
> > > suspend the flow when stopping DMA and resume it when starting. Update
> > > the driver to do so.
> > >
> > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > [Niklas: Rebase from BSP and reword commit message]
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> >
> > Thanks for your patch, which is now commit 353d8e7989b6babe ("net:
> > ethernet: ravb: Suspend and resume the transmission flow") in
> > linux-next/master net-next.
> >
> > > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > > @@ -694,6 +694,9 @@ static int ravb_dmac_init(struct net_device *ndev)
> > > const struct ravb_hw_info *info = priv->info;
> > > int error;
> > >
> > > + /* Clear transmission suspension */
> > > + ravb_modify(ndev, CCC, CCC_DTSR, 0);
> > > +
> > > /* Set CONFIG mode */
> > > error = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
> > > if (error)
> > > @@ -1103,6 +1106,12 @@ static int ravb_stop_dma(struct net_device *ndev)
> > > if (error)
> > > return error;
> > >
> > > + /* Request for transmission suspension */
> > > + ravb_modify(ndev, CCC, CCC_DTSR, CCC_DTSR);
> > > + error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
> > > + if (error)
> > > + netdev_err(ndev, "failed to stop AXI BUS\n");
> >
> > This error message is printed during resume from s2idle or s2ram on
> > e.g. Salvator-XS and Gray Hawk Single. Ethernet (nfsroot) still works
> > fine, though.
>
> I was not able to reproduce this on M3N (r8a77965-salvator-xs.dts) nor
> Sparrow Hawk (r8a779g3-sparrow-hawk.dts). I'm using the following to
> test, is your test-case different?
>
> # echo enabled > /sys/class/tty/ttySC0/power/wakeup
> # echo s2idle > /sys/power/mem_sleep
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo mem > /sys/power/state
Looks good. Major difference seems to be that I use either Wake-on-LAN
or gpio-keys wake-up, and I always have WoL enabled for ravb.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Fernando Fernandez Mancera @ 2026-04-08 7:48 UTC (permalink / raw)
To: luka.gejak, davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms
In-Reply-To: <20260407162502.19462-2-luka.gejak@linux.dev>
On 4/7/26 6:25 PM, luka.gejak@linux.dev wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> Supervision frames are only valid if terminated with a zero-length EOT
> TLV. The current check fails to reject non-EOT entries as the terminal
> TLV, potentially allowing malformed supervision traffic.
>
> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
> with a length of zero, and properly linearizing the TLV header before
> access.
>
> Assisted-by: Gemini:Gemini-3.1-flash
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> net/hsr/hsr_forward.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index 0aca859c88cb..eb89cc44eac0 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -82,35 +82,33 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
> hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct hsr_sup_payload))
> return false;
>
> - /* Get next tlv */
> + /* Get next TLV */
> total_length += hsr_sup_tag->tlv.HSR_TLV_length;
> - if (!pskb_may_pull(skb, total_length))
> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
> return false;
> skb_pull(skb, total_length);
> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
> skb_push(skb, total_length);
>
> - /* if this is a redbox supervision frame we need to verify
> - * that more data is available
> - */
> + /* If this is a RedBox supervision frame, verify additional data */
> if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
> - /* tlv length must be a length of a mac address */
> + /* TLV length must be the size of a MAC address */
> if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct hsr_sup_payload))
> return false;
>
> - /* make sure another tlv follows */
> + /* Make sure another TLV follows */
> total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv->HSR_TLV_length;
> - if (!pskb_may_pull(skb, total_length))
> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
Hi Luka,
why is the length adjusted here? The current total length was adjusted
correctly above see:
total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv->HSR_TLV_length;
Thanks,
Fernando.
> return false;
>
> - /* get next tlv */
> + /* Get next TLV */
> skb_pull(skb, total_length);
> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
> skb_push(skb, total_length);
> }
>
> - /* end of tlvs must follow at the end */
> - if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
> + /* Supervision frame must end with EOT TLV */
> + if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
> hsr_sup_tlv->HSR_TLV_length != 0)
> return false;
>
^ permalink raw reply
* Re: [net,PATCH] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Nicolai Buchwitz @ 2026-04-08 7:51 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel
In-Reply-To: <20260407212344.80265-1-marex@nabladev.com>
On 7.4.2026 23:23, Marek Vasut wrote:
> If CONFIG_PREEMPT_RT=y is set AND the driver executes ks8851_irq() AND
> KSZ_ISR register bit IRQ_RXI is set AND ks8851_rx_pkts() detects that
> there are packets in the RX FIFO, then netdev_alloc_skb_ip_align() is
> called to allocate SKBs. If netdev_alloc_skb_ip_align() is called with
> BH enabled, local_bh_enable() at the end of netdev_alloc_skb_ip_align()
> will call __local_bh_enable_ip(), which will call __do_softirq(), which
> may trigger net_tx_action() softirq, which may ultimately call the xmit
> callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try
> to lock struct ks8851_net_par .lock spinlock, which is already locked
> by ks8851_irq() from which ks8851_start_xmit_par() was called. This
> leads to a deadlock, which is reported by the kernel, including a trace
> listed below.
>
> Fix the problem by disabling BH around the IRQ handler, thus preventing
> the net_tx_action() softirq from triggering during the IRQ handler. The
> net_tx_action() softirq is now triggered at the end of the IRQ handler,
> once all the other IRQ handler actions have been completed.
>
> __schedule from schedule_rtlock+0x1c/0x34
> schedule_rtlock from rtlock_slowlock_locked+0x538/0x894
> rtlock_slowlock_locked from rt_spin_lock+0x44/0x5c
> rt_spin_lock from ks8851_start_xmit_par+0x68/0x1a0
> ks8851_start_xmit_par from netdev_start_xmit+0x1c/0x40
> netdev_start_xmit from dev_hard_start_xmit+0xec/0x1b0
> dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
> sch_direct_xmit from __qdisc_run+0x20c/0x4fc
> __qdisc_run from qdisc_run+0x1c/0x28
> qdisc_run from net_tx_action+0x1f4/0x244
> net_tx_action from handle_softirqs+0x1c0/0x29c
> handle_softirqs from __local_bh_enable_ip+0xdc/0xf4
> __local_bh_enable_ip from __netdev_alloc_skb+0x140/0x194
> __netdev_alloc_skb from ks8851_irq+0x348/0x4d8
> ks8851_irq from irq_thread_fn+0x24/0x64
> irq_thread_fn from irq_thread+0x110/0x1dc
> irq_thread from kthread+0x104/0x10c
> kthread from ret_from_fork+0x14/0x28
>
> Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler
> instead of disabling BHs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Ronald Wahl <ronald.wahl@raritan.com>
> Cc: Yicong Hui <yiconghui@gmail.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/ethernet/micrel/ks8851_common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/micrel/ks8851_common.c
> b/drivers/net/ethernet/micrel/ks8851_common.c
> index 8048770958d60..dadedea016fac 100644
> --- a/drivers/net/ethernet/micrel/ks8851_common.c
> +++ b/drivers/net/ethernet/micrel/ks8851_common.c
> @@ -316,6 +316,7 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
> unsigned int status;
> struct sk_buff *skb;
>
> + local_bh_disable();
> ks8851_lock(ks, &flags);
I suspect this breaks the SPI variant on non-RT since
ks8851_lock_spi() uses mutex_lock() which can't sleep with
BH disabled. I have KS8851 SPI hardware and will test, will
get back to you.
>
> status = ks8851_rdreg16(ks, KS_ISR);
> @@ -381,6 +382,7 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
> if (status & IRQ_RXI)
> while ((skb = __skb_dequeue(&rxq)))
> netif_rx(skb);
> + local_bh_enable();
>
> return IRQ_HANDLED;
> }
Thanks
Nicolai
^ permalink raw reply
* Re: [BUG] vsock: refcount_t saturation and OOM via buffer size invariant inversion
From: Stefano Garzarella @ 2026-04-08 8:01 UTC (permalink / raw)
To: Norbert Szetei
Cc: davem, edumazet, kuba, pabeni, horms, virtualization, netdev,
linux-kernel, John Villamil
In-Reply-To: <C918071D-C036-4FD3-BD64-16C8E143479F@doyensec.com>
On Mon, Apr 06, 2026 at 08:36:16PM +0200, Norbert Szetei wrote:
>Hi Stefano,
>
>I like option 1 the most, as it is the most straightforward way to fix
>the issue. I am including the patch below. This fixes the clamping
>mismatch, but as you pointed out, it won't solve the root problem
>regarding the issue to arbitrarily set a maximum buffer value.
>
>Since VSOCK uses a unified buffer size rather than separating read and
>write buffers like the core stack, introducing a vsock-specific sysctl
>(e.g., net.vmw_vsock.buffer_max_size) seems the cleanest approach to me.
>I was also considering net.core.wmem_max/rmem_max, but mapping to those
>feels less natural.
I would prefer to stop to add custom sysctl/sockopt for vsock and start
to reuse the common ones, so if net.core.wmem_max/rmem_max can be used
in some way, maybe we can try that path first and fallback to a custom
one if we see it isn't doable.
>
>If you agree with the vsock-specific sysctl, or have a different
>suggestion, let me know and I will send a follow-up patch for that.
>Thanks.
>
>Best, Norbert
>
>-- >8 --
>From f5d160167c862c7f2ad6e6a1d4181d01997b683a Mon Sep 17 00:00:00 2001
>From: Norbert Szetei <norbert@doyensec.com>
>Date: Mon, 6 Apr 2026 19:52:52 +0200
>Subject: [PATCH] vsock: fix buffer size clamping order
>
>In vsock_update_buffer_size(), the buffer size was being clamped to the
>maximum first, and then to the minimum. If a user sets a minimum buffer
>size larger than the maximum, the minimum check overrides the maximum
>check, inverting the constraint.
>
>This breaks the intended socket memory boundaries by allowing the
>vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
>
>Fix this by checking the minimum first, and then the maximum. This
>ensures the buffer size never exceeds the buffer_max_size.
Please add a Fixes tag here, that should be:
Fixes: b9f2b0ffde0c ("vsock: handle buffer_size sockopts in the core")
For virtio transport it was pre-existing of that commit IIUC, but
doesn't metter since these changes will not apply without that commit,
so should be fine.
Please add also a Suggested-by.
>
>Signed-off-by: Norbert Szetei <norbert@doyensec.com>
>---
> net/vmw_vsock/af_vsock.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index d912ed2f012a..08f4dfb9782c 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1951,12 +1951,12 @@ static void vsock_update_buffer_size(struct vsock_sock *vsk,
> const struct vsock_transport *transport,
> u64 val)
> {
>- if (val > vsk->buffer_max_size)
>- val = vsk->buffer_max_size;
>-
> if (val < vsk->buffer_min_size)
> val = vsk->buffer_min_size;
>
>+ if (val > vsk->buffer_max_size)
>+ val = vsk->buffer_max_size;
>+
The patch itself LGTM!
Thanks,
Stefano
^ permalink raw reply
* [PATCH net v2 0/2] net/rds: Fix use-after-free in RDS/IB for non-init namespaces
From: Allison Henderson @ 2026-04-08 8:04 UTC (permalink / raw)
To: netdev; +Cc: pabeni, edumazet, rds-devel, kuba, horms, linux-rdma, achender
This series fixes syzbot bug da8e060735ae02c8f3d1
https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1
The report finds a use-after-free bug where ib connections access an
invalid network namespace after it has been freed. The stack is:
rds_rdma_cm_event_handler_cmn
rds_conn_path_drop
rds_destroy_pending
check_net() <-- use-after-free
This is initially introduced in:
d5a8ac28a7ff ("RDS-TCP: Make RDS-TCP work correctly when it is set up
in a netns other than init_net").
Here, we made RDS aware of the namespace by storing a net pointer in
each connection. But it is not explicitly restricted to init_net in
the case of ib. The RDS/TCP transport has its own pernet exit handler
(rds_tcp_exit_net) that destroys connections when a namespace is torn
down. But RDS/IB does not support more than the initial namespace and
has no such handler. The initial namespace is statically allocated,
and never torn down, so it always has at least one reference.
Allowing non init namespaces that do not have a persistent reference
means that when their refcounts drop to zero, they are released through
cleanup_net(). Which would call any registered pernet clean up handlers
if it had any, but since they don't in this case, the extra
rds_connections remain with stale c_net pointers. Which are then
accessed later causing the use-after-free bug.
So, the simple fix is to disallow more than the initial namespace
to be created in the case of ib connections.
Fixes are ported from UEK patches found here:
https://github.com/oracle/linux-uek/commit/8ed9a82376b7
Patch 1 is a prerequisite optimization to rds_ib_laddr_check() that
avoids excessive rdma_bind_addr() calls during transport probing by
first checking rds_ib_get_device(). This is needed because patch 2
adds a namespace check at the top of the same function.
UEK: 8ed9a82376b7 ("rds: ib: Optimize rds_ib_laddr_check")
https://github.com/oracle/linux-uek/commit/bd9489a08004
Patch 2 restricts RDS/IB to the initial network namespace. It adds
checks in both rds_ib_laddr_check() and rds_set_transport() to reject
IB use from non-init namespaces with -EPROTOTYPE. This prevents the
use-after-free by ensuring IB connections cannot exist in namespaces
that may be torn down.
UEK: bd9489a08004 ("net/rds: Restrict use of RDS/IB to the initial
network namespace")
Questions, comments and feedback appreciated!
Thank you!
Allison
Change Log:
v2:
[PATCH net v2 1/2] net/rds: Optimize rds_ib_laddr_check
- Added missing author sob
- Added ipv6_addr_v4mapped check
[PATCH net v2 2/2] net/rds: Restrict use of RDS/IB to the initial
- Addressed comment consistency nits
- Addressed commit message nits
Greg Jumper (1):
net/rds: Restrict use of RDS/IB to the initial network namespace
Håkon Bugge (1):
net/rds: Optimize rds_ib_laddr_check
net/rds/af_rds.c | 10 ++++++++--
net/rds/ib.c | 24 ++++++++++++++++++++++--
net/rds/ib.h | 1 +
net/rds/ib_rdma.c | 2 +-
4 files changed, 32 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net v2 1/2] net/rds: Optimize rds_ib_laddr_check
From: Allison Henderson @ 2026-04-08 8:04 UTC (permalink / raw)
To: netdev; +Cc: pabeni, edumazet, rds-devel, kuba, horms, linux-rdma, achender
In-Reply-To: <20260408080420.540032-1-achender@kernel.org>
From: Håkon Bugge <haakon.bugge@oracle.com>
rds_ib_laddr_check() creates a CM_ID and attempts to bind the address
in question to it. This in order to qualify the allegedly local
address as a usable IB/RoCE address.
In the field, ExaWatcher runs rds-ping to all ports in the fabric from
all local ports. This using all active ToS'es. In a full rack system,
we have 14 cell servers and eight db servers. Typically, 6 ToS'es are
used. This implies 528 rds-ping invocations per ExaWatcher's "RDSinfo"
interval.
Adding to this, each rds-ping invocation creates eight sockets and
binds the local address to them:
socket(AF_RDS, SOCK_SEQPACKET, 0) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 5
bind(5, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 8
bind(8, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 9
bind(9, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
socket(AF_RDS, SOCK_SEQPACKET, 0) = 10
bind(10, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.36.2")}, 16) = 0
So, at every interval ExaWatcher executes rds-ping's, 4224 CM_IDs are
allocated, considering this full-rack system. After the a CM_ID has
been allocated, rdma_bind_addr() is called, with the port number being
zero. This implies that the CMA will attempt to search for an un-used
ephemeral port. Simplified, the algorithm is to start at a random
position in the available port space, and then if needed, iterate
until an un-used port is found.
The book-keeping of used ports uses the idr system, which again uses
slab to allocate new struct idr_layer's. The size is 2092 bytes and
slab tries to reduce the wasted space. Hence, it chooses an order:3
allocation, for which 15 idr_layer structs will fit and only 1388
bytes are wasted per the 32KiB order:3 chunk.
Although this order:3 allocation seems like a good space/speed
trade-off, it does not resonate well with how it used by the CMA. The
combination of the randomized starting point in the port space (which
has close to zero spatial locality) and the close proximity in time of
the 4224 invocations of the rds-ping's, creates a memory hog for
order:3 allocations.
These costly allocations may need reclaims and/or compaction. At
worst, they may fail and produce a stack trace such as (from uek4):
[<ffffffff811a72d5>] __inc_zone_page_state+0x35/0x40
[<ffffffff811c2e97>] page_add_file_rmap+0x57/0x60
[<ffffffffa37ca1df>] remove_migration_pte+0x3f/0x3c0 [ksplice_6cn872bt_vmlinux_new]
[<ffffffff811c3de8>] rmap_walk+0xd8/0x340
[<ffffffff811e8860>] remove_migration_ptes+0x40/0x50
[<ffffffff811ea83c>] migrate_pages+0x3ec/0x890
[<ffffffff811afa0d>] compact_zone+0x32d/0x9a0
[<ffffffff811b00ed>] compact_zone_order+0x6d/0x90
[<ffffffff811b03b2>] try_to_compact_pages+0x102/0x270
[<ffffffff81190e56>] __alloc_pages_direct_compact+0x46/0x100
[<ffffffff8119165b>] __alloc_pages_nodemask+0x74b/0xaa0
[<ffffffff811d8411>] alloc_pages_current+0x91/0x110
[<ffffffff811e3b0b>] new_slab+0x38b/0x480
[<ffffffffa41323c7>] __slab_alloc+0x3b7/0x4a0 [ksplice_s0dk66a8_vmlinux_new]
[<ffffffff811e42ab>] kmem_cache_alloc+0x1fb/0x250
[<ffffffff8131fdd6>] idr_layer_alloc+0x36/0x90
[<ffffffff8132029c>] idr_get_empty_slot+0x28c/0x3d0
[<ffffffff813204ad>] idr_alloc+0x4d/0xf0
[<ffffffffa051727d>] cma_alloc_port+0x4d/0xa0 [rdma_cm]
[<ffffffffa0517cbe>] rdma_bind_addr+0x2ae/0x5b0 [rdma_cm]
[<ffffffffa09d8083>] rds_ib_laddr_check+0x83/0x2c0 [ksplice_6l2xst5i_rds_rdma_new]
[<ffffffffa05f892b>] rds_trans_get_preferred+0x5b/0xa0 [rds]
[<ffffffffa05f09f2>] rds_bind+0x212/0x280 [rds]
[<ffffffff815b4016>] SYSC_bind+0xe6/0x120
[<ffffffff815b4d3e>] SyS_bind+0xe/0x10
[<ffffffff816b031a>] system_call_fastpath+0x18/0xd4
To avoid these excessive calls to rdma_bind_addr(), we optimize
rds_ib_laddr_check() by simply checking if the address in question has
been used before. The rds_rdma module keeps track of addresses
associated with IB devices, and the function rds_ib_get_device() is
used to determine if the address already has been qualified as a valid
local address. If not found, we call the legacy rds_ib_laddr_check(),
now renamed to rds_ib_laddr_check_cm().
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Signed-off-by: Allison Henderson <achender@kernel.org>
---
net/rds/ib.c | 20 ++++++++++++++++++--
net/rds/ib.h | 1 +
net/rds/ib_rdma.c | 2 +-
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/net/rds/ib.c b/net/rds/ib.c
index ac6affa33ce7..412ff61e74fa 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -401,8 +401,8 @@ static void rds6_ib_ic_info(struct socket *sock, unsigned int len,
* allowed to influence which paths have priority. We could call userspace
* asserting this policy "routing".
*/
-static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
- __u32 scope_id)
+static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
+ __u32 scope_id)
{
int ret;
struct rdma_cm_id *cm_id;
@@ -487,6 +487,22 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
return ret;
}
+static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
+ __u32 scope_id)
+{
+ struct rds_ib_device *rds_ibdev = NULL;
+
+ if (ipv6_addr_v4mapped(addr)) {
+ rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
+ if (rds_ibdev) {
+ rds_ib_dev_put(rds_ibdev);
+ return 0;
+ }
+ }
+
+ return rds_ib_laddr_check_cm(net, addr, scope_id);
+}
+
static void rds_ib_unregister_client(void)
{
ib_unregister_client(&rds_ib_client);
diff --git a/net/rds/ib.h b/net/rds/ib.h
index 8ef3178ed4d6..5ff346a1e8ba 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -381,6 +381,7 @@ void rds_ib_cm_connect_complete(struct rds_connection *conn,
__rds_ib_conn_error(conn, KERN_WARNING "RDS/IB: " fmt)
/* ib_rdma.c */
+struct rds_ib_device *rds_ib_get_device(__be32 ipaddr);
int rds_ib_update_ipaddr(struct rds_ib_device *rds_ibdev,
struct in6_addr *ipaddr);
void rds_ib_add_conn(struct rds_ib_device *rds_ibdev, struct rds_connection *conn);
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 2cfec252eeac..9594ea245f7f 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -43,7 +43,7 @@ struct workqueue_struct *rds_ib_mr_wq;
static void rds_ib_odp_mr_worker(struct work_struct *work);
-static struct rds_ib_device *rds_ib_get_device(__be32 ipaddr)
+struct rds_ib_device *rds_ib_get_device(__be32 ipaddr)
{
struct rds_ib_device *rds_ibdev;
struct rds_ib_ipaddr *i_ipaddr;
--
2.43.0
^ permalink raw reply related
* [PATCH net v2 2/2] net/rds: Restrict use of RDS/IB to the initial network namespace
From: Allison Henderson @ 2026-04-08 8:04 UTC (permalink / raw)
To: netdev; +Cc: pabeni, edumazet, rds-devel, kuba, horms, linux-rdma, achender
In-Reply-To: <20260408080420.540032-1-achender@kernel.org>
From: Greg Jumper <greg.jumper@oracle.com>
Prevent using RDS/IB in network namespaces other than the initial one.
The existing RDS/IB code will not work properly in non-initial network
namespaces.
Fixes: d5a8ac28a7ff ("RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net")
Reported-by: syzbot+da8e060735ae02c8f3d1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1
Signed-off-by: Greg Jumper <greg.jumper@oracle.com>
Signed-off-by: Allison Henderson <achender@kernel.org>
---
net/rds/af_rds.c | 10 ++++++++--
net/rds/ib.c | 4 ++++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index b396c673dfaf..76f625986a7f 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -357,7 +357,8 @@ static int rds_cong_monitor(struct rds_sock *rs, sockptr_t optval, int optlen)
return ret;
}
-static int rds_set_transport(struct rds_sock *rs, sockptr_t optval, int optlen)
+static int rds_set_transport(struct net *net, struct rds_sock *rs,
+ sockptr_t optval, int optlen)
{
int t_type;
@@ -373,6 +374,10 @@ static int rds_set_transport(struct rds_sock *rs, sockptr_t optval, int optlen)
if (t_type < 0 || t_type >= RDS_TRANS_COUNT)
return -EINVAL;
+ /* RDS/IB is restricted to the initial network namespace */
+ if (t_type != RDS_TRANS_TCP && !net_eq(net, &init_net))
+ return -EPROTOTYPE;
+
rs->rs_transport = rds_trans_get(t_type);
return rs->rs_transport ? 0 : -ENOPROTOOPT;
@@ -433,6 +438,7 @@ static int rds_setsockopt(struct socket *sock, int level, int optname,
sockptr_t optval, unsigned int optlen)
{
struct rds_sock *rs = rds_sk_to_rs(sock->sk);
+ struct net *net = sock_net(sock->sk);
int ret;
if (level != SOL_RDS) {
@@ -461,7 +467,7 @@ static int rds_setsockopt(struct socket *sock, int level, int optname,
break;
case SO_RDS_TRANSPORT:
lock_sock(sock->sk);
- ret = rds_set_transport(rs, optval, optlen);
+ ret = rds_set_transport(net, rs, optval, optlen);
release_sock(sock->sk);
break;
case SO_TIMESTAMP_OLD:
diff --git a/net/rds/ib.c b/net/rds/ib.c
index 412ff61e74fa..39f87272e071 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -492,6 +492,10 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
{
struct rds_ib_device *rds_ibdev = NULL;
+ /* RDS/IB is restricted to the initial network namespace */
+ if (!net_eq(net, &init_net))
+ return -EPROTOTYPE;
+
if (ipv6_addr_v4mapped(addr)) {
rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
if (rds_ibdev) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 net] vsock: fix buffer size clamping order
From: Stefano Garzarella @ 2026-04-08 8:05 UTC (permalink / raw)
To: Jakub Kicinski, Norbert Szetei
Cc: Norbert Szetei, davem, edumazet, pabeni, horms, virtualization,
netdev, linux-kernel, John Villamil
In-Reply-To: <20260406173702.56239557@kernel.org>
On Mon, Apr 06, 2026 at 05:37:02PM -0700, Jakub Kicinski wrote:
>On Mon, 6 Apr 2026 22:04:26 +0200 Norbert Szetei wrote:
>> v2: fix indentation/whitespace issues in the previous patch.
>
>This is not a correct way to submit a patch, but please wait until
>Stefano responds with any further postings.
>
I just replied to one of the patch inlined in a reply to the bug report
suggesting some changes.
Please as Jakub suggested, send a new version with at least the Fixes
tag, but follow the process, see
https://docs.kernel.org/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text
Feel free to reach me if you need any clarification.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Fernando Fernandez Mancera @ 2026-04-08 8:05 UTC (permalink / raw)
To: luka.gejak, davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms
In-Reply-To: <e29b7837-70ab-4db2-b9e5-abb59d8721d7@suse.de>
On 4/8/26 9:48 AM, Fernando Fernandez Mancera wrote:
> On 4/7/26 6:25 PM, luka.gejak@linux.dev wrote:
>> From: Luka Gejak <luka.gejak@linux.dev>
>>
>> Supervision frames are only valid if terminated with a zero-length EOT
>> TLV. The current check fails to reject non-EOT entries as the terminal
>> TLV, potentially allowing malformed supervision traffic.
>>
>> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
>> with a length of zero, and properly linearizing the TLV header before
>> access.
>>
>> Assisted-by: Gemini:Gemini-3.1-flash
>> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
>> ---
>> net/hsr/hsr_forward.c | 20 +++++++++-----------
>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
>> index 0aca859c88cb..eb89cc44eac0 100644
>> --- a/net/hsr/hsr_forward.c
>> +++ b/net/hsr/hsr_forward.c
>> @@ -82,35 +82,33 @@ static bool is_supervision_frame(struct hsr_priv
>> *hsr, struct sk_buff *skb)
>> hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct
>> hsr_sup_payload))
>> return false;
>> - /* Get next tlv */
>> + /* Get next TLV */
>> total_length += hsr_sup_tag->tlv.HSR_TLV_length;
>> - if (!pskb_may_pull(skb, total_length))
>> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
>> return false;
>> skb_pull(skb, total_length);
>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>> skb_push(skb, total_length);
>> - /* if this is a redbox supervision frame we need to verify
>> - * that more data is available
>> - */
>> + /* If this is a RedBox supervision frame, verify additional data */
>> if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
>> - /* tlv length must be a length of a mac address */
>> + /* TLV length must be the size of a MAC address */
>> if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct
>> hsr_sup_payload))
>> return false;
>> - /* make sure another tlv follows */
>> + /* Make sure another TLV follows */
>> total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv-
>> >HSR_TLV_length;
>> - if (!pskb_may_pull(skb, total_length))
>> + if (!pskb_may_pull(skb, total_length + sizeof(struct
>> hsr_sup_tlv)))
>
> Hi Luka,
>
> why is the length adjusted here? The current total length was adjusted
> correctly above see:
>
Never mind, it makes sense as the total_length must point to the
beginning of the next TLV.
LGTM,
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Thanks,
Fernando.
>> return false;
>> - /* get next tlv */
>> + /* Get next TLV */
>> skb_pull(skb, total_length);
>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>> skb_push(skb, total_length);
>> }
>> - /* end of tlvs must follow at the end */
>> - if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
>> + /* Supervision frame must end with EOT TLV */
>> + if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
>> hsr_sup_tlv->HSR_TLV_length != 0)
>> return false;
>
^ permalink raw reply
* Re: [PATCH v2] rxrpc/proc: size address buffers for %pISpc output
From: David Howells @ 2026-04-08 8:08 UTC (permalink / raw)
To: Pengpeng Hou
Cc: dhowells, Marc Dionne, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-afs, netdev, linux-kernel
In-Reply-To: <20260406170001.2-rxrpc-proc-v2-pengpeng@iscas.ac.cn>
Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
> - char lbuff[50], rbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
This might be saved upstream by the compiler padding the buffers out to
sizeof(long) because they're on the stack.
David
^ permalink raw reply
* [PATCH net] nfc: llcp: add missing return after LLCP_CLOSED checks
From: Junxi Qian @ 2026-04-08 8:10 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, kuba, pabeni, horms
In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket
state is LLCP_CLOSED, the code correctly calls release_sock() and
nfc_llcp_sock_put() but fails to return. Execution falls through to
the remainder of the function, which calls release_sock() and
nfc_llcp_sock_put() again. This results in a double release_sock()
and a refcount underflow via double nfc_llcp_sock_put(), leading to
a use-after-free.
Add the missing return statements after the LLCP_CLOSED branches
in both functions to prevent the fall-through.
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Signed-off-by: Junxi Qian <qjx1298677004@gmail.com>
---
net/nfc/llcp_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 366d75663..db5bc6a87 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1091,6 +1091,7 @@ static void nfc_llcp_recv_hdlc(struct nfc_llcp_local *local,
if (sk->sk_state == LLCP_CLOSED) {
release_sock(sk);
nfc_llcp_sock_put(llcp_sock);
+ return;
}
/* Pass the payload upstream */
@@ -1182,6 +1183,7 @@ static void nfc_llcp_recv_disc(struct nfc_llcp_local *local,
if (sk->sk_state == LLCP_CLOSED) {
release_sock(sk);
nfc_llcp_sock_put(llcp_sock);
+ return;
}
if (sk->sk_state == LLCP_CONNECTED) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v5 1/3] net: mana: Use pci_name() for debugfs directory naming
From: Erni Sri Satya Vennela @ 2026-04-08 8:12 UTC (permalink / raw)
To: Simon Horman
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, shradhagupta, shirazsaleem,
yury.norov, kees, ssengar, dipayanroy, gargaditya, linux-hyperv,
netdev, linux-kernel, linux-rdma
In-Reply-To: <20260404090514.GS113102@horms.kernel.org>
On Sat, Apr 04, 2026 at 10:05:14AM +0100, Simon Horman wrote:
> On Thu, Apr 02, 2026 at 11:26:55AM -0700, Erni Sri Satya Vennela wrote:
> > Use pci_name(pdev) for the per-device debugfs directory instead of
> > hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The
> > previous approach had two issues:
> >
> > 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs
> > in environments like generic VFIO passthrough or nested KVM,
> > causing a NULL pointer dereference.
> >
> > 2. Multiple PFs would all use "0", and VFs across different PCI
> > domains or buses could share the same slot name, leading to
> > -EEXIST errors from debugfs_create_dir().
> >
> > pci_name(pdev) returns the unique BDF address, is always valid, and
> > is unique across the system.
> >
> > Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device")
> > Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
>
> Hi Erni,
>
> Possibly the code differs between net and net-next.
> But if this is fixing a bug in code present in net - as per the cited
> commit - then I think it should be a patch that targets net.
> With some strategy for merging that change into net-next
> if conflicts are expected.
Thankyou for the clarity Simon.
I will send a separate patchset for net tree with the fixes.
- Vennela
^ permalink raw reply
* [PATCH net 0/2] net: mana: Fix debugfs directory naming and file lifecycle
From: Erni Sri Satya Vennela @ 2026-04-08 8:12 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ernis, ssengar, dipayanroy, gargaditya,
shradhagupta, kees, kotaranov, yury.norov, linux-hyperv, netdev,
linux-kernel
This series fixes two pre-existing debugfs issues in the MANA driver.
Patch 1 fixes the per-device debugfs directory naming to use the unique
PCI BDF address via pci_name(), avoiding a potential NULL pointer
dereference when pdev->slot is NULL (e.g. VFIO passthrough, nested KVM)
and preventing name collisions across multiple PFs or VFs.
Patch 2 moves the current_speed debugfs file creation from
mana_probe_port() to mana_init_port() so it survives detach/attach
cycles triggered by MTU changes or XDP program changes.
Erni Sri Satya Vennela (2):
net: mana: Use pci_name() for debugfs directory naming
net: mana: Move current_speed debugfs file to mana_init_port()
drivers/net/ethernet/microsoft/mana/gdma_main.c | 7 ++-----
drivers/net/ethernet/microsoft/mana/mana_en.c | 4 ++--
2 files changed, 4 insertions(+), 7 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH net 1/2] net: mana: Use pci_name() for debugfs directory naming
From: Erni Sri Satya Vennela @ 2026-04-08 8:12 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ernis, ssengar, dipayanroy, gargaditya,
shradhagupta, kees, kotaranov, yury.norov, linux-hyperv, netdev,
linux-kernel
In-Reply-To: <20260408081224.302308-1-ernis@linux.microsoft.com>
Use pci_name(pdev) for the per-device debugfs directory instead of
hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The
previous approach had two issues:
1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs
in environments like generic VFIO passthrough or nested KVM,
causing a NULL pointer dereference.
2. Multiple PFs would all use "0", and VFs across different PCI
domains or buses could share the same slot name, leading to
-EEXIST errors from debugfs_create_dir().
pci_name(pdev) returns the unique BDF address, is always valid, and is
unique across the system.
Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device")
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
---
drivers/net/ethernet/microsoft/mana/gdma_main.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index 43741cd35af8..098fbda0d128 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -2065,11 +2065,8 @@ static int mana_gd_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
gc->dev = &pdev->dev;
xa_init(&gc->irq_contexts);
- if (gc->is_pf)
- gc->mana_pci_debugfs = debugfs_create_dir("0", mana_debugfs_root);
- else
- gc->mana_pci_debugfs = debugfs_create_dir(pci_slot_name(pdev->slot),
- mana_debugfs_root);
+ gc->mana_pci_debugfs = debugfs_create_dir(pci_name(pdev),
+ mana_debugfs_root);
err = mana_gd_setup(pdev);
if (err)
--
2.34.1
^ permalink raw reply related
* [PATCH net 2/2] net: mana: Move current_speed debugfs file to mana_init_port()
From: Erni Sri Satya Vennela @ 2026-04-08 8:12 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ernis, ssengar, dipayanroy, gargaditya,
shradhagupta, kees, kotaranov, yury.norov, linux-hyperv, netdev,
linux-kernel
In-Reply-To: <20260408081224.302308-1-ernis@linux.microsoft.com>
Move the current_speed debugfs file creation from mana_probe_port() to
mana_init_port(). The file was previously created only during initial
probe, but mana_cleanup_port_context() removes the entire vPort debugfs
directory during detach/attach cycles. Since mana_init_port() recreates
the directory on re-attach, moving current_speed here ensures it survives
these cycles.
Fixes: 75cabb46935b ("net: mana: Add support for net_shaper_ops")
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
---
drivers/net/ethernet/microsoft/mana/mana_en.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 07630322545f..6302432b9bf6 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -3154,6 +3154,8 @@ static int mana_init_port(struct net_device *ndev)
eth_hw_addr_set(ndev, apc->mac_addr);
sprintf(vport, "vport%d", port_idx);
apc->mana_port_debugfs = debugfs_create_dir(vport, gc->mana_pci_debugfs);
+ debugfs_create_u32("current_speed", 0400, apc->mana_port_debugfs,
+ &apc->speed);
return 0;
reset_apc:
@@ -3432,8 +3434,6 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
netif_carrier_on(ndev);
- debugfs_create_u32("current_speed", 0400, apc->mana_port_debugfs, &apc->speed);
-
return 0;
free_indir:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next] vsock/virtio: remove unnecessary call to `virtio_transport_get_ops`
From: Stefano Garzarella @ 2026-04-08 8:11 UTC (permalink / raw)
To: Luigi Leonardi
Cc: Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Stefan Hajnoczi, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Arseniy Krasnov, kvm, virtualization,
netdev, linux-kernel
In-Reply-To: <20260407-remove_parameter-v1-1-e9729360a2be@redhat.com>
On Tue, Apr 07, 2026 at 04:31:56PM +0200, Luigi Leonardi wrote:
>`virtio_transport_send_pkt_info` gets all the transport information
>from the parameter `t_ops`. There is no need to call
>`virtio_transport_get_ops()`.
>
>Remove it.
>
>Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
>Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>---
>I marked this as net-next material, but honsetly I'm not sure if I
>should have targeted net. It's not a bug after all, it's just a cleanup.
The patch LGTM, but as Michael and Jakub pointed out, better to remove
Fixes tag if this is not a bug fix.
Thanks,
Stefano
>---
> net/vmw_vsock/virtio_transport_common.c | 2 --
> 1 file changed, 2 deletions(-)
>
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index 8a9fb23c6e85..a152a9e208d0 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -60,8 +60,6 @@ static bool virtio_transport_can_zcopy(const struct virtio_transport *t_ops,
> return false;
>
> /* Check that transport can send data in zerocopy mode. */
>- t_ops = virtio_transport_get_ops(info->vsk);
>-
> if (t_ops->can_msgzerocopy) {
> int pages_to_send = iov_iter_npages(iov_iter, MAX_SKB_FRAGS);
>
>
>---
>base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
>change-id: 20260407-remove_parameter-f61a3e40cf90
>
>Best regards,
>--
>Luigi Leonardi <leonardi@redhat.com>
>
^ permalink raw reply
* [PATCH net-next v6] net: mana: Expose hardware diagnostic info via debugfs
From: Erni Sri Satya Vennela @ 2026-04-08 8:15 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, horms, shradhagupta,
shirazsaleem, yury.norov, kees, ssengar, ernis, dipayanroy,
gargaditya, linux-hyperv, netdev, linux-kernel, linux-rdma
Add debugfs entries to expose hardware configuration and diagnostic
information that aids in debugging driver initialization and runtime
operations without adding noise to dmesg.
The debugfs directory for each PCI device is named using pci_name()
(the unique BDF address), and its creation and removal is integrated
into mana_gd_setup() and mana_gd_cleanup_device() respectively, so
that all callers (probe, remove, suspend, resume, shutdown) share a
single code path.
Device-level entries (under /sys/kernel/debug/mana/<BDF>/):
- num_msix_usable, max_num_queues: Max resources from hardware
- gdma_protocol_ver, pf_cap_flags1: VF version negotiation results
- num_vports, bm_hostmode: Device configuration
Per-vPort entries (under /sys/kernel/debug/mana/<BDF>/vportN/):
- port_handle: Hardware vPort handle
- max_sq, max_rq: Max queues from vPort config
- indir_table_sz: Indirection table size
- steer_rx, steer_rss, steer_update_tab, steer_cqe_coalescing:
Last applied steering configuration parameters
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
---
This patch depends on the following fixes submitted to net:
- "net: mana: Use pci_name() for debugfs directory naming"
- "net: mana: Move current_speed debugfs file to mana_init_port()"
Conflict resolution may be needed when net merges into net-next.
---
Changes in v6:
* Move out of patchset and create a separate patch.
Changes in v5:
* Update commit message.
* Fix conflicts to align with the new patches.
* Make it part of patchset.
Changes in v4:
* Rebase and fix conflicts.
Changes in v3:
* Rename mana_gd_cleanup to mana_gd_cleanup_device.
* Add creation of debugfs entries in mana_gd_setup.
* Add removal of debugfs entries in mana_gd_cleanup_device.
* Remove bm_hostmode and num_vports from debugfs in mana_remove itself,
because "ac" gets freed before debugfs_remove_recursive, to avoid
Use-After-Free error.
* Add "goto out:" in mana_cfg_vport_steering to avoid populating apc
values when resp.hdr.status is not NULL.
Changes in v2:
* Add debugfs_remove_recursice for gc>mana_pci_debugfs in
mana_gd_suspend to handle multiple duplicates creation in
mana_gd_setup and mana_gd_resume path.
* Move debugfs creation for num_vports and bm_hostmode out of
if(!resuming) condition since we have to create it again even for
resume.
* Recreate mana_pci_debugfs in mana_gd_resume.
---
.../net/ethernet/microsoft/mana/gdma_main.c | 59 ++++++++++---------
drivers/net/ethernet/microsoft/mana/mana_en.c | 33 +++++++++++
include/net/mana/gdma.h | 1 +
include/net/mana/mana.h | 8 +++
4 files changed, 74 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index 098fbda0d128..7a99db9afa03 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -194,6 +194,11 @@ static int mana_gd_query_max_resources(struct pci_dev *pdev)
if (gc->max_num_queues > gc->num_msix_usable - 1)
gc->max_num_queues = gc->num_msix_usable - 1;
+ debugfs_create_u32("num_msix_usable", 0400, gc->mana_pci_debugfs,
+ &gc->num_msix_usable);
+ debugfs_create_u32("max_num_queues", 0400, gc->mana_pci_debugfs,
+ &gc->max_num_queues);
+
return 0;
}
@@ -1264,6 +1269,13 @@ int mana_gd_verify_vf_version(struct pci_dev *pdev)
return err ? err : -EPROTO;
}
gc->pf_cap_flags1 = resp.pf_cap_flags1;
+ gc->gdma_protocol_ver = resp.gdma_protocol_ver;
+
+ debugfs_create_x64("gdma_protocol_ver", 0400, gc->mana_pci_debugfs,
+ &gc->gdma_protocol_ver);
+ debugfs_create_x64("pf_cap_flags1", 0400, gc->mana_pci_debugfs,
+ &gc->pf_cap_flags1);
+
if (resp.pf_cap_flags1 & GDMA_DRV_CAP_FLAG_1_HWC_TIMEOUT_RECONFIG) {
err = mana_gd_query_hwc_timeout(pdev, &hwc->hwc_timeout);
if (err) {
@@ -1943,15 +1955,20 @@ static int mana_gd_setup(struct pci_dev *pdev)
struct gdma_context *gc = pci_get_drvdata(pdev);
int err;
+ gc->mana_pci_debugfs = debugfs_create_dir(pci_name(pdev),
+ mana_debugfs_root);
+
err = mana_gd_init_registers(pdev);
if (err)
- return err;
+ goto remove_debugfs;
mana_smc_init(&gc->shm_channel, gc->dev, gc->shm_base);
gc->service_wq = alloc_ordered_workqueue("gdma_service_wq", 0);
- if (!gc->service_wq)
- return -ENOMEM;
+ if (!gc->service_wq) {
+ err = -ENOMEM;
+ goto remove_debugfs;
+ }
err = mana_gd_setup_hwc_irqs(pdev);
if (err) {
@@ -1992,11 +2009,14 @@ static int mana_gd_setup(struct pci_dev *pdev)
free_workqueue:
destroy_workqueue(gc->service_wq);
gc->service_wq = NULL;
+remove_debugfs:
+ debugfs_remove_recursive(gc->mana_pci_debugfs);
+ gc->mana_pci_debugfs = NULL;
dev_err(&pdev->dev, "%s failed (error %d)\n", __func__, err);
return err;
}
-static void mana_gd_cleanup(struct pci_dev *pdev)
+static void mana_gd_cleanup_device(struct pci_dev *pdev)
{
struct gdma_context *gc = pci_get_drvdata(pdev);
@@ -2008,6 +2028,10 @@ static void mana_gd_cleanup(struct pci_dev *pdev)
destroy_workqueue(gc->service_wq);
gc->service_wq = NULL;
}
+
+ debugfs_remove_recursive(gc->mana_pci_debugfs);
+ gc->mana_pci_debugfs = NULL;
+
dev_dbg(&pdev->dev, "mana gdma cleanup successful\n");
}
@@ -2065,9 +2089,6 @@ static int mana_gd_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
gc->dev = &pdev->dev;
xa_init(&gc->irq_contexts);
- gc->mana_pci_debugfs = debugfs_create_dir(pci_name(pdev),
- mana_debugfs_root);
-
err = mana_gd_setup(pdev);
if (err)
goto unmap_bar;
@@ -2096,16 +2117,8 @@ static int mana_gd_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
cleanup_mana:
mana_remove(&gc->mana, false);
cleanup_gd:
- mana_gd_cleanup(pdev);
+ mana_gd_cleanup_device(pdev);
unmap_bar:
- /*
- * at this point we know that the other debugfs child dir/files
- * are either not yet created or are already cleaned up.
- * The pci debugfs folder clean-up now, will only be cleaning up
- * adapter-MTU file and apc->mana_pci_debugfs folder.
- */
- debugfs_remove_recursive(gc->mana_pci_debugfs);
- gc->mana_pci_debugfs = NULL;
xa_destroy(&gc->irq_contexts);
pci_iounmap(pdev, bar0_va);
free_gc:
@@ -2155,11 +2168,7 @@ static void mana_gd_remove(struct pci_dev *pdev)
mana_rdma_remove(&gc->mana_ib);
mana_remove(&gc->mana, false);
- mana_gd_cleanup(pdev);
-
- debugfs_remove_recursive(gc->mana_pci_debugfs);
-
- gc->mana_pci_debugfs = NULL;
+ mana_gd_cleanup_device(pdev);
xa_destroy(&gc->irq_contexts);
@@ -2181,7 +2190,7 @@ int mana_gd_suspend(struct pci_dev *pdev, pm_message_t state)
mana_rdma_remove(&gc->mana_ib);
mana_remove(&gc->mana, true);
- mana_gd_cleanup(pdev);
+ mana_gd_cleanup_device(pdev);
return 0;
}
@@ -2220,11 +2229,7 @@ static void mana_gd_shutdown(struct pci_dev *pdev)
mana_rdma_remove(&gc->mana_ib);
mana_remove(&gc->mana, true);
- mana_gd_cleanup(pdev);
-
- debugfs_remove_recursive(gc->mana_pci_debugfs);
-
- gc->mana_pci_debugfs = NULL;
+ mana_gd_cleanup_device(pdev);
pci_disable_device(pdev);
}
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 6302432b9bf6..e7c627e3379a 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1276,6 +1276,9 @@ static int mana_query_vport_cfg(struct mana_port_context *apc, u32 vport_index,
apc->port_handle = resp.vport;
ether_addr_copy(apc->mac_addr, resp.mac_addr);
+ apc->vport_max_sq = *max_sq;
+ apc->vport_max_rq = *max_rq;
+
return 0;
}
@@ -1430,6 +1433,11 @@ static int mana_cfg_vport_steering(struct mana_port_context *apc,
netdev_info(ndev, "Configured steering vPort %llu entries %u\n",
apc->port_handle, apc->indir_table_sz);
+
+ apc->steer_rx = rx;
+ apc->steer_rss = apc->rss_state;
+ apc->steer_update_tab = update_tab;
+ apc->steer_cqe_coalescing = req->cqe_coalescing_enable;
out:
kfree(req);
return err;
@@ -3154,6 +3162,23 @@ static int mana_init_port(struct net_device *ndev)
eth_hw_addr_set(ndev, apc->mac_addr);
sprintf(vport, "vport%d", port_idx);
apc->mana_port_debugfs = debugfs_create_dir(vport, gc->mana_pci_debugfs);
+
+ debugfs_create_u64("port_handle", 0400, apc->mana_port_debugfs,
+ &apc->port_handle);
+ debugfs_create_u32("max_sq", 0400, apc->mana_port_debugfs,
+ &apc->vport_max_sq);
+ debugfs_create_u32("max_rq", 0400, apc->mana_port_debugfs,
+ &apc->vport_max_rq);
+ debugfs_create_u32("indir_table_sz", 0400, apc->mana_port_debugfs,
+ &apc->indir_table_sz);
+ debugfs_create_u32("steer_rx", 0400, apc->mana_port_debugfs,
+ &apc->steer_rx);
+ debugfs_create_u32("steer_rss", 0400, apc->mana_port_debugfs,
+ &apc->steer_rss);
+ debugfs_create_u32("steer_update_tab", 0400, apc->mana_port_debugfs,
+ &apc->steer_update_tab);
+ debugfs_create_u32("steer_cqe_coalescing", 0400, apc->mana_port_debugfs,
+ &apc->steer_cqe_coalescing);
debugfs_create_u32("current_speed", 0400, apc->mana_port_debugfs,
&apc->speed);
return 0;
@@ -3646,6 +3671,11 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
ac->bm_hostmode = bm_hostmode;
+ debugfs_create_u16("num_vports", 0400, gc->mana_pci_debugfs,
+ &ac->num_ports);
+ debugfs_create_u8("bm_hostmode", 0400, gc->mana_pci_debugfs,
+ &ac->bm_hostmode);
+
if (!resuming) {
ac->num_ports = num_ports;
@@ -3786,6 +3816,9 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
mana_gd_deregister_device(gd);
+ debugfs_lookup_and_remove("bm_hostmode", gc->mana_pci_debugfs);
+ debugfs_lookup_and_remove("num_vports", gc->mana_pci_debugfs);
+
if (suspending)
return;
diff --git a/include/net/mana/gdma.h b/include/net/mana/gdma.h
index 7fe3a1b61b2d..c4e3ce5147f7 100644
--- a/include/net/mana/gdma.h
+++ b/include/net/mana/gdma.h
@@ -442,6 +442,7 @@ struct gdma_context {
struct gdma_dev mana_ib;
u64 pf_cap_flags1;
+ u64 gdma_protocol_ver;
struct workqueue_struct *service_wq;
diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
index 96d21cbbdee2..6d2e05a7368c 100644
--- a/include/net/mana/mana.h
+++ b/include/net/mana/mana.h
@@ -568,6 +568,14 @@ struct mana_port_context {
/* Debugfs */
struct dentry *mana_port_debugfs;
+
+ /* Cached vport/steering config for debugfs */
+ u32 vport_max_sq;
+ u32 vport_max_rq;
+ u32 steer_rx;
+ u32 steer_rss;
+ u32 steer_update_tab;
+ u32 steer_cqe_coalescing;
};
netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev);
--
2.34.1
^ permalink raw reply related
* [GIT PULL] wireless-2026-04-08
From: Johannes Berg @ 2026-04-08 8:15 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
So in a way I'd hoped it wouldn't come to this, but while I
was out last week a couple of things came in that seemed
relevant enough to squeeze in now. I guess it wouldn't be
much of an issue if not, but I figured I'd try anyway :)
Please pull and let us know if there's any problem.
Thanks,
johannes
The following changes since commit f8f5627a8aeab15183eef8930bf75ba88a51622f:
Merge tag 'net-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-04-02 09:57:06 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git tags/wireless-2026-04-08
for you to fetch changes up to ea245d78dec594372e27d8c79616baf49e98a4a1:
net: rfkill: prevent unlimited numbers of rfkill events from being created (2026-04-07 12:35:04 +0200)
----------------------------------------------------------------
A few last-minute fixes:
- rfkill: prevent boundless event list
- rt2x00: fix USB resource management
- brcmfmac: validate firmware IDs
- brcmsmac: fix DMA free size
----------------------------------------------------------------
Greg Kroah-Hartman (1):
net: rfkill: prevent unlimited numbers of rfkill events from being created
Johan Hovold (1):
wifi: rt2x00usb: fix devres lifetime
Pengpeng Hou (1):
wifi: brcmfmac: validate bsscfg indices in IF events
Thomas Fourier (1):
wifi: brcmsmac: Fix dma_free_coherent() size
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 5 ++++
.../net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
net/rfkill/core.c | 35 +++++++++++++++-------
4 files changed, 31 insertions(+), 13 deletions(-)
^ 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