From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DB5BA1F8724; Fri, 12 Sep 2025 15:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757689365; cv=none; b=JNch66NasGaYcRlUgfZAUz7JETd0YYmtFE6kASmV7AFvb/43dF6jSgiisYrsuz/PoOgjQBzErHe51F2WTzmg8qtttjniJAF3qwspD89++WvzCXlgielpjKeJPnt7NtV4L4XiJolnNkJU9dtoNTHjEe5HJiIvck0tkrklew3BstI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757689365; c=relaxed/simple; bh=pjxju66cdgbuLH84lLr1f0aB2LRRyXTtvk+w4J2qi2Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kI+hFmO3Czr1ChKSXuwYCe6nntA0FxF481ToIsNnDh19Fp/uykeezViqrKEoMmw7xpxoYf77rKIa/JrECUn9F49iB9RIZ+Q0A6FPr9PoR/pws9FktBM4ulcsXmvM6GlVoPYIJTQxjnT4bMVP/cj0zmH+GpUvPFtvA32CEdhFZhs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 DCD5812FC; Fri, 12 Sep 2025 08:02:34 -0700 (PDT) Received: from [10.57.66.147] (unknown [10.57.66.147]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 558333F694; Fri, 12 Sep 2025 08:02:36 -0700 (PDT) Message-ID: Date: Fri, 12 Sep 2025 17:02:34 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/7] mm: introduce local state for lazy_mmu sections To: David Hildenbrand , Alexander Gordeev Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andreas Larsson , Andrew Morton , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "David S. Miller" , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Juergen Gross , "Liam R. Howlett" , Lorenzo Stoakes , Madhavan Srinivasan , Michael Ellerman , Michal Hocko , Mike Rapoport , Nicholas Piggin , Peter Zijlstra , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Vlastimil Babka , Will Deacon , Yeoreum Yun , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, Mark Rutland References: <4b4971fd-0445-4d86-8f3a-6ba3d68d15b7@arm.com> <4aa28016-5678-4c66-8104-8dcc3fa2f5ce@redhat.com> <15d01c8b-5475-442e-9df5-ca37b0d5dc04@arm.com> <7953a735-6129-4d22-be65-ce736630d539@redhat.com> <781a6450-1c0b-4603-91cf-49f16cd78c28@arm.com> <9ed5441f-cc03-472a-adc6-b9d3ad525664-agordeev@linux.ibm.com> <74d1f275-23c3-4fd8-b665-503c7fc87df0@redhat.com> <248b4623-8755-4323-8a44-be4af30e4856-agordeev@linux.ibm.com> <852d6f8c-e167-4527-9dc9-98549124f6b1@redhat.com> Content-Language: en-GB From: Kevin Brodsky In-Reply-To: <852d6f8c-e167-4527-9dc9-98549124f6b1@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/09/2025 16:25, David Hildenbrand wrote: > >> >> But I do not really expect it ever, since arch_enter_lazy_mmu_mode_pte() >> is only to be called in PTE walkers that never span more than one page >> table and follow the pattern: > > Well, the cover letter here states: > > "Unfortunately, a corner case (DEBUG_PAGEALLOC) may still cause > nesting to occur on arm64. Ryan proposed [2] to address that corner > case at the generic level but this approach received pushback; [3] > then attempted to solve the issue on arm64 only, but it was deemed too > fragile." > > So I guess we should support nesting cleanly, at least on the core-mm > side. Nesting remains a rare occurrence though. I think it would be plausible to require this new interface to be used in a region where no nesting can occur, just like pause()/resume(). In fact, I think this is a requirement if we go for the approach we have been discussing, because nested enter()/leave() calls are not meant to call arch_enter()/arch_leave(), and I really wouldn't want to use a different logic for this variant. > > I guess we could start with saying "well, s390x doesn't fully support > nesting yet but doing so just requires changing the way we manage this > per-nesting-level state internally". > > s390 is trying to do something different than the other archs here, so > that naturally concerns me :) > > But if it's really just about forwarding that data and having s390 > store it somewhere (task_struct, percpu variable, etc), fine with me.  Yes I think this is fine, with the restriction above. The extra arguments are directly forwarded to arch code and otherwise ignored by core code, and unless the arch defines some __HAVE_ARCH... or CONFIG, the extended interface falls back to regular enter()/leave(). - Kevin