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 1041FC001DF for ; Fri, 4 Aug 2023 17:31:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82E6E6B0071; Fri, 4 Aug 2023 13:31:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B6DA6B0072; Fri, 4 Aug 2023 13:31:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6581B8D0001; Fri, 4 Aug 2023 13:31:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 531656B0071 for ; Fri, 4 Aug 2023 13:31:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A9714C091A for ; Fri, 4 Aug 2023 17:31:12 +0000 (UTC) X-FDA: 81087113184.28.9E02344 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id F130040022 for ; Fri, 4 Aug 2023 17:31:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PIUqNuaY; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of "SRS0=PxYb=DV=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=PxYb=DV=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=1691170270; 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=/U/MiIXzotiRtaBQHRXqn15TP0w5xNZVk/AoFja18xQ=; b=vi7INHwXiOSJwvK4NDo0rGwbqt/NLiNDBOQwNa4liXpp3fxfhDjPygbGxi0Q2RJRnQ2cnt ys125C1jS5ZOYUjuEWjVTUSrfxB5rcRXFA2XTKXkYH2keJmGXjl1ZAwmHqU72Xi7taF0x1 8exocy+QRb9HFTwHcszFjtv2IoCOoD8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=PIUqNuaY; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of "SRS0=PxYb=DV=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=PxYb=DV=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691170270; a=rsa-sha256; cv=none; b=0GXVUaZiEQWO/2xaaGlgEsjuIaCidU9VnXHf1vBpYqQS2+qAAmggLHJvk021A+ZlzPw7EP vBp+9BgAF8yKHONw1sv6EOasJQB7hdJXV5gAmLq/u2GyJjzLlyeO11oIlDtPo/G2pUltz1 iVheBCrK3Q5cWvGVle4NM4GMdjbtErg= 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 ABB3D620B2; Fri, 4 Aug 2023 17:31:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08D1AC433C8; Fri, 4 Aug 2023 17:31:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691170268; bh=svLxVh9EeYIhyoGvToGfRdn37hDgyQdFwVgjw2oh8nQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=PIUqNuaYxNoZft5tJIhSnXfn7eaWCdwyqPXcwCtmloo2Z5chJXv8A8XcKrcP/Xh1q 4H/QW+fk25Ia3xV1e/Uo+QeydoCgr5/UNtVbZmgsbo+yIA2nmDuyolv4bzwWMIKzHD q7mx3rdHg1DRuUo8DlH1q7Cz46gNuzK6NyaUM67HawGWpqI/l2QMfyc4g2m/BmJC3S 90WGVQJ4aQEACno7QEdLmnFHS6wGBbOqVUkfJu/SSsZS+m2j8p5TH77DbU1XaZgnM3 KshU0IaBDpQRDGfiyrAx1B9u9PAZw6un+5gsC5Ng6vKoYGyPEiawjpM4vDwAB+sg49 DoUV+5BnZ3M8A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 85710CE0591; Fri, 4 Aug 2023 10:31:07 -0700 (PDT) Date: Fri, 4 Aug 2023 10:31:07 -0700 From: "Paul E. McKenney" To: thunder.leizhen@huaweicloud.com 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 Subject: Re: [PATCH v6 0/5] rcu: Dump memory object info if callback function is invalid Message-ID: <7af1d3d8-2d51-40a8-8021-0141e4bf1a0e@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20230804091136.1177-1-thunder.leizhen@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230804091136.1177-1-thunder.leizhen@huaweicloud.com> X-Rspamd-Queue-Id: F130040022 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 1rz7bmw78qckey396w7qf6pnmqfkeoh4 X-HE-Tag: 1691170269-568404 X-HE-Meta: U2FsdGVkX1+zV7S2ETEd6rndYvqueiHJI4cLw2DTKgg/08mu8HVjzsVrpi8rRChExIJz+ENPw0YLD+T7n0UAVnbMZrhI/eG99Jd2AwqPG8DhRlOl1MFyQcaHMzx6CvzOuT4vtOzBmj2UWL8MCPHldOsXKKaS9SpQG7qnTjhmifgtuPxuZbLXSp3Gfqzg7UAe5H5w/F2Bsp1ansP578UYPbwSz28NExyG5YEWeyJVQg5/Z2eF7kvcET664aZ7hoxPf/eTVe42NgssYO+0omPiq1zTgOzHZvEmMgKFlPNb7tag1ZOGp5Ejar007moO0sYqP5OAQi/bYh+Bi5PcIUdX/0QY9Of3BXXutPaI9xsID3/AhKQ52uhWT67dHS7Sghj9RwbS9xA5enULdUJ+JFg6EMgrAnTYFi5oEG9nMAl5J7o7HA+7BtIGKKAgX3p+adEnORpF2zJ4i4P6yBCkjVrG6p6poXr7PpN3WQFSQIg5hnndB4aBNzZJ5z8GZj4J1IVv5PZVZEwpJ5k2didhepDOXBcZ+4cn9x1RDEhfNMaEFNSoTvOijT/Vgx9JyuF7wdmlohAGXCfk19oN0YdQm+QUVNGWbakbv2wL4E/rsYosLjbK+sJG+W1mK+mlFL80/DiUW8Up9FsHQ+5WV50zlm+q3GSjenQ+oMGQxwQpWb2VktrLdtiQtEWLc1WMeMRBUl6ZqYAKbQ8NFYg67ZS2aucwm+PuTRM9xzPBF/NOeE2rY0Id7zQw6/CG7AEFpEGHSEN3WUrgSoecvno1CXZ9offAyTZ34IgIm69LjZ0FZICJxH2yO99yT4uVCD/gR3/UQImtyEkVoL2CtuVVMoumWSS2kTlJiDeaVvTzPODdcL7JzGB9jA3F23lfFOwyaD9ziP2g1CtRpLyH+4NfhpZRt3XRuZNEUJgJi55mkAz2qosbUralRsn9w6bD2n1GxdztapUyi8Sf0U811ZdTbPiYMT0 YQ4YCeZZ 4FS2fTXUgAONWrHNoMU6gqPE5pJIgeur57do2odmvhN4N6h7scQaoMCtly1mNIMgZB2sbDpaPZd6rIeahYqTSwWW6UK+zkbIQv51jx2E0v3v3Ku32/b4V+BpAN6lAj4OcTCoBibg3j+LjxVjiggk4dpIf6pYH5w3tIRZb7LJPZ4bkCMmEra2ysetWF+06my3AeAHg8D5KK7E70qQpUGfuXDkUdbuzG6y3DFO+7926yybQ4/6+h4RRpq47CfSJLZBcE3e96Bo0C0X60K2RDMqXarFkLraa82itX+tJVOelHZ+JtZJEGLVpsa2rKU9SSgLE3G2tg93c9FwLO54uIcdpeD0bDD9kYLjbAo+RY1f3hpEZHJuPOAGIciW9wMJUcEqSqfsStYDmocyABJEZhcH+GJwGYKtFxCbPfx8bhDY6L2gsi2UDEMV7tJaouwv/2PGIkvN8mIrafxaM7mATkOsaWIhrgowZl7mUxpBpGYt/tifcG2RffgmvvEr4ytpS1n70lysP5hPfoWGX1k8p2Unu+2BTDez+TQqyNq3fYFNmf/BgPt0nXhS16LYjhO6pe1/WkyYZC2j7rSujI+fgTeIatVNGlW9QiJXXWOUvzmWERhWVqSoGM4xm14Fbxq+of/yW3Eg584paNK2QWeyCVlcbMXhW9Jn3nFdz15knxjbBvaOaMYrJdG6/u9nVGQZntb+pGSWXjh3HHqFP9wiDkvWf6srMFwvXbSS/Tbh2AgMtnYMSNS4yyjL4+/JYA0fBhK9HXSgCxXHjPfd6ippHWfxc2gJUcTCFREp9lkGezAn6jllAAnyl9eUVUFJ0khQoQCc1Uae5Z63Oc4a0v9O2AaUch2GNryt073+KQYzN 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 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. ;-) 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 >