Re: [PATCH net] net_sched: sch_sfq: fix a potential crash on gso_skb handling

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Eric Dumazet <edumazet@google.com> writes:

> SFQ has an assumption of always being able to queue at least one packet.
>
> However, after the blamed commit, sch->q.len can be inflated by packets
> in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed
> by an immediate drop.
>
> Fix sfq_drop() to properly clear q->tail in this situation.
>
> Tested:
>
> ip netns add lb
> ip link add dev to-lb type veth peer name in-lb netns lb
> ethtool -K to-lb tso off                 # force qdisc to requeue gso_skb
> ip netns exec lb ethtool -K in-lb gro on # enable NAPI
> ip link set dev to-lb up
> ip -netns lb link set dev in-lb up
> ip addr add dev to-lb 192.168.20.1/24
> ip -netns lb addr add dev in-lb 192.168.20.2/24
> tc qdisc replace dev to-lb root sfq limit 100
>
> ip netns exec lb netserver
>
> netperf -H 192.168.20.2 -l 100 &
> netperf -H 192.168.20.2 -l 100 &
> netperf -H 192.168.20.2 -l 100 &
> netperf -H 192.168.20.2 -l 100 &
>
> Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback")
> Reported-by: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de>
> Closes: https://lore.kernel.org/netdev/9da42688-bfaa-4364-8797-e9271f3bdaef@hetzner-cloud.de/
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Thanks for the quick fix!

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>