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 9E6B9EE14D0 for ; Wed, 6 Sep 2023 19:18:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FC358D0019; Wed, 6 Sep 2023 15:18:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1ABDE8D0005; Wed, 6 Sep 2023 15:18:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 074638D0019; Wed, 6 Sep 2023 15:18:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E99A98D0005 for ; Wed, 6 Sep 2023 15:18:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A704FC0F1F for ; Wed, 6 Sep 2023 19:18:49 +0000 (UTC) X-FDA: 81207134778.24.C1DC05C Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf06.hostedemail.com (Postfix) with ESMTP id DBA0F18000A for ; Wed, 6 Sep 2023 19:18:47 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="Oa/k8Dpy"; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694027927; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ld+kZKXpmR6Fg6T3EwuKq7UToW9GAZ6Oid2qQccKGn4=; b=e+l+v73mXU+Dx9gSTjDsYN7GYVAl9tkPFhZEge3wicLTKyvMrhVsHp5DCgH4sODMaYEWsl nbqaLXu3COjHfR9DnJSAq8e0mIl1h8/H/QBrZ1etGF4RT7ZlMLn0TqNGhn19hIrxkb0fo4 xiGGcI7PMyxni13r/wb+Oj5s47A8D5A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694027927; a=rsa-sha256; cv=none; b=K/eZRb8akVCh/VuOTx0d9RM53X24hq0+3QnU9TW2CIkJClyIkP//sb0ThFoPxnplsXYrEW 0nXFpJ+1Ngw4sdhJtHT7unLLfqIZqri43dJWCtEk6F1xNGhoDxgnfxYiIuqcKzNOzMKnVC nIKGJOm7uP3CDbjD+KchgNuDNBeBO1A= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b="Oa/k8Dpy"; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-26f38171174so118549a91.3 for ; Wed, 06 Sep 2023 12:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694027927; x=1694632727; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ld+kZKXpmR6Fg6T3EwuKq7UToW9GAZ6Oid2qQccKGn4=; b=Oa/k8DpymouTe+Z6PT2nl1EC3TSdZ2D69M/b8yNDH+8YDrjuzy/vXwcxZSMfOMPIe4 ycQb2x+d1qcqtwoYYTnbTgRFViPADTJjvk1Xh4TYI0iB6Mz+sL29KVACl9twZm+wTFO8 weR77UoVgjwaeWCOcwLNnf4iXnDSgbywU227Y4/0/lhNbKGullpqHcYDb/UTYHbMldM9 RBt2uUnqw4gFBAKPGWqmxyxVfKD0aMckEnWHPPL1OiBy6JrMaxbiBeBGUk1UFd0/CLMa uxlaX486l6ag7hYLTueSZCEqzfEB7i/jvCIVxPH1VVULIX1m44HyQJqcMbrGtSCnGB2Z 8hpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694027927; x=1694632727; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ld+kZKXpmR6Fg6T3EwuKq7UToW9GAZ6Oid2qQccKGn4=; b=IDlvuX9cNaR7rmEvCJaPjq2u7XRxxkItlbrocw3p9vHmnxwJ73KVbTrEQ7v3G69AMj fIIqAdpxWaD5qpK74fHTlq4RvoXkheXxdisJCZPrgLNrlgYSK4SjouUS9vD5acjyhD4I Ax3XmoCXr9hS9BOfpAxOeq8CAWqCcKzI8e2jtRYoZ5+4qW8WLDsMoAxJY9egK6PK08b+ Dwi/ogeZYqCyjU5n3YgqNbLKe0HWHsIPkryRhPsADgaVHjH/kBzva4bkzga84544KCIs NXeYbsByRp2XthX3MWawIlG/sOYh0PmoXJQnSnhBuqCNDyyWWDe2cymoZ8sR0nBOHyRL 3Agg== X-Gm-Message-State: AOJu0YwaFTYuGftwnh1j7SF5iXglFPOOhg8Gyrvwm7hToqwhpJHgU6Ny In2FDzBODCHfBCLYPayiUcy3Yl8z6nz9OqBBgCo= X-Google-Smtp-Source: AGHT+IFCSbdVUxgWJzLrxfSRiUW/eGGPUL3k2TslBDvsE7l8uuX8RUCbiQ6bvVk/sJCtoLIKnw8hmybmgwnySCP/7jY= X-Received: by 2002:a17:90a:be16:b0:268:29cf:3231 with SMTP id a22-20020a17090abe1600b0026829cf3231mr15346826pjs.3.1694027926627; Wed, 06 Sep 2023 12:18:46 -0700 (PDT) MIME-Version: 1.0 References: <20230904180806.1002832-1-joel@joelfernandes.org> <20230904180806.1002832-2-joel@joelfernandes.org> <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> <20230905114841.GB3881391@google.com> In-Reply-To: <20230905114841.GB3881391@google.com> From: Lorenzo Stoakes Date: Wed, 6 Sep 2023 20:18:35 +0100 Message-ID: Subject: Re: [PATCH v3 2/2] rcu: Dump vmalloc memory info safely To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, Andrew Morton , "Paul E. McKenney" , Vlastimil Babka , Zqiang , Zhen Lei , rcu@vger.kernel.org, Matthew Wilcox , stable@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: DBA0F18000A X-Rspam-User: X-Stat-Signature: jf1iibruw1d4igne8upxiuhp4azrkr3f X-Rspamd-Server: rspam03 X-HE-Tag: 1694027927-684051 X-HE-Meta: U2FsdGVkX1/njKUsVuQzzeIeKS9f3K/9azGeq84BwHmdnqQqOs0lz7v/rrZXYIrMM6E8iT0D9jCDL68q0uFtrOBurH6bTW/CTsvglkl681zlS4ILlp5/Nyvnd/mDRAjXXFbM5qQofdiPEtR+twELAHonFy1CDgwloyjRFmM6ElmcPUURQZGGUsIgACmDjGgaWLdn7+tNfPTGbwQNWqVwtrxBWd+FwauW8Gqq2Bo09g23bQv+7OrflVq6uvxwgGXZyvIDwXPipSOanjbxQdM7jvtczvLhWoKbrP9ljNVSy3EsTGDMFhRkdVRJGskvthC6gVhFTFhWvg6b6QrjWS5xbMOjSMWEQoKuFBrinEDA8QMZX/eUltuDt+ZXVtToU6NFZSToQ0Z4q3FhUDvDTdUujS/SHi8eAT5pzcx1gKmRBk5F+TEgI6EcYqEhXlK+D+8H260W6EMK9UjOPQbD0tcJhx2WxbW1thqyaJ1vXIq9o6eJyJx2dD6ZHiOIbAVuCXkblUX51LSzgYuklXaZWncZUf2PGOzp80E7gO35LgMktz2yKtNfvTr8BIO2MMxHDP068n8AgjTzUW4hOGX2BtV9/0Qm5xK262ARTPjg1erYtj4K06KZ6E1oqMlO/ob6DCHqrCcOASrjaBtJ3nDUDFZO1/Eky6sValp/2XrK5cd3RX+wXlwCDnFSJ32FNuwHGtdjv11OuK96SZJkcJGFKT8VB8d6hfAuMftoAg4JZ62MX+7Yb506QZrXReClssZ+b4ruuU7ptFjMuwcd8W5e6Qj5mrSyjvJgBYIx0GX1D7g34pvU8339PgYKdlO//Tqrs7W4QFLSCnQ/CY94NkwpBiL5cum2qHuS+CtmbTlOa95OUpN01HnRLaJ6MtoiB/wv418gYnKVT1FefXTN3OEFeEYykKzAuVxsrtaKeOGtJH6PeCqNI89mKUkbNYCsZMPdhdIF9zWpipKePpvIdXH1+df X9a6Ff1r qqixkydktKOITS0aFjfv1U92Z/hIvFoSc56B21Sf9bgfRq0LAsoQhhKNrZ1ry564IT95BnS2JHWXrU97iXZzhx04hhViQVN96q60vR6m3u/U1v/m28tWHmOtfSy+y+1nEiTDwX5ndjiLDpPctxzrIfoP7j1WK8dD75xwWllSTnJjFe+8ApmokIhP8ngIqwZ5RDZuEeM7QD/3AMp24ltR20gFm5LnWqVEO5D4+cpm0wSRERUPAVNT4nch6EbNlCGbH6XiN4baRHSEWbW0HRUFEPzrTvXoo17B3aJqkKCwaIYttcVsPHRjVlwKgD7B8JwtpZePGzrN/1dSqnquEoS0tVm65Do40cvQrY07S3FY9Ymb/imJx5hmQQPv0lfEGm3ldTNslg5iT/XVW4yV7KVgrze2kyUF8XiSKb2hQrQ4Tj632snEqGKE1x+f+shAn8vm0dD5K5j+P7uuJTxGCpT8gwkNO6nu9jKTQokdZ67AL/TuYoKBuiOcQZDztsiNrj+WBPmkqD2UZSXU/XRiNlhOSKEbHY6IyblpvZtCkzW6MeZ+tZDZLyr17e7UnXX+9prI+RIMFc33HyjnRclv9PqlSkMVTHmPCBX5YdXYY9J/iWaeTLqIldQ3vnXAQrqfzSmmPHO+ojVurJD2BMHNfoIAAE/y+iZwcJSEY0OPNsZctvtm1t4D+bcCspR+uopBBnCaXz4vA2frOFO7VgdRw1puFpmbs/JAKGPdyKmortx9wxdbq6ayXs3nb1IIj249JgCCngP0+E7gdzpx590Hn4eErtsCNo1uN4O10DNu8eHFYDKow9Tw= 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 Tue, 5 Sept 2023 at 12:48, Joel Fernandes wrote: > > On Tue, Sep 05, 2023 at 08:00:44AM +0100, Lorenzo Stoakes wrote: > > On Mon, Sep 04, 2023 at 06:08:05PM +0000, Joel Fernandes (Google) wrote: > > > From: Zqiang > > > > > > Currently, for double invoke call_rcu(), will dump rcu_head objects > > > memory info, if the objects is not allocated from the slab allocator, > > > the vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock > > > need to be held, since the call_rcu() can be invoked in interrupt context, > > > therefore, there is a possibility of spinlock deadlock scenarios. > > > > > > And in Preempt-RT kernel, the rcutorture test also trigger the following > > > lockdep warning: > > > > > > BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 > > > in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 > > > preempt_count: 1, expected: 0 > > > RCU nest depth: 1, expected: 1 > > > 3 locks held by swapper/0/1: > > > #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 > > > #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 > > > #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70 > > > irq event stamp: 565512 > > > hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940 > > > hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370 > > > softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170 > > > softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0 > > > Preemption disabled at: > > > [] rcu_torture_init+0x1f13/0x2370 > > > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 > > > Call Trace: > > > > > > dump_stack_lvl+0x68/0xb0 > > > dump_stack+0x14/0x20 > > > __might_resched+0x1aa/0x280 > > > ? __pfx_rcu_torture_err_cb+0x10/0x10 > > > rt_spin_lock+0x53/0x130 > > > ? find_vmap_area+0x1f/0x70 > > > find_vmap_area+0x1f/0x70 > > > vmalloc_dump_obj+0x20/0x60 > > > mem_dump_obj+0x22/0x90 > > > __call_rcu_common+0x5bf/0x940 > > > ? debug_smp_processor_id+0x1b/0x30 > > > call_rcu_hurry+0x14/0x20 > > > rcu_torture_init+0x1f82/0x2370 > > > ? __pfx_rcu_torture_leak_cb+0x10/0x10 > > > ? __pfx_rcu_torture_leak_cb+0x10/0x10 > > > ? __pfx_rcu_torture_init+0x10/0x10 > > > do_one_initcall+0x6c/0x300 > > > ? debug_smp_processor_id+0x1b/0x30 > > > kernel_init_freeable+0x2b9/0x540 > > > ? __pfx_kernel_init+0x10/0x10 > > > kernel_init+0x1f/0x150 > > > ret_from_fork+0x40/0x50 > > > ? __pfx_kernel_init+0x10/0x10 > > > ret_from_fork_asm+0x1b/0x30 > > > > > > > > > The previous patch fixes this by using the deadlock-safe best-effort > > > version of find_vm_area. However, in case of failure print the fact that > > > the pointer was a vmalloc pointer so that we print at least something. > > > > > > Reported-by: Zhen Lei > > > Cc: Paul E. McKenney > > > Cc: rcu@vger.kernel.org > > > Reviewed-by: Matthew Wilcox (Oracle) > > > Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory") > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Zqiang > > > Signed-off-by: Joel Fernandes (Google) > > > --- > > > mm/util.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/util.c b/mm/util.c > > > index dd12b9531ac4..406634f26918 100644 > > > --- a/mm/util.c > > > +++ b/mm/util.c > > > @@ -1071,7 +1071,9 @@ void mem_dump_obj(void *object) > > > if (vmalloc_dump_obj(object)) > > > return; > > > > > > - if (virt_addr_valid(object)) > > > + if (is_vmalloc_addr(object)) > > > + type = "vmalloc memory"; > > > + else if (virt_addr_valid(object)) > > > type = "non-slab/vmalloc memory"; > > > > I think you should update this to say non-slab/non-vmalloc memory (as much > > as that description sucks!) as this phrasing in the past meant to say > > 'non-slab or vmalloc memory' (already confusing phrasing) so better to be > > clear. > > True, though the issue you mentioned it is in existing code, a respin of this > patch could update it to say non-vmalloc. Good point, thanks for reviewing! No it's not, you're changing the meaning, because you changed the code that determines the output... This has been merged now despite my outstanding comments (!) so I guess I'll have to send a follow up patch to address this. > > - Joel > -- Lorenzo Stoakes https://ljs.io