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 7A01FC83F33 for ; Tue, 5 Sep 2023 11:48:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF30A94000F; Tue, 5 Sep 2023 07:48:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA2038E001A; Tue, 5 Sep 2023 07:48:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6A9494000F; Tue, 5 Sep 2023 07:48:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A64E78E001A for ; Tue, 5 Sep 2023 07:48:46 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7A7B8140C69 for ; Tue, 5 Sep 2023 11:48:46 +0000 (UTC) X-FDA: 81202371852.15.4484417 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by imf22.hostedemail.com (Postfix) with ESMTP id A975DC0018 for ; Tue, 5 Sep 2023 11:48:43 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=mKSUt8YO; spf=pass (imf22.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.41 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693914523; 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=agO0bHd7pavHNlvZnzfpEMuMb6kyNAGPWGDG3TstaRk=; b=l1X4Y5tTfAQ93omuhXDQD5gUpHAdJRn5jUiHyy/9ySon1ZsUUSSwXYxHdM53ZPBuD3I2kJ BcloR/C3hhYTOakog/cuLttcn6B5+SB5rmd7GeSkwJC9R4vKE6SlrtZlXoCbA2mAzlaoFR /m2pKFhq9KYENUh7fiBbth52Lm64UlU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693914523; a=rsa-sha256; cv=none; b=cc5bAk0JvXTx8mPXjf9Z7b0E4vKaFQkcSwhro823NBl6ANtgq/7aGv+F6BncKM0Oom6Xz8 r0mJkDN9PfFG/oQtR/Gs01C5dseF9WEE/OfqIYiRxWyr1dsWtL5asfIcqhk5eFv1+9vClE T4BRXneuKCfWN7F7SM8Zk+7O/tBbPqY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=mKSUt8YO; spf=pass (imf22.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.41 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none Received: by mail-io1-f41.google.com with SMTP id ca18e2360f4ac-77acb04309dso95280939f.2 for ; Tue, 05 Sep 2023 04:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1693914523; x=1694519323; 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=agO0bHd7pavHNlvZnzfpEMuMb6kyNAGPWGDG3TstaRk=; b=mKSUt8YO63bba0NrbkiOvZLywqTRfGThevjrMBQ+IwxL1ogv162zpSIp8UTqY7Lckr 5rlQpJlxUfbwveTtoXgDSTNkrapznaoaZuy3Iu9K9c/RFrqGGiBx4jfoAOzWnbqehMdY /6gNrFHHKvvy5dD5hIirL8BdWZO8CJslyC9ig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693914523; x=1694519323; 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=agO0bHd7pavHNlvZnzfpEMuMb6kyNAGPWGDG3TstaRk=; b=LIHlyNQpN2W9kWoEHenwVc78PVSSgpRFGBTFZ/MLEODQx1yAqT1/nhCR/jZr5C96mz ZDJCdMN6b+eEgjbVWGfruYe4UTMATajxrBrETbnEqH2f6J32VIcwR8J4gbWyvvRJI04u Q9uEo6mVB44HHFG98SqA+1q32Y97AssXarShQbLiaAiDGg8FjNXDQNG44yNQlxbjgpqI kFDYMPQO5uNNrPBXmfEItujSeYYb6F0U0sSa8e2lRKf11WFYhJNk1UHbdXnC2LN3AnSu Jr3l6sr8eaBpjNqkhNlWRL5nGGF+D7ytLQrmSYC+KfLknSt8hPDzjrgURH1j4RLHmFvm eA8w== X-Gm-Message-State: AOJu0YwOHrpA0njKAubrjhG4EKXhLDL+OcMWcxmGCyydgrym+F3QhNUe qcXewU6MLKy6kCixfDF7EMH0nA== X-Google-Smtp-Source: AGHT+IHZEE0cD6pV/j4gqBPlwyHlFkqwQgME+6G/X3QKzwQ+iv+FZgNev0P/vstjQ/+aqRZo0bg65w== X-Received: by 2002:a6b:6406:0:b0:790:9728:4014 with SMTP id t6-20020a6b6406000000b0079097284014mr14044851iog.11.1693914522842; Tue, 05 Sep 2023 04:48:42 -0700 (PDT) Received: from localhost (156.190.123.34.bc.googleusercontent.com. [34.123.190.156]) by smtp.gmail.com with ESMTPSA id w11-20020a5d844b000000b0076ffebfc9fasm4207490ior.47.2023.09.05.04.48.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 04:48:42 -0700 (PDT) Date: Tue, 5 Sep 2023 11:48:41 +0000 From: Joel Fernandes To: Lorenzo Stoakes 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: <20230905114841.GB3881391@google.com> References: <20230904180806.1002832-1-joel@joelfernandes.org> <20230904180806.1002832-2-joel@joelfernandes.org> <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> X-Stat-Signature: fjp48fjsw61dbh5e17r3zs78k8kp63gr X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A975DC0018 X-Rspam-User: X-HE-Tag: 1693914523-985924 X-HE-Meta: U2FsdGVkX18P7QsWcGfvZj/x55B0MyQQoZwPRwhJVb+ylVfQGYKAaysfQO+AJ0afO7h/lGCWZ0idYyQuj7YvVbErpL7QP9t3qieWfRorag07gquMi6W65KAhzbb1X6mekEG2SK5Me2PBbo/DQhfacokGu8Tt17yqXCjNFFNo6XC1Oolvq5euJb8WzTsMuaX2TuRpk7Qs4q8/RyuKi8x/JKjIgyYSaowMMxrikPeLRMRRAPkBg7bN4iXgM6UtXvd9oVfuowfKLnhmwUKAcHbpbtOdXvsVD1V1xH1kWU1eCXNm+vEBWebm/FqA6EDqR+EoiTDemUgCrGqDap1O7dLNKNKkJ/Wy6CXTaud5p514JhqN2c/D/BSBb4sDaVPw/11TrfxX3HYPgFU2ZEZU4s11MZcGtxJfYoMzI1IIFQN+STRj0zBhInSM1d3fmJiZDHNKubksMqbT0bjRUm0UxBRt6fZFwQQi58UBBcxFsnIPeyic8yDEs3Upjkmqgrd0mHiYbyyHCTsI7ffe5O3kQnCp/pwZLeopkNyetKF+H8lK6Xf40v6Q0dKgfA7wLGT7RlB//+YxuEBnfxBW0Mhm/6/OCt6NKlAmRNOq6E49TozjtJQrvz5mw25NBYaKAP/B+NhhFphco3LSb81TzGzgD6JAfVhcHTULZ6Gw3jSXZT8nB25WVw3XlhkiROJPSnbzMgxj/0fyME2QbuEEWFY0ZKmw+v/4lx0+iYmsVUMAKiIxFtSR6ffzfugmPHCx+azPPMo8a0/X1tnC6oQdL2zxCuhwSbqwmlOgs63Mm6OKPpR2k5tx9xQtr0LV8MbLHeTIYsejhg1LMJ/z0wA4X1sX4706Ohl1tGtByTiI+Ipsd54yGxpUY8oVBM3+yg8KpAuIvYPbDeFxJH4k5L+FwtgvjfDzsKKO7Uw9XvFFBjhQMtvzf+Z3WBVRlDcIp5Fd7MOGK9SoLXHQyZ1H7tb4UrAxlz6 Gdrwylfx rZqY1g11VCDCaysz5rUI3siwJzMUQxSY6eTOu0BS8pVSqBC1ubeMp4plAVxsAMXSXv2Q66S83I4C8B7osZZSXrDngj5iDcFirJgQGfDXRnbMIW+M/AyRVpTnM8L+7BVPUwCrIiNK3cuK1yaDW6yIhu5AYUyjsVrPZqVp95X1/1p3HghJ8OzFaPpTlJqmmpAGB4VmBIsrDd8ODZmbVGPt1xTAB00WhnWNx2Nz4pAMHGqmLoWRhsLJxlwQjf4q+Os2ERYSikMPpCuOvrWu/TaV4Bj3SZ/McdE0IUrqsObA8t7vsrg7RfS/4FEbC/N2gqOZq8QEExX0SnqqXBHo+UesRhOGXKxnX5cMTZQuvX+kn4wHTLuS8EcTVS2r38dpelk6LZqnZfKc0wVNwzE354OXN9JZvHpS/ZGWxJznQPLa9uVJ8T3AAikw3XnuoH4ZnmQh8kY5IVT0O5ggHd/BcZge4RJInPToCmr6ANarwU9ftCpllgr0Tvx8IpEasIjHbrUcKmN/rxksllLuy9mYP0jSUQnQ07y41+hiaj+N57j3cw4MVUcfhao4HMYUEUg7eVqD5aeKuFLRBcnVP84b7+BTVLFFuyarPNIVUPxN5NLSyzzUMiZWc+vJkEFgTu0e2lMFnFCEsESK/j3qHigwglwmO04rXAUq5ygMY44+cPVZHinXa7ZYA/iPBMoGB4OM2K/uiKaqF/q8lxxYESa4= 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, 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! - Joel