From: sashiko-bot@kernel.org
To: "Tjerk Kusters" <tkusters@aweta.nl>
Cc: intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org
Subject: Re: [PATCH net v4 2/2] igb: only strip Rx timestamp header on the first buffer of a frame
Date: Tue, 03 Nov 2026 10:53:29 +0000 [thread overview]
Message-ID: <sashiko-outbox-195080@kernel.org> (raw)
In-Reply-To: <20261102-igb-rx-ts-fix-v4-2-8785124c5d23@aweta.nl>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] igb: XDP setup and MTU checks in igb_xdp_setup() reject default MTU 1500
--
commit e6fdd6185a160da19639b21242c6743c31579ab8
Author: Tjerk Kusters <tkusters@aweta.nl>
igb: only strip Rx timestamp header on the first buffer of a frame
This commit guards the Rx hardware timestamp header strip in
igb_clean_rx_irq() with !skb so that continuation buffers of multi-buffer
frames do not have payload bytes stripped when their payload starts with 8
zero bytes. It relies on the preceding commit in the series to prevent
multi-buffer frames from reaching the XDP path.
Link: https://lore.kernel.org/all/20261028083344.3047350-2-p@1g4.org/
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index 5bf489cd7b066..c4eb9f589fbe7 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -9072,8 +9072,11 @@ static int igb_clean_rx_irq(struct igb_q_vector *q_vector, const int budget)
> rx_buffer = igb_get_rx_buffer(rx_ring, size, &rx_buf_pgcnt);
> pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
>
> - /* pull rx packet timestamp if available and valid */
> - if (igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
> + /* pull rx packet timestamp if available and valid; it is only
> + * present on the first buffer of a frame
> + */
> + if (!skb &&
> + igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
[Severity: High]
Does the prerequisite buffer size check in the series break attaching and
detaching XDP programs at the default MTU of 1500 on systems with 4 KiB
pages?
When the interface is opened at the default MTU of 1500
(adapter->max_frame_size = 1526), igb_open() -> igb_configure() ->
igb_configure_rx() -> igb_set_rx_buffer_len() enables build_skb without
setting the 3 KiB buffer flag:
drivers/net/ethernet/intel/igb/igb_main.c:igb_set_rx_buffer_len() {
...
set_ring_build_skb_enabled(rx_ring);
#if (PAGE_SIZE < 8192)
if (adapter->max_frame_size > IGB_MAX_FRAME_BUILD_SKB ||
IGB_2K_TOO_SMALL_WITH_PADDING ||
rd32(E1000_RCTL) & E1000_RCTL_SBP)
set_ring_uses_large_buffer(rx_ring);
#endif
}
Because adapter->max_frame_size (1526) is not greater than
IGB_MAX_FRAME_BUILD_SKB (1536 - NET_IP_ALIGN, i.e. 1536 or 1534) and
IGB_2K_TOO_SMALL_WITH_PADDING is false with 4 KiB pages, igb_rx_bufsz()
returns IGB_MAX_FRAME_BUILD_SKB:
drivers/net/ethernet/intel/igb/igb.h:igb_rx_bufsz() {
#if (PAGE_SIZE < 8192)
if (ring_uses_large_buffer(ring))
return IGB_RXBUFFER_3072;
if (ring_uses_build_skb(ring))
return IGB_MAX_FRAME_BUILD_SKB;
#endif
return IGB_RXBUFFER_2048;
}
However, igb_xdp_setup() checks whether frame_size + IGB_TS_HDR_LEN fits in
igb_rx_bufsz(ring):
drivers/net/ethernet/intel/igb/igb_main.c:igb_xdp_setup() {
int i, frame_size = dev->mtu + IGB_ETH_PKT_HDR_PAD;
...
for (i = 0; i < adapter->num_rx_queues; i++) {
struct igb_ring *ring = adapter->rx_ring[i];
if (frame_size + IGB_TS_HDR_LEN > igb_rx_bufsz(ring)) {
...
return -EINVAL;
}
}
}
At MTU 1500, frame_size + IGB_TS_HDR_LEN is 1526 + 16 = 1542, which exceeds
IGB_MAX_FRAME_BUILD_SKB (1536 or 1534) and causes igb_xdp_setup() to reject
attaching XDP with -EINVAL. In addition, because igb_xdp_setup() runs this
check even when bpf->prog is NULL, if an XDP program was attached before the
interface was first opened (when ring->flags is 0 and igb_rx_bufsz() returns
2048) or at MTU 3000 before lowering the MTU to 1500, detaching the XDP
program at MTU 1500 also fails with -EINVAL.
Similarly, igb_change_mtu() checks max_frame + IGB_TS_HDR_LEN against
igb_rx_bufsz(ring) using the current ring flags before adapter->max_frame_size
is updated and igb_set_rx_buffer_len() reconfigures the rings:
drivers/net/ethernet/intel/igb/igb_main.c:igb_change_mtu() {
...
if (igb_xdp_is_enabled(adapter)) {
int i;
for (i = 0; i < adapter->num_rx_queues; i++) {
struct igb_ring *ring = adapter->rx_ring[i];
if (max_frame + IGB_TS_HDR_LEN > igb_rx_bufsz(ring)) {
...
return -EINVAL;
}
}
}
}
If XDP is attached at MTU <= 1494 (where 1536-byte build_skb buffers are
used), raising the MTU to 1500..3030 is rejected even though MTUs above 1510
would switch the rings to 3072-byte buffers, whereas lowering the MTU from
3000 to 1500 succeeds and leaves XDP active on 1536-byte build_skb buffers
where it can no longer be detached.
Should igb_set_rx_buffer_len() account for IGB_TS_HDR_LEN (or select 3 KiB
buffers when needed for XDP/PTP), and should igb_xdp_setup() skip the frame
size check when detaching (bpf->prog == NULL)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-igb-rx-ts-fix-v4-0-8785124c5d23@aweta.nl?part=2
next prev parent reply other threads:[~2026-11-03 10:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 9:58 [PATCH net v4 0/2] igb: only strip the Rx timestamp header from the first buffer of a frame Tjerk Kusters via B4 Relay
2026-11-02 9:58 ` [PATCH net v4 1/2] igb: do not let XDP frames span more than one Rx buffer Tjerk Kusters via B4 Relay
2026-11-03 10:53 ` sashiko-bot
2026-11-03 11:16 ` netdev-bot+sashiko
2026-11-03 13:16 ` Tjerk Kusters
2026-11-02 9:58 ` [PATCH net v4 2/2] igb: only strip Rx timestamp header on the first buffer of a frame Tjerk Kusters via B4 Relay
2026-11-03 10:53 ` sashiko-bot [this message]
2026-11-03 11:16 ` netdev-bot+sashiko
2026-11-02 13:28 ` [PATCH net v4 0/2] igb: only strip the Rx timestamp header from " Maciej Fijalkowski
2026-11-02 14:55 ` Tjerk Kusters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-195080@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tkusters@aweta.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox