From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EE56C5DF61 for ; Thu, 7 Nov 2019 13:13:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EE2892075C for ; Thu, 7 Nov 2019 13:13:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE2892075C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 89F856B0003; Thu, 7 Nov 2019 08:13:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 84F876B0006; Thu, 7 Nov 2019 08:13:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 766246B0007; Thu, 7 Nov 2019 08:13:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 5C7C76B0003 for ; Thu, 7 Nov 2019 08:13:46 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 0F6AB8249980 for ; Thu, 7 Nov 2019 13:13:46 +0000 (UTC) X-FDA: 76129523652.27.angle52_3df11422b5008 X-HE-Tag: angle52_3df11422b5008 X-Filterd-Recvd-Size: 2885 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 13:13:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CB4B9B169; Thu, 7 Nov 2019 13:13:43 +0000 (UTC) Date: Thu, 7 Nov 2019 14:13:42 +0100 From: Michal Hocko To: Knut Omang Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton Subject: Re: [PATCH] mm: provide interface for retrieving kmem_cache name Message-ID: <20191107131342.GT8314@dhcp22.suse.cz> References: <20191107115404.3030723-1-knut.omang@oracle.com> <20191107115806.GP8314@dhcp22.suse.cz> <27006f47b0b85fb99acee2a638207268aef8d010.camel@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27006f47b0b85fb99acee2a638207268aef8d010.camel@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 07-11-19 13:26:09, Knut Omang wrote: > On Thu, 2019-11-07 at 12:58 +0100, Michal Hocko wrote: > > On Thu 07-11-19 12:54:04, Knut Omang wrote: > > > With the restructuring done in commit 9adeaa226988 > > > ("mm, slab: move memcg_cache_params structure to mm/slab.h") > > > > > > it is no longer possible for code external to mm to access > > > the name of a kmem_cache as struct kmem_cache has effectively become > > > opaque. Having access to the cache name is helpful to kernel testing > > > infrastructure. > > > > > > Expose a new function kmem_cache_name to mitigate that. > > > > Who is going to use that symbol? It is preferred that a user is added in > > the same patch as the newly added symbol. > > Yes, I am aware that that's the normal practice, > we're currently using cache->name directly in the kernel > unit test framework KTF (https://github.com/oracle/ktf/) > which we are working (https://lkml.org/lkml/2019/8/13/111) to get > into the kernel in one form or another. Please add the export with a patch that really needs it. > To me this seems like a natural part of an API for the kmem_cache > data structure now that it has in effect become opaque, so it seemed > appropriate to get it in close in time to the patch that no longer > makes this possible, instead of someone else hitting this down the road. Well, this is something for SLAB maintainers but I do not really think the name is something the in kernel code should care about. It is solely for presenting reasonable statistics to the userspace and that code workds just fine AFAIK. -- Michal Hocko SUSE Labs