From: "Paul E. McKenney" <paulmck@kernel.org>
To: thunder.leizhen@huaweicloud.com
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org, Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun.feng@gmail.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhen Lei <thunder.leizhen@huawei.com>
Subject: Re: [PATCH v6 0/5] rcu: Dump memory object info if callback function is invalid
Date: Fri, 4 Aug 2023 10:31:07 -0700 [thread overview]
Message-ID: <7af1d3d8-2d51-40a8-8021-0141e4bf1a0e@paulmck-laptop> (raw)
In-Reply-To: <20230804091136.1177-1-thunder.leizhen@huaweicloud.com>
On Fri, Aug 04, 2023 at 05:11:30PM +0800, thunder.leizhen@huaweicloud.com wrote:
> From: Zhen Lei <thunder.leizhen@huawei.com>
>
> 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 <linux/mm.h>
> +#include <linux/slab.h>
>
> 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
>
next prev parent reply other threads:[~2023-08-04 17:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 9:11 thunder.leizhen
2023-08-04 9:11 ` [PATCH v6 1/5] hexdump: add a new dump prefix DUMP_PREFIX_ADDRESS_LOW16 thunder.leizhen
2023-08-04 9:11 ` [PATCH v6 2/5] hexdump: minimize the output width of the offset thunder.leizhen
2023-08-04 9:11 ` [PATCH v6 3/5] mm: Remove kmem_valid_obj() thunder.leizhen
2023-08-04 9:11 ` [PATCH v6 4/5] mm: Dump the memory of slab object in kmem_dump_obj() thunder.leizhen
2023-08-04 9:11 ` [PATCH v6 5/5] rcu: Dump memory object info if callback function is invalid thunder.leizhen
2023-08-04 17:31 ` Paul E. McKenney [this message]
2023-08-05 2:30 ` [PATCH v6 0/5] " Leizhen (ThunderTown)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7af1d3d8-2d51-40a8-8021-0141e4bf1a0e@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=cl@linux.com \
--cc=frederic@kernel.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=john.ogness@linutronix.de \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=penberg@kernel.org \
--cc=pmladek@suse.com \
--cc=qiang.zhang1211@gmail.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=thunder.leizhen@huawei.com \
--cc=thunder.leizhen@huaweicloud.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox