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:   Tue, 22 Nov 2022 13:30:19 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Andrew Morton <akpm@linux-foundation.org>
CC:     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>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        <linux-mm@kvack.org>, <kasan-dev@googlegroups.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next 1/2] mm/slab: add is_kmalloc_cache() helper macro
Message-ID: <Y3xeYF5NipSbBFSZ@feng-clx>
References: <20221121135024.1655240-1-feng.tang@intel.com>
 <20221121121938.1f202880ffe6bb18160ef785@linux-foundation.org>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20221121121938.1f202880ffe6bb18160ef785@linux-foundation.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QUs1SHFxR09mbkZHSU1aMkhGUEptTDNpcFNvZWY5VUliUXdVVTdyalF3Y0xQ?=
 =?utf-8?B?Y0p6QmQ5L20rbnE3ckl2MldETWZSdlp6MjZPK1FlUUpaWmdvMWlsSWR6bHFn?=
 =?utf-8?B?OG8xNWRLSUFlenVjUkVML3h6YXF2b3lNdjFGc3JHZG9PWVl2dDR1ZDJGbUNQ?=
 =?utf-8?B?ODhDY0t6aWIwZk1YbFdmNGxjN3IzaXpKQXdmQXk0WFhZa3BGNW45VzVWWEZ5?=
 =?utf-8?B?bzdoeWo2eTZjMEF3QXZURG94eWJweXF2MFpyVGVidGpkd2R0dUFXZGpvYTg2?=
 =?utf-8?B?YTBVTU96SkRrRDVIb1A4OUxCMGYrUFJJVjN1NThJV0piUXdlWXE3VEcwVzdM?=
 =?utf-8?B?TlVJdUZTRWdRZnBVb0UwOThybExKc0ozSytZRmRYSkxZYnR6VEx2YjRsQU9C?=
 =?utf-8?B?cFNQN0ZvRTljUVBmamJ3dDR5bWVHYUd5bm1ISUZuc3JXdzdkSHN4SFpaUzBr?=
 =?utf-8?B?SzNWMEppemw0bU5vc0JtY004RXFEbjBNUmJVOWxjU2JvRktNRlhUeHFuUHZ6?=
 =?utf-8?B?NW11UFVtRzVOMU9lbFVNSTR3WTdJVkxqTlUvNXR6bFFWQldUczJBMVRFMUtN?=
 =?utf-8?B?VkJySGhLdmFzUTRET0F3dHJJMnUxOFFwY1FIZjJSVGlpamcwYjYrUUtyRWxh?=
 =?utf-8?B?bCtiS3BDdmVLUHhFUFl0bWhJS25CRHdkcVBoc3ozUklGOW44U3J3a3BlRUQ4?=
 =?utf-8?B?VHhFSi9EclFPWnoyUXdpcHpDRXFRdFlOM3NVTmZHRUQxTGRWZXpNRUp6b3k1?=
 =?utf-8?B?Y0lTdDBjaHp3QnU0NGFrcGpiRnpyUlZWRCs2T1llMFpjMVgvWkh6N21qcHAz?=
 =?utf-8?B?YkFZL0I0ZVc1SVJzS1c0MFhmMkgrNzR1OXdkSFNBeW1OYWVrUFloT05CdHdZ?=
 =?utf-8?B?SmVWWWgzUVhkWGhqUWFJWjNPcThaa0ZNczZTQ041M2hHWkVXZU9WZHFqWVJq?=
 =?utf-8?B?Z1djS2xjektRdFBxL1Q5NHBNa2tUVzE5ZnVRMEk1NE1hK01sNSthL0pWc2tK?=
 =?utf-8?B?bWlGbkxRQXhIODB4RW4zMXl6bnIrTllXaW42K3IwcytWWUEyKzFreXpvN1VN?=
 =?utf-8?B?djB6ajhFRkllL1VLVXVCQ1k2L2xROVppd3UwdmdaV3lIbkFtMXZEL2dPSFF0?=
 =?utf-8?B?NEswUFR3TUtFV3EvdGxONG1RMmp3YmhlOHlSbGNLMUVlUzlrV0JRemJLUmNx?=
 =?utf-8?B?c2lqYVM5eTkvRk9lUTNVMTkvUmlwbDA3YWVWODdOOWx5bWpoWjBFYXdiQTY0?=
 =?utf-8?B?cmlVNEloYUZZdUcxaUJIR0ZaNGNyOG9wemhwcVY0WS95T0N0RHFxT3JlRG9C?=
 =?utf-8?B?S0RqYUljcWZjYmNNbVBOOEhhb0JpRjl4V0VkMXFsWUdJZStrL083b1ZZaDkz?=
 =?utf-8?B?akRQTVFYZmI4NG8zai9sM05saTNwSjJWRXVEWG1KcGs1RTdWaDZJQXdpRmht?=
 =?utf-8?B?Mkk0VUFIZlp4SytaTHZpaU00Z0x4eDJwMG52NENBdWxsL0h1S2pxb0FwbXla?=
 =?utf-8?B?a1M1dVptOERWcE5jOGJJb0pZRzRGRXJkQnFzQWd1Qitrdk1iOWxyaVRNUTJT?=
 =?utf-8?B?dE9LMnBieDJjZ2d6MFEyY0tPRGRjaDRNRVZTZll6R1FRWnJZdDJFVnlTZnNQ?=
 =?utf-8?B?ekEzOUwwbEFpa2hEdTFtQlc0eDVGbC9xTGVoNE1sYWtuNUxuRGYyamthb2Ev?=
 =?utf-8?B?bm9mbzIwaHV2a2lrVk5wRDJUWW4xZWFWRFU1ZHZRTU5wbkQvU1NvSUNtM2NJ?=
 =?utf-8?B?M2Jnb3FNUGZ1M2h0N1I5ZWtvdEFkVHhmNTRYZFlxcU11c2dSY2dIYnU2MlhM?=
 =?utf-8?B?ZjBEL0lvQ3VONGJST2VNYldSY210VmNXSDBNZmVOOWt4TWxuYXdYOS9aVTJB?=
 =?utf-8?B?NUxRT3prQ0ZwbkFmNzJuQ2RTYjhpSFkyY24rNzUrM1JTWE9TL3gwNFlWeUI4?=
 =?utf-8?B?NUdiaEo3YmZGSDZjVVBuRGhhSktoUjAvQ0pIT1kyN205NTFoejRIbGt5SS9X?=
 =?utf-8?B?SUNYdWxGMXFBMFNYbEdQcEpWQU50RXhJUkt4ZzBUMVZ2M2JxWHpvV3Y2UzZG?=
 =?utf-8?B?UHcwVFo2Y0tJdjBJT2drWDZXZGtxMG9yQkliYmhUTE9ISE1JWVFqV2JvaUR6?=
 =?utf-8?Q?VWUeylH8WgO8FijljNnJb9yCc?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 45688f1f-eb30-4b10-054e-08dacc4b18f3
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2022 05:33:34.1102
 (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: tRULEFoLB4rH28M4zG1YJqlF1rCg3birLJOCNRfGh6AvpD5AJFOmEI2dgozhiwB4mB+m9TZukN6VHnAUWEtKkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4963
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_PASS,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 Mon, Nov 21, 2022 at 12:19:38PM -0800, Andrew Morton wrote:
> On Mon, 21 Nov 2022 21:50:23 +0800 Feng Tang <feng.tang@intel.com> wrote:
> 
> > +#ifndef CONFIG_SLOB
> > +#define is_kmalloc_cache(s) ((s)->flags & SLAB_KMALLOC)
> > +#else
> > +#define is_kmalloc_cache(s) (false)
> > +#endif
> 
> Could be implemented as a static inline C function, yes?

Right, I also did try inline function first, and met compilation error: 

"
./include/linux/slab.h: In function ‘is_kmalloc_cache’:
./include/linux/slab.h:159:18: error: invalid use of undefined type ‘struct kmem_cache’
  159 |         return (s->flags & SLAB_KMALLOC);
      |                  ^~
"

The reason is 'struct kmem_cache' definition for slab/slub/slob sit
separately in slab_def.h, slub_def.h and mm/slab.h, and they are not
included in this 'include/linux/slab.h'. So I chose the macro way.

Btw, I've worked on some patches related with sl[auo]b recently, and
really felt the pain when dealing with 3 allocators, on both reading
code and writing patches. And I really like the idea of fading away
SLOB as the first step :)

