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 4FB53EB64DD for ; Fri, 11 Aug 2023 16:07:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D069E6B0074; Fri, 11 Aug 2023 12:07:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C68B56B0078; Fri, 11 Aug 2023 12:07:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0BB06B007B; Fri, 11 Aug 2023 12:07:25 -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 9F21C6B0074 for ; Fri, 11 Aug 2023 12:07:25 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 75EDE14114A for ; Fri, 11 Aug 2023 16:07:25 +0000 (UTC) X-FDA: 81112303650.26.3A23AD5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 9658340033 for ; Fri, 11 Aug 2023 16:07:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fmW+jn6R; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of "SRS0=VRW/=D4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=VRW/=D4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691770042; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LN2IfJKHO4bRp+AlTMOo8Pq1xeczYSKCha/Tg477d4k=; b=r6Gdhzwqwkg8yhX7vo7lISzk4aHyyBIY6+0jye259an/4dNujHWOr+CYHNpugOE56acNT7 iQaUjdytwP89MUFTTrwNmkhHlGlMpNoh+lsMof2FJRBr9SjvvbzAC+xIAfV3mC0I09CHQv 7vinhM5ruZmxqeky35F1p/swT9IKBwU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fmW+jn6R; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of "SRS0=VRW/=D4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=VRW/=D4=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691770042; a=rsa-sha256; cv=none; b=U9FhN9i/1jLlQcJWSc/mE/1lhnxgk/qC+pNbUFWi8i+7qlEyqioMTjiusgAhUBa06YmQ35 bNP6Jhza8OEvphW3r8iV2ZFYVK56dZBo0ksiQZbDPLP9duDVyW6dyxpytL0u6ogll3jaVh mVfdVBh09KXWo5uDjImWZ4ZhW+yITbw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9BA7C616BC; Fri, 11 Aug 2023 16:07:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0125FC433C7; Fri, 11 Aug 2023 16:07:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691770041; bh=6VvrmSIW6cPl+IAjFwpiICETdVuCXpsKWZNGmIpEQx0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=fmW+jn6Rz18nR/ip1Z0weHQbJZNkqd50JJW2gbqh4VUvJWevWUQRxpxM/tm2OQAiL +f70QN5H/8neTlFe+zG3frJn4WgpEAtP4XPW8WmKa7kjgvBUIe8O7NgNHDNLobs1NK IU5Zix8ZOGJiiHT3Hsgjs8neyeWYO5tPc4U0FlLgfABbhx5Y/tDQNX9LTWL4VVhW2z mlnBW1guvxdBvIK5xF1GmV2dFwMbBKwFvJv3XfDDfoZ33zO5c35ZzJ6M7JXU074PyM cq6bNkp14iHu3UrTjiaFRE+BvHg34Mzlu6NBSdIA4Fj3a/5VOO4BAzh1Hu7Q3OAkjx 7MIXQOriZuoEA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 8855BCE0593; Fri, 11 Aug 2023 09:07:20 -0700 (PDT) Date: Fri, 11 Aug 2023 09:07:20 -0700 From: "Paul E. McKenney" To: thunder.leizhen@huaweicloud.com 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, 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, Zhen Lei Subject: Re: [PATCH v7 0/2] rcu: Dump memory object info if callback function is invalid Message-ID: <75ece297-e936-48f5-9daa-35a6bd740f76@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20230805031726.1230-1-thunder.leizhen@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230805031726.1230-1-thunder.leizhen@huaweicloud.com> X-Rspam-User: X-Stat-Signature: raki6mj34wi6u94ag7wj8q6z67or5wqq X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9658340033 X-HE-Tag: 1691770042-778274 X-HE-Meta: U2FsdGVkX18oQlTHL714bHwJpRCAMrkKMdbZSIMntk/A0qPmXkbo5t0FFFqVjbntUUetuXF3+alcUfy9ec8O/Q80oNEk9XwDmLJBlAVpaQimQ9APn/1gAxzn1P7xc92eubzdMUwBn9nPszgCMDsZcUsf2tsL5dwTtP7kVYFMZRdAFvAUZV1V/OA7s7jgqQ4vbFSvqiE3zENZ7vF5odWZ1US0rqT0An+aa/lFx+SnugLl+G2v8nypbkdncFTLVBC5NcKYSH5moD2H2154qS6/uSiciuyKZpQiTKpGchSCyL4KrCqeHXG2ZuDr08dIP/q8AUL4U88tbNYBYHsJF/PiqR8QEK0HsnQH0gDJRP+mTb53XgZ8MFFmxbU0kvL6Efb+y/9G5bOAarBCyhh8wkyXQN+SUVUeGTF1bAQa0fqQleWTvVVO5aIakOvUaEmt0wfWrw7noeXy2FsaooN2v71wfP2ts45IlWv1dnJvuOaQxXS1E2TVDYEcuehGtDYymykV5VHXdwwX8IY6lWSNyKE5JHc0mIl5IGi9bLEE8C6WwTxTGJ44TV6r026yt7z1uWUmSIv2fc+yfOO9LFkKLZEQZlJFU+ysd74kraew9Y/113t/HrVK/QW28Olr/iBIO3gI8tn9x9FGiQj47KvKISIykJ7uGGBv6uqxlFM2E8mIJ89YwbQ0k1neNWtl2ZoM+mRn7iU/MqF2BKJN3QfmQT0hHlT7AaKSqoGg4RyV+E4+m0RiDKJMUFhWNjvVNSnu3nLlqh4ytUiHUvT2a6UjoKndZ76t/I5bdMPzrihtBuA4eFCChAjAqMmaW2/Y+Ba7TJwxjR+3aFOYDAwML1RVl7N49bDDx+j2gHM0SHQIyj5g3KrJF5WWaYUWA1Grctnh3P1ishPR6oC9KX54rm9Rape3JsGVLTomnE11hPXsMZp2Mre+DLEYS7z0wXckrtiRnXqs53Fn+oqJQyPqsYRJnJG v8kcPbps 31wnYukHhF8oahZDCSUrb8jbB03ZhcXt5/zELGFlQv1cV61a3Ar5h0m93f9u4lqxvIoTDXKJfePwxNK2LqEpXVR8ImbOJZjH0omb37L1M66TgQmOx8fsxXtwEdaxlrmWjBWVgSLXIrHkxd0PRkt2dXGp1LFGzdIlGlV9xocBgwA3EnPWGqFuFrZHRdF9HWX0oA7vFmepbD6ruW8F2CsIDcFCT/HKgPlbIXAxoZ8IjQj7j9iHrmgEgwWaDbZMq5sjHNDLzDq4sK0X1dcahTVVOd59W0s6BzkfBCgyLzQUtvgDx0mnxLqTUB3zYhdGYNOnhQ3wJlWydGX0MVmf9/xQn7moUyqoz1IsXE+Nn2yJsICuW3fwwlR940P4VeC4+IbrWLVYlzrOibQYicaBusTP4vBYc5my5my58EkOq3fV6BP9BmGfVKMw7lMeZ2X9jUl7TPCuI8VgW9Vw9ZNetcfTOnHBYY97WjPAiDetsvRLjV3letBVIm41ZktU1lQSXOjZcQnU/sPT73ltnw4upBKNF11nfGOhB/rh9uQrn4bDLt2WysZGkr5DKMCCSZZF7c2Iubbw37ikxChL7AK84apUcERqd7pjf+Z0KqOeo7CMWjnblXLNJMfMrtsUlRC9yK2w9+ILAaACsp6BVYWohafGXVhpRikCgREQ9kvO9AEEOp5e/kfxbqzcDBxl0Rc7ieg97H8ogOngyx07alQeW1gssEvZTtc5rJ3lwGw29U7EIoQ5iWd6uBjdjdEUVa/T+InDXud/tNigrKLn63ozA1zi4kqY+mqTtdLVxqASKzpmOlTAqYAaausxH2BKv+eci/M64B8obP/PFh1i/NgM71ylOU3ih+Q== 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 Sat, Aug 05, 2023 at 11:17:24AM +0800, thunder.leizhen@huaweicloud.com wrote: > From: Zhen Lei > > v6 --> v7: > To avoid snowballing, resend the two RCU-related patches that we've discussed > OK. The remaining three patches themselves do not need to be gone into RCU tree, > I'll send them separately for discussion. > > 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. > > > Zhen Lei (2): > mm: Remove kmem_valid_obj() > rcu: Dump memory object info if callback function is invalid Queued both on -rcu, thank you all! Thanx, Paul > 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 + > mm/slab_common.c | 41 +++++++++++------------------------------ > mm/util.c | 4 +--- > 9 files changed, 27 insertions(+), 35 deletions(-) > > -- > 2.34.1 >