From: Steven Rostedt <rostedt@goodmis.org>
To: Catalin Marinas <catalin.marinas@arm.com>
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: Wed, 20 Nov 2024 10:26:02 -0500 [thread overview]
Message-ID: <20241120102602.3e17f2d5@gandalf.local.home> (raw)
In-Reply-To: <Zz332cG45rNSeE_B@arm.com>
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.
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.
-- Steve
next prev parent reply other threads:[~2024-11-20 15:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 10:23 Alessandro Carminati
2024-11-20 14:53 ` Catalin Marinas
2024-11-20 15:13 ` Thomas Weissschuh
2024-11-20 15:26 ` Steven Rostedt [this message]
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
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=20241120102602.3e17f2d5@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=acarmina@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alessandro.carminati@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox