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, 1 Sep 2022 13:04:58 +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>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        "John Garry" <john.garry@huawei.com>,
        Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH v4 1/4] mm/slub: enable debugging memory wasting of
 kmalloc
Message-ID: <YxA9etTqGsaogfZ6@feng-clx>
References: <20220829075618.69069-1-feng.tang@intel.com>
 <20220829075618.69069-2-feng.tang@intel.com>
 <Yw91n/AzjmAXmdh8@hyeyoo>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Yw91n/AzjmAXmdh8@hyeyoo>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Q7Et+R0iaZlryo6qCRnaDvSf7oRHTyUqmK9AUiFNwoIKOSDZxe+lGpeUT+QZ?=
 =?us-ascii?Q?BwcLtrb1ykwSOQIT4HGupgK5XJ1YfWhBwNA5If6ci6vRWetB70VbMoMxZiRj?=
 =?us-ascii?Q?0kB9OwUjVzwfZdjhlnvsUEscbi+hjbV0J2RFQFlJifIJSnNtr0u0B28U0kxw?=
 =?us-ascii?Q?G+mStLIKLGSrijWZaqZNUgk5jLw7lNsQja0BV5ggEp0UJtJDl7r7yxkSwB+0?=
 =?us-ascii?Q?duJ/Kv7kEeQ+c4jWOsrx22GbKWgsagDBf/i9SPJU/YR7sw3gyFNnpJXn/sNx?=
 =?us-ascii?Q?g9HUipb/TLLysGLQvQeFump8irIolPQGf8L/IQNV2EiUqwU1LtY4RX996Bej?=
 =?us-ascii?Q?CE0oGxGJNhAzbthssnCxemOfRSkLqocCqvJiY46SIQFTA273OQjhVnNAObP3?=
 =?us-ascii?Q?BVdYkOk6XMBS+IMXs0YFdwuFcmTmYtU4KJA6C+nkunW6xmpd3msXPuwJTPQ4?=
 =?us-ascii?Q?J3tYLZ0YdA+WYfAX2Kwm12/6aLxY6ZAJ2i9JJcXHRIHmFNoQnLS9KJUALPc1?=
 =?us-ascii?Q?z+1sVpmTHdm8Q0tPTRCtn017JOUt1YWc22iZFsp7etrpcm8hzHA7gNU/7GbT?=
 =?us-ascii?Q?Wy1Md3nUh9Qj/8z08LvfPzZDndqZF09t4nIfx7qL7IBLB2eN92A0aKHuJR9o?=
 =?us-ascii?Q?+/9nuutbRj5M74KlgQ6kenEbEmi6KJ3CHji0Z3K4w6PUFYVUgKzG0N0sql7J?=
 =?us-ascii?Q?14k/wJCpnNUqtTHo800FqjE9mAXL4uOM8NRbhbGN7DhrAsz0WEJUJw94Sn4w?=
 =?us-ascii?Q?SjApufsD/idDj+vqeHQsIWL0YvjQ7FKXVSUX4tNbvdefub9XgEnRSbebKie3?=
 =?us-ascii?Q?9Tz9tX6JGrSrtSsDmURc260/p+K7W5JfVcSsiFkVF7s51BKhipCMSGT8e104?=
 =?us-ascii?Q?fbvmi+LxS7erIMGkeOOK/ue+3AvlPs1l/2zIDut3dKVxn5Vy3bJspEM1Yuwe?=
 =?us-ascii?Q?q+hBF7+M3tpbpC+qnf/hX+My7fP4qSX9T8Z6xuI9VwxiQF0uM3sDmW+Sxwr6?=
 =?us-ascii?Q?+9wQTplfkd+VXyn2BcTPlHes+Oe6K+dhhxFQ8aSYhoZ+Y0IO9lIQ08Yz+5eX?=
 =?us-ascii?Q?lObVOm8lge0tXXQdaxf1dq/BorzSzWxFfcB3a3I5OO5Q0JURrQFeWLu15iAK?=
 =?us-ascii?Q?leKIChLbYsP7uozfQKFNL38qgC0E1ZeZ3Nuebi41eEJXusxLYyQjWCsifdQB?=
 =?us-ascii?Q?eVTxvaFbReOtBO4b07Net07FbhvnGQqug3yT5FMHi2Knf/0C/XJ+XIvkXSkd?=
 =?us-ascii?Q?BQx2wPqLvEaZ0KV7MrhdSAJSFd6h0lVuyx0C9LwyyfBuuGDrbJiuT6ZvgfKS?=
 =?us-ascii?Q?uqHtjUycnGEo6B9rTGaFxanIXEqLOJ0l8Pe6YEl/XS0E20ywJ3Em30HsrfHs?=
 =?us-ascii?Q?tvHzTDlSI1RL/h1mJqjFr21/qtQv/P09EM1bn9oYeDJ8wf7/VCuJj/bNlMud?=
 =?us-ascii?Q?k+30+Ak/UvPCQuIbIWUi1DBZJujQpxY4wnxjcNz2VSxfntEXIdUA0is9iDnz?=
 =?us-ascii?Q?OeZwgeBvu/D38k+1cxeB5ntqdUgmCU6Wo5aaOE59ET6MR5cenfzi3gx9GlDs?=
 =?us-ascii?Q?qqTGk9R3oQ1LTv8eSAw2BflDs0XEM01g2QRGgi8X?=
X-MS-Exchange-CrossTenant-Network-Message-Id: cd5b83c2-2051-4cc1-5ef1-08da8bd799b6
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2022 05:05:34.1159
 (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: 6X0BFVEJVNGDke5ud/jaxGIHeLgS8yLWeYx5qevOYe07Um0NSggXjfjUdxZEheHedCnw6ZKav9vwz1VYNyDY/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4536
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,
        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, Aug 31, 2022 at 10:52:15PM +0800, Hyeonggon Yoo wrote:
> On Mon, Aug 29, 2022 at 03:56:15PM +0800, Feng Tang wrote:
> > kmalloc's API family is critical for mm, with one nature that it will
> > round up the request size to a fixed one (mostly power of 2). Say
> > when user requests memory for '2^n + 1' bytes, actually 2^(n+1) bytes
> > could be allocated, so in worst case, there is around 50% memory
> > space waste.
> > 
> 
> [...]
> 
> >  static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> > -			  unsigned long addr, struct kmem_cache_cpu *c)
> > +			  unsigned long addr, struct kmem_cache_cpu *c, unsigned int orig_size)
> >  {
> >  	void *freelist;
> >  	struct slab *slab;
> > @@ -3115,6 +3158,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> >  
> >  		if (s->flags & SLAB_STORE_USER)
> >  			set_track(s, freelist, TRACK_ALLOC, addr);
> > +		set_orig_size(s, freelist, orig_size);
> >  
> >  		return freelist;
> >  	}
> > @@ -3140,6 +3184,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> >  		 */
> >  		if (s->flags & SLAB_STORE_USER)
> >  			set_track(s, freelist, TRACK_ALLOC, addr);
> > +		set_orig_size(s, freelist, orig_size);
> > +
> >  		return freelist;
> >  	}
> 
> Maybe we can move set_track() and set_orig_size() to after slab_post_alloc_hook().
> something like alloc/free hooks for debugging caches? (and drop orig_size parameter.) 

Yep, we discussed this during v3 review
https://lore.kernel.org/lkml/442d2b9c-9f07-8954-b90e-b4a9f8b64303@intel.com/

Will revisit this considering recent refactoring and the following
kmalloc data redzone patches.

Thanks,
Feng

> Thanks!