From: Thomas Gleixner <tglx@kernel.org>
To: Waiman Long <llong@redhat.com>, Marc Zyngier <maz@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH] irqchip/gic-v3-its: Don't acquire rt_spin_lock in allocate_vpe_l1_table()
Date: Mon, 12 Jan 2026 16:09:49 +0100 [thread overview]
Message-ID: <87cy3eg94y.ffs@tglx> (raw)
In-Reply-To: <40cec799-f363-4642-969b-24f5a2d56dfb@redhat.com>
On Sun, Jan 11 2026 at 18:02, Waiman Long wrote:
> On 1/11/26 5:38 AM, Marc Zyngier wrote:
>>> Also that patch seems to be incomplete because there is another
>>> allocation further down in allocate_vpe_l1_table()....
>> Yeah, I wondered why page allocation wasn't affected by this issue,
>> but didn't try to find out.
>
> The use of GFP_ATOMIC flag in the page allocation request may help it to
> dip into the reserved area and avoid taking any spinlock. In my own
> test, just removing the kzalloc() call is enough to avoid any invalid
> context warning. In the page allocation code, there is a zone lock and a
> per_cpu_pages lock. They were not acquired in my particular test case,
> though further investigation may be needed to make sure it is really safe.
They might be acquired though. Only alloc_pages_nolock() guarantees that
no lock is taken IIRC.
next prev parent reply other threads:[~2026-01-12 15:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 21:53 [PATCH] irqchip/gic-v3-its: Don't acquire rt_spin_lock in allocate_vpe_l1_table() Waiman Long
2026-01-08 8:26 ` Marc Zyngier
2026-01-08 22:11 ` Thomas Gleixner
2026-01-09 16:13 ` Marc Zyngier
2026-01-11 9:39 ` Thomas Gleixner
2026-01-11 10:38 ` Marc Zyngier
2026-01-11 16:20 ` Thomas Gleixner
2026-01-12 11:20 ` Marc Zyngier
2026-01-12 14:08 ` Sebastian Andrzej Siewior
2026-01-12 14:38 ` Marc Zyngier
2026-01-21 8:38 ` Marc Zyngier
2026-01-21 16:48 ` Waiman Long
2026-01-21 20:41 ` Waiman Long
2026-01-22 3:49 ` Waiman Long
2026-03-09 19:06 ` Waiman Long
2026-03-10 8:12 ` Marc Zyngier
2026-01-11 23:02 ` Waiman Long
2026-01-12 15:09 ` Thomas Gleixner [this message]
2026-01-12 17:14 ` Waiman Long
2026-01-13 11:55 ` Sebastian Andrzej Siewior
2026-01-13 23:25 ` Alexei Starovoitov
2026-01-14 16:01 ` Sebastian Andrzej Siewior
2026-01-14 17:59 ` Vlastimil Babka
2026-01-21 16:37 ` Waiman Long
2026-01-10 21:47 ` Waiman Long
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=87cy3eg94y.ffs@tglx \
--to=tglx@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=llong@redhat.com \
--cc=maz@kernel.org \
--cc=rostedt@goodmis.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.