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 62D8FC04A6A for ; Sat, 5 Aug 2023 02:30:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 868E68D0002; Fri, 4 Aug 2023 22:30:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 818D28D0001; Fri, 4 Aug 2023 22:30:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E0AB8D0002; Fri, 4 Aug 2023 22:30:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5A8618D0001 for ; Fri, 4 Aug 2023 22:30:21 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0D6811A0613 for ; Sat, 5 Aug 2023 02:30:21 +0000 (UTC) X-FDA: 81088471842.24.B52C0A6 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) by imf09.hostedemail.com (Postfix) with ESMTP id 3C5C1140023 for ; Sat, 5 Aug 2023 02:30:16 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=none; spf=none (imf09.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=1691202618; 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=Obl9zYeWA19aTO6N0HXxQW061ByiTF7jKft/3/uVwGY=; b=YmX8cp+23583k7rJTbEoOxotCIsK6OU4bv1zWaOFFrDCW3954eMjLhcRyYzr1DEur1P4pg YCZgvip/gLkgXQtzyqSp6KrvdZEP404jDb8VCpYyeJ8C3nNhZymzfcfRKm4B/f/6TRidr7 sXPA0PLNZ1hsKzOhPusCSv+O/0McAkA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; dmarc=none; spf=none (imf09.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=1691202618; a=rsa-sha256; cv=none; b=x9gKMXugVNcrG2yUjzHUsYXKG9/NutONsRnJ7pLWXvTYRvtReXLslbslGb5f+coSznxdlo yZKIXdVJQunEtyJLx+AJOwBjNHWNUWRe5LG06czZpOFJ6dAT79I+/OM36lN9amK5Yqfa80 yEv1wvVxX1jRjQnjr5HOwKLYbK/5Z2Q= Received: from mail02.huawei.com (unknown [172.30.67.143]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4RHml61xD7z4f3nJh for ; Sat, 5 Aug 2023 10:30:10 +0800 (CST) Received: from [10.174.178.55] (unknown [10.174.178.55]) by APP4 (Coremail) with SMTP id gCh0CgBH_rEvtM1krxhcPg--.25609S3; Sat, 05 Aug 2023 10:30:10 +0800 (CST) Subject: Re: [PATCH v6 0/5] rcu: Dump memory object info if callback function is invalid To: paulmck@kernel.org Cc: Petr Mladek , Sergey Senozhatsky , Steven Rostedt , John Ogness , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , rcu@vger.kernel.org, linux-kernel@vger.kernel.org, Zhen Lei References: <20230804091136.1177-1-thunder.leizhen@huaweicloud.com> <7af1d3d8-2d51-40a8-8021-0141e4bf1a0e@paulmck-laptop> From: "Leizhen (ThunderTown)" Message-ID: Date: Sat, 5 Aug 2023 10:30:07 +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: <7af1d3d8-2d51-40a8-8021-0141e4bf1a0e@paulmck-laptop> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CM-TRANSID:gCh0CgBH_rEvtM1krxhcPg--.25609S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZw1DKF4UWFyfCw15tFyxKrg_yoW5XF17p3 sxWasxKrn8Xry7Cr1fZr1xCry5ta1fKFsxKFnxZwn5u3WUZr9ayr95Ar4xWa4UGFWxKF1j y3WYyF1qkr15ArDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6r1S6rWUM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a 6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf 9x07UZ18PUUUUU= X-CM-SenderInfo: hwkx0vthuozvpl2kv046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3C5C1140023 X-Stat-Signature: cape49zem6ousjdneo5dtcxch6gb4d7q X-Rspam-User: X-HE-Tag: 1691202616-842557 X-HE-Meta: U2FsdGVkX1+CPLz8mVelRnf7wzxLa/Iol2QEeR50SJxq+H86Aohs0wmC3L0KlyMxqaUbaf/wY9yQzmoP5N1r9sncJbzs2IqdY5NIidUR8z6eLDCJ54hzgQFzaDAZgaacFN21ukE84UT5M325yOx/S0WMFgL2Ju7M8lLuYUmNhRIHzqwWHkzRSZk3kH9Bbxp4pBSHnNhd5gR7BmaVr9MFE0HxTzA7/pSQPBs5wokTteNY+hKUWcfhXAzlsVOfzQqlh+0wpy77+0a3VWdS+5HPAX0OOG7mByhiN1jD5nONL/0h+6l3ZFl8V57I7FVTvvPsIozu61iwq6YgMEhvmujbNrDSzAZG1jFciyUBfMR8UyIZjHD8m3TWeYZjrAioPQLyvj8cr/Zm7mMk/WSoPBwEZFQYPOnTCY89uhNDbn3k2PlbvozI+CKhHTMvVSVIh9j55+OUdRF2GUWgNNOIA8RKTwNjRHwf0zS5rYuhylpbEy4ljOhMl7W2TL3+tvm9vJ+YhqHOZAGXLddbG+UrMn3uBbNjq0He887Cj1uHghQJSd0gkXmNJUm0b0S/J1CRnzBcH7Ftt4vwMMlu+buYILvcqQIQZ9x0QOJf9y+qip84Ma9AKxrh86YuP1s9M2IGNJfENsw7H7YwF5oXkMWlOybIwiV2eSWOyUDqgd6lND1PT0mVYKhIk9qRBiGWYkUXO1GxbvJILDse/AZY9abdK/jSw+MeUYNnVkf6xdSMjuROMGI8LK6rPqVDgNGym14iHR5B1+AGS0CT7gTIAoRTRdMhNDgV+OcgEi2n4+0qYCv98CbOoCDFDi7DZ0sBmVg37a8Kk5fhX/hAGD8Bkn0LL3BCBjnGBJKaTR3aJWoYzkLoRVzCcIfttIRiTmS89c9rIYC8E0qMo8yraXCbWE5n1CR4pnEc3EdpJWdK5w5i++zIEe11u3iuSnsUxawGe7R1IF6xUvzKqpxFaCNfdp/0J3l PhYmaBQQ nQTVP9DqwhholJaMDqUumypcE4fC5WZ+PhLsYWUsSw55JwMvzkWkFmT+i8kupj1Velq50kCSEW1iT6awG+0pDHMq2zvyecG6wGu3SKdQi7vWMaPsMni4ubuuiAyINgFZyEv7JGXgG2Kitd0B+KoQSdE3+N2dmBHX7+Cseqa6h7xjDP00tIYx5ECZzLsQx7ip7fzjDTfJ79SwO721OCviweBcs3NzTu8YHxqz9G7SmXy+n8Bqy4vxd9lR15PZGw8Rp0zgF7G1HvD1cM//hkfPv4AAQeLfrdn0jQXpBUVh+zBxsDLg5sMvKQSYwq/rQanqtJfjRx2/H1qy42SV1h4fAWQpkUsx5Hwz5BG6xPaHmnpjBCDRlzP0k4MhfWbqtqAqUGqBlcR+Uxex2mIpuRBQ3lr2B3A== 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/5 1:31, Paul E. McKenney wrote: > On Fri, Aug 04, 2023 at 05:11:30PM +0800, thunder.leizhen@huaweicloud.com wrote: >> From: Zhen Lei >> >> v5 --> v6: >> 1. Use print_hex_dump() to dump the memory of slab object. >> 2. Add a new dump prefix DUMP_PREFIX_ADDRESS_LOW16 >> 3. Minimize the output width of the offset >> >> v4 --> v5: >> 1. Add Reviewed-by Acked-by for patch 1/3 >> 2. Add patch 3/3: >> mm: Dump the memory of slab object in kmem_dump_obj() >> >> v3 --> v4: >> 1. Remove kmem_valid_obj() and convert kmem_dump_obj() to work the same way >> as vmalloc_dump_obj(). >> 2. In kernel/rcu/rcu.h >> -#include >> +#include >> >> v2 --> v3: >> 1. I made statistics about the source of 'rhp'. kmem_valid_obj() accounts for >> more than 97.5%, and vmalloc accounts for less than 1%. So change call >> mem_dump_obj() to call kmem_dump_obj() can meet debugging requirements and >> avoid the potential deadlock risk of vmalloc_dump_obj(). >> - mem_dump_obj(rhp); >> + if (kmem_valid_obj(rhp)) >> + kmem_dump_obj(rhp); >> >> The discussion about vmap_area_lock deadlock in v2: >> https://lkml.org/lkml/2022/11/11/493 >> >> 2. Provide static inline empty functions for kmem_valid_obj() and kmem_dump_obj() >> when CONFIG_PRINTK=n. >> >> v1 --> v2: >> 1. Remove condition "(unsigned long)rhp->func & 0x3", it have problems on x86. >> 2. Paul E. McKenney helped me update the commit message, thanks. > > I would be happy to take the patch that Matthew and Vlastimil are happy > with, and also the one against RCU. But unless you tell me otherwise, > I will assume that you would prefer me to wait until the entire series > is ready. The best way to tell me otherwise is of course to resend just > those two patches in their own series. ;-) Yes, I also feel this snowball rolling bigger and bigger. Let me resend the two RCU-related patches that we've discussed OK. > > Thanx, Paul > >> Zhen Lei (5): >> hexdump: add a new dump prefix DUMP_PREFIX_ADDRESS_LOW16 >> hexdump: minimize the output width of the offset >> mm: Remove kmem_valid_obj() >> mm: Dump the memory of slab object in kmem_dump_obj() >> rcu: Dump memory object info if callback function is invalid >> >> include/linux/printk.h | 1 + >> include/linux/slab.h | 5 ++-- >> kernel/rcu/rcu.h | 7 +++++ >> kernel/rcu/srcutiny.c | 1 + >> kernel/rcu/srcutree.c | 1 + >> kernel/rcu/tasks.h | 1 + >> kernel/rcu/tiny.c | 1 + >> kernel/rcu/tree.c | 1 + >> lib/hexdump.c | 17 +++++++++-- >> mm/slab_common.c | 68 ++++++++++++++++++++++-------------------- >> mm/util.c | 4 +-- >> 11 files changed, 67 insertions(+), 40 deletions(-) >> >> -- >> 2.34.1 >> > . > -- Regards, Zhen Lei