Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] net: fix memory leaks in flush_backlog() with RPS
Date:   Sat, 2 May 2020 00:12:24 -0400
Message-Id: <C9E5387E-6241-4CB3-B3F2-9CA575920569@lca.pw>
References: <8a012879-825f-596d-9866-0dd3a095dfbb@gmail.com>
Cc:     davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
In-Reply-To: <8a012879-825f-596d-9866-0dd3a095dfbb@gmail.com>
To:     Eric Dumazet <eric.dumazet@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 1, 2020, at 11:32 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>=20
> kfree_skb() is supposed to call skb_dst_drop() (look in skb_release_head_s=
tate())
>=20
> If you think about it, we would have hundreds of similar bugs if this was n=
ot the case.

Thanks for quick response. Funny thing is that once I applied this patch, th=
e leaks went away. It could be the fuzzers do not always reproduce the leaks=
 or it could be that call_rcu() in skb_dst_drop() takes a long time waiting f=
or grace periods which may confuse kmemleak because skb has already gone.=