linux-kernel - Re: [PATCH v13 4/5] arm64: support copy_mc_[user]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z698SFVqHjpGeGC0@arm.com>
Date: Fri, 14 Feb 2025 17:24:24 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: Tong Tiangen <tongtiangen@...wei.com>
Cc: Mark Rutland <mark.rutland@....com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
	Will Deacon <will@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	James Morse <james.morse@....com>,
	Robin Murphy <robin.murphy@....com>,
	Andrey Konovalov <andreyknvl@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Vincenzo Frascino <vincenzo.frascino@....com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nicholas Piggin <npiggin@...il.com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Alexander Potapenko <glider@...gle.com>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
	"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	kasan-dev@...glegroups.com, wangkefeng.wang@...wei.com,
	Guohanjun <guohanjun@...wei.com>
Subject: Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage()

On Fri, Feb 14, 2025 at 10:49:01AM +0800, Tong Tiangen wrote:
> 在 2025/2/13 1:11, Catalin Marinas 写道:
> > On Mon, Dec 09, 2024 at 10:42:56AM +0800, Tong Tiangen wrote:
> > > Currently, many scenarios that can tolerate memory errors when copying page
> > > have been supported in the kernel[1~5], all of which are implemented by
> > > copy_mc_[user]_highpage(). arm64 should also support this mechanism.
> > > 
> > > Due to mte, arm64 needs to have its own copy_mc_[user]_highpage()
> > > architecture implementation, macros __HAVE_ARCH_COPY_MC_HIGHPAGE and
> > > __HAVE_ARCH_COPY_MC_USER_HIGHPAGE have been added to control it.
> > > 
> > > Add new helper copy_mc_page() which provide a page copy implementation with
> > > hardware memory error safe. The code logic of copy_mc_page() is the same as
> > > copy_page(), the main difference is that the ldp insn of copy_mc_page()
> > > contains the fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR, therefore, the
> > > main logic is extracted to copy_page_template.S. In addition, the fixup of
> > > MOPS insn is not considered at present.
> > 
> > Could we not add the exception table entry permanently but ignore the
> > exception table entry if it's not on the do_sea() path? That would save
> > some code duplication.
> 
> I'm sorry, I didn't catch your point, that the do_sea() and non do_sea()
> paths use different exception tables?

No, they would have the same exception table, only that we'd interpret
it differently depending on whether it's a SEA error or not. Or rather
ignore the exception table altogether for non-SEA errors.

> My understanding is that the
> exception table entry problem is fine. After all, the search is
> performed only after a fault trigger. Code duplication can be solved by
> extracting repeated logic to a public file.

If the new exception table entries are only taken into account for SEA
errors, why do we need a duplicate copy_mc_page() function generated?
Isn't the copy_page() and copy_mc_page() code identical (except for the
additional labels to jump to for the exception)?

-- 
Catalin