Netdev List
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: <netdev-bot+sashiko@kernel.org>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<bjorn@kernel.org>, <magnus.karlsson@intel.com>,
	<jonathan.lemon@gmail.com>, <sdf@fomichev.me>, <ast@kernel.org>,
	<daniel@iogearbox.net>, <hawk@kernel.org>,
	<john.fastabend@gmail.com>, <aleksander.lobakin@intel.com>,
	<bpf@vger.kernel.org>, <netdev@vger.kernel.org>,
	<syzbot+f16c1b285c9f63994eec@syzkaller.appspotmail.com>
Subject: Re: [PATCH net v2] xsk: set network header on skb at generic transmit
Date: Tue, 22 Sep 2026 18:05:48 +0200	[thread overview]
Message-ID: <arKm5gCaERk6MaGA@boxer> (raw)
In-Reply-To: <CAL+tcoC=w6j+1p8ovjbLxgb1QdL3ipic0nMOvX_9OJrspSQS2Q@mail.gmail.com>

On Fri, Sep 04, 2026 at 12:10:37PM +0800, Jason Xing wrote:
> On Fri, Sep 4, 2026 at 11:53 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > On Fri, Sep 4, 2026 at 7:34 AM <netdev-bot+sashiko@kernel.org> wrote:
> > >
> > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > issue(s) to consider:
> > >
> > > Critical: 0 · High: 0 · Medium: 1 · Low: 0
> > >
> > > - [Medium] net/xdp/xsk.c: the new skb_reset_network_header(skb) in
> > >   xsk_skb_init_misc() (net/xdp/xsk.c:950) anchors the *network* header…
> > >
> > > --
> > >
> > > xsk: set network header on skb at generic transmit
> > >
> > > The XSK generic transmit path never reset the network header, so after
> > > skb_reserve(hr) the stored offset was left behind skb->data and
> > > skb_network_offset() returned -hr, which tripped the
> > > DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) in pskb_may_pull_reason() when the
> > > skb reached a tunnel device. This adds skb_reset_network_header() in
> > > xsk_skb_init_misc() so the offset is 0.
> > >
> > > Closes: https://syzkaller.appspot.com/bug?extid=f16c1b285c9f63994eec
> > > Link: https://lore.kernel.org/all/20260826012052.51028-1-kerneljasonxing@gmail.com/
> > >
> > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > index 33475b180ea6f..2077bb6299ca9 100644
> > > > --- a/net/xdp/xsk.c
> > > > +++ b/net/xdp/xsk.c
> > > > @@ -947,6 +947,8 @@ static int xsk_skb_init_misc(struct sk_buff *skb, struct xdp_sock *xs,
> > > >  {
> > > >       int err;
> > > >
> > > > +     skb_reset_network_header(skb);
> > > > +
> > >
> > > [Severity: Medium]
> > > The negative offset does look closed by this: xsk_skb_init_misc() runs
> > > after skb_reserve(hr) in xsk_build_skb() and xsk_build_skb_zerocopy(), so
> > > skb_network_offset() becomes 0. Two parts of the reasoning look off
> > > though.
> > >
> > > First, the commit message says:
> > >
> > >   "Note this anchors it at the start of the frame (L2 for an ethernet
> > >    device), which is the same convention AF_PACKET uses on TX."
> > >
> > > Is that what AF_PACKET does? packet_parse_headers() anchors the MAC
> > > header, not the network header:
> > >
> > > net/packet/af_packet.c:packet_parse_headers() {
> > >         /* On TX skb->data is the L2 header; anchor it for all socket types. */
> > >         skb_reset_mac_header(skb);
> > >
> > >         if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
> > >             sock->type == SOCK_RAW)
> > >                 skb->protocol = dev_parse_header_protocol(skb);
> > >         ...
> > > }
> >
> > I'm going to remove this part.
> >
> > >
> > > and packet_snd() for SOCK_RAW resets network_header before moving
> > > skb->data back over the hard header, so network_header stays at the L3
> > > boundary:
> > >
> > >         skb_reset_network_header(skb);
> > >         ...
> > >         } else if (reserve) {
> > >                 skb_reserve(skb, -reserve);
> > >
> > > So after this patch an AF_XDP skb differs from an AF_PACKET one by
> > > hard_header_len in network_header, and mac_header is still at the unset
> > > sentinel left by __finalize_skb_around(), i.e. skb_mac_header_was_set()
> > > is false.
> > >
> > > Second, the commit message says AF_PACKET "supports GSO/checksum
> > > offload; none of that applies here". Does checksum offload really not
> > > apply? xsk_skb_metadata() in the same file does:
> > >
> > > net/xdp/xsk.c:xsk_skb_metadata() {
> > >                 skb->csum_start = hr + csum_start;
> > >                 skb->csum_offset = csum_offset;
> > >                 skb->ip_summed = CHECKSUM_PARTIAL;
> > >
> > >                 if (unlikely(pool->tx_sw_csum)) {
> > >                         ...
> > >                         err = skb_checksum_help(skb);
> > >         ...
> > > }
> > >
> > > The software fallback only happens when the user opted in via
> > > XDP_UMEM_TX_SW_CSUM, so a CHECKSUM_PARTIAL AF_XDP skb does reach the
> > > driver through __dev_direct_xmit(), and drivers take the L2/L3 split
> > > from network_header:
> > >
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:ixgbe_tx_csum() {
> > >         vlan_macip_lens = skb_checksum_start_offset(skb) -
> > >                           skb_network_offset(skb);
> > > no_csum:
> > >         /* vlan_macip_lens: MACLEN, VLAN tag */
> > >         vlan_macip_lens |= skb_network_offset(skb) << IXGBE_ADVTXD_MACLEN_SHIFT;
> > >         ...
> > > }
> >
> > After digging into the probing logic, I strongly feel that Jakub is
> > right to consider whether to add the probing logic.
> >
> > >
> > > With skb_network_offset() now 0 on an ethernet frame, does this program
> > > MACLEN == 0 and an IPLEN that swallows the ethernet header, so the NIC
> > > inserts a checksum derived from the wrong header layout?
> > >
> > > Would it make sense to also call skb_reset_mac_header() and place
> > > network_header at the real L3 boundary here? Alternatively, if the
> > > minimal reset is the intent, could the commit message describe
> >
> > The minimal reset doesn't help with the checksum problem mentioned above.
> >
> > Adding simple logic like resetting l2/l3 headers doesn't guarantee
> > that csum problem won't be triggered. Adding complete probing hurts
> > perfomance for sure.
> >
> > Maybe we can cook two patches:
> > 1. Fix the current bug syzbot reported as is.
> > 2. Fix offload logic by adding complete probing
> >
> > @Jakub, Maciej, Stan
> > Do we need a complex logic like af_packet to handle this?
> 
> Until now, it seems we've got three fixes in the queue:
> 1. reset mac header:
> https://lore.kernel.org/all/20260817153957.3177627-1-poros@redhat.com/
> (commit 35fcde7f8deb "xsk: support for Tx")

Hi!

I'd keep this separate and focus on Eric's hint to fix the drivers so they
use skb_eth_hdr() consistently

> 2. reset network header like this patch. (commit 3914d88f7608 "xsk:
> Respect device's headroom and tailroom")

For packets without CHECKSUM_PARTIAL, resetting network_header should be
enough to fix the negative offset reported by syzbot.

For CHECKSUM_PARTIAL, however, I think we need to establish proper skb
header metadata. Existing drivers do rely on it. For example, i40e and ice
use both skb_network_header() and skb_transport_header() in their non-GSO
checksum offload paths, while ixgbe derives its offsets from
skb_network_offset() and skb_checksum_start_offset().

For Ethernet I would avoid depending on mac_header here. The frame can
also be non-linear with IFF_TX_SKB_NO_LINEAR, so using
skb_header_pointer() to inspect the Ethernet header and the fragment-safe
VLAN helpers looks more appropriate than dev_parse_header_protocol().

> 3. handle csum offload issue by adding probing code. (commit
> 48eb03dd2630 "xsk: Add TX ... checksum offload support")
> 
> Thanks,
> Jason
> 
> >
> > Thanks,
> > Jason
> >
> > > network_header as a placeholder and drop the claims about the AF_PACKET
> > > convention and the absence of checksum offload?
> > >
> > > --
> > > Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260901083325.3445-1-kerneljasonxing%40gmail.com

      reply	other threads:[~2026-09-22 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  8:33 [PATCH net v2] xsk: set network header on skb at generic transmit Jason Xing
2026-09-03 23:34 ` netdev-bot+sashiko
2026-09-04  3:53   ` Jason Xing
2026-09-04  4:10     ` Jason Xing
2026-09-22 16:05       ` Maciej Fijalkowski [this message]

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=arKm5gCaERk6MaGA@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kerneljasonxing@gmail.com \
    --cc=kuba@kernel.org \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev-bot+sashiko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=syzbot+f16c1b285c9f63994eec@syzkaller.appspotmail.com \
    /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