Re: [TEST] TCP MD5 vs kmemleak

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 18, 2024 at 07:40:37AM -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?

I myself don't run KASAN with kmemleak, but maybe some of the others
on this list do.

What sort of hint should be we add to call_rcu()?  The memory is still
reachable in the garbage-collector sense.

							Thanx, Paul




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux