On Mon, Feb 17, 2025 at 04:07:49PM +0800, Tong Tiangen wrote: > 在 2025/2/15 1:24, Catalin Marinas 写道: > > 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. > > You mean to use the same exception type (EX_TYPE_KACCESS_ERR_ZERO) and > then do different processing on SEA errors and non-SEA errors, right? Right. > If so, some instructions of copy_page() did not add to the exception > table will be added to the exception table, and the original logic will > be affected. > > For example, if an instruction is not added to the exception table, the > instruction will panic when it triggers a non-SEA error. If this > instruction is added to the exception table because of SEA processing, > and then a non-SEA error is triggered, should we fix it? No, we shouldn't fix it. The exception table entries have a type associated. For a non-SEA error, we preserve the original behaviour even if we find a SEA-specific entry in the exception table. You already need such logic even if you duplicate the code for configurations where you have MC enabled. -- Catalin
