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 C1487EB8FDE for ; Fri, 8 Sep 2023 00:26:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 096406B0072; Thu, 7 Sep 2023 20:26:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 046978E0001; Thu, 7 Sep 2023 20:26:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E29796B0075; Thu, 7 Sep 2023 20:26:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D261C6B0072 for ; Thu, 7 Sep 2023 20:26:29 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A458F160B1E for ; Fri, 8 Sep 2023 00:26:29 +0000 (UTC) X-FDA: 81211538898.28.48FCB5D Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by imf03.hostedemail.com (Postfix) with ESMTP id E8A0D2002B for ; Fri, 8 Sep 2023 00:26:27 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=GJzkN143; dmarc=none; spf=pass (imf03.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.49 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694132787; 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=HVZN5vN8bRfWt9fXaRaMQ7INcbyUKWi7temjOgZW5Mk=; b=VVSY7JAx1/LwMB6iHZaCElRvmyqNe6NHXXXxyipAkGsSDxfQDL3/AAGfBKQ64eGJYqIIIa ih9m6k3Qx9rR91X0zusIb8dBy8m174NFr7MRZerSO+cXLWE2OLwBbpnuui7DE+25VnuV1L 7jRclks/vWsrXpYSpjW0h94ZF45YMe8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=GJzkN143; dmarc=none; spf=pass (imf03.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.49 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694132787; a=rsa-sha256; cv=none; b=uLS8sztD+ULeWIf9Cvgr6Qb4eQUsQYc6/ZEo/2K/hkAPbtjYab41rb7cAe8JNBELGeKPNm ljQcj7yMQSFAi6UKOCba4gSACdRBXv7W7CwtjVYz0tNsAZvwcSQUBmozfL8KH/sRAj/6tA ONn6PW13lq2O829+hhFQmEmwdWDQ+l4= Received: by mail-io1-f49.google.com with SMTP id ca18e2360f4ac-7926de0478eso68616139f.0 for ; Thu, 07 Sep 2023 17:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1694132787; x=1694737587; 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=HVZN5vN8bRfWt9fXaRaMQ7INcbyUKWi7temjOgZW5Mk=; b=GJzkN1430lAXxBLEDN9EaS7oRuK57Dh42lSJ1yVfFazmfisunDc9kwTD32tsAN5EQR Gtf5bFhhtXNFKZzhFBRN7d5dQRGJFDR6uKm/NgN1UVjJGATlyeVQS22EhTyOZm96rBxt jBQ6eiMOCJmAE8LKytA3c03ftr0tRGr1bOads= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694132787; x=1694737587; 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=HVZN5vN8bRfWt9fXaRaMQ7INcbyUKWi7temjOgZW5Mk=; b=ktHEUFLY8PHNjh2a8t0qmPfoUgKEQVUv22Rs4eHax2hHvJmnMhoxOhg7MutvpYjecB QD1Vo8+LSjWPm/7DROE/YV9DJNPZ5fqcpeGW2vVfVDNuaPcZYDkx7g58QYpbBksg4+NU g2lbO4SQ4DD1fvQnc/TkpcpscwQuW/3MSdkC2IlkS7y6CGAM0ZUYBRoJ5i1Crs3LSI/+ WBJhMaI1XapyOa1nkjMbITbczr+UtlQEt8HAKgTIfkgEmnqb9SG8YGYXGAFs7ZRgfp+9 rCx0bT9DvvLbxnsVYyawJ/bmgsRBrhaGiwPk7EFzUu58bC6HJWRgpxo71rnsFGdceLg8 cUDg== X-Gm-Message-State: AOJu0YyY6uLAH1OPtsOSNHynj7bDOObFnocSW66uTxcDzTBjyKTp0tRt Iv+OxBKZvApxAI6eCcUzYptqWg== X-Google-Smtp-Source: AGHT+IFRVFtwWrfcVc0Z7SXHe2h5aZvauo+UgAqJm05OoRDsjuegTeHmvw/xRiZ8zZNk0DTKgvpQMw== X-Received: by 2002:a5d:8048:0:b0:783:498c:9cf0 with SMTP id b8-20020a5d8048000000b00783498c9cf0mr1256406ior.4.1694132787021; Thu, 07 Sep 2023 17:26:27 -0700 (PDT) Received: from localhost (156.190.123.34.bc.googleusercontent.com. [34.123.190.156]) by smtp.gmail.com with ESMTPSA id x5-20020a6bda05000000b0076373f90e46sm168208iob.33.2023.09.07.17.26.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 17:26:26 -0700 (PDT) Date: Fri, 8 Sep 2023 00:26:26 +0000 From: Joel Fernandes To: Vlastimil Babka Cc: Lorenzo Stoakes , linux-kernel@vger.kernel.org, Andrew Morton , "Paul E. McKenney" , 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: <20230908002626.GB4088026@google.com> References: <20230904180806.1002832-1-joel@joelfernandes.org> <20230904180806.1002832-2-joel@joelfernandes.org> <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> <20230905114841.GB3881391@google.com> <737d399d-c83a-3e66-ceb7-4ae7ba4acfb4@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <737d399d-c83a-3e66-ceb7-4ae7ba4acfb4@suse.cz> X-Rspamd-Queue-Id: E8A0D2002B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: pysspo7oia69yoosegm8jbtqoiro6aka X-HE-Tag: 1694132787-255163 X-HE-Meta: U2FsdGVkX1/1S1aC7Hl1eRRWr8mYUwlBYu1lT/Ew4a30dhHbl34VAe8FgzIrMFzOOJE3c6hQMJITKM93tz4lwMXushfEVrhNeEXED1aCRPuBPf5f9AQWT/PowO2AXfVIECwe6ufW1qYB8Rcgr/FAgrWdj3bEArso7U5toTJdhYFp0EM/8CfGa84RzR65+VetQceSC5VK0IjpXEhB/+WTZh4cZlFOc2a9IUguetgqTINjf0tWog9aI+wbtEHWUjSddgJFYa57ePORqCiCqwxL2Z3Q6LUUCEpI2+Yl2kZ4/dtiDNknrmDKBtYhrn0a+WemoqpIl7+wYlAxX09YDBdVsa3c5sTjZcHFQaAWBn8XG+VR5LGzCFVBKqCcOpxLwDTc9kjAGWU7z0CExo47Jsn02ziZ0MttCyP+YbQTiZf5hSQ7KcUKRQiVMptCaUTPnUIJLyeFr8XLwSFyaXIEXHGw2KoOO5u2LEQF4jhrEjbTeAmyWr03VSUN+LsGTTVMtwH0UwRVCnZ4kxoogdMNNXDReYY50C2kFUsBuytE5Mz+R2GzZ3xSC6VOjrgu4PAdqKRUfOd5McXwWbFxFwOXjTFhlA23n05SkKuDm5DYA87j+1PUyGJZ/nvXvsLca23jxR/j9Pp9VFxEf2MQx9I85/fE8+AuQ5/2xotQ+SiDE1hnfAUjKKxCz+ZalUsz9FwCxygiIjqjPcjQqQv78Va3b5ZXWZnS5UfZNIXtf9B5+g6bpSVXBISI9c8gP3k6EYmGc40f0g/dNXVM7Zb9T1lonmb2iAqleU27fWmhfqbO/wAugw75sZF8+6dhctFXnZZ+8f/k6wzViYanxokm/shrUanAl70/WlgM2diaqg0z94MDjOhCHd7ThZhxMGGsKPCWPQsNhyLl7PXpnpzzZHThWV7QeBTAyD0qVZo4zTxuPpE+Lh7EEJamgXiUsJDnybGoDU+arqzdaFmHseXo847ojiv F26Vc45v bLxN6QI21hjn7mFXiIPkZZW18ogD9ug52BOyWD7xtaoajRN/WQqMjz1s0Oo2QCQBouaFNOJ4YdIeXmA8ZFxz7U00dzU+KyC8C/Adj0s2a8F8g4YHUor+OxUCtlXwLYvy+Zj1mhjkAfnwnU2nFgrJzMnSOSz3OTXmq+Pb3ppf9DihQFerlfneNuW5FkTFHwRSaMi54dbiN+X3degWjCHY4/yIw+9TlyIa4KnJn3kCzZJCUChqFAuX2V0k2Y7KOzmzFyKRy7a9AUuqo4X9Q73ZtuYm7knqT9UbjEmuEPZJOkVKUfC5dHfs3RJ2iWAIlTfN99xKfUUm3V6eciHM+Oxblz1daoz+Ud3pri9DmnmTS9SdpHezw3EjLDyJ16oqh9tRLRReAqus/s0h2wbHIp5p3gGeK0y0y82R19MX/a++jgiubTxK5hx6iTEWDKSWyYDQIHA5ESYZP9EGGCK6h0t6CDVSOohbRv+7CZW1uH/e1uFYLRZdatMKg34sjtTOtAWS0a0yZFu/XQ9AFJ3bp8GAmU7MxJ1ic0Vr/TIqHCtzUqtROircKhoCJm6faFrtQ3zp3+HRX3VOpNk9SZVCzwfdkph5jDdOf+1BaAtTvziTKSnPZ7fOySDN9LhETco8yfSwNRJec+v1AKAcP12dlXuFcODKw5AONQd13Nnkx7wDv1kfR8JFj+CwBziDfGiio7OvtdGBb0nw7RsKtc5o= 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 Thu, Sep 07, 2023 at 09:10:38AM +0200, Vlastimil Babka wrote: > On 9/6/23 21:18, Lorenzo Stoakes wrote: > > 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... > > I think it has always meant (but clearly it's not unambiguously worded) "not > slab && not vmalloc", that is before and after this patch. Only in case > patch 1 is applied and patch 2 not, can the output be wrong in that a > vmalloc pointer will (in case of trylock fail) be classified as "not slab && > not vmalloc", but seems fine to me after patch 2. > > I guess if we wanted, we could also rewrite it to be more like the kmem > check in the beginning of mem_dump_obj(), so there would be: > > if (is_vmalloc_addr(...)) { > vmalloc_dump_obj(...); > return; > } > > where vmalloc_dump_obj() itself would print at least "vmalloc memory" with > no further details in case of trylock failure. > > that assumes is_vmalloc_addr() is guaranteed to be true for all addresses > that __find_vmap_area resolves, otherwise it could miss something compared > to current code. Is it guaranteed? It is guaranteed based on my reading of the code. But maybe it may aid additional vmalloc-internals debugging if for some reason the address of the object stored in the vmalloc data structures is out of bound for some reason and the lookup actually succeded. That's just a hypothetical situation though and I don't think that that can actually happen. thanks, - Joel