From: Baoquan He <bhe@redhat.com>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
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 18:09:26 +0800 [thread overview]
Message-ID: <ZgFNVtp3EsJRaSN0@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20240325093959.9453-B-hca@linux.ibm.com>
On 03/25/24 at 10:39am, Heiko Carstens wrote:
> 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:
......snip
> > 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.
If so, I would rather add a vmalloc_is_available() to achieve the same.
The added code and the code comment definitely will confuse people and
make people to dig why.
>
> 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 10:09 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
2024-03-25 10:09 ` Baoquan He [this message]
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=ZgFNVtp3EsJRaSN0@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=david@fromorbit.com \
--cc=gor@linux.ibm.com \
--cc=hca@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