On Mon, Mar 25, 2024 at 08:40:20PM +0800, V, Narasimhan wrote:
> [AMD Official Use Only - General]
>
> Hi,
> There is a boot failure as below.
> On bisecting, the bad commit is found to be 328c801335d5f7edf2a3c9c331ddf8978f21e2a7.
> Boots fine if we revert the above bad commit.
>
>
> kernel BUG at mm/usercopy.c:102!
> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> CPU: 15 PID: 567 Comm: systemd-udevd Not tainted 6.9.0-rc1-next-20240325-1711333827684 #1
> Hardware name: AMD Corporation Shale96/Shale96, BIOS RSH100BD 12/11/2023
> RIP: 0010:usercopy_abort+0x72/0x90
> __check_heap_object+0xd6/0x110
> __check_object_size+0x28a/0x2f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> __x64_sys_sched_getaffinity+0xda/0x120
> do_syscall_64+0x76/0x120
I met similar issue with QEMU boot test, and seems the root cause is
the 'cpumask' slub object could be copied to user space, and fail
the usercopy check. With below patch, the panic is gone in my test.
Could you give it a try?
Thanks,
Feng
---
diff --git a/lib/cpumask.c b/lib/cpumask.c
index f3f68c45caba..dcadcf7adc7c 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -62,8 +62,8 @@ static struct kmem_cache *cpumask_cache __ro_after_init;
int __init cpumask_cache_init(void)
{
- cpumask_cache = kmem_cache_create("cpumask", cpumask_size(), sizeof(long),
- SLAB_HWCACHE_ALIGN, NULL);
+ cpumask_cache = kmem_cache_create_usercopy("cpumask", cpumask_size(), sizeof(long),
+ SLAB_HWCACHE_ALIGN, 0, cpumask_size(), NULL);
return cpumask_cache ? 0 : -ENOMEM;
}
