All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	rcu@vger.kernel.org
Subject: Re: [TEST] TCP MD5 vs kmemleak
Date: Tue, 18 Jun 2024 10:02:10 -0700	[thread overview]
Message-ID: <20240618100210.16c028e1@kernel.org> (raw)
In-Reply-To: <ee5a9d15-deaf-40c9-a559-bbc0f11fbe76@paulmck-laptop>

On Tue, 18 Jun 2024 09:42:35 -0700 Paul E. McKenney wrote:
> > 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@arm.com>
> > 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???  

Dmitry mentioned this commit, too, but we use the same config for MPTCP
tests, and while we repro TCP AO failures quite frequently, mptcp
doesn't seem to have failed once.

> 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.

To be clear I think Dmitry was suspecting kfree_rcu(), he mentioned
call_rcu() as something he was expecting to have a similar issue but 
it in fact appeared immune.

  reply	other threads:[~2024-06-18 17:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-17 14:24 [TEST] TCP MD5 vs kmemleak Jakub Kicinski
2024-06-18  3:24 ` Dmitry Safonov
2024-06-18 14:40   ` Jakub Kicinski
2024-06-18 16:17     ` Paul E. McKenney
2024-06-18 16:30     ` Paolo Abeni
2024-06-18 16:42       ` Paul E. McKenney
2024-06-18 17:02         ` Jakub Kicinski [this message]
2024-06-18 17:04           ` Uladzislau Rezki
2024-06-18 17:47           ` Paul E. McKenney
2024-06-19  0:33             ` Dmitry Safonov
2024-06-20 17:02               ` Paul E. McKenney
2024-07-02  2:08                 ` Dmitry Safonov
2024-07-08 11:05                   ` Catalin Marinas
2024-07-08 18:29                   ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240618100210.16c028e1@kernel.org \
    --to=kuba@kernel.org \
    --cc=0x7f454c46@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.