Martin Zaharinov reports BUG() in mm land for 5.19.10 kernel:
kernel BUG at mm/vmalloc.c:2437!
invalid opcode: 0000 [#1] SMP
CPU: 28 PID: 0 Comm: swapper/28 Tainted: G W O 5.19.9 #1
[..]
RIP: 0010:__get_vm_area_node+0x120/0x130
__vmalloc_node_range+0x96/0x1e0
kvmalloc_node+0x92/0xb0
bucket_table_alloc.isra.0+0x47/0x140
rhashtable_try_insert+0x3a4/0x440
rhashtable_insert_slow+0x1b/0x30
[..]
bucket_table_alloc uses kvzalloc(GPF_ATOMIC). If kmalloc fails, this now
falls through to vmalloc and hits code paths that assume GFP_KERNEL.
I sent a patch to restore GFP_ATOMIC support in kvmalloc but mm
maintainers rejected it.
This patch is partial revert of
commit 93f976b5190d ("lib/rhashtable: simplify bucket_table_alloc()"),
to avoid kvmalloc for ATOMIC case.
As kvmalloc doesn't warn when used with ATOMIC, kernel will only crash
once vmalloc fallback occurs, so we may see more crashes in other areas
in the future.
Most other callers seem ok but kvm_mmu_topup_memory_cache looks like it
might be affected by the same breakage, so Cc kvm@.
Reported-by: Martin Zaharinov <[email protected]>
Fixes: a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")
Link: https://lore.kernel.org/linux-mm/Yy3MS2uhSgjF47dy@pc636/T/#t
Cc: Michal Hocko <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: [email protected]
Signed-off-by: Florian Westphal <[email protected]>
---
lib/rhashtable.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index e12bbfb240b8..9451f411bc71 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -181,7 +181,13 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
int i;
static struct lock_class_key __key;
- tbl = kvzalloc(struct_size(tbl, buckets, nbuckets), gfp);
+ size = struct_size(tbl, buckets, nbuckets);
+
+ /* kvmalloc API does not support GFP_KERNEL anymore */
+ if ((gfp & GFP_KERNEL) != GFP_KERNEL)
+ tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY);
+ else
+ tbl = kvzalloc(size, gfp);
size = nbuckets;
--
2.37.3
Herbert Xu <[email protected]> wrote:
> Only in the case of kvzalloc. We expect kzalloc to fail, that's
> why it gets NOWARN. There is no sane reason for kvzalloc to fail
> so it should warn.
To me a WARN() only has one purpose:
It will get reported to mailing list and a developer can use that
to develop a patch/fix.
In memory allocation failure, there is no bug, so nothing to fix,
so WARN is useless.
On Mon, Sep 26, 2022 at 12:24:56PM +0200, Florian Westphal wrote:
.
> In memory allocation failure, there is no bug, so nothing to fix,
> so WARN is useless.
It depends on why it failed. If it failed because we're asking
for something that simply can't be fulfilled then sure. But if
we're asking for something sane and kvzalloc still failed it then
we should know about it.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt