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:   Fri, 4 Nov 2022 11:52:07 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        John Thomson <lists@johnthomson.fastmail.com.au>,
        Andrew Morton <akpm@linux-foundation.org>,
        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>,
        "Andrey Konovalov" <andreyknvl@gmail.com>,
        "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>,
        Robin Murphy <robin.murphy@arm.com>,
        John Garry <john.garry@huawei.com>,
        Kefeng Wang <wangkefeng.wang@huawei.com>,
        "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
        "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v6 1/4] mm/slub: enable debugging memory wasting of
 kmalloc
Message-ID: <Y2SMZ0//dReS/NMV@feng-clx>
References: <53b53476-bb1e-402e-9f65-fd7f0ecf94c2@app.fastmail.com>
 <Y2DngwUc7cLB0dG7@hyeyoo>
 <29271a2b-cf19-4af9-bfe5-5bcff8a23fda@app.fastmail.com>
 <097d8fba-bd10-a312-24a3-a4068c4f424c@suse.cz>
 <Y2NXiiAF6V2DnBrB@feng-clx>
 <f88a5d34-de05-25d7-832d-36b3a3eddd72@suse.cz>
 <Y2PNLENnxxpqZ74g@feng-clx>
 <Y2PR45BW2mgLLMwC@hyeyoo>
 <8f2cc14c-d8b3-728d-7d12-13f2c1b0d8a0@suse.cz>
 <55ace2db-80b6-04db-e8b5-03bd3b5061cf@suse.cz>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55ace2db-80b6-04db-e8b5-03bd3b5061cf@suse.cz>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?V1Gq5p1ZA7tiH0dSTCKei9R7oQCLW6aHqGOc1YSUzqJCWaaEdKWKvmJslhXe?=
 =?us-ascii?Q?+mF3XSblpJlDFpU+2IYO7L5xnUIn4QSbz7593ImeBuiz0vhvEKLxi8x+eGMo?=
 =?us-ascii?Q?HA2/pTJWpqEgNFUmkbSRSqh6tKXaAj9piBdV9o9s+GJA2qcDevoe2jZSTbSw?=
 =?us-ascii?Q?rCuS1cPw1R+1axFZMaI+/krwW9gT57vFnetne61MFlVYvko7gH4azdf2qsyB?=
 =?us-ascii?Q?rNEgv1TgDXpih3fnvD9+Ad8SjxgDHcJ7oACdsgKwqffnYWM9NH2IKS0oGxYz?=
 =?us-ascii?Q?XqGjoBtE6UttU/XdPE3LoIxxv79tZKvSEKCoFnVHs8ByyjpvvaR1WU7lq+h+?=
 =?us-ascii?Q?l0jI0PWHa2i+6G0VQFKYUzIcSQ9SFFPDn4K7omJMP9KllamM0gjI9+K+id/D?=
 =?us-ascii?Q?1/tydRmkOhFHVmBINuVkdylniq50aHCNPrMnd/QCoELFASeOOSU6+OxDxiS3?=
 =?us-ascii?Q?IGljVTuTcmx0h7WR2XtAJztWMDOHgewBliJrQrDq1In/B64ZW0sMgTNnQvlL?=
 =?us-ascii?Q?j5R7zITWwjp7OYxyjM/XX53djTn87fj6SeHPXZ5JyUL7iAnp+RzLIP/I/fli?=
 =?us-ascii?Q?4Qnu8lHensuGjqa8ae16EFI3U6k5VMpyLWFzcB0YLL9KLqkr9thFx+T3fuUI?=
 =?us-ascii?Q?LqXXVY5uVAMfFyIH+KVJk7jVSSzp3/Vl19VpLjQOGZ6ze76cRPozd1KQKamX?=
 =?us-ascii?Q?gpoXequK26oXHUbsQUPnBl8jq+cFP9wD/dMM3LuumN5Ur0j9TN168ha4cM+N?=
 =?us-ascii?Q?C4hgIt6PMF5umkUqCyin2170zYUgMgpUZzWTh1WEHyV9fpGkde0O9Ycw58n3?=
 =?us-ascii?Q?joGUbtLZhiMxhZ9lBJUHxmtTdnG0dGo2Mi2RTWjlWad9HkCOlo3b6RpVGMPj?=
 =?us-ascii?Q?Iphs4jeslTq9xCw0oqGNIFw/osLxaz9Ey1kyfKtcBkIH4ydp4lzhtFRfAP91?=
 =?us-ascii?Q?UYuPcgj8N958kzvyzcyj+to/oSUJvYMJ0YgpheFqV5EO3jZn3NwUT3AcZ65/?=
 =?us-ascii?Q?Xh0g02fV7tdZdBAKT1bPIP607R8+gFi0xJeuD6omLXkS86d4pc6pCFmQ0n25?=
 =?us-ascii?Q?hLJeLr04Tiv4b0p6oLpx/Vb3YIK1rLWiSwKkgJzOIWy5KRhxx+29Jr2Haybc?=
 =?us-ascii?Q?oGvDu+NUFY7SiVplyw+2zIl3NrExBQAs/ZVoUGTJQ66WpaPhDr4I1sru7vx1?=
 =?us-ascii?Q?SX+v+M1Mb4IckpQO+m9l7Pdp7vyUDHz4/hzdhIJ7TiOZbDqiZdLHbQ4fX7ay?=
 =?us-ascii?Q?yYtyU3bKqFnhW96Xj32QtZ4bkSc6CqbRc/qEBc7NC9WAdKYU9cH8/S5+Da8x?=
 =?us-ascii?Q?7sr4b14BpChbzy/kZW6/8DMAzpPj4UpUIEP/59zAoTHcjkuyy7HsdBlqFICC?=
 =?us-ascii?Q?YvNvwB6++tFe1Oqlhx7DcN7u5huMG0fXUu0a5azdDrBXdJdxmqtnBhweh3yp?=
 =?us-ascii?Q?RB8bDHR4qERBVE7V3bjEl3Ppo4D7UnCQBYmC3hS+75eyvCFX/hTCwlWoK9Pa?=
 =?us-ascii?Q?Yj/sFU6Q7oPUzzGb+I/CPVCOE+S+U1ZB/tSG4uG5GUM48dV2Bn+eWyq2+q5G?=
 =?us-ascii?Q?ghtqvD/9Jw6AMgX+oPCw2Sh+eQneS+Y3gX7PzX2V?=