> If so, that's always best.  For (silly) example, consider the behaviour
> of
> 
> 	x = is_kmalloc_cache(s++);
> 
> with and without CONFIG_SLOB.

Another solution I can think of is putting the implementation into
slab_common.c, like the below?

Thanks,
Feng

---
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 067f0e80be9e..e4fcdbfb3477 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -149,6 +149,17 @@
 
 struct list_lru;
 struct mem_cgroup;
+
+#ifndef CONFIG_SLOB
+extern bool is_kmalloc_cache(struct kmem_cache *s);
+#else
+static inline bool is_kmalloc_cache(struct kmem_cache *s)
+{
+	return false;
+}
+#endif
+
 /*
  * struct kmem_cache related prototypes
  */
diff --git a/mm/slab_common.c b/mm/slab_common.c
index a5480d67f391..860e804b7c0a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -77,6 +77,13 @@ __setup_param("slub_merge", slub_merge, setup_slab_merge, 0);
 __setup("slab_nomerge", setup_slab_nomerge);
 __setup("slab_merge", setup_slab_merge);
 
+#ifndef CONFIG_SLOB
+bool is_kmalloc_cache(struct kmem_cache *s)
+{
+	return (s->flags & SLAB_KMALLOC);
+}
+#endif
+
 /*
  * Determine the size of a slab object
  */