Received-SPF: pass (google.com: domain of linux-kernel+bounces-119845-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 26 Mar 2024 12:56:23 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Feng Tang <feng.tang@intel.com>
Cc: Borislav Petkov <bp@alien8.de>, "V, Narasimhan" <Narasimhan.V@amd.com>,
 "linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
 "linux-mm@kvack.org" <linux-mm@kvack.org>, "Aithal, Srikanth"
 <Srikanth.Aithal@amd.com>, Dawei Li <dawei.li@shingroup.cn>, Andy
 Shevchenko <andriy.shevchenko@linux.intel.com>, Rasmus Villemoes
 <linux@rasmusvillemoes.dk>, Yury Norov <yury.norov@gmail.com>, lkml
 <linux-kernel@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>
Subject: Re: Boot failure with kernel BUG at mm/usercopy.c on next-20240325
Message-Id: <20240326125623.266550b81bb36aafc9a2c613@linux-foundation.org>
In-Reply-To: <ZgIzMqiZzqUmqEOZ@feng-clx.sh.intel.com>
References: <DM4PR12MB5086E76CF24A39017DA8567189362@DM4PR12MB5086.namprd12.prod.outlook.com>
	<20240325125017.GBZgFzCXVxeF50uGVE@fat_crate.local>
	<20240325113433.e04c2b508ac325630cd113c8@linux-foundation.org>
	<20240325203714.GJZgHgem2TR1aVAVlU@fat_crate.local>
	<ZgIzMqiZzqUmqEOZ@feng-clx.sh.intel.com>
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 26 Mar 2024 10:30:10 +0800 Feng Tang <feng.tang@intel.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.