From: Vlastimil Babka <vbabka@suse.cz>
To: Mike Rapoport <rppt@kernel.org>
Cc: kernel test robot <oliver.sang@intel.com>,
0day robot <lkp@intel.com>, Dmitry Vyukov <dvyukov@google.com>,
Marco Elver <elver@google.com>,
Vijayanand Jitta <vjitta@codeaurora.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Oliver Glitta <glittao@gmail.com>,
Imran Khan <imran.f.khan@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org, Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, kasan-dev@googlegroups.com
Subject: Re: [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address
Date: Fri, 15 Oct 2021 10:27:17 +0200 [thread overview]
Message-ID: <137e4211-266f-bdb3-6830-e101c27c3be4@suse.cz> (raw)
In-Reply-To: <YWgDkjqtJO4e3DM6@kernel.org>
On 10/14/21 12:16, Mike Rapoport wrote:
> On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
>> On 10/14/21 10:54, kernel test robot wrote:
>>
>> In my local testing of the patch, when stackdepot was initialized through
>> page owner init, it was using kvmalloc() so slab_is_available() was true.
>> Looks like the exact order of slab vs page_owner alloc is non-deterministic,
>> could be arch-dependent or just random ordering of init calls. A wrong order
>> will exploit the apparent fact that slab_is_available() is not a good
>> indicator of using memblock vs page allocator, and we would need a better one.
>> Thoughts?
>
> The order of slab vs page_owner is deterministic, but it is different for
> FLATMEM and SPARSEMEM. And page_ext_init_flatmem_late() that initializes
> page_ext for FLATMEM is called exactly between buddy and slab setup:
Oh, so it was due to FLATMEM, thanks for figuring that out!
> static void __init mm_init(void)
> {
> ...
>
> mem_init();
> mem_init_print_info();
> /* page_owner must be initialized after buddy is ready */
> page_ext_init_flatmem_late();
> kmem_cache_init();
>
> ...
> }
>
> I've stared for a while at page_ext init and it seems that the
> page_ext_init_flatmem_late() can be simply dropped because there is anyway
> a call to invoke_init_callbacks() in page_ext_init() that is called much
> later in the boot process.
Yeah, but page_ext_init() only does something for SPARSEMEM, and is empty on
FLATMEM. Otherwise it would be duplicating all the work. So I'll just move
page_ext_init_flatmem_late() below kmem_cache_init() in mm_init(). Thanks
again!
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Mike Rapoport <rppt@kernel.org>
Cc: kernel test robot <oliver.sang@intel.com>,
0day robot <lkp@intel.com>, Dmitry Vyukov <dvyukov@google.com>,
Marco Elver <elver@google.com>,
Vijayanand Jitta <vjitta@codeaurora.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Oliver Glitta <glittao@gmail.com>,
Imran Khan <imran.f.khan@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org, Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, kasan-dev@googlegroups.com
Subject: Re: [Intel-gfx] [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address
Date: Fri, 15 Oct 2021 10:27:17 +0200 [thread overview]
Message-ID: <137e4211-266f-bdb3-6830-e101c27c3be4@suse.cz> (raw)
In-Reply-To: <YWgDkjqtJO4e3DM6@kernel.org>
On 10/14/21 12:16, Mike Rapoport wrote:
> On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
>> On 10/14/21 10:54, kernel test robot wrote:
>>
>> In my local testing of the patch, when stackdepot was initialized through
>> page owner init, it was using kvmalloc() so slab_is_available() was true.
>> Looks like the exact order of slab vs page_owner alloc is non-deterministic,
>> could be arch-dependent or just random ordering of init calls. A wrong order
>> will exploit the apparent fact that slab_is_available() is not a good
>> indicator of using memblock vs page allocator, and we would need a better one.
>> Thoughts?
>
> The order of slab vs page_owner is deterministic, but it is different for
> FLATMEM and SPARSEMEM. And page_ext_init_flatmem_late() that initializes
> page_ext for FLATMEM is called exactly between buddy and slab setup:
Oh, so it was due to FLATMEM, thanks for figuring that out!
> static void __init mm_init(void)
> {
> ...
>
> mem_init();
> mem_init_print_info();
> /* page_owner must be initialized after buddy is ready */
> page_ext_init_flatmem_late();
> kmem_cache_init();
>
> ...
> }
>
> I've stared for a while at page_ext init and it seems that the
> page_ext_init_flatmem_late() can be simply dropped because there is anyway
> a call to invoke_init_callbacks() in page_ext_init() that is called much
> later in the boot process.
Yeah, but page_ext_init() only does something for SPARSEMEM, and is empty on
FLATMEM. Otherwise it would be duplicating all the work. So I'll just move
page_ext_init_flatmem_late() below kmem_cache_init() in mm_init(). Thanks
again!
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: lkp@lists.01.org
Subject: Re: [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address
Date: Fri, 15 Oct 2021 10:27:17 +0200 [thread overview]
Message-ID: <137e4211-266f-bdb3-6830-e101c27c3be4@suse.cz> (raw)
In-Reply-To: <YWgDkjqtJO4e3DM6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
On 10/14/21 12:16, Mike Rapoport wrote:
> On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
>> On 10/14/21 10:54, kernel test robot wrote:
>>
>> In my local testing of the patch, when stackdepot was initialized through
>> page owner init, it was using kvmalloc() so slab_is_available() was true.
>> Looks like the exact order of slab vs page_owner alloc is non-deterministic,
>> could be arch-dependent or just random ordering of init calls. A wrong order
>> will exploit the apparent fact that slab_is_available() is not a good
>> indicator of using memblock vs page allocator, and we would need a better one.
>> Thoughts?
>
> The order of slab vs page_owner is deterministic, but it is different for
> FLATMEM and SPARSEMEM. And page_ext_init_flatmem_late() that initializes
> page_ext for FLATMEM is called exactly between buddy and slab setup:
Oh, so it was due to FLATMEM, thanks for figuring that out!
> static void __init mm_init(void)
> {
> ...
>
> mem_init();
> mem_init_print_info();
> /* page_owner must be initialized after buddy is ready */
> page_ext_init_flatmem_late();
> kmem_cache_init();
>
> ...
> }
>
> I've stared for a while at page_ext init and it seems that the
> page_ext_init_flatmem_late() can be simply dropped because there is anyway
> a call to invoke_init_callbacks() in page_ext_init() that is called much
> later in the boot process.
Yeah, but page_ext_init() only does something for SPARSEMEM, and is empty on
FLATMEM. Otherwise it would be duplicating all the work. So I'll just move
page_ext_init_flatmem_late() below kmem_cache_init() in mm_init(). Thanks
again!
next prev parent reply other threads:[~2021-10-15 8:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 9:06 [PATCH v2] lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() Vlastimil Babka
2021-10-12 9:06 ` [Intel-gfx] " Vlastimil Babka
2021-10-12 9:57 ` Marco Elver
2021-10-12 9:57 ` [Intel-gfx] " Marco Elver
2021-10-12 11:48 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() (rev2) Patchwork
2021-10-12 12:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-12 18:14 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-10-12 21:52 ` [PATCH v2] lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() kernel test robot
2021-10-12 21:52 ` kernel test robot
2021-10-12 21:52 ` [Intel-gfx] " kernel test robot
2021-10-12 21:52 ` [RFC PATCH] lib/stackdepot: stack_depot_init_mutex can be static kernel test robot
2021-10-12 21:52 ` kernel test robot
2021-10-12 21:52 ` [Intel-gfx] " kernel test robot
2021-10-13 7:30 ` [PATCH v3] lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() Vlastimil Babka
2021-10-13 7:30 ` [Intel-gfx] " Vlastimil Babka
2021-10-15 8:57 ` Vlastimil Babka
2021-10-15 8:57 ` [Intel-gfx] " Vlastimil Babka
2021-10-13 7:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() (rev3) Patchwork
2021-10-13 8:16 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-13 10:19 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-10-14 8:54 ` [lib/stackdepot] 1cd8ce52c5: BUG:unable_to_handle_page_fault_for_address kernel test robot
2021-10-14 8:54 ` kernel test robot
2021-10-14 8:54 ` [Intel-gfx] " kernel test robot
2021-10-14 9:33 ` Vlastimil Babka
2021-10-14 9:33 ` Vlastimil Babka
2021-10-14 9:33 ` [Intel-gfx] " Vlastimil Babka
2021-10-14 10:16 ` Mike Rapoport
2021-10-14 10:16 ` Mike Rapoport
2021-10-14 10:16 ` [Intel-gfx] " Mike Rapoport
2021-10-15 8:27 ` Vlastimil Babka [this message]
2021-10-15 8:27 ` Vlastimil Babka
2021-10-15 8:27 ` [Intel-gfx] " Vlastimil Babka
2021-10-15 8:55 ` Mike Rapoport
2021-10-15 8:55 ` Mike Rapoport
2021-10-15 8:55 ` [Intel-gfx] " Mike Rapoport
2021-10-15 9:28 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() (rev4) Patchwork
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=137e4211-266f-bdb3-6830-e101c27c3be4@suse.cz \
--to=vbabka@suse.cz \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=geert@linux-m68k.org \
--cc=glider@google.com \
--cc=glittao@gmail.com \
--cc=imran.f.khan@oracle.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=oliver.sang@intel.com \
--cc=rppt@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=tzimmermann@suse.de \
--cc=vjitta@codeaurora.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.