On Tue, 2024-06-18 at 07:40 -0700, Jakub Kicinski wrote: > 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? FTR, with mptcp self-tests we hit a few kmemleak false positive on RCU freed pointers, that where addressed by to this patch: commit 5f98fd034ca6fd1ab8c91a3488968a0e9caaabf6 Author: Catalin Marinas <catalin.marinas@xxxxxxx> Date: Sat Sep 30 17:46:56 2023 +0000 rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects I'm wondering if this is hitting something similar? Possibly due to lazy RCU callbacks invoked after MSECS_MIN_AGE??? Cheers, Paolo
