On Tue, Jun 18, 2024 at 06:30:59PM +0200, Paolo Abeni wrote: > 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??? Fun! ;-) This commit handles memory passed to kfree_rcu() and friends, but not memory passed to call_rcu() and friends. Of course, call_rcu() does not necessarily know the full extent of the memory passed to it, for example, if passed a linked list, call_rcu() will know only about the head of that list. There are similar challenges with synchronize_rcu() and friends. Thanx, Paul
