* Re: [PATCH v2 2/6] bus: mhi: host: Add support for non-posted TSC timesync feature
From: Vadim Fedorenko @ 2026-04-14 17:46 UTC (permalink / raw)
To: Krishna Chaitanya Chundru, Manivannan Sadhasivam, Richard Cochran
Cc: mhi, linux-arm-msm, linux-kernel, netdev, Vivek Pernamitta
In-Reply-To: <20260411-tsc_timesync-v2-2-6f25f72987b3@oss.qualcomm.com>
On 11/04/2026 09:12, Krishna Chaitanya Chundru wrote:
> From: Vivek Pernamitta <quic_vpernami@quicinc.com>
>
> Implement non-posted time synchronization as described in section 5.1.1
> of the MHI v1.2 specification. The host disables low-power link states
> to minimize latency, reads the local time, issues a MMIO read to the
> device's TIME register.
>
> Add support for initializing this feature and export a function to be
> used by the drivers which does the time synchronization.
>
> MHI reads the device time registers in the MMIO address space pointed to
> by the capability register after disabling all low power modes and keeping
> MHI in M0. Before and after MHI reads, the local time is captured
> and shared for processing.
[...]
> + /*
> + * time critical code to fetch device time, delay between these two steps
> + * should be deterministic as possible.
> + */
> + preempt_disable();
> + local_irq_disable();
> +
> + time->t_host_pre = ktime_get_real();
> +
> + /*
> + * To ensure the PCIe link is in L0 when ASPM is enabled, perform series
> + * of back-to-back reads. This is necessary because the link may be in a
> + * low-power state (e.g., L1 or L1ss), and need to be forced it to
> + * transition to L0.
> + */
> + for (i = 0; i < MHI_NUM_BACK_TO_BACK_READS; i++) {
> + ret = mhi_read_reg(mhi_cntrl, mhi_tsync->time_reg,
> + TSC_TIMESYNC_TIME_LOW_OFFSET, &time->t_dev_lo);
> +
> + ret = mhi_read_reg(mhi_cntrl, mhi_tsync->time_reg,
> + TSC_TIMESYNC_TIME_HIGH_OFFSET, &time->t_dev_hi);
> + }
> +
> + time->t_host_post = ktime_get_real();
> +
> + local_irq_enable();
> + preempt_enable();
PTP_SYS_OFFSET_EXTENDED receives the amount of samples to read from user
space, you can use it instead of MHI_NUM_BACK_TO_BACK_READS, and in this
case it's better to grab host-pre and host-post time for a single
register read.
Also, PTP_SYS_OFFSET_EXTENDED was improved and currently supports
multiple clockids as system time, it's good to account for it.
^ permalink raw reply
* Re: [PATCH] net: mdio: octeon: use %p for bus id
From: Russell King (Oracle) @ 2026-04-14 17:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chen Jung Ku, davem, kuba, edumazet, pabeni, hkallweit1, netdev,
linux-kernel
In-Reply-To: <efc34ba8-730a-4c01-bc44-ee64569d2d4e@lunn.ch>
On Tue, Apr 14, 2026 at 06:16:08PM +0200, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 11:56:52PM +0800, Chen Jung Ku wrote:
> > Replace %px with %p to avoid exposing raw kernel pointer values.
>
> What exactly are we giving away here?
>
> compatible = "cavium,octeon-3860-mdio";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x11800 0x00001900 0x0 0x40>;
>
> Isn't bus->register_base this well known value?
>
> You also need to think about ABI.
There isn't ABI here.
bus->register_base = devm_platform_ioremap_resource(pdev, 0);
snprintf(bus->mii_bus->id, MII_BUS_ID_SIZE, "%px", bus->register_base);
bus->register_base is the ioremap'd version of the resource, which is
effectively random, and it can be either a 32 or 64-bit hex number
depending on the pointer size. It's an exceedingly bad choice of MDIO
bus ID.
A better more stable choice would be to use the bus address or
dev_name().
Even so, I don't think there's any ABI here as the existing "ID" will
not be stable.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Keith Busch @ 2026-04-14 17:34 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <20260409120415.GF86584@unreal>
On Thu, Apr 09, 2026 at 03:04:15PM +0300, Leon Romanovsky wrote:
> Something like that, on top of this proposal:
...
> +struct vfio_region_dma_tph {
> + u16 tag;
> + u8 ph;
> +};
> +
> struct vfio_region_dma_range {
> - __u64 offset;
> - __u64 length;
> + union {
> + __u64 offset;
> + struct vfio_region_dma_tph tph;
> + };
> + union {
> + __u64 length;
> + __u64 reserved;
> + };
> +};
> +
> +enum {
> + VFIO_DMABUF_FLAG_TPH = 1 << 0,
> };
Okay, so you have the hints as a separate action from the dmabuf
creation. I was trying to set it up in one shot, but this proposal may
be fine. We'll try this idea out internally.
^ permalink raw reply
* Re: [PATCH net-next v2] net/smc: cap allocation order for SMC-R physically contiguous buffers
From: Simon Horman @ 2026-04-14 17:16 UTC (permalink / raw)
To: D. Wythe
Cc: David S. Miller, Dust Li, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi,
Tony Lu, Wen Gu, linux-kernel, linux-rdma, linux-s390, netdev,
oliver.yang, pasic
In-Reply-To: <20260414021054.GA111420@j66a10360.sqa.eu95>
On Tue, Apr 14, 2026 at 10:10:54AM +0800, D. Wythe wrote:
> On Fri, Apr 10, 2026 at 04:16:31PM +0100, Simon Horman wrote:
> > On Tue, Apr 07, 2026 at 08:43:37PM +0800, D. Wythe wrote:
> > > The alloc_pages() cannot satisfy requests exceeding MAX_PAGE_ORDER,
> > > and attempting such allocations will lead to guaranteed failures
> > > and potential kernel warnings.
> > >
> > > For SMCR_PHYS_CONT_BUFS, cap the allocation order to MAX_PAGE_ORDER.
> > > This ensures the attempts to allocate the largest possible physically
> > > contiguous chunk succeed, instead of failing with an invalid order.
> > > This also avoids redundant "try-fail-degrade" cycles in
> > > __smc_buf_create().
> > >
> > > For SMCR_MIXED_BUFS, no cap is needed: if the order exceeds
> > > MAX_PAGE_ORDER, alloc_pages() will silently fail (__GFP_NOWARN)
> > > and automatically fall back to virtual memory.
> > >
> > > Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> > > Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
> > > ---
> > > Changes v1 -> v2:
> > > https://lore.kernel.org/netdev/20260312082154.36971-1-alibuda@linux.alibaba.com/
> > >
> > > - Move the bufsize cap from smcr_new_buf_create() up to
> > > __smc_buf_create(), which is simpler and avoids touching
> > > the allocation logic itself.
> >
> > The nit below notwithstanding, this looks good to me.
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
> >
> > > ---
> > > net/smc/smc_core.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
> > > index e2d083daeb7e..cdd881746e21 100644
> > > --- a/net/smc/smc_core.c
> > > +++ b/net/smc/smc_core.c
> > > @@ -2440,6 +2440,10 @@ static int __smc_buf_create(struct smc_sock *smc, bool is_smcd, bool is_rmb)
> > > /* use socket send buffer size (w/o overhead) as start value */
> > > bufsize = smc->sk.sk_sndbuf / 2;
> > >
> > > + /* limit bufsize for physically contiguous buffers */
> > > + if (!is_smcd && lgr->buf_type == SMCR_PHYS_CONT_BUFS)
> > > + bufsize = min_t(int, bufsize, (PAGE_SIZE << MAX_PAGE_ORDER));
> >
> > nit: I think min() is sufficient here, and the inner parentheses are
> > unnecessary
>
> Hi Simon,
>
> I think min_t is required here because min() triggers a signedness
> error:
>
> ././include/linux/compiler_types.h:706:38: error: call to
> ‘__compiletime_assert_950’ declared with attribute error: min(bufsize,
> ((1UL) << 12) << 10) signedness error
>
> The inner parentheses can be removed, though.
Ack, thanks for checking.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-net v2 2/6] ixgbe: add bounds check for debugfs register access
From: Simon Horman @ 2026-04-14 17:16 UTC (permalink / raw)
To: Jacob Keller
Cc: Aleksandr Loktionov, intel-wired-lan, anthony.l.nguyen, netdev,
Paul Greenwalt
In-Reply-To: <dda1f0f3-f57b-418a-93e6-2cdaa1d2ef35@intel.com>
On Mon, Apr 13, 2026 at 06:00:28PM -0700, Jacob Keller wrote:
> On 4/13/2026 3:30 AM, Simon Horman wrote:
> > On Wed, Apr 08, 2026 at 03:11:50PM +0200, Aleksandr Loktionov wrote:
> >> From: Paul Greenwalt <paul.greenwalt@intel.com>
> >>
> >> Prevent out-of-bounds MMIO accesses triggered through user-controlled
> >> register offsets. IXGBE_HFDR (0x15FE8) is the highest valid MMIO
> >> register in the ixgbe register map; any offset beyond it would address
> >> unmapped memory.
> >>
> >> Add a defense-in-depth check at two levels:
> >>
> >> 1. ixgbe_read_reg() -- the noinline register read accessor. A
> >> WARN_ON_ONCE() guard here catches any future code path (including
> >> ioctl extensions) that might inadvertently pass an out-of-range
> >> offset without relying on higher layers to catch it first.
> >> ixgbe_write_reg() is a static inline called from the TX/RX hot path;
> >> adding WARN_ON_ONCE there would inline the check at every call site,
> >> so only the read path gets this guard.
> >>
> >> 2. ixgbe_dbg_reg_ops_write() -- the debugfs 'reg_ops' interface is the
> >> only current path where a raw, user-supplied offset enters the driver.
> >> Gating it before invoking the register accessors provides a clean,
> >> user-visible failure (silent ignore with no kernel splat) for
> >> deliberately malformed debugfs writes.
> >>
> >> Add a reg <= IXGBE_HFDR guard to both the read and write paths in
> >> ixgbe_dbg_reg_ops_write(), and a WARN_ON_ONCE + early-return guard to
> >> ixgbe_read_reg().
> >>
> >> Fixes: 91fbd8f081e2 ("ixgbe: added reg_ops file to debugfs")
> >> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> >> ---
> >> v1 -> v2:
> >> - Add Fixes: tag; reroute from iwl-next to iwl-net (security-relevant
> >> hardening for user-controllable out-of-bounds MMIO).
> >
> > Thanks for the update.
> >
> > And sorry for not thinking to ask this earlier: this patch
> > addresses possible overruns of the mapped address space if the
> > supplied value for reg is too large. But do we also need a
> > guard against underrun if the value for reg is too small?
> >
>
> I don't think so. This is bounds checking a register offset which is an
> unsigned 32-bit value and begins at 0, so the map goes from 0 to
> IXGBE_HFDR. Since the value is unsigned, if it does underflow somehow it
> would then get caught by the check for IXGBE_HFDR right?
If the entire range from 0 to IXGBE_HFDR is mapped,
and it's ok for reg to have any value in that range,
then I agree there is no problem here.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: mdio: octeon: use %p for bus id
From: 古鎮榮 @ 2026-04-14 17:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, kuba, edumazet, pabeni, hkallweit1, linux, netdev,
linux-kernel
In-Reply-To: <efc34ba8-730a-4c01-bc44-ee64569d2d4e@lunn.ch>
Thank you for the clarification. I understand the concern now and will
not pursue this patch further.
Best regards,
Chen Jung Ku
Andrew Lunn <andrew@lunn.ch> 於 2026年4月15日週三 上午12:16寫道：
>
> On Tue, Apr 14, 2026 at 11:56:52PM +0800, Chen Jung Ku wrote:
> > Replace %px with %p to avoid exposing raw kernel pointer values.
>
> What exactly are we giving away here?
>
> compatible = "cavium,octeon-3860-mdio";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x11800 0x00001900 0x0 0x40>;
>
> Isn't bus->register_base this well known value?
>
> You also need to think about ABI.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net v5 1/2] flow_dissector: do not dissect PPPoE PFC frames
From: Simon Horman @ 2026-04-14 17:08 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Tony Nguyen, Guillaume Nault, Wojciech Drewek,
netdev, linux-kernel, Paul Mackerras, Jaco Kroon, James Carlson,
Marcin Szycik
In-Reply-To: <20260414021353.23471-1-qingfang.deng@linux.dev>
On Tue, Apr 14, 2026 at 10:13:48AM +0800, Qingfang Deng wrote:
> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT
> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating
> PFC for PPPoE sessions, and the flow dissector driver has assumed an
> uncompressed frame until the blamed commit.
>
> During the review process of that commit [1], support for PFC is
> suggested. However, having a compressed (1-byte) protocol field means
> the subsequent PPP payload is shifted by one byte, causing 4-byte
> misalignment for the network header and an unaligned access exception
> on some architectures.
>
> The exception can be reproduced by sending a PPPoE PFC frame to an
> ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE
> session is active on that interface:
>
> $ 0 : 00000000 80c40000 00000000 85144817
> $ 4 : 00000008 00000100 80a75758 81dc9bb8
> $ 8 : 00000010 8087ae2c 0000003d 00000000
> $12 : 000000e0 00000039 00000000 00000000
> $16 : 85043240 80a75758 81dc9bb8 00006488
> $20 : 0000002f 00000007 85144810 80a70000
> $24 : 81d1bda0 00000000
> $28 : 81dc8000 81dc9aa8 00000000 805ead08
> Hi : 00009d51
> Lo : 2163358a
> epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50
> ra : 805ead08 __skb_get_hash_net+0x74/0x12c
> Status: 11000403 KERNEL EXL IE
> Cause : 40800010 (ExcCode 04)
> BadVA : 85144817
> PrId : 0001992f (MIPS 1004Kc)
> Call Trace:
> [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50
> [<805ead08>] __skb_get_hash_net+0x74/0x12c
> [<805ef330>] get_rps_cpu+0x1b8/0x3fc
> [<805fca70>] netif_receive_skb_list_internal+0x324/0x364
> [<805fd120>] napi_complete_done+0x68/0x2a4
> [<8058de5c>] mtk_napi_rx+0x228/0xfec
> [<805fd398>] __napi_poll+0x3c/0x1c4
> [<805fd754>] napi_threaded_poll_loop+0x234/0x29c
> [<805fd848>] napi_threaded_poll+0x8c/0xb0
> [<80053544>] kthread+0x104/0x12c
> [<80002bd8>] ret_from_kernel_thread+0x14/0x1c
>
> Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000
>
> To reduce the attack surface and maintain performance, do not process
> PPPoE PFC frames.
>
> [1] https://patch.msgid.link/20220630231016.GA392@debian.home
> Fixes: 46126db9c861 ("flow_dissector: Add PPPoE dissectors")
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> Changes in v5: drop byte-swap change
> Link to v4: https://lore.kernel.org/netdev/20260410033627.93786-1-qingfang.deng@linux.dev/
>
> net/core/flow_dissector.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 1b61bb25ba0e..f9aaba554128 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -1374,16 +1374,8 @@ bool __skb_flow_dissect(const struct net *net,
> break;
> }
>
> - /* least significant bit of the most significant octet
> - * indicates if protocol field was compressed
> - */
> ppp_proto = ntohs(hdr->proto);
> - if (ppp_proto & 0x0100) {
> - ppp_proto = ppp_proto >> 8;
> - nhoff += PPPOE_SES_HLEN - 1;
> - } else {
> - nhoff += PPPOE_SES_HLEN;
> - }
I think it would be good to add a comment around here
describing how PFC is safely handled in this function.
> + nhoff += PPPOE_SES_HLEN;
>
> if (ppp_proto == PPP_IP) {
> proto = htons(ETH_P_IP);
> --
> 2.43.0
>
^ permalink raw reply
* [syzbot ci] Re: veth: add Byte Queue Limits (BQL) support
From: syzbot ci @ 2026-04-14 17:05 UTC (permalink / raw)
To: nogikh, hawk, linux-kernel, netdev, syzbot, syzkaller-bugs
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260414083316.19864-1-nogikh@google.com>
syzbot ci has tested the suggested fix patch on top of the following series:
[v2] veth: add Byte Queue Limits (BQL) support
https://lore.kernel.org/all/20260413094442.1376022-1-hawk@kernel.org
Patch: https://ci.syzbot.org/jobs/bf27b11f-8196-4c99-bc10-11843ded8a31/patch
The patch testing request could not be completed:
tree "net-next" is no longer known
Full report is available here:
https://ci.syzbot.org/session/31e795da-e7ea-4f46-8412-c30d420a5f1e
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply
* Re: [PATCH net] net: pse-pd: fix kernel-doc function name for pse_control_find_by_id()
From: Andrew Lunn @ 2026-04-14 16:44 UTC (permalink / raw)
To: Kory Maincent
Cc: Jakub Kicinski, netdev, linux-kernel, thomas.petazzoni,
Oleksij Rempel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni
In-Reply-To: <20260414150948.744618-1-kory.maincent@bootlin.com>
On Tue, Apr 14, 2026 at 05:09:47PM +0200, Kory Maincent wrote:
> The kernel-doc comment header incorrectly referenced the function
> name pse_control_find_net_by_id() instead of the actual function name
> pse_control_find_by_id(). Correct the function name in the documentation
> to match the implementation.
>
> Fixes: fc0e6db30941a ("net: pse-pd: Add support for reporting events")
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Willy Tarreau @ 2026-04-14 16:23 UTC (permalink / raw)
To: Pavitra Jha; +Cc: pabeni, chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <20260414153201.1633720-1-jhapavitra98@gmail.com>
Hello,
On Tue, Apr 14, 2026 at 11:31:56AM -0400, Pavitra Jha wrote:
> t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as
> a loop bound over port_msg->data[] without checking that the message buffer
> contains sufficient data. A modem sending port_count=65535 in a 12-byte
> buffer triggers a slab-out-of-bounds read of up to 262140 bytes.
>
> Add a struct_size() check after extracting port_count and before the loop.
> Pass msg_len to t7xx_port_enum_msg_handler() and use it to validate
> the message size before accessing port_msg->data[].
> Pass msg_len from both call sites: skb->len at the DPMAIF path after
> skb_pull(), and the captured rt_feature->data_len at the handshake path.
>
> Fixes: 39d439047f1d ("net: wwan: t7xx: Add control DMA interface")
> Cc: stable@vger.kernel.org
> Reported-by: Pavitra Jha <jhapavitra98@gmail.com>
> Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com>
Please note that you don't need the Reported-by tag when it's the same
as the Signed-off-by one.
Also, I'm noticing a few empty-line removals out of context below:
> diff --git a/drivers/net/wwan/t7xx/t7xx_modem_ops.c b/drivers/net/wwan/t7xx/t7xx_modem_ops.c
> index 7968e208d..d0559fe16 100644
> --- a/drivers/net/wwan/t7xx/t7xx_modem_ops.c
> +++ b/drivers/net/wwan/t7xx/t7xx_modem_ops.c
> @@ -453,25 +453,25 @@ static int t7xx_parse_host_rt_data(struct t7xx_fsm_ctl *ctl, struct t7xx_sys_inf
> {
> enum mtk_feature_support_type ft_spt_st, ft_spt_cfg;
> struct mtk_runtime_feature *rt_feature;
> + size_t feat_data_len;
> int i, offset;
>
> offset = sizeof(struct feature_query);
> for (i = 0; i < FEATURE_COUNT && offset < data_length; i++) {
> rt_feature = data + offset;
> - offset += sizeof(*rt_feature) + le32_to_cpu(rt_feature->data_len);
> -
> + feat_data_len = le32_to_cpu(rt_feature->data_len);
> + offset += sizeof(*rt_feature) + feat_data_len;
> ft_spt_cfg = FIELD_GET(FEATURE_MSK, core->feature_set[i]);
> if (ft_spt_cfg != MTK_FEATURE_MUST_BE_SUPPORTED)
> continue;
> -
here
> ft_spt_st = FIELD_GET(FEATURE_MSK, rt_feature->support_info);
> if (ft_spt_st != MTK_FEATURE_MUST_BE_SUPPORTED)
> return -EINVAL;
> -
Here, the original author probably left the line to highlight the return
statement.
> - if (i == RT_ID_MD_PORT_ENUM || i == RT_ID_AP_PORT_ENUM)
> - t7xx_port_enum_msg_handler(ctl->md, rt_feature->data);
> + if (i == RT_ID_MD_PORT_ENUM || i == RT_ID_AP_PORT_ENUM) {
> + t7xx_port_enum_msg_handler(ctl->md, rt_feature->data,
> + feat_data_len);
> + }
> }
> -
Here, why?
> return 0;
> }
>
> diff --git a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> index ae632ef96..d984a688d 100644
> --- a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> +++ b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> @@ -154,7 +161,6 @@ int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg)
>
> return 0;
> }
> -
This one as well.
> static int control_msg_handler(struct t7xx_port *port, struct sk_buff *skb)
> {
> const struct t7xx_port_conf *port_conf = port->port_conf;
Better leave them untouched, it will keep the code as readable as it
previously was and reduce the overall review effort.
thanks,
willy
^ permalink raw reply
* [PATCH net 2/2] bnge: remove unsupported backing store type
From: Vikas Gupta @ 2026-04-14 16:18 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, andrew+netdev, horms
Cc: netdev, linux-kernel, vsrama-krishna.nemani, bhargava.marreddy,
rajashekar.hudumula, ajit.khaparde, dharmender.garg,
rahul-rg.gupta, Vikas Gupta
In-Reply-To: <20260414161822.742382-1-vikas.gupta@broadcom.com>
The backing store type, BNGE_CTX_MRAV, is not applicable in Thor Ultra
devices. Remove it from the backing store configuration, as the firmware
will not populate entities in this backing store type, due to which the
driver load fails.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
---
drivers/net/ethernet/broadcom/bnge/bnge_rmem.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_rmem.c b/drivers/net/ethernet/broadcom/bnge/bnge_rmem.c
index 94f15e08a88c..b066ee887a09 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_rmem.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_rmem.c
@@ -324,7 +324,6 @@ int bnge_alloc_ctx_mem(struct bnge_dev *bd)
u32 l2_qps, qp1_qps, max_qps;
u32 ena, entries_sp, entries;
u32 srqs, max_srqs, min;
- u32 num_mr, num_ah;
u32 extra_srqs = 0;
u32 extra_qps = 0;
u32 fast_qpmd_qps;
@@ -390,21 +389,6 @@ int bnge_alloc_ctx_mem(struct bnge_dev *bd)
if (!bnge_is_roce_en(bd))
goto skip_rdma;
- ctxm = &ctx->ctx_arr[BNGE_CTX_MRAV];
- /* 128K extra is needed to accommodate static AH context
- * allocation by f/w.
- */
- num_mr = min_t(u32, ctxm->max_entries / 2, 1024 * 256);
- num_ah = min_t(u32, num_mr, 1024 * 128);
- ctxm->split_entry_cnt = BNGE_CTX_MRAV_AV_SPLIT_ENTRY + 1;
- if (!ctxm->mrav_av_entries || ctxm->mrav_av_entries > num_ah)
- ctxm->mrav_av_entries = num_ah;
-
- rc = bnge_setup_ctxm_pg_tbls(bd, ctxm, num_mr + num_ah, 2);
- if (rc)
- return rc;
- ena |= FUNC_BACKING_STORE_CFG_REQ_ENABLES_MRAV;
-
ctxm = &ctx->ctx_arr[BNGE_CTX_TIM];
rc = bnge_setup_ctxm_pg_tbls(bd, ctxm, l2_qps + qp1_qps + extra_qps, 1);
if (rc)
--
2.47.1
^ permalink raw reply related
* [PATCH net 1/2] bnge: fix initial HWRM sequence
From: Vikas Gupta @ 2026-04-14 16:18 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, andrew+netdev, horms
Cc: netdev, linux-kernel, vsrama-krishna.nemani, bhargava.marreddy,
rajashekar.hudumula, ajit.khaparde, dharmender.garg,
rahul-rg.gupta, Vikas Gupta
In-Reply-To: <20260414161822.742382-1-vikas.gupta@broadcom.com>
Firmware may not advertize correct resources if backing store is not
enabled before resource information is queried.
Fix the initial sequence of HWRMs so that driver gets capabilities
and resource information correctly.
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Reviewed-by: Rahul Gupta <rahul-rg.gupta@broadcom.com>
---
.../net/ethernet/broadcom/bnge/bnge_core.c | 40 ++++++++++---------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnge/bnge_core.c b/drivers/net/ethernet/broadcom/bnge/bnge_core.c
index b4090283df0f..2b13c552a2f6 100644
--- a/drivers/net/ethernet/broadcom/bnge/bnge_core.c
+++ b/drivers/net/ethernet/broadcom/bnge/bnge_core.c
@@ -73,30 +73,39 @@ static int bnge_func_qcaps(struct bnge_dev *bd)
return rc;
}
+ rc = bnge_alloc_ctx_mem(bd);
+ if (rc) {
+ dev_err(bd->dev, "Failed to allocate ctx mem rc: %d\n", rc);
+ goto err_free_ctx_mem;
+ }
+
rc = bnge_hwrm_func_resc_qcaps(bd);
if (rc) {
dev_err(bd->dev, "query resc caps failure rc: %d\n", rc);
- return rc;
+ goto err_free_ctx_mem;
}
rc = bnge_hwrm_func_qcfg(bd);
if (rc) {
dev_err(bd->dev, "query config failure rc: %d\n", rc);
- return rc;
+ goto err_free_ctx_mem;
}
rc = bnge_hwrm_vnic_qcaps(bd);
if (rc) {
dev_err(bd->dev, "vnic caps failure rc: %d\n", rc);
- return rc;
+ goto err_free_ctx_mem;
}
return 0;
+
+err_free_ctx_mem:
+ bnge_free_ctx_mem(bd);
+ return rc;
}
static void bnge_fw_unregister_dev(struct bnge_dev *bd)
{
- /* ctx mem free after unrgtr only */
bnge_hwrm_func_drv_unrgtr(bd);
bnge_free_ctx_mem(bd);
}
@@ -132,32 +141,25 @@ static int bnge_fw_register_dev(struct bnge_dev *bd)
bnge_hwrm_fw_set_time(bd);
- rc = bnge_hwrm_func_drv_rgtr(bd);
+ /* Get the resources and configuration from firmware */
+ rc = bnge_func_qcaps(bd);
if (rc) {
- dev_err(bd->dev, "Failed to rgtr with firmware rc: %d\n", rc);
+ dev_err(bd->dev, "Failed initial configuration rc: %d\n", rc);
return rc;
}
- rc = bnge_alloc_ctx_mem(bd);
+ rc = bnge_hwrm_func_drv_rgtr(bd);
if (rc) {
- dev_err(bd->dev, "Failed to allocate ctx mem rc: %d\n", rc);
- goto err_func_unrgtr;
- }
-
- /* Get the resources and configuration from firmware */
- rc = bnge_func_qcaps(bd);
- if (rc) {
- dev_err(bd->dev, "Failed initial configuration rc: %d\n", rc);
- rc = -ENODEV;
- goto err_func_unrgtr;
+ dev_err(bd->dev, "Failed to rgtr with firmware rc: %d\n", rc);
+ goto err_free_ctx_mem;
}
bnge_set_dflt_rss_hash_type(bd);
return 0;
-err_func_unrgtr:
- bnge_fw_unregister_dev(bd);
+err_free_ctx_mem:
+ bnge_free_ctx_mem(bd);
return rc;
}
--
2.47.1
^ permalink raw reply related
* [PATCH net 0/2] bnge fixes
From: Vikas Gupta @ 2026-04-14 16:18 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, andrew+netdev, horms
Cc: netdev, linux-kernel, vsrama-krishna.nemani, bhargava.marreddy,
rajashekar.hudumula, ajit.khaparde, dharmender.garg,
rahul-rg.gupta, Vikas Gupta
Hi,
This series fix two issues.
Patch-1:
Due to wrong HWRM sequence, driver do not get the correct
information regarding resources and capabilitie.
The patch fixes the initial HWRM sequence.
Patch-2:
Remove the unsupported backing store type initialization, which is
not supported in Thor Ultra devices.
Thanks,
Vikas
Vikas Gupta (2):
bnge: fix initial HWRM sequence
bnge: remove unsupported backing store type
.../net/ethernet/broadcom/bnge/bnge_core.c | 40 ++++++++++---------
.../net/ethernet/broadcom/bnge/bnge_rmem.c | 16 --------
2 files changed, 21 insertions(+), 35 deletions(-)
--
2.47.1
^ permalink raw reply
* Re: [PATCH] net: mdio: octeon: use %p for bus id
From: Andrew Lunn @ 2026-04-14 16:16 UTC (permalink / raw)
To: Chen Jung Ku
Cc: davem, kuba, edumazet, pabeni, hkallweit1, linux, netdev,
linux-kernel
In-Reply-To: <20260414155652.7468-1-ku.loong@gapp.nthu.edu.tw>
On Tue, Apr 14, 2026 at 11:56:52PM +0800, Chen Jung Ku wrote:
> Replace %px with %p to avoid exposing raw kernel pointer values.
What exactly are we giving away here?
compatible = "cavium,octeon-3860-mdio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x11800 0x00001900 0x0 0x40>;
Isn't bus->register_base this well known value?
You also need to think about ABI.
Andrew
^ permalink raw reply
* [PATCH net v3 3/3] vsock/test: add MSG_PEEK after partial recv test
From: Luigi Leonardi @ 2026-04-14 16:10 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260414-fix_peek-v3-0-e7daead49f83@redhat.com>
Add a test that verifies MSG_PEEK works correctly after a partial
recv().
This is to test a bug that was present in the
`virtio_transport_stream_do_peek()` when computing the number of bytes to
copy: After a partial read, the peek function didn't take into
consideration the number of bytes that were already read. So peeking the
whole buffer would cause an out-of-bounds read, that resulted in a -EFAULT.
This test does exactly this: do a partial recv on a buffer, then try to
peek the whole buffer content.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
tools/testing/vsock/vsock_test.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index bdb0754965df..ab387a13f0ae 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -346,6 +346,38 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
return test_msg_peek_server(opts, false);
}
+static void test_stream_peek_after_recv_server(const struct test_opts *opts)
+{
+ unsigned char buf_normal[MSG_PEEK_BUF_LEN];
+ unsigned char buf_peek[MSG_PEEK_BUF_LEN];
+ int fd;
+
+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
+ if (fd < 0) {
+ perror("accept");
+ exit(EXIT_FAILURE);
+ }
+
+ control_writeln("SRVREADY");
+
+ /* Partial recv to advance offset within the skb */
+ recv_buf(fd, buf_normal, 1, 0, 1);
+
+ /* Ask more bytes than available */
+ recv_buf(fd, buf_peek, sizeof(buf_peek), MSG_PEEK, sizeof(buf_peek) - 1);
+
+ /* Recv rest of the data */
+ recv_buf(fd, buf_normal, sizeof(buf_normal) - 1, 0, sizeof(buf_normal) - 1);
+
+ /* Compare full peek and normal read. */
+ if (memcmp(buf_peek, buf_normal, sizeof(buf_peek) - 1)) {
+ fprintf(stderr, "Full peek data mismatch\n");
+ exit(EXIT_FAILURE);
+ }
+
+ close(fd);
+}
+
#define SOCK_BUF_SIZE (2 * 1024 * 1024)
#define SOCK_BUF_SIZE_SMALL (64 * 1024)
#define MAX_MSG_PAGES 4
@@ -2509,6 +2541,11 @@ static struct test_case test_cases[] = {
.run_client = test_stream_tx_credit_bounds_client,
.run_server = test_stream_tx_credit_bounds_server,
},
+ {
+ .name = "SOCK_STREAM MSG_PEEK after partial recv",
+ .run_client = test_stream_msg_peek_client,
+ .run_server = test_stream_peek_after_recv_server,
+ },
{},
};
--
2.53.0
^ permalink raw reply related
* [PATCH net v3 2/3] vsock/test: fix MSG_PEEK handling in recv_buf()
From: Luigi Leonardi @ 2026-04-14 16:10 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260414-fix_peek-v3-0-e7daead49f83@redhat.com>
`recv_buf` does not handle the MSG_PEEK flag correctly: it keeps calling
`recv` until all requested bytes are available or an error occurs.
The problem is how it calculates the amount of bytes read: MSG_PEEK
doesn't consume any bytes, will re-read the same bytes from the buffer
head, so, summing the return value every time is wrong.
Moreover, MSG_PEEK doesn't consume the bytes in the buffer, so if the
requested amount is more than the bytes available, the loop will never
terminate, because `recv` will never return EOF. For this reason we need
to compare the amount of read bytes with the number of bytes expected.
Add a check, and if the MSG_PEEK flag is present, update the counter of
read bytes differently, and break if we read the expected amount.
This allows us to simplify the `test_stream_credit_update_test`, by
reusing `recv_buf`, like some other tests already do.
This also fixes callers that pass MSG_PEEK to recv_buf().
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
tools/testing/vsock/util.c | 15 +++++++++++++++
tools/testing/vsock/vsock_test.c | 13 +------------
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 1fe1338c79cd..2c9ee3210090 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -381,7 +381,13 @@ void send_buf(int fd, const void *buf, size_t len, int flags,
}
}
+#define RECV_PEEK_RETRY_USEC 10
+
/* Receive bytes in a buffer and check the return value.
+ *
+ * MSG_PEEK note: MSG_PEEK doesn't consume bytes from the buffer, so partial
+ * reads cannot be summed. Instead, the function retries until recv() returns
+ * exactly expected_ret bytes in a single call.
*
* expected_ret:
* <0 Negative errno (for testing errors)
@@ -403,6 +409,15 @@ void recv_buf(int fd, void *buf, size_t len, int flags, ssize_t expected_ret)
if (ret <= 0)
break;
+ if (flags & MSG_PEEK) {
+ if (ret == expected_ret) {
+ nread = ret;
+ break;
+ }
+ timeout_usleep(RECV_PEEK_RETRY_USEC);
+ continue;
+ }
+
nread += ret;
} while (nread < len);
timeout_end();
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5bd20ccd9335..bdb0754965df 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -1500,18 +1500,7 @@ static void test_stream_credit_update_test(const struct test_opts *opts,
}
/* Wait until there will be 128KB of data in rx queue. */
- while (1) {
- ssize_t res;
-
- res = recv(fd, buf, buf_size, MSG_PEEK);
- if (res == buf_size)
- break;
-
- if (res <= 0) {
- fprintf(stderr, "unexpected 'recv()' return: %zi\n", res);
- exit(EXIT_FAILURE);
- }
- }
+ recv_buf(fd, buf, buf_size, MSG_PEEK, buf_size);
/* There is 128KB of data in the socket's rx queue, dequeue first
* 64KB, credit update is sent if 'low_rx_bytes_test' == true.
--
2.53.0
^ permalink raw reply related
* [PATCH net v3 0/3] vsock/virtio: fix MSG_PEEK calculation on bytes to copy
From: Luigi Leonardi @ 2026-04-14 16:10 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
`virtio_transport_stream_do_peek`, when calculating the number of bytes to
copy, didn't consider the `offset`, caused by partial reads that happened
before.
This might cause out-of-bounds read that lead to an EFAULT.
More details in the commits.
Commit 1 introduces the fix
Commit 2 introduces some preliminary work for adding a test and fixes a
problem in existing tests.
Commit 3 introduces a test that checks for this bug to avoid future
regressions.
For disclosure: this bug was found initially by claude opus 4.6, I then analzyed
it and worked on the fix and the test.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
Changes in v3:
- Addressed reviwers omment
- Dropped test client, reusing the one already existing
- Minor changes: added comment, improved commit messages
- Rebased to latest net-next
- Link to v2: https://lore.kernel.org/r/20260407-fix_peek-v2-0-2e2581dc8b7c@redhat.com
Changes in v2:
- Addressed reviewers comment
- Test now uses the recv_buf utils.
- Removed unnecessary barrier
- Checkpatch warnings.
- Added new commit that allows to use recv_buf with MSG_PEEK
- Picked up RoBs
- Link to v1: https://lore.kernel.org/r/20260402-fix_peek-v1-0-ad274fcef77b@redhat.com
---
Luigi Leonardi (3):
vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
vsock/test: fix MSG_PEEK handling in recv_buf()
vsock/test: add MSG_PEEK after partial recv test
net/vmw_vsock/virtio_transport_common.c | 5 ++--
tools/testing/vsock/util.c | 15 ++++++++++
tools/testing/vsock/vsock_test.c | 50 +++++++++++++++++++++++++--------
3 files changed, 55 insertions(+), 15 deletions(-)
---
base-commit: bc28831d7a09f7058cdca4658d81e5faf635bed7
change-id: 20260401-fix_peek-6837b83469e3
Best regards,
--
Luigi Leonardi <leonardi@redhat.com>
^ permalink raw reply
* [PATCH net v3 1/3] vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
From: Luigi Leonardi @ 2026-04-14 16:10 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260414-fix_peek-v3-0-e7daead49f83@redhat.com>
`virtio_transport_stream_do_peek()` does not account for the skb offset
when computing the number of bytes to copy.
This means that, after a partial recv() that advances the offset, a peek
requesting more bytes than are available in the sk_buff causes
`skb_copy_datagram_iter()` to go past the valid payload, resulting in
a -EFAULT.
The dequeue path already handles this correctly.
Apply the same logic to the peek path.
Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index a152a9e208d0..b5015ab2ee1e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -545,9 +545,8 @@ virtio_transport_stream_do_peek(struct vsock_sock *vsk,
skb_queue_walk(&vvs->rx_queue, skb) {
size_t bytes;
- bytes = len - total;
- if (bytes > skb->len)
- bytes = skb->len;
+ bytes = min_t(size_t, len - total,
+ skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset);
spin_unlock_bh(&vvs->rx_lock);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v3 4/5] net: phy: microchip_t1: Replace phydev->lock with mdio_lock in lan937x_dsp_workaround()
From: Andrew Lunn @ 2026-04-14 16:08 UTC (permalink / raw)
To: Biju
Cc: Arun Ramadoss, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Biju Das, UNGLinuxDriver,
Russell King, netdev, linux-kernel, Geert Uytterhoeven,
Prabhakar Mahadev Lad, linux-renesas-soc
In-Reply-To: <20260412140032.122841-5-biju.das.jz@bp.renesas.com>
> - mutex_lock(&phydev->lock);
> + mutex_lock(&phydev->mdio.bus->mdio_lock);
phy_lock_mdio_bus(), and the phy_unlock_mdio_bus().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 3/5] net: phy: mscc: Drop unnecessary phydev->lock
From: Andrew Lunn @ 2026-04-14 16:06 UTC (permalink / raw)
To: Biju
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Biju Das, Russell King, Lad Prabhakar,
Horatiu Vultur, Vladimir Oltean, netdev, linux-kernel,
Geert Uytterhoeven, linux-renesas-soc
In-Reply-To: <20260412140032.122841-4-biju.das.jz@bp.renesas.com>
On Sun, Apr 12, 2026 at 03:00:25PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Remove manual mutex_lock/unlock(&phydev->lock) calls from several
> functions in the MSCC PHY driver.
>
> In vsc85xx_edge_rate_cntl_set(), phydev->lock is taken around a single
> phy_modify_paged() call. phy_modify_paged() is already a fully locked
> atomic operation that acquires the MDIO bus lock internally, so the
> additional phydev->lock is unnecessary.
>
> The remaining three functions — vsc85xx_mac_if_set(),
> vsc8531_pre_init_seq_set(), and vsc85xx_eee_init_seq_set() — use
> phy_read(), phy_write(), phy_select_page(), and phy_restore_page(),
> all of which operate under the MDIO bus lock. Taking phydev->lock
> around them provides no additional serialisation.
>
> Along with dropping the locks, error-path labels are renamed from
> out_unlock to err or restore_oldpage to better reflect their purpose.
> In vsc8531_pre_init_seq_set() and vsc85xx_eee_init_seq_set(), the
> redundant intermediate assignment of oldpage before returning is also
> eliminated.
>
> No functional change intended.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] net: mdio: octeon: use %p for bus id
From: Chen Jung Ku @ 2026-04-14 15:56 UTC (permalink / raw)
To: davem, kuba
Cc: edumazet, pabeni, andrew, hkallweit1, linux, netdev, linux-kernel,
Chen Jung Ku
Replace %px with %p to avoid exposing raw kernel pointer values.
Signed-off-by: Chen Jung Ku <ku.loong@gapp.nthu.edu.tw>
---
drivers/net/mdio/mdio-octeon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mdio/mdio-octeon.c b/drivers/net/mdio/mdio-octeon.c
index cb53dccbde1a..c9c000bb0cd5 100644
--- a/drivers/net/mdio/mdio-octeon.c
+++ b/drivers/net/mdio/mdio-octeon.c
@@ -38,7 +38,7 @@ static int octeon_mdiobus_probe(struct platform_device *pdev)
oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
bus->mii_bus->name = KBUILD_MODNAME;
- snprintf(bus->mii_bus->id, MII_BUS_ID_SIZE, "%px", bus->register_base);
+ snprintf(bus->mii_bus->id, MII_BUS_ID_SIZE, "%p", bus->register_base);
bus->mii_bus->parent = &pdev->dev;
bus->mii_bus->read = cavium_mdiobus_read_c22;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v3 5/5] net: phy: Move phy_init_hw() from phy_resume() to __phy_resume()
From: Andrew Lunn @ 2026-04-14 16:03 UTC (permalink / raw)
To: Biju
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Biju Das, Russell King, netdev, linux-kernel,
Geert Uytterhoeven, Prabhakar Mahadev Lad, linux-renesas-soc
In-Reply-To: <20260412140032.122841-6-biju.das.jz@bp.renesas.com>
On Sun, Apr 12, 2026 at 03:00:27PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Now that redundant locking has been removed from PHY driver callbacks,
> phy_init_hw() can be called with phydev->lock held.
>
> Many MAC drivers and the phylink framework resume the PHY via
> phy_start(), which invokes __phy_resume() directly without going
> through phy_resume(). Keeping phy_init_hw() in phy_resume() means it
> is not called in this path.
>
> Move phy_init_hw() into __phy_resume() so that PHY soft reset and
> re-initialisation happen unconditionally on every resume, regardless
> of which code path triggers it.
I would change the order of these patches. First remove the redundant
locks. You can then put phy_init_hw() into __phy_resume(), rather than
first moving it into phy_resume() and then __phy_resume().
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Dipayaan Roy @ 2026-04-14 16:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <20260412125917.4fa8fc8d@kernel.org>
On Sun, Apr 12, 2026 at 12:59:17PM -0700, Jakub Kicinski wrote:
> On Thu, 9 Apr 2026 18:35:09 -0700 Jakub Kicinski wrote:
> > On Tue, 7 Apr 2026 12:59:17 -0700 Dipayaan Roy wrote:
> > > This behavior is observed on a single platform; other platforms
> > > perform better with page_pool fragments, indicating this is not a
> > > page_pool issue but platform-specific.
> >
> > Well, someone has to run some experiments and confirm other ARM
> > platforms are not impacted, with data. I was hoping to do it myself
> > but doesn't look like that will happen in time for the merge window :(
>
> Please repost with the perf analysis on other commercially available
> ARM platform. Something like:
>
> This is a workaround applicable to only some platforms. Modifying
> driver X to use a similar workaround on [Ampere Max|nVidia
> Grace|Amazon Graviton 3|..] the performance for split pages is
> y% higher than when using single pages.
> --
> pw-bot: cr
Hi Jakub,
I ran the same experiment on an alternate ARM64 platform from a
different vendor, which I was able to access only recently. I still see
roughly a 5% overhead from the atomic refcount operation itself, but on
that platform there is no throughput drop when using page fragments
versus full-page mode. In both cases, the setup reaches line rate. That
suggests the atomic overhead alone does not explain the throughput loss
on the specific hardware we are discussing.
I also received an update from the hardware team. They collected PCIe
traces and observed stalls on this particular ARM64 prcossor
when running with page fragments, while those stalls are not seen in
full-page mode. The exact root cause is still under investigation, but
their current assessment is that this is likely a microarchitectural
issue in the PCIe root port. Based on that, they are asking for a
software workaround that uses full pages until the issue is fully
understood.
For that reason, I am asking whether this could be accepted as an
ethtool private flag rather than as a generic driver change,
since the problem is still specific to one CPU/platform.
Please let me know whether you think this patch with private flag
would be acceptable here.
Regards
Dipayaan Roy
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexei Starovoitov @ 2026-04-14 15:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZd31GzdpEqR8VhfK4JtUKyyRMgbBoAbeGACJgm7WvB6Vw@mail.gmail.com>
On Tue, Apr 14, 2026 at 8:10 AM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Tue, Apr 14, 2026 at 4:36 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > > ACK, I'll try to use those kasan_check_read and kasan_check_write rather
> > > than __asan_{load,store}X.
> >
> > No. The performance penalty will be too high.
>
> With using __asan_load/storeX(), it will be one function call to get
> to check_region_inline(): __asan_load/storeX->check_region_inline.
>
> With kasan_check_read/write(), right now, it would be two function
> calls: __kasan_check_read->kasan_check_range->check_region_inline.
>
> I doubt an extra function call would make a difference in terms of
> performance: the shadow checking itself is also expensive.
>
> But if the second call is a concern, we can move kasan_check_range()
> and lower-level functions into mm/kasan/generic.h and include it into
> shadow.c, and then it will be just one function call.
>
> To improve performance further, the JIT compiler could emit inlined
> shadow checking instructions, same as the C compiler does with
> KASAN_INLINE=y.
>
> > hw_tags won't work without corresponding JIT work.
>
> You probably meant SW_TAGS here.
>
> HW_TAGS will likely just work without any JIT changes (even the
> kasan_check_byte() thing I mentioned should not be required), assuming
> JIT'ed BPF code just accesses kernel-returned pointers as is.
>
> > I see no point sacrificing performance for aesthetics.
>
> With the change I suggested above, there would be no performance
> difference. And the code stays cleaner.
>
> > __asan_load/storeX is what compilers emit.
>
> For Generic mode. For SW_TAGS, the function names are different.
> Keeping this detail within the KASAN code is cleaner.
I think we're talking past each other.
We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
We're not going to modify arm64 JIT at all.
This is purely KASAN_GENRIC and only on x86-64.
JIT will emit exactly what compilers emit for generic
which is __asan_load/store. This is as stable ABI as it can get
and we don't want to deviate from it.
The goal here is to find bugs in the verifier.
If something got past it, that shouldn't have,
kasan generic on x86-64 is enough.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] Follow-ups to nk_qlease net selftests
From: patchwork-bot+netdevbpf @ 2026-04-14 15:50 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, kuba, dw, pabeni, razor
In-Reply-To: <20260413220809.604592-1-daniel@iogearbox.net>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 14 Apr 2026 00:08:03 +0200 you wrote:
> This is a set of follow-ups addressing [0]:
>
> - Split netdevsim tests from HW tests in nk_qlease and move the SW
> tests under selftests/net/
> - Remove multiple ksft_run()s to fix the recently enforced hard-fail
> - Move all the setup inside the test cases for the ones under
> selftests/net/ (I'll defer the HW ones to David)
> - Add more test coverage related to queue leasing behavior and corner
> cases, so now we have 45 tests in nk_qlease.py with netdevsim
> which does not need special HW
>
> [...]
Here is the summary with links:
- [net-next,v2,1/3] tools/ynl: Make YnlFamily closeable as a context manager
https://git.kernel.org/netdev/net-next/c/4a6fe5fe6004
- [net-next,v2,2/3] selftests/net: Split netdevsim tests from HW tests in nk_qlease
https://git.kernel.org/netdev/net-next/c/e254ffb9502c
- [net-next,v2,3/3] selftests/net: Add additional test coverage in nk_qlease
https://git.kernel.org/netdev/net-next/c/1e822171ba9b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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