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 for Android: free password hash cracker in your pocket

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

Message-Id: <20240326125623.266550b81bb36aafc9a2c613@linux-foundation.org>
Date: Tue, 26 Mar 2024 12:56:23 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Feng Tang <feng.tang@...el.com>
Cc: Borislav Petkov <bp@...en8.de>, "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

On Tue, 26 Mar 2024 10:30:10 +0800 Feng Tang <feng.tang@...el.com> wrote:

> 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. 

I'll await a resend, please.