linux-kernel - [PATCH v2 0/2] Dax poison recovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri,  5 Nov 2021 19:16:36 -0600
From:   Jane Chu <jane.chu@...cle.com>
To:     david@...morbit.com, djwong@...nel.org, dan.j.williams@...el.com,
        hch@...radead.org, vishal.l.verma@...el.com, dave.jiang@...el.com,
        agk@...hat.com, snitzer@...hat.com, dm-devel@...hat.com,
        ira.weiny@...el.com, willy@...radead.org, vgoyal@...hat.com,
        linux-fsdevel@...r.kernel.org, nvdimm@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: [PATCH v2 0/2] Dax poison recovery

Up till now, the method commonly used for data recovery from
dax media error has been a combination of hole-punch followed
by a pwrite(2). The downside of this method is that it causes
fragmentation of the pmem backend, which brings a host of
very challenging issues.

This patch is an attempt to provide an alternative way for
dax users to perform data recovery from pmem media error without
fragmenting the pmem backend.

Dax media error may be manifested to user process via SIGBUS
with .si_code BUS_MCEERR_AR when a load instruction consumes
a poison in the media, or SIGBUS with .si_code BUS_ADRERR when
a page fault handler fails to resolve due to existing poison
record, or IO error returned from a block read or write.

With the patch in place, the way for user process to recover
the data can be just a pwrite(2) to a page aligned range without
the need to punch-a-hole. In case of BUS_MCEERR_AR, the range
is incidated by the signal payload: .si_addr and .si_addr_lsb.
In case of BUS_ADRERR, the range is the user mapping page size
starting from .si_addr. If the clue of media error come from
block IO error, the range is a stretch of the block IO range
to page aligned range.

Changes from v1:
- instead of giving user the say to start dax data recovery,
  let dax-filesystem decide when to enter data recovery mode.
  Hence 99% of the non-dax usage of pwrite and its variants
  aren't aware of dax specific recovering.
- Instead of exporting dax_clear_error() API that does one thing,
  combine dax {poison-clearing, error-record-update, writing-good-data}
  in one tight operation to better protect data integrity.
- some semantics and format fixes

v1: 
https://lore.kernel.org/lkml/20211029223233.GB449541@dread.disaster.area/T/

Jane Chu (2):
  dax: Introduce normal and recovery dax operation modes
  dax,pmem: Implement pmem based dax data recovery

 drivers/dax/super.c             | 15 +++---
 drivers/md/dm-linear.c          | 14 +++---
 drivers/md/dm-log-writes.c      | 19 +++++---
 drivers/md/dm-stripe.c          | 14 +++---
 drivers/md/dm-target.c          |  2 +-
 drivers/md/dm-writecache.c      |  8 +--
 drivers/md/dm.c                 | 16 +++---
 drivers/nvdimm/pmem.c           | 86 +++++++++++++++++++++++++++++----
 drivers/nvdimm/pmem.h           |  2 +-
 drivers/s390/block/dcssblk.c    | 13 +++--
 fs/dax.c                        | 32 +++++++++---
 fs/fuse/dax.c                   |  4 +-
 fs/fuse/virtio_fs.c             | 12 +++--
 include/linux/dax.h             | 18 ++++---
 include/linux/device-mapper.h   |  5 +-
 tools/testing/nvdimm/pmem-dax.c |  2 +-
 16 files changed, 187 insertions(+), 75 deletions(-)

-- 
2.18.4