From: Catalin Marinas <catalin.marinas@arm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Alessandro Carminati <acarmina@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev,
Thomas Weissschuh <thomas.weissschuh@linutronix.de>,
Alessandro Carminati <alessandro.carminati@gmail.com>,
Juri Lelli <juri.lelli@redhat.com>,
Gabriele Paoloni <gpaoloni@redhat.com>,
Eric Chanudet <echanude@redhat.com>
Subject: Re: [PATCH] mm/kmemleak: Fix sleeping function called from invalid context in kmemleak_seq_show
Date: Thu, 21 Nov 2024 19:19:05 +0000 [thread overview]
Message-ID: <Zz-HqbsWxFPrrjST@arm.com> (raw)
In-Reply-To: <20241120102602.3e17f2d5@gandalf.local.home>
On Wed, Nov 20, 2024 at 10:26:02AM -0500, Steven Rostedt wrote:
> On Wed, 20 Nov 2024 14:53:13 +0000
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > -static void print_unreferenced(struct seq_file *seq,
> > > +static depot_stack_handle_t print_unreferenced(struct seq_file *seq,
> > > struct kmemleak_object *object)
> > > {
> > > - int i;
> > > - unsigned long *entries;
> > > - unsigned int nr_entries;
> > > -
> > > - nr_entries = stack_depot_fetch(object->trace_handle, &entries);
> > > warn_or_seq_printf(seq, "unreferenced object 0x%08lx (size %zu):\n",
> > > object->pointer, object->size);
> > > warn_or_seq_printf(seq, " comm \"%s\", pid %d, jiffies %lu\n",
> > > @@ -371,6 +366,23 @@ static void print_unreferenced(struct seq_file *seq,
> > > hex_dump_object(seq, object);
> > > warn_or_seq_printf(seq, " backtrace (crc %x):\n", object->checksum);
> > >
> > > + return object->trace_handle;
> > > +}
> >
> > What I don't fully understand - is this a problem with any seq_printf()
> > or just the backtrace pointers from the stack depot that trigger this
> > issue? I guess it's something to do with restricted pointers but I'm not
> > familiar with the PREEMPT_RT concepts. It would be good to explain,
> > ideally both in the commit log and a comment in the code, why we only
> > need to do this for the stack dump.
>
> In PREEMPT_RT, to achieve the ability to preempt in more context,
> spin_lock() is converted to a special sleeping mutex. But there's some
> places where it can not be converted, and in those cases we use
> raw_spin_lock(). kmemleak has been converted to use raw_spin_lock() which
> means anything that gets called under that lock can not take a normal
> spin_lock().
>
> What happened here is that the kmemleak raw spinlock is held and
> seq_printf() is called. Normally, this is not an issue, but the behavior of
> seq_printf() is dependent on what values is being printed.
>
> The "%pK" dereferences a pointer and there's some SELinux hooks attached to
> that code. The problem is that the SELinux hooks take spinlocks. This would
> not have been an issue if it wasn't for that "%pK" in the format.
Thanks Steven. That's very useful.
> Maybe SELinux locks should be converted to raw? I don't know how long that
> lock is held. There are some loops though :-/
>
> avc_insert():
>
> spin_lock_irqsave(lock, flag);
> hlist_for_each_entry(pos, head, list) {
> if (pos->ae.ssid == ssid &&
> pos->ae.tsid == tsid &&
> pos->ae.tclass == tclass) {
> avc_node_replace(node, pos);
> goto found;
> }
> }
> hlist_add_head_rcu(&node->list, head);
> found:
> spin_unlock_irqrestore(lock, flag);
>
> Perhaps that could be converted to simple RCU?
>
> As I'm sure there's other places that call vsprintf() under a raw_spin_lock
> or non-preemptable context, perhaps this should be the fix we do.
My preference would also be to convert SELinux rather than avoiding the
issue in kmemleak (and other similar places).
--
Catalin
next prev parent reply other threads:[~2024-11-21 19:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 10:23 [PATCH] mm/kmemleak: Fix sleeping function called from invalid context in kmemleak_seq_show Alessandro Carminati
2024-11-20 14:53 ` Catalin Marinas
2024-11-20 15:13 ` Thomas Weissschuh
2024-11-20 15:26 ` Steven Rostedt
2024-11-20 16:36 ` Alessandro Carminati
2024-11-20 16:40 ` Sebastian Andrzej Siewior
2024-11-21 16:50 ` Alessandro Carminati
2024-11-21 17:03 ` Sebastian Andrzej Siewior
2024-11-22 10:48 ` Alessandro Carminati
2024-11-26 8:11 ` Thomas Weissschuh
2024-11-26 10:49 ` Catalin Marinas
2024-11-21 19:19 ` Catalin Marinas [this message]
2024-11-22 8:14 ` Sebastian Andrzej Siewior
2024-11-22 10:12 ` Catalin Marinas
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=Zz-HqbsWxFPrrjST@arm.com \
--to=catalin.marinas@arm.com \
--cc=acarmina@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alessandro.carminati@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=echanude@redhat.com \
--cc=gpaoloni@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=thomas.weissschuh@linutronix.de \
/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.