* Bug in skb_gro_receive - possible bad page state problems?
@ 2017-05-05 3:27 Anand H. Krishnan
2017-05-05 4:14 ` Eric Dumazet
0 siblings, 1 reply; 2+ messages in thread
From: Anand H. Krishnan @ 2017-05-05 3:27 UTC (permalink / raw)
To: netdev
Hello,
Is skb_gro_receive doing the right thing for cloned packets?
When we are merging fragments, we do not seem to be taking a reference
to the underlying page. To me, it looks like it should work fine for non-cloned
packets. However, for cloned packets, when the gro-ed packet is eventually
freed (because the original skb was not cloned and hence reference was 1),
the merged skb's frags also get freed (put_page-ed) without taking into account
the other references that were held for the fragments (dataref).
We saw crashes because of this behavior. Our setup had a third party kernel
forwarding module which uses GRO (napi_gro_receive). Doing iperf3 with small
packets and doing tcpdump on the receiving tap interface results in the problem.
With DEBUG_VM enabled, put page crashes. Without DEBUG_VM, bad page
state results.
Your thoughts (please CC me, since I am not part of this list).
Thanks,
Anand
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bug in skb_gro_receive - possible bad page state problems?
2017-05-05 3:27 Bug in skb_gro_receive - possible bad page state problems? Anand H. Krishnan
@ 2017-05-05 4:14 ` Eric Dumazet
0 siblings, 0 replies; 2+ messages in thread
From: Eric Dumazet @ 2017-05-05 4:14 UTC (permalink / raw)
To: Anand H. Krishnan; +Cc: netdev
On Fri, 2017-05-05 at 08:57 +0530, Anand H. Krishnan wrote:
> Hello,
>
> Is skb_gro_receive doing the right thing for cloned packets?
>
> When we are merging fragments, we do not seem to be taking a reference
> to the underlying page. To me, it looks like it should work fine for non-cloned
> packets. However, for cloned packets, when the gro-ed packet is eventually
> freed (because the original skb was not cloned and hence reference was 1),
> the merged skb's frags also get freed (put_page-ed) without taking into account
> the other references that were held for the fragments (dataref).
>
> We saw crashes because of this behavior. Our setup had a third party kernel
> forwarding module which uses GRO (napi_gro_receive). Doing iperf3 with small
> packets and doing tcpdump on the receiving tap interface results in the problem.
> With DEBUG_VM enabled, put page crashes. Without DEBUG_VM, bad page
> state results.
Yep, GRO must not be used with cloned skb.
This is why gro_cells_receive() has this check :
if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev))
return netif_rx(skb);
(But not the main napi_gro_receive() that is supposed to be used by
driver before any tap)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-05-05 4:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-05 3:27 Bug in skb_gro_receive - possible bad page state problems? Anand H. Krishnan
2017-05-05 4:14 ` Eric Dumazet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.