Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Sep 2022 15:38:37 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Hyeonggon Yoo <42.hyeyoo@gmail.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Vlastimil Babka <vbabka@suse.cz>,
        Christoph Lameter <cl@linux.com>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        "Dmitry Vyukov" <dvyukov@google.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Subject: Re: [PATCH v5 2/4] mm/slub: only zero the requested size of buffer
 for kzalloc
Message-ID: <Yxmb/W4wmJnwA0Qt@feng-clx>
References: <20220907071023.3838692-1-feng.tang@intel.com>
 <20220907071023.3838692-3-feng.tang@intel.com>
 <YxixXhscutM0nw66@hyeyoo>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YxixXhscutM0nw66@hyeyoo>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?I8Sq/pwGYWcE8jz0mDzvo2MVcwz/C17M/6FzFaUuv5pI+8NEk4r2PCvLkpNv?=
 =?us-ascii?Q?gwLrhBRAxsAbfvGzdegSITvM6T+MluhUwo8M6ERP5skWPk4vRPNS3OIs8sey?=
 =?us-ascii?Q?/8JliCY6toC0v+7R6sFGopzyJscbkqBkms/VEfueXzf95dCWeF9CUG/iXOWs?=
 =?us-ascii?Q?rJCjSNymkbAg8AzaZb2V5/d2VJWEC1rn0gpr2+toOLqKfAwgtIVyqkzQ9AOs?=
 =?us-ascii?Q?URmFMKmgTPOBWKFroLKAJJh4FAg4tTVM2aCEQNSRs8HL5yna2kFnOKR7zfL8?=
 =?us-ascii?Q?90YUIe2bcmX7WY6S5pbmQ8jqY3UMyS6U32AcaOe+i1/tFIe5R7rUkU8qbYFj?=
 =?us-ascii?Q?4Z9DkbtbHW8O/jvoi0rlwkbhtHOztS62YWIXttJz34l4INWIu9FvSDlanc9T?=
 =?us-ascii?Q?9egCt14qtmS9UQ+5sB/ZxAPMGUHmmbMQnnHCgAQz2UVnYXr9X0l3bp6PRC/A?=
 =?us-ascii?Q?iyIqdcLE3gmcbKecoJ4885u91CxekAM2SmBKz8/KEjZNTkGxJ5zrNwn11YCm?=
 =?us-ascii?Q?TIpedQaYlD783uKc3Lwefu1y0PZ6vBKF0EyE/yQdu3wsaRC7BUcT2bB+tA98?=
 =?us-ascii?Q?YwA5bwK5oMra7F+z/Dq+r0nq3JSyxjikNiVfDUHWcNusfXYAPY2XyWxFx2EB?=
 =?us-ascii?Q?Hgiz84IpYodQAKEngs6/4YYSi8FnWsdjVqQl4w53TNJa5/LJJxeP9BctBXK8?=
 =?us-ascii?Q?AUhVzUm1HEgshdjtVw3wxfV6p9lnrO20NjZkt/k4/wA0NYYOYbJcLU/yd8t2?=
 =?us-ascii?Q?HU5wyKwmCdkoyeNC8YmJrVRJJyWrzsQvHvF6QrjLvJSjLfdB0CY5TEQ5R4fT?=
 =?us-ascii?Q?WkVq0D6D+rYBMUqz/f378UcyYCOF4rH24QztdFAI/XzK/PsGx5WYIcORzcWM?=
 =?us-ascii?Q?ZgUwU9rqXjqOg+6dGz+Mb5E7jInTT5+60+IOxr9H5lXqp4rRaSFhNN0OlrtL?=
 =?us-ascii?Q?cLGTh+MZ57w3LP/VyUnv4ubcGtIGYVUY/ePo2CYVi8bX7XvMIWEkycegR9iM?=
 =?us-ascii?Q?HAtcLy9Hnsxs5bHioN6rHexIpbkyx5pEcmpYbBomweGamNtZ8yE7oNkuZgoe?=
 =?us-ascii?Q?QXrOIcICPWHP4QIvG3uYdjWFlmKkVfydqmxaQBxj5MxUs68PGAqPB5lnzuT8?=
 =?us-ascii?Q?2COoBTsB6hmdQYnSg1PpFx8Z4pQrvAUKi8R9cXNkOVjhr3L1z9pRpdKlDD3g?=
 =?us-ascii?Q?xMrF9V2ZrfgFrQe6Mi71IS4wCrZroOYRCqHcN0yz0kYwuSra5ZtLk6YmQzYd?=
 =?us-ascii?Q?6uFyEjA7+S7vPoxc+tUeyf2Uc6QsNrega6p7Uomq5zo8p65pdnxH1LuYxDxj?=
 =?us-ascii?Q?XruRmZhqlsIpB8vLQOhmoIw4CxrhXXEeut4PtS/OW9ELN+UFtWO1M33j2jS6?=
 =?us-ascii?Q?Y3ayaSlXoeikWwyYXdSt0g41lyt6eICz+z03EjcCUPQlAJTu1QsT2t0jtuY/?=
 =?us-ascii?Q?YO4InW80leo2hVYR5q33OjyaUHW0elu6eS6J2b9oX6Wr37sxb4lTU7H2zudT?=
 =?us-ascii?Q?qq2Z+AyuHqJ48Y5KDxl0LCbCsX1i3ejFP/u5925iHX7ZuLvFMvjo0u3xMx72?=
 =?us-ascii?Q?3co4z4AjZyOk9/PSTmKsHusG6cazBUwdCVS1EhLS?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 3538e9a4-07ed-4fb0-056e-08da916d3945
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2022 07:39:12.5727
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3Br2P7REQv8q5/k28guH0OiAA8HxU3VpajMsKkACUTKDOcx3Jn5Mf9iFuMqAjOFWCczaDZXd4XmOJE5aYplqhg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB6863
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 07, 2022 at 10:57:34PM +0800, Hyeonggon Yoo wrote:
> On Wed, Sep 07, 2022 at 03:10:21PM +0800, Feng Tang wrote:
> > kzalloc/kmalloc will round up the request size to a fixed size
> > (mostly power of 2), so the allocated memory could be more than
> > requested. Currently kzalloc family APIs will zero all the
> > allocated memory.
> > 
> > To detect out-of-bound usage of the extra allocated memory, only
> > zero the requested part, so that sanity check could be added to
> > the extra space later.
> > 
> > For kzalloc users who will call ksize() later and utilize this
> > extra space, please be aware that the space is not zeroed any
> > more.
> 
> Can this break existing users?
> or should we initialize extra bytes to zero when someone called ksize()?

