Hi, On Mon, Oct 10, 2016, at 16:03, Eric Dumazet wrote: > On Mon, 2016-10-10 at 15:43 +0200, Sabrina Dubroca wrote: > > Currently, GRO can do unlimited recursion through the gro_receive > > handlers. This was fixed for tunneling protocols by limiting tunnel GRO > > to one level with encap_mark, but both VLAN and TEB still have this > > problem. Thus, the kernel is vulnerable to a stack overflow, if we > > receive a packet composed entirely of VLAN headers. > > > > This patch adds a recursion counter to the GRO layer to prevent stack > > overflow. When a gro_receive function hits the recursion limit, GRO is > > aborted for this skb and it is processed normally. > > > > Thanks to Vladimír Beneš <vbe...@redhat.com> for the initial bug report. > > [...] > > Have you considered using a per cpu counter ? > > It might be cheaper than using a 4-bit field in skb. > > Really this counter does not need to be stored in skb. GRO already uses > way too much space in skb->cb[]
The idea was to use some padding space and not bother with another static per cpu allocation as long as there is space in the cb, which is certainly more expensive in terms of memory consumption. We can add a comment to make future users in gro_cb aware that this can easily be moved to per cpu allocation if necessary in future? Bye, Hannes
