From: Andrey Ryabinin <ryabinin.a.a@gmail.com>
To: Waiman Long <llong@redhat.com>
Cc: Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
Nico Pache <npache@redhat.com>
Subject: Re: [PATCH] kasan: Don't call find_vm_area() in RT kernel
Date: Wed, 12 Feb 2025 18:52:39 +0100 [thread overview]
Message-ID: <ef785e05-f52e-4a88-9377-b51b81b228ce@gmail.com> (raw)
In-Reply-To: <cfe70f31-e650-4033-9281-baa4cdc40b96@redhat.com>
On 2/12/25 2:34 PM, Waiman Long wrote:
>
> On 2/12/25 6:59 AM, Andrey Ryabinin wrote:
>> On Tue, Feb 11, 2025 at 5:08 PM Waiman Long <longman@redhat.com> wrote:
>>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>>> index 3fe77a360f1c..e1ee687966aa 100644
>>> --- a/mm/kasan/report.c
>>> +++ b/mm/kasan/report.c
>>> @@ -398,9 +398,20 @@ static void print_address_description(void *addr, u8 tag,
>>> pr_err("\n");
>>> }
>>>
>>> - if (is_vmalloc_addr(addr)) {
>>> - struct vm_struct *va = find_vm_area(addr);
>>> + if (!is_vmalloc_addr(addr))
>>> + goto print_page;
>>>
>>> + /*
>>> + * RT kernel cannot call find_vm_area() in atomic context.
>>> + * For !RT kernel, prevent spinlock_t inside raw_spinlock_t warning
>>> + * by raising wait-type to WAIT_SLEEP.
>>> + */
>>> + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) {
>>> + static DEFINE_WAIT_OVERRIDE_MAP(vmalloc_map, LD_WAIT_SLEEP);
>>> + struct vm_struct *va;
>>> +
>>> + lock_map_acquire_try(&vmalloc_map);
>>> + va = find_vm_area(addr);
>> Can we hide all this logic behind some function like
>> kasan_find_vm_area() which would return NULL for -rt?
> Sure. We can certainly do that.
>>
>>> if (va) {
>>> pr_err("The buggy address belongs to the virtual mapping at\n"
>>> " [%px, %px) created by:\n"
>>> @@ -410,8 +421,13 @@ static void print_address_description(void *addr, u8 tag,
>>>
>>> page = vmalloc_to_page(addr);
>> Or does vmalloc_to_page() secretly take some lock somewhere so we
>> need to guard it with this 'vmalloc_map' too?
>> So my suggestion above wouldn't be enough, if that's the case.
>
> AFAICS, vmalloc_to_page() doesn't seem to take any lock. Even if it takes another spinlock, it will still be under the vmalloc_map protection until lock_map_release() is called.
>
I meant to do something like bellow, which would leave vmalloc_to_page() out of vmalloc_map scope.
That's why I raised this question.
---
mm/kasan/report.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 3fe77a360f1c..f3683215f4ca 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -370,6 +370,20 @@ static inline bool init_task_stack_addr(const void *addr)
sizeof(init_thread_union.stack));
}
+static inline struct vm_struct *kasan_find_vm_area(void *addr)
+{
+ static DEFINE_WAIT_OVERRIDE_MAP(vmalloc_map, LD_WAIT_SLEEP);
+ struct vm_struct *va;
+
+ if (IS_ENABLED(CONFIG_PREEMPT_RT))
+ return NULL;
+
+ lock_map_acquire_try(&vmalloc_map);
+ va = find_vm_area(addr);
+ lock_map_release(&vmalloc_map);
+ return va;
+}
+
static void print_address_description(void *addr, u8 tag,
struct kasan_report_info *info)
{
@@ -399,8 +413,7 @@ static void print_address_description(void *addr, u8 tag,
}
if (is_vmalloc_addr(addr)) {
- struct vm_struct *va = find_vm_area(addr);
-
+ struct vm_area *va = kasan_find_vm_area(addr);
if (va) {
pr_err("The buggy address belongs to the virtual mapping at\n"
" [%px, %px) created by:\n"
--
2.45.3
prev parent reply other threads:[~2025-02-12 17:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 16:07 Waiman Long
2025-02-11 22:57 ` Andrew Morton
2025-02-11 23:24 ` Steven Rostedt
2025-02-12 0:16 ` Waiman Long
2025-02-12 0:20 ` Andrew Morton
2025-02-12 11:59 ` Andrey Ryabinin
2025-02-12 13:34 ` Waiman Long
2025-02-12 17:52 ` Andrey Ryabinin [this message]
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=ef785e05-f52e-4a88-9377-b51b81b228ce@gmail.com \
--to=ryabinin.a.a@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=llong@redhat.com \
--cc=npache@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vincenzo.frascino@arm.com \
/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