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 <[email protected]> wrote: > > > > 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? > > 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
