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 AAFF3C3ABC3 for ; Mon, 12 May 2025 13:53:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C29BB6B0141; Mon, 12 May 2025 09:53:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD7716B0142; Mon, 12 May 2025 09:53:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC75B6B0143; Mon, 12 May 2025 09:53:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8D4C26B0141 for ; Mon, 12 May 2025 09:53:16 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 583EC161330 for ; Mon, 12 May 2025 13:53:17 +0000 (UTC) X-FDA: 83434397634.02.4AA627C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP id 50B041C0011 for ; Mon, 12 May 2025 13:53:15 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747057995; 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; bh=LI4CXmwfkUBuHNzkkeGcyn8vqgVoXk3iadfVRqdZ1ak=; b=TC1irdY5aXcK3Uetv6A+eOZmew0I8C4pTWHsiTd6U11xlGLxs2vBganb8IqDhzPhxae+Md YjkNa0YJcYldKwYln+0kGdu3HkT7yoaLfSP9HwGHGED8kuUbgVJD5XoJN7YbKqqKPjX3JL WWdA+UgKQyN9U7l2H7+G+OFZPl5/h4k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747057995; a=rsa-sha256; cv=none; b=ZRkBMykZSJEXjCIzeXLY4TXIN73owGEf2iXfdqD24oZmeSj7i725H2BfyxtFtl7QZTx3OY xBEl98yFL04puFaaB1r3vcIHD5AhterhAsqp2s/kLyyS3MmnT+teiX3CYCkHyz9Tc7jN8w guPN5UlFdGnVhplyhRGvOBWP110jGl0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 59A05150C; Mon, 12 May 2025 06:53:03 -0700 (PDT) Received: from [10.57.90.222] (unknown [10.57.90.222]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B76E63F673; Mon, 12 May 2025 06:53:11 -0700 (PDT) Message-ID: <7852c047-e8da-44d4-8220-68c2ebca5206@arm.com> Date: Mon, 12 May 2025 14:53:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64/mm: Disable barrier batching in interrupt contexts Content-Language: en-GB To: Catalin Marinas Cc: Will Deacon , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , David Hildenbrand , "Matthew Wilcox (Oracle)" , Mark Rutland , Anshuman Khandual , Alexandre Ghiti , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+5c0d9392e042f41d45c5@syzkaller.appspotmail.com References: <20250512102242.4156463-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: zk15b43uska6shqch18dtfhbemn6epf5 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 50B041C0011 X-HE-Tag: 1747057995-963144 X-HE-Meta: U2FsdGVkX1+QuwehNiMQAan9TB+f39tZ5wLjdBouorqhm6aFdLKHafmNTVKXHxV84TWKT6NfZ1D0ujrNLkmAMTNoJ4byT2Q32HHmYxJBGYZBhLWZ9aPjuRuJO/R4h1qzp/GrQVIS8Qn8d4TxfXmCyA+ulkUpgyNDh/vPOupNxQSkhe6HmyNf2UcAdjZSQrHxq3yo58fZ7d1BH+ZU4T0DkMKJVeA6nxO8VVRS9uEkIdav3dEllrgDXVQgWypOhP36UZTndZXtRyabDk0FuN8XI56WuddZfsZ/IiD5kmHgN7g8R9S54m5lgNoIJDIOkATHyHKzZnGybOwMaIPcVWYtLoIHZTZZbF0lFlBfdh/52QRpmk4/MFy93rhaiB+uHRAFm8v6syAQZA4IhX6KetqPPXLNzMDIpIY86YdqqbaXIIZ+xA08KC/xRDS3ph7SOTyaI0oFVwDZ8H7DAW+5Ulh7Ycv4wNpVXuEdalmm8mNpJSwN+mnyHf7PFnoceTkWVdNRZinKleCX23/TImUp4/zHdBz0xs2bqmJnBdyh83puMUzeXjzUun8+qcQwVRAJS8swHP1amD7DXalcOa15SfNMAdw9X7nfcSKfbg1xvKVvHsNsdxRA4o4d6qBS4iZMna/+0hez1SJ0q6gxzb/4XNdJGVAnJ0kPhYPdGLsTTvQZchWhzY5Vk6bX5rc+YPoRa6Sitl5eK0tKfYUrEGIkVPt2pHoOwSQNvmlYFQo46swN2NYV9l1fJLsarbaNuiGDtKsSFLJEoiCCth405GtVw2jQdIW47BkM5IfUY5dUc8c8wgsutFhVUhM9nLJnR7iOeerWYNh2ZzM4TA87QJjbNcT8RmG+I0sC6xu6oDC+M8Fbo3qCiFi1/xJUsIMYmZIzSL/sK9kozTO97mYXJf7DQRLtLgn1TTAz3bl4s11JOw8ngOEZnm9Yl10d0+LnOhND5s6Rs2KUX7mlXhdMQEJWVgz SP3VGTWD itWAUyTgrdwucZGSAJOU33EnkZ5Nb3fXmOQznSTh4aTMlPiZWTN1GMPnYuMWsn/r2LN/u4XdHzgKEKZtXiDGt4ILFJWbexqMwMgc0CDc64n97arf08WZuJniTnNsd+D6inmpibfMOL4ecFvjwylhVQu31HRnVpmT6Jh01x6jvlzAq7ftBVhCjGGOOzvmMn3vBFEcD3XsQJF0y41iZTtFzCJHHEM5TRvHFr59oiDDSWcH0F/XLDxDtt8cThQ== 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: List-Subscribe: List-Unsubscribe: On 12/05/2025 14:14, Catalin Marinas wrote: > On Mon, May 12, 2025 at 11:22:40AM +0100, Ryan Roberts wrote: >> @@ -79,7 +83,9 @@ static inline void queue_pte_barriers(void) >> #define __HAVE_ARCH_ENTER_LAZY_MMU_MODE >> static inline void arch_enter_lazy_mmu_mode(void) >> { >> - VM_WARN_ON(in_interrupt()); >> + if (in_interrupt()) >> + return; >> + >> VM_WARN_ON(test_thread_flag(TIF_LAZY_MMU)); > > I still get this warning trigger with some debugging enabled (more > specifically, CONFIG_DEBUG_PAGEALLOC). Patch applied on top of the arm64 > for-kernelci. Thanks for the report... I'll admit I didn't explicitly test CONFIG_DEBUG_PAGEALLOC since I thought we concluded when talking that the failure mode was the same as KFENCE in that it was due to pte manipulations in the interrupt context. But that's not what this trace shows... The warning is basically saying we have nested lazy mmu mode regions, both in task context, which is completely illegal as far as lazy mmu is concerned. Looks like the first nest is zap_pte_range(), which is batching with mmu_gather and that allocates memory in tlb_next_batch(). And when CONFIG_DEBUG_PAGEALLOC is enabled, it calls into the arch to make the allocated page valid in the linear map. arm64 does that with apply_to_page_range(), which does a second lazy mmu nest. I need to have a think about what the right fix is. Will get back to you shortly. Thanks, Ryan > > Is it because the unmap code uses arch_enter_lazy_mmu_mode() already and > __apply_to_page_range() via __kernel_map_pages() is attempting another > nested call? I think it's still safe, we just drop the optimisation in > the outer code and issue the barriers immediately. So maybe drop this > warning as well but add a comment on how nesting works. > > ------------[ cut here ]------------ > WARNING: CPU: 6 PID: 1 at arch/arm64/include/asm/pgtable.h:89 __apply_to_page_range+0x85c/0x9f8 > Modules linked in: ip_tables x_tables ipv6 > CPU: 6 UID: 0 PID: 1 Comm: systemd Not tainted 6.15.0-rc5-00075-g676795fe9cf6 #1 PREEMPT > Hardware name: QEMU KVM Virtual Machine, BIOS 2024.08-4 10/25/2024 > pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : __apply_to_page_range+0x85c/0x9f8 > lr : __apply_to_page_range+0x2b4/0x9f8 > sp : ffff80008009b3c0 > x29: ffff80008009b460 x28: ffff0000c43a3000 x27: ffff0001ff62b108 > x26: ffff0000c43a4000 x25: 0000000000000001 x24: 0010000000000001 > x23: ffffbf24c9c209c0 x22: ffff80008009b4d0 x21: ffffbf24c74a3b20 > x20: ffff0000c43a3000 x19: ffff0001ff609d18 x18: 0000000000000001 > x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000003 > x14: 0000000000000028 x13: ffffbf24c97c1000 x12: ffff0000c43a3fff > x11: ffffbf24cacc9a70 x10: ffff0000c43a3fff x9 : ffff0001fffff018 > x8 : 0000000000000012 x7 : ffff0000c43a4000 x6 : ffff0000c43a4000 > x5 : ffffbf24c9c209c0 x4 : ffff0000c43a3fff x3 : ffff0001ff609000 > x2 : 0000000000000d18 x1 : ffff0000c03e8000 x0 : 0000000080000000 > Call trace: > __apply_to_page_range+0x85c/0x9f8 (P) > apply_to_page_range+0x14/0x20 > set_memory_valid+0x5c/0xd8 > __kernel_map_pages+0x84/0xc0 > get_page_from_freelist+0x1110/0x1340 > __alloc_frozen_pages_noprof+0x114/0x1178 > alloc_pages_mpol+0xb8/0x1d0 > alloc_frozen_pages_noprof+0x48/0xc0 > alloc_pages_noprof+0x10/0x60 > get_free_pages_noprof+0x14/0x90 > __tlb_remove_folio_pages_size.isra.0+0xe4/0x140 > __tlb_remove_folio_pages+0x10/0x20 > unmap_page_range+0xa1c/0x14c0 > unmap_single_vma.isra.0+0x48/0x90 > unmap_vmas+0xe0/0x200 > vms_clear_ptes+0xf4/0x140 > vms_complete_munmap_vmas+0x7c/0x208 > do_vmi_align_munmap+0x180/0x1a8 > do_vmi_munmap+0xac/0x188 > __vm_munmap+0xe0/0x1e0 > __arm64_sys_munmap+0x20/0x38 > invoke_syscall+0x48/0x104 > el0_svc_common.constprop.0+0x40/0xe0 > do_el0_svc+0x1c/0x28 > el0_svc+0x4c/0x16c > el0t_64_sync_handler+0x10c/0x140 > el0t_64_sync+0x198/0x19c > irq event stamp: 281312 > hardirqs last enabled at (281311): [] bad_range+0x164/0x1c0 > hardirqs last disabled at (281312): [] el1_dbg+0x24/0x98 > softirqs last enabled at (281054): [] handle_softirqs+0x4cc/0x518 > softirqs last disabled at (281019): [] __do_softirq+0x14/0x20 > ---[ end trace 0000000000000000 ]--- >