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 22A4EEE14D0 for ; Thu, 7 Sep 2023 07:10:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 834B6940008; Thu, 7 Sep 2023 03:10:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E4BE8E000F; Thu, 7 Sep 2023 03:10:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6ACCB940008; Thu, 7 Sep 2023 03:10:43 -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 5CD3C8E000F for ; Thu, 7 Sep 2023 03:10:43 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 33C541CAE51 for ; Thu, 7 Sep 2023 07:10:43 +0000 (UTC) X-FDA: 81208928766.10.A824D1C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id F35B0180025 for ; Thu, 7 Sep 2023 07:10:40 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=3AkW0YDd; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=vWb+l5pO; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694070641; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DbVdXW/jNFCFxdW+0x/LfhB7YMcuH/QmkF6mZXOuaLE=; b=VKKLszy8E/MvlSa47yQbw2dy2tRNVuHddZ03wTKNV5qR+wyUNvj4KCsJddmoKkN/HFTZ2F uL1RiaVXbGymr+KEvNC9xbVZme7nVAAHOC/Mbt0PbFeKecdm4VaJVd6QcaTgejfA6NcEpf Nf3TSUo8SyRS4hBKgAxuQMgtPG39BFw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=3AkW0YDd; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=vWb+l5pO; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694070641; a=rsa-sha256; cv=none; b=ewYtLLWiU8i20ZUL7I+UuCaDWfXn8OAOpAR6TMIpnVFe7ABfSP66vcl+xZ+uGrZBjDWdAl +O4hHD5iVGIK5aW2qz71KFheu0ipf3/dXTuwNwvxFThdtxHDzSy2TTkFgeWNssK622EN+N YpD5Miin7mQYqvhPq3sJ+asGp4FhjWA= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 45D511F86C; Thu, 7 Sep 2023 07:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1694070639; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DbVdXW/jNFCFxdW+0x/LfhB7YMcuH/QmkF6mZXOuaLE=; b=3AkW0YDdz/+le3pX62tW9FtHTG97hy9+xiaxNkWWz4qd/7IKfwRUqLtZprB3fdgW9GDEDY LFrgg0Ur4ZlsksnUNEJSaKDkYlfsXc5aiAFCaFJyN9VMpHwJHaZbazm8EnzYx2tb3XR+im I1yAN+SQOBtwGyrpofbtRLJlgDUO2lU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1694070639; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DbVdXW/jNFCFxdW+0x/LfhB7YMcuH/QmkF6mZXOuaLE=; b=vWb+l5pOCouADD9LzFATDdCF4CBnb8ZVlVUDrX4mn6q2mcJltWbN3YfD6sYkyMILlMzFBp ADdgkcIN+z9Pz/AQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 118381358B; Thu, 7 Sep 2023 07:10:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id RUqJA293+WRdBgAAMHmgww (envelope-from ); Thu, 07 Sep 2023 07:10:39 +0000 Message-ID: <737d399d-c83a-3e66-ceb7-4ae7ba4acfb4@suse.cz> Date: Thu, 7 Sep 2023 09:10:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v3 2/2] rcu: Dump vmalloc memory info safely Content-Language: en-US To: Lorenzo Stoakes , Joel Fernandes Cc: 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 References: <20230904180806.1002832-1-joel@joelfernandes.org> <20230904180806.1002832-2-joel@joelfernandes.org> <9e329429-73a5-4926-af4f-edcf9e547101@lucifer.local> <20230905114841.GB3881391@google.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F35B0180025 X-Rspam-User: X-Stat-Signature: pxqqyp86b5zx5wuaytpqd7e4i1bb43nr X-Rspamd-Server: rspam01 X-HE-Tag: 1694070640-528645 X-HE-Meta: U2FsdGVkX18yWCAam9ttv+D28ESYSBuLRqyRn4MekLnhUGQguxZLFu+3cqLW40+b2jNnnGpNeW5PRYVDeLi2M9aM6dtfMvSpjDgogQWg5N+SlEi0UwylxBtt7y1dk/WjAwrgcQgTjcTPQ7dYtpw5OAsXMD1TQvkYmM7qw8A3p6hwhn62P02QzgMupyV0Di+RwwJjYLpVvFc6BS9Qu93kWadtcwQTQ7u3DxB/LoBqNc7uDuzmfRLYDQytfI459aVuHdqYJ0cLNwE4xoWn7SAqNcyr7o+T4zRvlvZboAAIGTfXTCHYuvo72UyCJzLPlqzsmibu60J22+H9qajCxHjjFhI6VfHbC91h7aggLKMTjS+lodPotUJ5kuwy25kcK3lyc/nSSTD4Vb5g+RBKLAF97SsDrYy6K2zLJMm/p2DLQmAKyYElPOEBLkXymby+5ZjOUDgQ2Ek/lW4c33NliZQ1fLypRdW4RS803xvmM3a6jdVOkpczup2uLprLo1crEC71iE1WufOOThzSUnil9AZCXrjtyQlul3HG+9xJNEMk2COppxrq3M6KIYDUM+OMk6soMWEW/40Y5WsMiUxp5SfYvlsqQIvk7Rk6aQvX/CDyMpvT76TYwaO//jS7Jpg+t0HCwKiqk5F8Pzpwalzp/5AnhiaHBzYy066+EQwdSgk9F1x74Aq+Rzpdo35PHeedZ/R4HDG6ev8nTYA3hrSK4V8EFNCFbzmCdFxuDyNZzJRlxcELUxthGrBYakbYsQGjLFnOa5/a6hOYcFBPYN2EwnFrjA3yEhTEyzky4IMYlRjewanowdNjRym7j6OhAX7HLXr1OreyaA1qdztcKxVpe5axDE+3hXhTNQB93pXKtyiCi3oFAZuSRvkqvNy2ZZutuAkxSep2uevD9eV4QJloCuenLWmEBBJf+tBtsLQ67Rl/7xeLUs7tif72D1fe2g1P+ypwcXi2bI8OabIheqqpPeU bq+bT+Ib r03Wk7+z0Jd0wa+WfnuUFHiziwDdh6cVfWxZq1yKeOi44AZgfpo3TiO+R5xy988ypsNHISxt/7hmt45F31M3ucgV6I8epeDWiSUNn8V0ADUdc2ac572yI7xaiAfqv+XjJyAdSRF1uirlF9n40On2DnWxBiBoQq/06clcxOYumarUJr0NgmoBOsho0s+Tz5iohlmsiPWLyOZXOSu8NO4oREZAOUfjDsInhiV2/ythrcybVv9CsfphTQ5lJRBRx82/0Z2lbwfKL7nQOZ9/ZTqgBmdYJcHEEeJWTPwjFNHtndPPYeoHmLvpO2MCC5Lvr2Gl7GcLGeDw3BFYUkUv258W84PvHOBhAzS3bxXBWecD2Amv9RAUZUyRlSCG4YSuBFaQ7IiG6vP+xUZcajyc0pEATvZTZNe2Etl8KU88ONW8JviP5+V5yWliK+sCz5i5ENHoK6Yv3muoEZImZPDY7Cq1VCCfVBxV/zKyDSSkDmAy5Atzufu+NqRy3F+6b1g2Fr6g5UGHUb8GXpZt9Md0iNvRUBLv9WX4wQo2AzDJW2Z2OZoVm6xdhxFRv8Ac0NMKWQqyXjx5OfWWA3koIkg037JEBCin2pdMQd0zlLp6bKLcli8+iwCQ1Qy0T3CcmyOxoAhyQI6drSVC1TPBbft8= 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 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? > 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