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 6C98CC83F33 for ; Tue, 5 Sep 2023 07:00:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 083CB900008; Tue, 5 Sep 2023 03:00:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 034C38E001A; Tue, 5 Sep 2023 03:00:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3EB9900008; Tue, 5 Sep 2023 03:00:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D4E6D8E001A for ; Tue, 5 Sep 2023 03:00:51 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AAE45B39F4 for ; Tue, 5 Sep 2023 07:00:51 +0000 (UTC) X-FDA: 81201646302.13.7B0E763 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf14.hostedemail.com (Postfix) with ESMTP id 9360010003B for ; Tue, 5 Sep 2023 07:00:48 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KN7Vpgvr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693897248; 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=PXyDlNAn3aTmEsTW95GvcdGMYos2arUzMqrBn1clqqU=; b=Vn7LEyc7IAKIdhKaYy0ywYSovnIoxj91mWe9uNULwXsyW/7q2v8M5hl52ZJalYmJRx6OnZ dzbZ8e9xqvhiN9YbhPCp/SJYlqEVFoqnJgAu3giAHS6Jgm7AfTpH1lpRcOWaJw3rYlh9x+ x1X/SQsG2vYb05VRawg0G31fRGHXJOc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=KN7Vpgvr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693897248; a=rsa-sha256; cv=none; b=mlvDKl1gDrhLvjl/upGjSU9SAdrcLgVLj6jf2JPIuAwTqdacvCm1wqw3tVJQnexU/8R56W VOxKmOukJEyT1Vc3RXi+fH3hGACMrjVFknKmTKvTb1OEZyV2MUCpt2L4nGg9gFQCKuqy+Y K4Spu0F+oRISsPELpMrQ1bfcafrGa3c= Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-31c479ede21so1899671f8f.2 for ; Tue, 05 Sep 2023 00:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693897247; x=1694502047; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PXyDlNAn3aTmEsTW95GvcdGMYos2arUzMqrBn1clqqU=; b=KN7VpgvrJw1Jv7JRtkRBRSlzjGcHRCVbZEgDJOjtmpW3XyiBzxWcB9jNYmaIZgIhGJ YNbKs9hoKp6svu6geN4Zviikk9EYdsckrUHyqE5ZDRwXkEpdhLY9AiM8S84ntTHNyFeE WmPxok7rH8OZw1dd+34MrfAH9EM1o5QvZmP8ArSnGrWZDtTZCBY3qmbPDdpQDL7k5OCJ UDmUqfNJKRj9aiYQkDbMKQ6ospkQVvwavYUEqZ9k4Eixoe9ZZ574rVoC+Q3lpnft4Fjx QPM9/ozteSR+iGxOIorQR1rgLkkOazyyzIhgbfUqmoIgUNXP5KDWT2OMHwj8vaCdR4Ji NmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693897247; x=1694502047; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PXyDlNAn3aTmEsTW95GvcdGMYos2arUzMqrBn1clqqU=; b=W/XhMQFrnw2qU3MEZnnebkARPfrD6SquoLYw+o9pDTplkJYki9c0TCB7me0PDYnt9N nSsPOVCzjZvSovDOJJEUWrDbteZbwP4iisPj648//m/EaIArlwtpHJFgYrA2Ky5O3/69 5JMUW75mAtuNux5ODkRbSZW9ir8EZun3By3WWpLYadP/qDZZi4NNiaryUD8kKrx01s3g 5xCtu8nEL7D33p2ufEJrxX1x+yj3J8ECg9S/YRAOP3N5Rk6wwzKKpKt6wTeL+HwupWgy nWSc8k1lXkL8P86Qt564Oz1X7Ki1HU2QWweGYeQZB/pE8a4m+LV6Ex00cTMAopO8yVgF wWoA== X-Gm-Message-State: AOJu0Yx6E21bT0fG3JXHm+wr0GNFlAix5vVoymYXSwqxQ/cts7Ut6E8D pV53KHjhqXIxHPqIB1hOXTk= X-Google-Smtp-Source: AGHT+IEKEbKZfrPdCfjnpm+31/ypyN57DgQ4HIlr4pBsGEOmUoh+hYLzMpfl8Lvumz9Ie9xQTh6RQQ== X-Received: by 2002:a5d:4d49:0:b0:319:6ce2:e5a3 with SMTP id a9-20020a5d4d49000000b003196ce2e5a3mr8470261wru.26.1693897246723; Tue, 05 Sep 2023 00:00:46 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id r5-20020adfe685000000b003143867d2ebsm16569287wrm.63.2023.09.05.00.00.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 00:00:45 -0700 (PDT) Date: Tue, 5 Sep 2023 08:00:44 +0100 From: Lorenzo Stoakes To: "Joel Fernandes (Google)" 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 Subject: Re: [PATCH v3 2/2] rcu: Dump vmalloc memory info safely Message-ID: <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> References: <20230904180806.1002832-1-joel@joelfernandes.org> <20230904180806.1002832-2-joel@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230904180806.1002832-2-joel@joelfernandes.org> X-Rspamd-Queue-Id: 9360010003B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qquufuj18kd7mc4h1xoi7kr9xtyxyp54 X-HE-Tag: 1693897248-419383 X-HE-Meta: U2FsdGVkX1/E1ujFUW9JcMEG+GxeX3Sq8O6e7v+BBjpWY1DP3lN203csOyHqmcvuD2MtUT38Gy78KdW3GmW0+m/Z9koZ0WLyd446zmGZ8lHRhVaoKvuZhCC86oBNcaMcB7mCWXc2Np5H0hW4+CJhHAAXSicHtyOJFxY7iX+KomFUB0ksDG6uWhg+9+M5xO99krT3+BNvb4Bz+psZSaPtEM8YUzioYjprRxbLGELq0kF8lsFW8a4o+J9L2UUrW9NMKKFFKQkw3KN8nc+oMyf2yjw2iaDYOnJgBtNt7op+9Qm8ZEIWS6WwTSvD+UmtIeethn+k0bptFSzgXqIk74S8YnQiYexxpld3vkZXWEROb3pzmmeM9I+RgJ6SetdEBDjsZ3tn5F3rJ6vHhWGxHWipY0EsyrQ40AuVcNDRiRtyLMv0iOyGHge8CNjIpI/Za2FJQL+riPYYgTqKVmWABDaPcYuxx9uoMK2dE0xADBP7wSBf2Nq3Gx3v/iezzvg0MN6imrSzgbQ3kHfJ2g1bcy507QRygNdvZS5SpAxS2Vr8JJGUgAk78LvN+YBtsVi7/vEcTbOWZKtCu8c2gBSoUNH1V/HAs1Or1ym3ZaJxwlPLhV/z0m+dFMYamMoa6zSyylsKkvOjL6Q6TW1VE9dHx7EeOlQHZYyPf2eGNgJpvaXexlRRkXoBa6aHDFeNDXjfNDGg1WW6CYyo4CCLUHA7bJxowp1EJsYA0ugYhD/byIDmklhKJdJnuQH9wwTATC/H0GerNzAoh1h2YuyLfhF+WKKx2yK69dp5x2gv+OhVvDDnb+oArngy1nyMJJ6NmNLIX2PqNr6yt+eRCvO+O4u+MGElPE6uYyWjRWg9XQQN1wuWR2IOzM2y6KK8JHw4SB5jAoZqcaqO6eqjPFwzhAFXStlNt8qtblJ6yI+kjbOO10DyTbnjWF+SKCLSDsm0TR+3rTui+LsSPxT+JvqdVnCUY4p WwvhBCpT B7cPPJdZofBiA5VwQZGcIHQoltWc9nhc8syrBzf16pFWxYMLIFWMyh64sDU09eTTpvQG3LYiYppePxDoWhNlDdyJPjq7vLCLVJUrg5924xBYVw7u8jcDEBveLggEj9lgKrMmzYG1RB+wog+6MEgaVRc4ddCisRZAbS6up+HaPesMc4jIWAVHo48jG/IfgCt5rC5+R1+xOdEMVE6wLjTdH120kJeeUrEcOroqG/du5yXzzi4RToj7hGrLj44Rfz8ecRkRwGnzSLRwu/b49bxb8H508pHmVd+jcqXTG3FohPdDpl4MyTpuNpmVnP62mTgjdmNmKIJ90e/EQQ92O8u/Iy5UM5QOg6zpq2n4+SEkjeXlBOHAG9LSDcjsbdrebpQI6lXcoE0djeGt8cUsmQ5bUg9nAp8nCZnZiY3Sabp+WhroLtR7lOZt3UZT6kTj+wsuKdlOPFK+F3tNuzZIPE2XKzou7k5W/QUem/ukYidB2enMKz9ZVxv7CDYYfjBW5iwGsIWUzlowKM0VvuGzdbNhHJXrJOjt48y+9Pp4tRd+W8tSxO8EMlvyFmIs8uJAIjknBEhTooy+bv1WJyp/wJo/rNE21m8VSmZjd4PYC63PMADsee6O8irEhvL2jD87YZg8pfkZKe7rwDwGNyYCMgMk27Ex4ZkmQ9vz270epYBra1LS+Wk6uLsQisQ5ukcqtBR/yIuX5Gry1IBHWpjtDmSY7EfdKiXTpXKAD+hDs5wGwlZREEWOYQxV0shR3L6H+eSLOAPSNmHgehjEijsr33oz9DiY5ICyu1hC+VOOS 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 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. > else if (object == NULL) > type = "NULL pointer"; > -- > 2.42.0.283.g2d96d420d3-goog >