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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 13:55:40 -0700 From: Jane Chu <jane.chu@...cle.com> To: "Darrick J. Wong" <djwong@...nel.org> Cc: Dan Williams <dan.j.williams@...el.com>, Vishal L Verma <vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, "Weiny, Ira" <ira.weiny@...el.com>, Al Viro <viro@...iv.linux.org.uk>, Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>, Linux NVDIMM <nvdimm@...ts.linux.dev>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org> Subject: Re: [PATCH 0/3] dax: clear poison on the fly along pwrite On 9/15/2021 9:15 AM, Darrick J. Wong wrote: > On Wed, Sep 15, 2021 at 12:22:05AM -0700, Jane Chu wrote: >> Hi, Dan, >> >> On 9/14/2021 9:44 PM, Dan Williams wrote: >>> On Tue, Sep 14, 2021 at 4:32 PM Jane Chu <jane.chu@...cle.com> wrote: >>>> >>>> If pwrite(2) encounters poison in a pmem range, it fails with EIO. >>>> This is unecessary if hardware is capable of clearing the poison. >>>> >>>> Though not all dax backend hardware has the capability of clearing >>>> poison on the fly, but dax backed by Intel DCPMEM has such capability, >>>> and it's desirable to, first, speed up repairing by means of it; >>>> second, maintain backend continuity instead of fragmenting it in >>>> search for clean blocks. >>>> >>>> Jane Chu (3): >>>> dax: introduce dax_operation dax_clear_poison >>> >>> The problem with new dax operations is that they need to be plumbed >>> not only through fsdax and pmem, but also through device-mapper. >>> >>> In this case I think we're already covered by dax_zero_page_range(). >>> That will ultimately trigger pmem_clear_poison() and it is routed >>> through device-mapper properly. >>> >>> Can you clarify why the existing dax_zero_page_range() is not sufficient? >> >> fallocate ZERO_RANGE is in itself a functionality that applied to dax >> should lead to zero out the media range. So one may argue it is part >> of a block operations, and not something explicitly aimed at clearing >> poison. > > Yeah, Christoph suggested that we make the clearing operation explicit > in a related thread a few weeks ago: > https://lore.kernel.org/linux-fsdevel/YRtnlPERHfMZ23Tr@infradead.org/ > > I like Jane's patchset far better than the one that I sent, because it > doesn't require a block device wrapper for the pmem, and it enables us > to tell application writers that they can handle media errors by > pwrite()ing the bad region, just like they do for nvme and spinners. > >> I'm also thinking about the MOVEDIR64B instruction and how it >> might be used to clear poison on the fly with a single 'store'. >> Of course, that means we need to figure out how to narrow down the >> error blast radius first. > > That was one of the advantages of Shiyang Ruan's NAKed patchset to > enable byte-granularity media errors to pass upwards through the stack > back to the filesystem, which could then tell applications exactly what > they lost. > > I want to get back to that, though if Dan won't withdraw the NAK then I > don't know how to move forward... > >> With respect to plumbing through device-mapper, I thought about that, >> and wasn't sure. I mean the clear-poison work will eventually fall on >> the pmem driver, and thru the DM layers, how does that play out thru >> DM? > > Each of the dm drivers has to add their own ->clear_poison operation > that remaps the incoming (sector, len) parameters as appropriate for > that device and then calls the lower device's ->clear_poison with the > translated parameters. > > This (AFAICT) has already been done for dax_zero_page_range, so I sense > that Dan is trying to save you a bunch of code plumbing work by nudging > you towards doing s/dax_clear_poison/dax_zero_page_range/ to this series > and then you only need patches 2-3. Thanks Darrick for the explanation! I don't mind to add DM layer support, it sounds straight forward. I also like your latest patch and am wondering if the clear_poison API is still of value. thanks, -jane > >> BTW, our customer doesn't care about creating dax volume thru DM, so. > > They might not care, but anything going upstream should work in the > general case. > > --D > >> thanks! >> -jane >> >> >>> >>>> dax: introduce dax_clear_poison to dax pwrite operation >>>> libnvdimm/pmem: Provide pmem_dax_clear_poison for dax operation >>>> >>>> drivers/dax/super.c | 13 +++++++++++++ >>>> drivers/nvdimm/pmem.c | 17 +++++++++++++++++ >>>> fs/dax.c | 9 +++++++++ >>>> include/linux/dax.h | 6 ++++++ >>>> 4 files changed, 45 insertions(+) >>>> >>>> -- >>>> 2.18.4 >>>>
Powered by blists - more mailing lists