All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: linux-kernel@vger.kernel.org, "Jason Wang" <jasowangio@gmail.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	netdev@vger.kernel.org, virtualization@lists.linux.dev,
	"Max Krasnyansky" <maxk@qualcomm.com>,
	"Rusty Russell" <rusty@rustcorp.com.au>
Subject: Re: [PATCH net-next 3/4] net: resolve uncommon partial checksums at ingress
Date: Tue, 13 Oct 2026 16:38:21 -0400	[thread overview]
Message-ID: <20261013163706-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAF=yD-Lz92nGVFab1Dq8M9VusDsKf-ioda8KrZoyh28x3Xtg4Q@mail.gmail.com>

On Tue, Oct 13, 2026 at 02:32:26PM -0600, Willem de Bruijn wrote:
> > > > > +
> > > > > +     if (virtio_net_csum_partial_ok_at_offset(skb, gso_inner_type, inner_nh,
> > > > > +                                            inner_proto))
> > > > > +             return 0;
> > > > > +
> > > > > +     if (skb_is_gso(skb))
> > > > > +             return -EINVAL;
> > >
> > > This is a risk the commit message will have to call out.
> >
> > I tried with this:
> >
> >         > > > We can't easily "complete the checksum" for GSO we don't recognize - GSO
> >         > > > assumes knowledge of the protocol. We could segment ignoring the
> >         > > > checksum then do whatever csum_start and csum_offset say, but that
> >         > > > seems like an overkill for something that should happen.
> >
> > I guess I can add a more detailed explanation about what the risk is?
> 
> Let's just explicitly mention the consequence: non-standard GSO
> packets that previous would be sent may now fail.
> 
> >
> > > I don't see a simple way around it. We discussed segmenting here too,
> > > but that requires intrusive changes to all callers too.
> > > Alternatively,
> > >
> > > 1. call segmentation, but only to see it remove the SKB_GSO_DODGY and
> > > thus verify that the TSO/USO packet is valid. Still drop otherwise.
> > > This also does not add overhead, because it would be called later
> > > anyway.
> > >
> > > 2. a failsafe off-by-default sysctl + static_branch that skips the
> > > drop when set. Messy, but so is the situation we're dealing with.
> >
> > Tack this on top or do you feel it's needed straight away.
> 
> Not urgent. Can even wait until a report appears. But worth taking a
> look sooner if either of us gets around to it.

Maybe if people intend all this for stable, I'll feel safer with this in
there.

Just to make sure, the branch would just short-circuit all checks, yes?

-- 
MST


  reply	other threads:[~2026-10-13 20:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 10:58 [PATCH net-next 0/4] more virtio-net csum hardening Michael S. Tsirkin
2026-10-13 10:58 ` [PATCH net-next 1/4] net: add ip4_parse() Michael S. Tsirkin
2026-10-13 11:15   ` sashiko-bot
2026-10-13 10:58 ` [PATCH net-next 2/4] net: use ip4_parse() in receive validation Michael S. Tsirkin
2026-10-13 11:15   ` sashiko-bot
2026-10-13 10:58 ` [PATCH net-next 3/4] net: resolve uncommon partial checksums at ingress Michael S. Tsirkin
2026-10-13 11:06   ` Michael S. Tsirkin
2026-10-13 15:03     ` Willem de Bruijn
2026-10-13 18:35       ` Michael S. Tsirkin
2026-10-13 20:32         ` Willem de Bruijn
2026-10-13 20:38           ` Michael S. Tsirkin [this message]
2026-10-13 20:45             ` Willem de Bruijn
2026-10-13 20:51               ` Michael S. Tsirkin
2026-10-13 20:15       ` Michael S. Tsirkin
2026-10-13 11:15   ` sashiko-bot
2026-10-13 10:58 ` [PATCH net-next 4/4] net: account for ingress-resolved virtio net hdr state Michael S. Tsirkin
2026-10-13 11:15   ` sashiko-bot
2026-10-13 17:45   ` Björn Töpel
2026-10-13 18:12     ` Michael S. Tsirkin
2026-10-13 11:05 ` [PATCH net-next 0/4] more virtio-net csum hardening Michael S. Tsirkin
2026-10-13 18:51   ` Chris Arges
2026-10-13 14:41 ` Willem de Bruijn
2026-10-13 18:41   ` Michael S. Tsirkin
2026-10-13 20:29     ` Willem de Bruijn
2026-10-13 20:36       ` Michael S. Tsirkin
2026-10-13 20:54         ` Willem de Bruijn
2026-10-13 20:56           ` Michael S. Tsirkin

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=20261013163706-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=jasowangio@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux.dev \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=xuanzhuo@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.