Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1610505pxb;
        Thu, 4 Nov 2021 05:33:23 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzYchgpEZVnDebh9KO/8LxrLdSkMotI6g/YJ7atfYFX60szYmoVu8xjW8vbdsJT3Frae3ZB
X-Received: by 2002:a92:2903:: with SMTP id l3mr27865186ilg.35.1636029203361;
        Thu, 04 Nov 2021 05:33:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1636029203; cv=none;
        d=google.com; s=arc-20160816;
        b=pWYOIvpcfB5VD6RjiwguAXReVTTfcRe0cFZGxEFN5hgfhOicy1CUa6AAVmW/yLgP51
         ctEyGQ4JGcrzNPxfhbuaX9jgu89np6xs+Z+H7zEbuE/4ePrGfjvsfb+XhtriRV1kmao/
         eeCEHRSsJEOZMhm3owXEwldbUhZBeggOlRZUA+64wkFOf8jiWVJMcPa4QLHLYG0VOENv
         KtGaH3wqanC0C+B8ieCxNtjGymxGyNoeQ7CtySgc9FwFbytlnN2IM2xu6M2OT50D+qql
         pe10z5rAnM6LrwcktmTghaoP3EffSbCWdCf22ftnTpmNa4qiOlOJ9QAQNulBKwtJnGh3
         JUgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:dkim-signature;
        bh=iQDesZV5L2mroTI3Kp4Q9Tkxn1uaR3bTz2ke0CiK9wE=;
        b=R4o7fOt6HJDYIY8lU8GQM6Fa8L3wXy3Ro8zJOc5zRqKU6IG14R6ApOMf7Ph44HWuWW
         qljBeXdneOW83gz4K7443axzYIJkT3cS299R9s+EehrlHYVxs5/jHxvBd+yPbAjlA/Eg
         3EYU0ObuKHuDKC30+WYnF4SGZmjNw/2uxsn7jhegqGNqLAAaJeAbqHQagt5DqIFcaAg+
         x0RtN/1aDVGWeI7uvTnZmBwEhA1pf17BqOdY5mj7hwJtsyCIB2VslpdKSsmCNPYCmy6l
         XVvhFWUI5QpB2AHPF4RqqpvZMaEHWIaGZLqj/fzy1m1wWYdVk/G06v6U72PUyIoqXadv
         SipQ==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=l05sE+7q;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18])
        by mx.google.com with ESMTP id k5si9177846iov.114.2021.11.04.05.33.04;
        Thu, 04 Nov 2021 05:33:23 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=l05sE+7q;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S231295AbhKDMeJ (ORCPT <rfc822;ly15351151@gmail.com> + 99 others);
        Thu, 4 Nov 2021 08:34:09 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44900 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229809AbhKDMeH (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 4 Nov 2021 08:34:07 -0400
Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93B3FC061714;
        Thu,  4 Nov 2021 05:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
        d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
        References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
        Content-Transfer-Encoding:Content-ID:Content-Description;
        bh=iQDesZV5L2mroTI3Kp4Q9Tkxn1uaR3bTz2ke0CiK9wE=; b=l05sE+7qLWw6hasWyI/n0sgCrx
        1gk2a/tDTo4hfhxCY2tx9KEeS3Me3gh5TO/MYJsvwrTQ7Uk2XzOQGVGEMRKLI0tl9ouAAsajZAYQQ
        qScYChjvl1Mx+k3w3OHPSsjy5wz1TeQFTAVbPl7mJTLC5cHnGIhKhN5wdbQ3QGtSMGeCl+zqA7hp2
        NUJ72xXrPItCUBAWEQGuvyeMknqkRWwyQVRjCFS2B/hFsjoTkXs0Y5uFTY1Z1L03Sl+V6x8ko9F25
        HEy9RYwqNe19PXKLzMA3IoGWaMQYYlH6x+koORZ53RoCD2TIuFZVTG2orIoah0SlzuiAe3oRIVf0i
        7wQ3cDPA==;
Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux))
        id 1mibrf-005rYi-P5; Thu, 04 Nov 2021 12:29:31 +0000
Date:   Thu, 4 Nov 2021 12:29:07 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Dan Williams <dan.j.williams@intel.com>,
        "Darrick J. Wong" <djwong@kernel.org>,
        Jane Chu <jane.chu@oracle.com>,
        "david@fromorbit.com" <david@fromorbit.com>,
        "vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
        "dave.jiang@intel.com" <dave.jiang@intel.com>,
        "agk@redhat.com" <agk@redhat.com>,
        "snitzer@redhat.com" <snitzer@redhat.com>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>,
        "ira.weiny@intel.com" <ira.weiny@intel.com>,
        "vgoyal@redhat.com" <vgoyal@redhat.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [dm-devel] [PATCH 0/6] dax poison recovery with
 RWF_RECOVERY_DATA flag
Message-ID: <YYPSE4XACpqs21Yl@casper.infradead.org>
References: <e89a2b17-3f03-a43e-e0b9-5d2693c3b089@oracle.com>
 <YXJN4s1HC/Y+KKg1@infradead.org>
 <2102a2e6-c543-2557-28a2-8b0bdc470855@oracle.com>
 <YXj2lwrxRxHdr4hb@infradead.org>
 <20211028002451.GB2237511@magnolia>
 <YYDYUCCiEPXhZEw0@infradead.org>
 <CAPcyv4j8snuGpy=z6BAXogQkP5HmTbqzd6e22qyERoNBvFKROw@mail.gmail.com>
 <YYK/tGfpG0CnVIO4@infradead.org>
 <CAPcyv4it2_PVaM8z216AXm6+h93frg79WM-ziS9To59UtEQJTA@mail.gmail.com>
 <YYOaOBKgFQYzT/s/@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YYOaOBKgFQYzT/s/@infradead.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Nov 04, 2021 at 01:30:48AM -0700, Christoph Hellwig wrote:
> Well, the whole problem is that we should not have to manage this at
> all, and this is where I blame Intel.  There is no good reason to not
> slightly overprovision the nvdimms and just do internal bad page
> remapping like every other modern storage device.

What makes you think they don't?

The problem is persuading the CPU to do writes without doing reads.
That's where magic instructions or out of band IO is needed.