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 A40BFC3ABCD for ; Mon, 12 May 2025 12:33:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93EB56B00FB; Mon, 12 May 2025 08:33:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8EDD96B00FC; Mon, 12 May 2025 08:33:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B4C26B00FD; Mon, 12 May 2025 08:33:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 48CDF6B00FB for ; Mon, 12 May 2025 08:33:35 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 158A0591C9 for ; Mon, 12 May 2025 12:33:35 +0000 (UTC) X-FDA: 83434196790.19.6359412 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 322178000B for ; Mon, 12 May 2025 12:33:33 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747053213; a=rsa-sha256; cv=none; b=Wzxh71jZsRhQG3b3wwOKJ9SfG0QlO7y0VVgWEnC0WeD+yRIir4/jbqCpu+nFXJmh7xFAHc f/4TlPAQLpbnZbIgINhYoaBYMrapeT9mP61zLivgFL6ZQwniUlrQkTNY5YPAxDVDCC7XD9 cWJBhXq6upvAexRtlD+l6bTl3K9t9+I= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.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=1747053213; 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=3ZOXapXSxILsz0tz3iKOuTxStanObmjL2mIFLW0SH88=; b=RiiuzYmWKycnp/0MGUMbB9UO0qXBophbLeX0v5oUU1UbfDMNGfXu08IqY5XxY5NXPh/tvR FRGXBwVF5XwuGJS8wxsmY1qTOb7L2dY2vHnW1Ek0szoiXRKEIIZDH1ktn+d+/sqDya5Snz wiSoos15shpY77VDrHdO0A/oe5Q7EgM= 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 8AC20150C; Mon, 12 May 2025 05:33:21 -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 1098A3F673; Mon, 12 May 2025 05:33:29 -0700 (PDT) Message-ID: <20e6ac75-6c4b-499b-ba26-cc1a2110509e@arm.com> Date: Mon, 12 May 2025 13:33:28 +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: David Hildenbrand , Catalin Marinas , Will Deacon , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , "Matthew Wilcox (Oracle)" , Mark Rutland , Anshuman Khandual , Alexandre Ghiti , Kevin Brodsky Cc: 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> <001dfd4f-27f2-407f-bd1c-21928a754342@redhat.com> <836f2574-cb60-44c5-865c-7f13a90779ec@redhat.com> From: Ryan Roberts In-Reply-To: <836f2574-cb60-44c5-865c-7f13a90779ec@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: bjq3eef4ko69du7ax13zph33orygair7 X-Rspam-User: X-Rspamd-Queue-Id: 322178000B X-Rspamd-Server: rspam06 X-HE-Tag: 1747053213-578734 X-HE-Meta: U2FsdGVkX1+LhX5C/feSa2dnIYQCWpoVY4z4q64Dg48WN/N1GpSazcEKnkOLBkdkh0iXkNLnK5txQUDF1yI6rs621Q4j0+uNvdMmj3u9LkO+DfJT5s6LknJtyWA3DY0VOE2AZ1h/CkxrYfw1P4hj3y0dFUMi8ZiJwP68v4LEXtxTmZAqiUY7twt0ZZ0wj3ce9oub0Vm4A/cvuR2gxa2RYFQZPeq88GQUoFYvXUNByf4Suh7gcXsZo2/SvZCO3AH5uTSUOq212RHaT7gBPKsJUMHK0RKsHjFKbh0KDmzz10oqv2XOXTbr+m9p0nI1zrFRGW1q9mbWwb5Vu5X4PcDDvCGpmukdFlUSqi2WjUqhzS1/q84+Tqu6uqjzUhTbjWuWFAkixMIl2zwbg8vK2ApzEIOqe8uCocT5zivsdA1AST6BZPjgFw4H4ZBAmU31UH/0WEeHDiQCdM86LaSMqpAlkW3JAmHkA7tq1eOTo4P8ofPXcuTPpEzswdMhaazy0plzA0A6/SwivelmWQC4BnazwEqdIHRXXazjITbhjnbQVy7wioUAJPvO5HJHN2HpJylP9o79HetyDXRQeJN7EWfi6/JMo2ocIhx/DqUDS98Xp6SqEI6sQ8IplcWA+Gn7a+1w94ny2bWL7eedUlAreE4g7q+1ORNFb8XnNZdR+jVZYsP+of2L9L+LHuYqkNd8rARsHImyyHEADG4ajBWEnklCeE52S19nel8Q7T5atyydHIALBvB2Fns9kukJ/THvAoiYOPtgpVXPkp5m0ZTK6Ap6jZepjBi3uK3nAvDUFTtq69K0HBD/+Lmckd4UZHHAs1nruxKpamT7Re/Osb61mhx+L/h5bnTFKf5pNwQ9hZugpoU+rwbc0+v40r28vkhs+zvcEQGtHzy7oehIzrPufsS8VUIs+cJT6S7q/X2DrUIjjyojrA6jC7DVM6yQPGDG3NKpRoADzEyL8SbboxVDhLs 3lclmpzu H2V7pNREMXaShUizkCyS/4DDgSdeveJwDExGceZCxVZih4NO7eSzX7PGqQfkTYwNQq2BX3h0K0xolG3kDOuWvw6FjWmFiiXQD4o6qXo5YQEk1MJcBih+QtKuB38jLnj9AqnEv2PVk3o6Y+aDrwiTTCtmD1lE4AaiznHpAH+TstwfjibrvlBLulmbhT0P2bcYVyWwXPGpJjgwFeKd4Muv7s3Hkxy8sWlm74xyw/6THUSQdjLWqagDDFlIxSIKmG9MzPe6n+EUg/xg0+PA= 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 13:05, David Hildenbrand wrote: > >>>>    static inline void arch_leave_lazy_mmu_mode(void) >>>>    { >>>> +    if (in_interrupt()) >>>> +        return; >>>> + >>>>        arch_flush_lazy_mmu_mode(); >>>>        clear_thread_flag(TIF_LAZY_MMU); >>>>    } >>> >>> I guess in all cases we could optimize out the in_interrupt() check on !debug >>> configs. >> >> I think that assumes we can easily and accurately identify all configs that >> cause this? We've identified 2 but I'm not confident that it's a full list. > > Agreed. I was wondering if we could convert the ones to use different pte > helpers, whereby these helpers would not be available without CONFIG_WHATEVER. > Then, make these features select CONFIG_WHATEVER. Trouble is, in KFENCE's case, there is quite a bit of code between the general API it calls and the pte manipulations: arch_enter_lazy_mmu_mode arch/arm64/include/asm/pgtable.h:82 [inline] (P) apply_to_pte_range mm/memory.c:2936 [inline] (P) apply_to_pmd_range mm/memory.c:2985 [inline] (P) apply_to_pud_range mm/memory.c:3021 [inline] (P) apply_to_p4d_range mm/memory.c:3057 [inline] (P) __apply_to_page_range+0xdb4/0x13e4 mm/memory.c:3093 (P) apply_to_page_range+0x4c/0x64 mm/memory.c:3112 __change_memory_common+0xac/0x3f8 arch/arm64/mm/pageattr.c:64 set_memory_valid+0x68/0x7c arch/arm64/mm/pageattr.c:-1 kfence_protect_page arch/arm64/include/asm/kfence.h:17 [inline] kfence_protect mm/kfence/core.c:247 [inline] kfence_guarded_free+0x278/0x5a8 mm/kfence/core.c:565 __kfence_free+0x104/0x198 mm/kfence/core.c:1187 kfence_free include/linux/kfence.h:187 [inline] slab_free_hook mm/slub.c:2318 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x268/0x474 mm/slub.c:4841 slab_free_after_rcu_debug+0x78/0x2f4 mm/slub.c:4679 rcu_do_batch kernel/rcu/tree.c:2568 [inline] rcu_core+0x848/0x17a4 kernel/rcu/tree.c:2824 rcu_core_si+0x10/0x1c kernel/rcu/tree.c:2841 handle_softirqs+0x328/0xc88 kernel/softirq.c:579 __do_softirq+0x14/0x20 kernel/softirq.c:613 > > VM_WARN_ON_* would be used to catch any violations / wrong use of pte helpers. > >> Also, KFENCE isn't really a debug config (despite me calling it that in the >> commit log) - it's supposed to be something that can be enabled in production >> builds. > > Agreed. Even Fedora has it. > >> >>> >>> Hm, maybe there is an elegant way to catch all of these "problematic" users? >> >> I'm all ears if you have any suggestions? :) >> >> >> It actaully looks like x86/XEN tries to solves this problem in a similar way: > > Heh, yes. Good old xen ... > >> >> enum xen_lazy_mode xen_get_lazy_mode(void) >> { >>     if (in_interrupt()) >>         return XEN_LAZY_NONE; >> >>     return this_cpu_read(xen_lazy_mode); >> } >> >> Although I'm not convinced it's fully robust. It also has: >> >> static inline void enter_lazy(enum xen_lazy_mode mode) >> { >>     BUG_ON(this_cpu_read(xen_lazy_mode) != XEN_LAZY_NONE); >> >>     this_cpu_write(xen_lazy_mode, mode); >> } >> >> which is called as part of its arch_enter_lazy_mmu_mode() implementation. If a >> task was already in lazy mmu mode when an interrupt comes in and causes the >> nested arch_enter_lazy_mmu_mode() that we saw in this bug report, surely that >> BUG_ON() should trigger? > > Hm, good point. But that code is old, so probably something seems to be > preventing that? > > > In any case, just a thought on the in_interrupt() check, I think this commit is > good enough as is. OK thanks. I'll leave it as-is then in the absence of other feedback :)