From: Waiman Long <llong@redhat.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.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 08:34:06 -0500 [thread overview]
Message-ID: <cfe70f31-e650-4033-9281-baa4cdc40b96@redhat.com> (raw)
In-Reply-To: <CAPAsAGzk4h3B-LNQdedrk=2aRbPoOJeVv_tQF2QPgzwwUvirEw@mail.gmail.com>
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.
Cheers,
Longman
next prev parent reply other threads:[~2025-02-12 13:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 16:07 [PATCH] kasan: Don't call find_vm_area() in RT kernel 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 [this message]
2025-02-12 17:52 ` Andrey Ryabinin
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=cfe70f31-e650-4033-9281-baa4cdc40b96@redhat.com \
--to=llong@redhat.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=npache@redhat.com \
--cc=rostedt@goodmis.org \
--cc=ryabinin.a.a@gmail.com \
--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 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.