Message ID | 20230805031726.1230-1-thunder.leizhen@huaweicloud.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp265450vqr; Fri, 4 Aug 2023 21:44:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFBA780y1FAxZWy2LnLmnQ//6yqZZBhXRbATLRXxbIxVS2aFsU/i71rAoMZHl811+odZx4R X-Received: by 2002:a05:6871:b23:b0:1bf:4f42:de9d with SMTP id fq35-20020a0568710b2300b001bf4f42de9dmr4981932oab.42.1691210683974; Fri, 04 Aug 2023 21:44:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691210683; cv=none; d=google.com; s=arc-20160816; b=zgvOlhwOhqP1z+NfaofDTv8yX1jiyAIKpf9uCr7UehjpU3TI12KeKC3BiOcesE+PPK EFHjJpLORtS1eCAh/Z/v6W14r/5QOBj8ovNJRPyMwOLVjBF/fgq4siv6VkR4g6NVnlCD neqcoYV00RrSRRjyMvRQUyUVh9Pnyw+8WhUd0Y+khR43Rb/aUpPflblQgc5CSKGGPVUC +7JjB0drukGlcf7OQ4KKPLDagaV9+iM1AP1U878E/sbdC2SKsx6BeokiGOrb7NyjDo+0 bN3rT+pUhQoSeeoMJ6yOTWfwEA7fnxldmkU2iQhCY+ltiYykuTPAiyjEiOjOVr7NnuzO kfXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=5lbVtJ38zoj6WWnS0l5uqhOfVFbkWu4GVLq9WSdTSYc=; fh=ixpq6thPVOOZuciljZRZ5gp6/ROsGXjbN7hNRM43S+c=; b=gpVpy1X/NyUO1c0WscBR24oMWVO6ncZGeH4mXm/gqQsc5JpmRS9pQExMlyNaPxAbyr qmHY6/OCW/uYVMHmyX7TaTUir9OVxbn3uc8qApfaV0r7W4mgPjTh7H1Ncvqr+Meidj2V cJnpCN7AnShzsCML/+Wabsrt/ogJ/wLQqEQ8sQ84X23NzRNk2owNSwBBm0rV1CryRVfT CXt1IQ/+EcZULMeNx9peR4jPua/YD31XcSu03P1sv4UxkovM28EMuHnBvohpSWAZ8Bdb /odFhMFJsDSHJ9rxxIRz58tOWdf1/v3bTnehLSM/SKDqJ9DKVf4oWHXapgq91BkLylwi 5QLA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m15-20020a17090a668f00b0025bb4a1c12esi2782439pjj.148.2023.08.04.21.44.24; Fri, 04 Aug 2023 21:44:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229544AbjHEDVA (ORCPT <rfc822;liqunnana@gmail.com> + 99 others); Fri, 4 Aug 2023 23:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjHEDU6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Aug 2023 23:20:58 -0400 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F13B24ED6; Fri, 4 Aug 2023 20:20:56 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.30.67.143]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4RHnsc5Kfvz4f3lfp; Sat, 5 Aug 2023 11:20:52 +0800 (CST) Received: from huaweicloud.com (unknown [10.174.178.55]) by APP4 (Coremail) with SMTP id gCh0CgAHoZQRwM1kZdNePg--.61999S4; Sat, 05 Aug 2023 11:20:52 +0800 (CST) From: thunder.leizhen@huaweicloud.com To: 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, "Paul E . McKenney" <paulmck@kernel.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>, Steven Rostedt <rostedt@goodmis.org>, 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 Cc: Zhen Lei <thunder.leizhen@huawei.com> Subject: [PATCH v7 0/2] rcu: Dump memory object info if callback function is invalid Date: Sat, 5 Aug 2023 11:17:24 +0800 Message-Id: <20230805031726.1230-1-thunder.leizhen@huaweicloud.com> X-Mailer: git-send-email 2.37.3.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgAHoZQRwM1kZdNePg--.61999S4 X-Coremail-Antispam: 1UD129KBjvJXoW7ZFWfJry8Cw4rJw18XrW8WFg_yoW8Zr18p3 ZxW3sxWr1DJry3CF1fZF1xCry5Zay8GFsIk3ZxZw4kuw1YvF97uF97Jr1IqF98GF93K3Wj ya1Y9F1jka1DZrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6r1S6rWUM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7M4kE6xkI j40Ew7xC0wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_Wryl IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07 UKfO7UUUUU= X-CM-SenderInfo: hwkx0vthuozvpl2kv046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773358858643635962 X-GMAIL-MSGID: 1773362934374257828 |
Series |
rcu: Dump memory object info if callback function is invalid
|
|
Message
Leizhen (ThunderTown)
Aug. 5, 2023, 3:17 a.m. UTC
From: Zhen Lei <thunder.leizhen@huawei.com>
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 <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.
Zhen Lei (2):
mm: Remove kmem_valid_obj()
rcu: Dump memory object info if callback function is invalid
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(-)
Comments
On Sat, Aug 05, 2023 at 11:17:24AM +0800, thunder.leizhen@huaweicloud.com wrote: > From: Zhen Lei <thunder.leizhen@huawei.com> > > 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 <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. > > > 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 >