[v3,0/7] DAX poison recovery

Message

Jane Chu Jan. 11, 2022, 6:59 p.m. UTC

In v3, dax recovery code path is independent of that of
normal write. Competing dax recovery threads are serialized,
racing read threads are guaranteed not overlapping with the
recovery process.

In this phase, the recovery granularity is page, future patch
will explore recovery in finer granularity.

Please refer to below discussions for more information:
v2:
https://lore.kernel.org/all/[e-mail]/
Disussions about marking poisoned page as 'np':
https://lore.kernel.org/all/[e-mail]/

Jane Chu (7):
  mce: fix set_mce_nospec to always unmap the whole page
  dax: introduce dax device flag DAXDEV_RECOVERY
  dm: make dm aware of target's DAXDEV_RECOVERY capability
  dax: add dax_recovery_write to dax_op and dm target type
  pmem: add pmem_recovery_write() dax op
  dax: add recovery_write to dax_iomap_iter in failure path
  pmem: fix pmem_do_write() avoid writing to 'np' page

 arch/x86/include/asm/set_memory.h |  17 ++---
 arch/x86/kernel/cpu/mce/core.c    |   6 +-
 arch/x86/mm/pat/set_memory.c      |   8 ++-
 drivers/dax/super.c               |  53 ++++++++++++++++
 drivers/md/dm-linear.c            |  13 ++++
 drivers/md/dm-log-writes.c        |  14 +++++
 drivers/md/dm-stripe.c            |  13 ++++
 drivers/md/dm-table.c             |  33 ++++++++++
 drivers/md/dm.c                   |  27 ++++++++
 drivers/nvdimm/pmem.c             | 101 +++++++++++++++++++++++++++---
 drivers/nvdimm/pmem.h             |   1 +
 fs/dax.c                          |  25 +++++++-
 include/linux/dax.h               |   9 +++
 include/linux/device-mapper.h     |   3 +
 include/linux/set_memory.h        |   2 +-
 15 files changed, 298 insertions(+), 27 deletions(-)

Comments

Christoph Hellwig Jan. 20, 2022, 9:55 a.m. UTC | #1

On Tue, Jan 11, 2022 at 11:59:23AM -0700, Jane Chu wrote:
> In v3, dax recovery code path is independent of that of
> normal write. Competing dax recovery threads are serialized,
> racing read threads are guaranteed not overlapping with the
> recovery process.
> 
> In this phase, the recovery granularity is page, future patch
> will explore recovery in finer granularity.

What tree is this against? I can't apply it to either 5.16 or Linus'
current tree.

Jane Chu Jan. 21, 2022, 1:33 a.m. UTC | #2

On 1/20/2022 1:55 AM, Christoph Hellwig wrote:
> On Tue, Jan 11, 2022 at 11:59:23AM -0700, Jane Chu wrote:
>> In v3, dax recovery code path is independent of that of
>> normal write. Competing dax recovery threads are serialized,
>> racing read threads are guaranteed not overlapping with the
>> recovery process.
>>
>> In this phase, the recovery granularity is page, future patch
>> will explore recovery in finer granularity.
> 
> What tree is this against? I can't apply it to either 5.16 or Linus'
> current tree.

It was based on your 'dax-block-cleanup' branch a while back.

thanks,
-jane

Christoph Hellwig Jan. 24, 2022, 9:01 a.m. UTC | #3

On Fri, Jan 21, 2022 at 01:33:40AM +0000, Jane Chu wrote:
> > What tree is this against? I can't apply it to either 5.16 or Linus'
> > current tree.
> 
> It was based on your 'dax-block-cleanup' branch a while back.

Do you have a git tree with your patches included available somewhere?

Jane Chu Jan. 27, 2022, 12:25 a.m. UTC | #4

On 1/24/2022 1:01 AM, Christoph Hellwig wrote:
> On Fri, Jan 21, 2022 at 01:33:40AM +0000, Jane Chu wrote:
>>> What tree is this against? I can't apply it to either 5.16 or Linus'
>>> current tree.
>>
>> It was based on your 'dax-block-cleanup' branch a while back.
> 
> Do you have a git tree with your patches included available somewhere?

Sorry I don't have a git tree, so I rebased the series to 
v5.17-rc1-81-g0280e3c58f9, hope that helps.

-jane