X-MS-Exchange-CrossTenant-Network-Message-Id: cf39d40a-b05a-466b-e087-08dabe1864d2
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2022 03:55:20.8893
 (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: 810jYzCHR3aa/YHl0WUWiLZjioeig6ltQ33g6rxcxDdpDwPmtRhQV7NQ9VkXYlB61v8rmN8ENg8l3v7r4FNV6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5536
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE 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 Thu, Nov 03, 2022 at 06:35:53PM +0100, Vlastimil Babka wrote:

[...]

> >> But FYI I'm suggesting to drop CONFIG_TRACING=n variant:
> >> 
> >> https://lore.kernel.org/linux-mm/20221101222520.never.109-kees@kernel.org/T/#m20ecf14390e406247bde0ea9cce368f469c539ed
> >> 
> >> Any thoughts?
> > 
> > I'll get to it, also I think we were pondering that within your series too,
> > but I wanted to postpone in case somebody objects to the extra function call
> > it creates.
> > But that would be for 6.2 anyway while I'll collect the fix here for 6.1.
> 
> On second thought, the fix is making the inlined kmalloc_trace() expand to a
> call that had 2 parameters and now it has 5, which seems to me like a worse
> thing (code bloat) than the function call. With the other reasons to ditch
> the CONFIG_TRACING=n variant I'm inclined to just do it right now.

That's great! It will save much trouble, and reduce code complexity.

Btw, the patch below also has some compiling issue for some kconfig
(thanks to 0Day's kbuild bot).

Thanks,
Feng

> >>> 
> >>> How about the following fix?
> >>> 
> >>> Thanks,
> >>> Feng
> >>> 
> >>> ---
> >>> From 9f9fa9da8946fd44625f873c0f51167357075be1 Mon Sep 17 00:00:00 2001
> >>> From: Feng Tang <feng.tang@intel.com>
> >>> Date: Thu, 3 Nov 2022 21:32:10 +0800
> >>> Subject: [PATCH] mm/slub: Add missing orig_size parameter for wastage debug
> >>> 
> >>> commit 6edf2576a6cc ("mm/slub: enable debugging memory wasting of
> >>> kmalloc") was introduced for debugging kmalloc memory wastage,
> >>> and it missed to pass the original request size for kmalloc_trace()
> >>> and kmalloc_node_trace() in CONFIG_TRACING=n path.
> >>> 
> >>> Fix it by using __kmem_cache_alloc_node() with correct original
> >>> request size.
> >>> 
> >>> Fixes: 6edf2576a6cc ("mm/slub: enable debugging memory wasting of kmalloc")
> >>> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> >>> Signed-off-by: Feng Tang <feng.tang@intel.com>
> >>> ---
> >>>  include/linux/slab.h | 9 +++++++--
> >>>  1 file changed, 7 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/include/linux/slab.h b/include/linux/slab.h
> >>> index 90877fcde70b..9691afa569e1 100644
> >>> --- a/include/linux/slab.h
> >>> +++ b/include/linux/slab.h
> >>> @@ -469,6 +469,9 @@ void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_kmalloc_alignm
> >>>  							 __alloc_size(1);
> >>>  void *kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node) __assume_slab_alignment
> >>>  									 __malloc;
> >>> +void *__kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node,
> >>> +				size_t orig_size, unsigned long caller) __assume_slab_alignment
> >>> +									 __malloc;
> >>>  
> >>>  #ifdef CONFIG_TRACING
> >>>  void *kmalloc_trace(struct kmem_cache *s, gfp_t flags, size_t size)
> >>> @@ -482,7 +485,8 @@ void *kmalloc_node_trace(struct kmem_cache *s, gfp_t gfpflags,
> >>>  static __always_inline __alloc_size(3)
> >>>  void *kmalloc_trace(struct kmem_cache *s, gfp_t flags, size_t size)
> >>>  {
> >>> -	void *ret = kmem_cache_alloc(s, flags);
> >>> +	void *ret = __kmem_cache_alloc_node(s, flags, NUMA_NO_NODE,
> >>> +					    size, _RET_IP_);
> >>>  
> >>>  	ret = kasan_kmalloc(s, ret, size, flags);
> >>>  	return ret;
> >>> @@ -492,7 +496,8 @@ static __always_inline __alloc_size(4)
> >>>  void *kmalloc_node_trace(struct kmem_cache *s, gfp_t gfpflags,
> >>>  			 int node, size_t size)
> >>>  {
> >>> -	void *ret = kmem_cache_alloc_node(s, gfpflags, node);
> >>> +	void *ret = __kmem_cache_alloc_node(s, gfpflags, node,
> >>> +					    size, _RET_IP_);
> >>>  
> >>>  	ret = kasan_kmalloc(s, ret, size, gfpflags);
> >>>  	return ret;
> >>> -- 
> >>> 2.34.1
> >>> 
> >>> 
> >>> 
> >> 
> > 
> 
>