RE: [PATCH RESEND v6 1/9] pagemap: Introduce ->memory_failure()

-----Original Message-----
From: Jane Chu <redacted>
Subject: Re: [PATCH RESEND v6 1/9] pagemap: Introduce ->memory_failure()

Hi, ShiYang,

So I applied the v6 patch series to my 5.14-rc3 as it's what you indicated is what
v6 was based at, and injected a hardware poison.

I'm seeing the same problem that was reported a while ago after the poison
was consumed - in the SIGBUS payload, the si_addr is missing:

** SIGBUS(7): canjmp=1, whichstep=0, **
** si_addr(0x(nil)), si_lsb(0xC), si_code(0x4, BUS_MCEERR_AR) **

The si_addr ought to be 0x7f6568000000 - the vaddr of the first page in this
case.

Something is not right...

Hi Jane,

Sorry for late reply.  Thanks for testing.  This address should have been reported in my code. I'll check why it's finally nil.


--
Thanks.
Ruan.

thanks,
-jane


On 8/5/2021 6:17 PM, Jane Chu wrote:

quoted

The filesystem part of the pmem failure handling is at minimum built
on PAGE_SIZE granularity - an inheritance from general memory_failure
handling.  However, with Intel's DCPMEM technology, the error blast
radius is no more than 256bytes, and might get smaller with future
hardware generation, also advanced atomic 64B write to clear the poison.
But I don't see any of that could be incorporated in, given that the
filesystem is notified a corruption with pfn, rather than an exact
address.

So I guess this question is also for Dan: how to avoid unnecessarily
repairing a PMD range for a 256B corrupt range going forward?

thanks,
-jane


On 7/30/2021 3:01 AM, Shiyang Ruan wrote:

quoted

When memory-failure occurs, we call this function which is
implemented by each kind of devices.  For the fsdax case, pmem device
driver implements it.  Pmem device driver will find out the
filesystem in which the corrupted page located in.  And finally call
filesystem handler to deal with this error.

The filesystem will try to recover the corrupted data if necessary.