On Wed, Oct 7, 2020 at 3:37 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > Daniel Borkmann wrote: > > On 10/7/20 6:23 PM, Jesper Dangaard Brouer wrote: > > [...] > > > net/core/dev.c | 24 ++++++++++++++++++++++-- > > > 1 file changed, 22 insertions(+), 2 deletions(-) > > Couple high-level comments. Whats the problem with just letting the driver > consume the packet? I would chalk it up to a buggy BPF program that is > sending these packets. The drivers really shouldn't panic or do anything > horrible under this case because even today I don't think we can be > 100% certain MTU on skb matches set MTU. Imagine the case where I change > the MTU from 9kB->1500B there will be some skbs in-flight with the larger > length and some with the shorter. If the drivers panic/fault or otherwise > does something else horrible thats not going to be friendly in general case > regardless of what BPF does. And seeing this type of config is all done > async its tricky (not practical) to flush any skbs in-flight. > > I've spent many hours debugging these types of feature flag, mtu > change bugs on the driver side I'm not sure it can be resolved by > the stack easily. Better to just build drivers that can handle it IMO. > > Do we know if sending >MTU size skbs to drivers causes problems in real > cases? I haven't tried on the NICs I have here, but I expect they should > be fine. Fine here being system keeps running as expected. Dropping the > skb either on TX or RX side is expected. Even with this change though > its possible for the skb to slip through if I configure MTU on a live > system. I wholeheartedly agree with the above. Ideally the only >mtu check should happen at driver admittance. But again ideally it should happen in some core stack location not in the driver itself. However, due to both gso and vlan offload, even this is not trivial to do... The mtu is L3, but drivers/hardware/the wire usually care about L2... (because ultimately that's what gets received and must fit in receive buffers)