Good point!

As kmalloc caches' size are not strictly power of 2, the logical
usage for users is to call ksize() first to know the actual size.

I did a grep of both "xxzalloc" + "ksize" with cmd 

#git-grep " ksize(" | cut -f 1 -d':' | xargs grep zalloc | cut -f 1 -d':' | sort  -u

and got:

	arch/x86/kernel/cpu/microcode/amd.c
	drivers/base/devres.c
	drivers/net/ethernet/intel/igb/igb_main.c
	drivers/net/wireless/intel/iwlwifi/mvm/scan.c
	fs/btrfs/send.c
	include/linux/slab.h
	lib/test_kasan.c
	mm/mempool.c
	mm/nommu.c
	mm/slab_common.c
	security/tomoyo/memory.c

I roughly went through these files, and haven't found obvious breakage
regarding with data zeroing (I could miss something)

Also these patches has been in a tree monitored by 0Day, and some basic
sanity tests should have been run with 0Day's help, no problem with
this patch so far (one KASAN related problem was found though, see
patch 3/4).

And in worst case there is problem, we can fix it quickly.


> If it is not going to break something - I think we can add a comment of this.
> something like "... kzalloc() will initialize to zero only for @size bytes ..."
 
Agree, this is necessary. 

> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> > ---
> >  mm/slab.c | 6 +++---
> >  mm/slab.h | 9 +++++++--
> >  mm/slub.c | 6 +++---
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/mm/slab.c b/mm/slab.c
> > index a5486ff8362a..73ecaa7066e1 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -3253,7 +3253,7 @@ slab_alloc_node(struct kmem_cache *cachep, struct list_lru *lru, gfp_t flags,
> >  	init = slab_want_init_on_alloc(flags, cachep);
> >  
> >  out:
> > -	slab_post_alloc_hook(cachep, objcg, flags, 1, &objp, init);
> > +	slab_post_alloc_hook(cachep, objcg, flags, 1, &objp, init, 0);
> >  	return objp;
> >  }
> >  
> > @@ -3506,13 +3506,13 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size,
> >  	 * Done outside of the IRQ disabled section.
> >  	 */
> >  	slab_post_alloc_hook(s, objcg, flags, size, p,
> > -				slab_want_init_on_alloc(flags, s));
> > +				slab_want_init_on_alloc(flags, s), 0);
> >  	/* FIXME: Trace call missing. Christoph would like a bulk variant */
> >  	return size;
> >  error:
> >  	local_irq_enable();
> >  	cache_alloc_debugcheck_after_bulk(s, flags, i, p, _RET_IP_);
> > -	slab_post_alloc_hook(s, objcg, flags, i, p, false);
> > +	slab_post_alloc_hook(s, objcg, flags, i, p, false, 0);
> >  	kmem_cache_free_bulk(s, i, p);
> >  	return 0;
> >  }
> > diff --git a/mm/slab.h b/mm/slab.h
> > index d0ef9dd44b71..20f9e2a9814f 100644
> > --- a/mm/slab.h
> > +++ b/mm/slab.h
> > @@ -730,12 +730,17 @@ static inline struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s,
> >  
> >  static inline void slab_post_alloc_hook(struct kmem_cache *s,
> >  					struct obj_cgroup *objcg, gfp_t flags,
> > -					size_t size, void **p, bool init)
> > +					size_t size, void **p, bool init,
> > +					unsigned int orig_size)
> >  {
> >  	size_t i;
> >  
> >  	flags &= gfp_allowed_mask;
> >  
> > +	/* If original request size(kmalloc) is not set, use object_size */
> > +	if (!orig_size)
> > +		orig_size = s->object_size;
> 
> I think it is more readable to pass s->object_size than zero

OK, will change. 

Thanks,
Feng