From: Heiko Carstens <hca@linux.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Guenter Roeck <linux@roeck-us.net>,
Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: vmalloc: Bail out early in find_vmap_area() if vmap is not init
Date: Mon, 25 Mar 2024 10:39:59 +0100 [thread overview]
Message-ID: <20240325093959.9453-B-hca@linux.ibm.com> (raw)
In-Reply-To: <ZgC38GfEZYpYGUU9@infradead.org>
On Sun, Mar 24, 2024 at 04:32:00PM -0700, Christoph Hellwig wrote:
> On Sat, Mar 23, 2024 at 03:15:44PM +0100, Uladzislau Rezki (Sony) wrote:
> > During the boot the s390 system triggers "spinlock bad magic" messages
> > if the spinlock debugging is enabled:
> >
> > [ 0.465445] BUG: spinlock bad magic on CPU#0, swapper/0
> > [ 0.465490] lock: single+0x1860/0x1958, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> > [ 0.466067] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-12955-g8e938e398669 #1
> > [ 0.466188] Hardware name: QEMU 8561 QEMU (KVM/Linux)
> > [ 0.466270] Call Trace:
> > [ 0.466470] [<00000000011f26c8>] dump_stack_lvl+0x98/0xd8
> > [ 0.466516] [<00000000001dcc6a>] do_raw_spin_lock+0x8a/0x108
> > [ 0.466545] [<000000000042146c>] find_vmap_area+0x6c/0x108
> > [ 0.466572] [<000000000042175a>] find_vm_area+0x22/0x40
> > [ 0.466597] [<000000000012f152>] __set_memory+0x132/0x150
> > [ 0.466624] [<0000000001cc0398>] vmem_map_init+0x40/0x118
> > [ 0.466651] [<0000000001cc0092>] paging_init+0x22/0x68
> > [ 0.466677] [<0000000001cbbed2>] setup_arch+0x52a/0x708
> > [ 0.466702] [<0000000001cb6140>] start_kernel+0x80/0x5c8
> > [ 0.466727] [<0000000000100036>] startup_continue+0x36/0x40
...
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 22aa63f4ef63..0d77d171b5d9 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -2343,6 +2343,9 @@ struct vmap_area *find_vmap_area(unsigned long addr)
> > struct vmap_area *va;
> > int i, j;
> >
> > + if (unlikely(!vmap_initialized))
> > + return NULL;
> > +
>
> I guess this is ok as an urgend bandaid to get s390 booting again,
> but calling find_vmap_area before the vmap area is initialized
> seems an actual issue in the s390 mm init code.
>
> Adding the s390 maintainers to see if they have and idea how this could
> get fixed in a better way.
I'm going to push the patch below to the s390 git tree later. This is not a
piece of art, but I wanted to avoid to externalize vmalloc's vmap_initialized,
or come up with some s390 specific change_page_attr_alias_early() variant where
sooner or later nobody remembers what "early" means.
So this seems to be "good enough".
From 0308cd304fa3b01904c6060e2115234101811e48 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <hca@linux.ibm.com>
Date: Thu, 21 Mar 2024 09:41:20 +0100
Subject: [PATCH] s390/mm,pageattr: avoid early calls into vmalloc code
The vmalloc code got changed and doesn't have the global statically
initialized vmap_area_lock spinlock anymore. This leads to the following
lockdep splat when find_vm_area() is called before the vmalloc code is
initialized:
BUG: spinlock bad magic on CPU#0, swapper/0
lock: single+0x1868/0x1978, .magic: 00000000, .owner: swapper/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-11767-g23956900041d #1
Hardware name: IBM 3931 A01 701 (KVM/Linux)
Call Trace:
[<00000000010d840a>] dump_stack_lvl+0xba/0x148
[<00000000001fdf5c>] do_raw_spin_unlock+0x7c/0xd0
[<000000000111d848>] _raw_spin_unlock+0x38/0x68
[<0000000000485830>] find_vmap_area+0xb0/0x108
[<0000000000485ada>] find_vm_area+0x22/0x40
[<0000000000132bbc>] __set_memory+0xbc/0x140
[<0000000001a7f048>] vmem_map_init+0x40/0x158
[<0000000001a7edc8>] paging_init+0x28/0x80
[<0000000001a7a6e2>] setup_arch+0x4b2/0x6d8
[<0000000001a74438>] start_kernel+0x98/0x4b0
[<0000000000100036>] startup_continue+0x36/0x40
INFO: lockdep is turned off.
Add a slab_is_available() check to change_page_attr_alias() in order to
avoid early calls into vmalloc code. slab_is_available() is not exactly
what is needed, but there is currently no other way to tell if the vmalloc
code is initialized or not, and there is no reason to expose
e.g. vmap_initialized from vmalloc to achieve the same.
The fixes tag does not mean that the referenced commit is broken, but that
there is a dependency to this commit if the vmalloc commit should be
backported.
Fixes: d093602919ad ("mm: vmalloc: remove global vmap_area_root rb-tree")
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/mm/pageattr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/s390/mm/pageattr.c b/arch/s390/mm/pageattr.c
index 01bc8fad64d6..b6c6453d66e2 100644
--- a/arch/s390/mm/pageattr.c
+++ b/arch/s390/mm/pageattr.c
@@ -344,6 +344,9 @@ static int change_page_attr_alias(unsigned long addr, unsigned long end,
struct vm_struct *area;
int rc = 0;
+ /* Avoid early calls into not initialized vmalloc code. */
+ if (!slab_is_available())
+ return 0;
/*
* Changes to read-only permissions on kernel VA mappings are also
* applied to the kernel direct mapping. Execute permissions are
--
2.40.1
next prev parent reply other threads:[~2024-03-25 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-23 14:15 Uladzislau Rezki (Sony)
2024-03-23 23:22 ` Guenter Roeck
2024-03-24 2:56 ` Baoquan He
2024-03-24 23:32 ` Christoph Hellwig
2024-03-25 9:39 ` Heiko Carstens [this message]
2024-03-25 10:09 ` Baoquan He
2024-03-25 11:16 ` Heiko Carstens
2024-03-25 13:25 ` Baoquan He
2024-03-26 7:48 ` Heiko Carstens
2024-03-26 9:25 ` Uladzislau Rezki
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=20240325093959.9453-B-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@fromorbit.com \
--cc=gor@linux.ibm.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lstoakes@gmail.com \
--cc=oleksiy.avramchenko@sony.com \
--cc=svens@linux.ibm.com \
--cc=urezki@gmail.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox