Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage()

[Tong Tiangen <tongtiangen@huawei.com>]

在 2025/2/17 22:55, Catalin Marinas 写道:
> 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.

Ok, now we have the same understanding.

> 
>> 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.


So we need another way to distinguish the different processing of the
same exception type on SEA and non-SEA path.

For example, using strcut exception_table_entry.data, the disadvantage
is that it occupies the future expansion space of data.

I still think it's better to use methods like copy_from_user.S and
copy_to_user.S calling copy_template.S, and the duplicate code in
copy_template.S.

Thanks,
Tong.

>