Re: [RFC PATCH -next V2 7/7] arm64: add pagecache reading to machine check safe

From: Tong Tiangen
Date: Sat Apr 09 2022 - 05:24:43 EST



在 2022/4/8 19:11, Robin Murphy 写道:
On 2022-04-08 03:43, Tong Tiangen wrote:


在 2022/4/7 23:53, Robin Murphy 写道:
On 2022-04-07 15:56, Tong Tiangen wrote:


在 2022/4/6 19:27, Mark Rutland 写道:
On Wed, Apr 06, 2022 at 09:13:11AM +0000, Tong Tiangen wrote:
When user process reading file, the data is cached in pagecache and
the data belongs to the user process, When machine check error is
encountered during pagecache reading, killing the user process and
isolate the user page with hardware memory errors is a more reasonable
choice than kernel panic.

The __arch_copy_mc_to_user() in copy_to_user_mc.S is largely borrows
from __arch_copy_to_user() in copy_to_user.S and the main difference
is __arch_copy_mc_to_user() add the extable entry to support machine
check safe.

As with prior patches, *why* is the distinction necessary?

This patch adds a bunch of conditional logic, but *structurally* it doesn't
alter the handling to be substantially different for the MC and non-MC cases.

This seems like pointless duplication that just makes it harder to maintain
this code.

Thanks,
Mark.

Agreed, The implementation here looks a little ugly and harder to maintain.

The purpose of my doing this is not all copy_to_user can be recovered.

A memory error is consumed when reading pagecache using copy_to_user.
I think in this scenario, only the process is affected because it can't read
pagecache data correctly. Just kill the process and don't need the whole
kernel panic.

So I need two different copy_to_user implementation, one is existing __arch_copy_to_user,
this function will panic when consuming memory errors. The other one is this new helper
__arch_copy_mc_to_user, this interface is used when reading pagecache. It can recover from
consume memory error.

OK, but do we really need two almost-identical implementations of every function where the only difference is how the exception table entries are annotated? Could the exception handler itself just figure out who owns the page where the fault occurred and decide what action to take as appropriate?

Robin.


Thank you, Robin.

I added this call path in this patchset: do_sea() -> fixup_exception(), the purpose is to provide a chance for sea fault to fixup (refer patch 3/7).

If fixup successful, panic can be avoided. Otherwise, panic can be eliminated according to the original logic.

fixup_exception() will set regs->pc and jump to regs->pc when the context recovery of an exception occurs.

If mc-safe-fixup added to  __arch_copy_to_user(),  in *non pagecache reading* scenario encount memory error when call __arch_copy_to_user() , do_sea() -> fixup_exception() will not return fail and will miss the panic logic in do_sea().

So I add new helper __arch_copy_mc_to_user()  and add mc-safe-fixup to this helper, which can be used in the required scenarios. At present, there is only one pagecache reading scenario, other scenarios need to be developed.

This is my current confusion. Of course, I will think about the solution to  solve the duplicate code problem.

Right, but if the point is that faults in pagecahe pages are special, surely __do_kernel_fault() could ultimately figure out from the address whether that's the case or not?

In general, if the principle is that whether a fault is recoverable or not depends on what was being accessed, then to me it seems fundamentally more robust to base that decision on details of the fault that actually occurred, rather than what the caller thought it was supposed to be doing at the time.

Thanks,
Robin.
.
According to Mark's suggestion, all uaccess can be recovered, including copy_to_user(), so there is no need to add new helper __arch_mc_copy_to_user()。

Thanks,
Tong.