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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0F44C00528 for ; Wed, 2 Aug 2023 11:12:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B232280152; Wed, 2 Aug 2023 07:12:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 113C8280143; Wed, 2 Aug 2023 07:12:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF602280152; Wed, 2 Aug 2023 07:12:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DC59B280143 for ; Wed, 2 Aug 2023 07:12:32 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A821C120DEF for ; Wed, 2 Aug 2023 11:12:32 +0000 (UTC) X-FDA: 81078901344.25.6A18673 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) by imf17.hostedemail.com (Postfix) with ESMTP id A3A7C4000E for ; Wed, 2 Aug 2023 11:12:26 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=none (imf17.hostedemail.com: domain of thunder.leizhen@huaweicloud.com has no SPF policy when checking 45.249.212.51) smtp.mailfrom=thunder.leizhen@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690974749; a=rsa-sha256; cv=none; b=PTzlkc/8dZQ5o/gjryU81sk0VzZp+sTyC3c5LVkV7eKYnaTpLud5PowcBNVS/VwIoESidc XXAYgneNViQKNLFajN7SIP1bhd+kPZKgMJ8o5GBnVG/ir2F59g2X1tcjBnMHSW37hGwK+y 9Tg5SwdN+kc/LBQfKSWvtMabrnTx7IQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=none; spf=none (imf17.hostedemail.com: domain of thunder.leizhen@huaweicloud.com has no SPF policy when checking 45.249.212.51) smtp.mailfrom=thunder.leizhen@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690974749; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/2bEGNjErH8XPcsxXMsdYBBgwtZFBRLf9bFNVee5rdI=; b=vTjVgHijbaEOSLuCjtsIU5Pi/GWGKcGFDq0aPqGke0ejP2Xugyz5kkmPmz0jRjtZP+fDN/ eXR+G/JlDNIf7OgeuDWwoN/ZrWwwODvRHxfwofHXUo7rKrfdxOn6gYaaq9qILvElJ0qYlK GbjPXb8ovaqWw8l0NXjqG6u++TptKTQ= Received: from mail02.huawei.com (unknown [172.30.67.143]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4RG8Sz6S11z4f4Q4Y for ; Wed, 2 Aug 2023 19:12:19 +0800 (CST) Received: from [10.174.178.55] (unknown [10.174.178.55]) by APP4 (Coremail) with SMTP id gCh0CgCnD7PIOcpkYBWPPQ--.20712S3; Wed, 02 Aug 2023 19:11:06 +0800 (CST) Subject: Re: [PATCH v3 1/2] mm: Provide empty function for kmem_dump_obj() when CONFIG_PRINTK=n To: Matthew Wilcox Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, "Paul E . McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , rcu@vger.kernel.org, linux-kernel@vger.kernel.org, openeuler References: <20230802034518.1115-1-thunder.leizhen@huaweicloud.com> <20230802034518.1115-2-thunder.leizhen@huaweicloud.com> From: "Leizhen (ThunderTown)" Message-ID: <91233a90-94bb-0318-3bcb-10a4403cd526@huaweicloud.com> Date: Wed, 2 Aug 2023 19:11:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CM-TRANSID:gCh0CgCnD7PIOcpkYBWPPQ--.20712S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar4DZw1xXr17tr43WF4rXwb_yoW8Xryxp3 saqa9xWrWUAr9rJrn7A3ZakFy5Gr48XrnxC3Z0qw45Zr18X397Z3s7K34YqFn8JFy7Xr10 yaykuFs7A3yqyrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6r1S6rWUM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I 0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40E x7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7I2V7IY0VAS 07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c 02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_ WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7 CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAF wI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa 7IU13rcDUUUUU== X-CM-SenderInfo: hwkx0vthuozvpl2kv046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A3A7C4000E X-Stat-Signature: oxrbu7xejyucpsw9wde5adjt36aqqrz3 X-Rspam-User: X-HE-Tag: 1690974746-598297 X-HE-Meta: U2FsdGVkX1+FWcmHw95nVTgOZCdZDb4s0ui4Yvr4WeSLuSErvT4tqeAnZIyFjoqoDNSgNnteMe2fl3HJFBxgA4FcqUbTtOj+eXEeRSZ1yoPaddK06qmP3NFRTwxQolyo1Quxk2Cv2nEGD3RePibWFcbZikzFMxCfp7Nchw8qVkRaPV/o2y9C2eA9yGmx3KOP7jZkacMx39k/U5lfp9nk8cwcXuOTyKU+mSm+ia0vD6G3fXUfxaREezBByRUc7ogjJUzrQxVa+54RN1zxW/ja21+5AUbR1xE4F448SdNFSGx8capGjVNl2VASbfx4V+WYJXO5ssGdTPtuhuFz70kZvuDCx5A9JpQDz90C6kbSo768smvM82MGQu/G2aplyz7m799mD9gwikAoJHLAUqttwJRk/PSAO7fkHSGOw3X/R2GZeBfHvGhSU0s5+Gahogwr7SEW6SQmLJ+VgVHwLMmQxlVxE49oAEpqHNBNdpc+ve7ifY0gwbQ6X5M+UgnOy/yiELvrsRpW/mnRo1nLothfyfoUTNH8DEwm9B95l8diFRy4gFaRlm3+XK5by+gaQNRsfjvDNC3tDsB/coAB9ijb6c319D1mNFDy4ZlNAmeGaUpD8J2o9BTjIfmDySvlXccwI407zfdkrEz+2mDAfdfujahXSOu0L+oE+aA5/8aKExAPRgCMuskTCybXHKy7vzwuvNVDvVdm3lg5/jGIzA1CFtDorXR/zVZgNGP6neJZ/jR4jlLmtiasB4nvoT+rEXOlYODcNSjL2cMB9X7oT7k2Ik+1402ai/dsjMbpWrrCz9IZjoS4VJQawN97T5s8N6guqHBd8mseQeGPj1W7MCUP+1v/l1SGgDjoGtFAe/m4pzuzAPQ/i4t7g6qigY/c8uEP+OxGyYnwCnWsXh4JqHiAXVj2OP1b/g1y6H9PI6h+oSLs17mMMGo7TuxtpxRSu8Ld0JFFj7uZYS4uy0Vm5i/ HSS2Ld7W m765fqPxxduu5TSyJfTWqFiFF8IO8OkZsmpaMMCZ2WKSw8SNCPb9Nbxab9ES6wBy0RR87ZC+2gTwyFI+WHWhPXHHIYUWdU4QzxU3PVwDpgrsnX3RNLv9UlLHfAE830ELBvaN6s5mtxvqX3H4EgqIswQWqmFak1f/MyL3DQubxnPLMemcTeUjftVQNikhSE4CbY3OTUEnYzJdJjzKY3djIaP41ApZtCObeKZstsbKrZGRFBQRyutacF10eHsTVp55jmPh8Xanzx6oukvlSen10SDY/qZSKlyp/btcnaZ5Qc/kftI2Q+4ZdN/ZAi4NYc9c9ZU46TVE6IpW4VY/0M6IIU74IiRjXA9S6E9RA5V0YUbGiFo4= 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 2023/8/2 11:57, Matthew Wilcox wrote: > On Wed, Aug 02, 2023 at 11:45:16AM +0800, thunder.leizhen@huaweicloud.com wrote: >> +++ b/include/linux/slab.h >> @@ -246,6 +246,9 @@ size_t ksize(const void *objp); >> #ifdef CONFIG_PRINTK >> bool kmem_valid_obj(void *object); >> void kmem_dump_obj(void *object); >> +#else >> +static inline bool kmem_valid_obj(void *object) { return false; } > > That is very confusing. kmem_valid_obj() looks like a function which > should exist regardless of CONFIG_PRINTK and to have it always return > false if CONFIG_PRINTK isn't set seems weird. Yes, I noticed it, but I didn't come up with a good idea. > > I see we have one caller of kmem_valid_obj() right now. Which means it > shouldn't be an EXPORT_SYMBOL since that caller is not a module. > > I think the right solution is to convert kmem_dump_obj() to > work the same way as vmalloc_dump_obj(). ie: Okay, it's a good suggestion. In fact, kmem_dump_obj() also does what kmem_valid_obj() does, except that it will print warning if the check fails. So, do as you suggest, the duplicated code can be eliminated. > > +++ b/mm/util.c > @@ -1057,11 +1057,8 @@ void mem_dump_obj(void *object) > { > const char *type; > > - if (kmem_valid_obj(object)) { > - kmem_dump_obj(object); > + if (kmem_dump_obj(object)) > return; > - } > - > if (vmalloc_dump_obj(object)) > return; > > ... with corresponding changes to eliminate kmem_valid_obj() as a > symbol. > > . > -- Regards, Zhen Lei