On Tue, Oct 13, 2026 at 02:45:07PM -0600, Willem de Bruijn wrote:
On Tue, Oct 13, 2026 at 2:38 PM Michael S. Tsirkin [off-list ref] wrote:
quoted
On Tue, Oct 13, 2026 at 02:32:26PM -0600, Willem de Bruijn wrote:
quoted
quoted
quoted
quoted
quoted
+
+ 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.
quoted
quoted
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?
Ah option 2, the failsafe? At least any new failures (GSO) that could
cause regression reports. Operating entirely as before this series
sounds fine too.
Right. I feel 1 is just as likely to cause regressions. At least 2 gives
us exactly legacy behaviour back.
--
MST