On Tue, 18 Jun 2024 04:24:08 +0100 Dmitry Safonov wrote: > Hi Jakub, > > thanks for pinging, > > On Mon, 17 Jun 2024 at 15:24, Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > > Hi Dmitry! > > > > We added kmemleak checks to the selftest runners, TCP AO/MD5 tests seem > > to trip it: > > > > https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/643761/4-unsigned-md5-ipv6/stdout > > > > Could you take a look? kmemleak is not infallible, it could be a false > > positive. > > Sure, that seems somewhat interesting, albeit at this moment not from > the TCP side :D > > There is some pre-history to the related issue here: > https://lore.kernel.org/lkml/0000000000004d83170605e16003@xxxxxxxxxx/ > > Which I was quite sure being addressed with what now is > https://git.kernel.org/linus/5f98fd034ca6 > > But now that I look at that commit, I see that kvfree_call_rcu() is > defined to __kvfree_call_rcu() under CONFIG_KASAN_GENERIC=n. And I > don't see the same kmemleak_ignore() on that path. > > To double-check, you don't have kasan enabled on netdev runners, right? We do: CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y here's the full config: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/645202/config > And then straight away to another thought: the leak-report that you > get currently is ao_info, which should not happen if kfree_rcu() is > properly fixed. > But I'd expect kmemleak to be unhappy with ao keys freeing as well: > they are currently released with call_rcu(&key->rcu, > tcp_ao_key_free_rcu), which doesn't have a hint for kmemleak, too. > > I'm going to take a look at it this week. Just to let you know, I'm > also looking at fixing those somewhat rare flakes on tcp-ao counters > checks (but that may be net-next material together with tracepoint > selftests). Let me add rcu@ to CC, perhaps folks there can guide us on known false positives with KASAN + kmemleak?
