linux-kernel - Re: Boot failure with kernel BUG at mm/usercopy.c on next-20240325

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZgIzMqiZzqUmqEOZ@feng-clx.sh.intel.com>
Date: Tue, 26 Mar 2024 10:30:10 +0800
From: Feng Tang <feng.tang@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Andrew Morton <akpm@...ux-foundation.org>, "V, Narasimhan"
	<Narasimhan.V@....com>, "linux-next@...r.kernel.org"
	<linux-next@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Aithal, Srikanth" <Srikanth.Aithal@....com>, Dawei Li
	<dawei.li@...ngroup.cn>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>, Yury Norov
	<yury.norov@...il.com>, lkml <linux-kernel@...r.kernel.org>, Vlastimil Babka
	<vbabka@...e.cz>
Subject: Re: Boot failure with kernel BUG at mm/usercopy.c on next-20240325

Add Vlastimil for slab related topic.

On Tue, Mar 26, 2024 at 04:37:14AM +0800, Borislav Petkov wrote:
> On Mon, Mar 25, 2024 at 11:34:33AM -0700, Andrew Morton wrote:
> > Thanks, I'll just drop the patch.  It didn't receive a very favorable
> > review reception anyway.
> 
> See here:
> 
> https://lore.kernel.org/all/DM4PR12MB5086B9BDBF32D53DF226CBF489362@DM4PR12MB5086.namprd12.prod.outlook.com/
> 
> folks still need to learn email. :-)
> 
> Anyway, apparently there's some fix there.

The original commit 328c801335d5 ("cpumask: create dedicated kmem
cache for cpumask var") has some benefit, that there are CPU numbers
which are not power of 8, like 144, 288 etc where it will save
some memory. 

And 'slabtop' on a qemu-VM with 16 cpus shows it is surprisingly
non-trivial and has the third largest number of objects: 

22350   22350 100%    0.13K    745       30      2980K kernfs_node_cache
 11172  10693   0%    0.19K    266       42      2128K dentry
 10240   8222   0%    0.01K     20      512        80K cpumask

Andrew, if it is worth merging, you can folder my fix into the patch. 

Thanks,
Feng


> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette
>