Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 27 Apr 2023 18:35:57 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jane Chu <jane.chu@oracle.com>,
        Dan Williams <dan.j.williams@intel.com>,
        <vishal.l.verma@intel.com>, <dave.jiang@intel.com>,
        <ira.weiny@intel.com>, <willy@infradead.org>,
        <viro@zeniv.linux.org.uk>, <brauner@kernel.org>,
        <nvdimm@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
        <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2] dax: enable dax fault handler to report
 VM_FAULT_HWPOISON
Message-ID: <644b22fddc18c_1b6629488@dwillia2-xfh.jf.intel.com.notmuch>
References: <20230406230127.716716-1-jane.chu@oracle.com>
 <644aeadcba13b_2028294c9@dwillia2-xfh.jf.intel.com.notmuch>
 <a3c1bef3-4226-7c24-905a-d58bd67b89f1@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a3c1bef3-4226-7c24-905a-d58bd67b89f1@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OGazJdA6+GAxi33Of2uAUNkb2Zj9kL7bvkM0TJtLBPX86iJB1k7jW4OV0MJS?=
 =?us-ascii?Q?bY5y0W3YOMAcGbDowwKqzxH3nXKrgJN9hjOzz1uY3oCIlhNopaD93mce/lg1?=
 =?us-ascii?Q?niu6QfXkD8SjmyWPwwJHIajdb+SeG2hbOxnCk1a2ECkEDRONOY3PE9SpYSr2?=
 =?us-ascii?Q?sQdKQVQQmXiZDzBbjj/2KvPWudRU+ob0Plze4Uws7Cn1Lzjpxw5L+xjlDt8g?=
 =?us-ascii?Q?nOu/SHlCzPP43pZ6s9xVbGDSVVhnYSr2yWcI5+CL/1ADmbQkuBLj9s5mWlls?=
 =?us-ascii?Q?/O4ksfcpQ+HRSK0rbTBWYgdsGFb5naG45TOuALBqtPICy9Fpmk5Y521vFeRh?=
 =?us-ascii?Q?z2vtQWPpQFqwEyLkJrr3dp6Rk+sgRxsn8PWKJiAvfN/TQqfRGEvNqXfi+U6W?=
 =?us-ascii?Q?Jw3k1WWIm9L/SR69ZhTPR4Et/MlVKZIjfa+d6jERD4C7ylW99u+RNCyrUvqz?=
 =?us-ascii?Q?fmbfYmaljO9FxRthn24McFwnIa9iuBFrZbrW7aAk5O2To0UsWvvETv3cp1/u?=
 =?us-ascii?Q?8yMTVCQngVKChmkihJBajVjs8tWtdcwyp/s21smML3Vx5LUY6NwTCQctimS+?=
 =?us-ascii?Q?1DGxVs8WMC+w6SyuLH/XFDbn5WgQUtk7JSP1uPcxs1OYX8P7Qa74qdjsnklF?=
 =?us-ascii?Q?yFhas9ZSXHqrhL/PMZ9yIocw5ewAFYWvGN7eVns2nOszxbcxAap8wlOc6drX?=
 =?us-ascii?Q?K4FxX/vZThKCZSqerXVLF3XgcAJ40i2ppKW0hvsDFJJWu7Gv8WS3c0Nd51aG?=
 =?us-ascii?Q?DAHldJ0IATKmyzev+LJINbKAqnYfEPgPQS/gpTuZUjMmKEQbKDkkj/WVGRW7?=
 =?us-ascii?Q?iX2sslWl7XHmMwGcXvLw390ZpOTz93ZbF4//MCgMoc1SR6f0d9QBPk5HujuE?=
 =?us-ascii?Q?tEGOv7MBk+TawRUldmxsCgOmm9xNw9ccgOK7P0E+OCyaqc/tbxPBl35GFSkv?=
 =?us-ascii?Q?+kSVsZ3MPvbKQjigKPezdAMpjR1WT2L9/UcOFkIiA0zcaYVW5BHLG77YXUI7?=
 =?us-ascii?Q?9e29/s2q/gCc1BOemS8fZ8mJtjKu7EyKvc5d9ZOBCcmwsvdOSEr8mBabXzP5?=
 =?us-ascii?Q?jXTaFd/qc1GjHSWzc/ISHvD1T5abEP+igXlkSbS0qORwfFxLBChWa46WBIoU?=
 =?us-ascii?Q?kz1A8SnN1Bjvr49yA/2qOy5hQjB9ZtkKh9n0GgDKmcGHCewcVE6FmLHtTu7N?=
 =?us-ascii?Q?fWADGGEmf0xrjdGrgdUzvhPiYjDYLUuUSBmMDQXbhfOEvP7y1W9tCvxntyCO?=
 =?us-ascii?Q?P5Ih43rRaIvNLAQBW0D93c2p339vDm5FGA0pWIYa4nTF18MO+oI9h83TQEmX?=
 =?us-ascii?Q?gn9Ciy4Imx0I10doyvc1IHfimFHsQzrGciREIZ2t5gR2Yf2vGznf5cv6V9ke?=
 =?us-ascii?Q?6q06XeGI0K/2eubhd9fnn08VZF7Paqe1Kn9km/Im8XG7X/cLn9wP04P+yh+o?=
 =?us-ascii?Q?S3VzIVttA62Hf7shdQVat6bGyDIi7++s5DgsTTVrA4QJCpR45sxGpfhEgtxE?=
 =?us-ascii?Q?rRfjTJziovjd7z7q59nA9MHPg76DXbLD61u91MRbynjAomCKQWQb6dG3hFbn?=
 =?us-ascii?Q?4iiNyYAaGO4n69mBrNfe5AUXq5eXoNVZpnkhwJ5XDcZeBJqyVPvzBWZagGVx?=
 =?us-ascii?Q?6Q=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fc3864e-c841-43a9-fb2d-08db4788ec07
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2023 01:36:00.7496
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: z5s/UbIsXod2GFMuCbr8r4Pmob5RO+QzrT2tS8+YQT84kuRFX5uy1SrVQnPOLku/mUpVGPHWdcov+pjrmbpEbwxqw4YsnDkio9IeYQRUuoo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB7968
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jane Chu wrote:
> Hi, Dan,
> 
> On 4/27/2023 2:36 PM, Dan Williams wrote:
> > Jane Chu wrote:
> >> When dax fault handler fails to provision the fault page due to
> >> hwpoison, it returns VM_FAULT_SIGBUS which lead to a sigbus delivered
> >> to userspace with .si_code BUS_ADRERR.  Channel dax backend driver's
> >> detection on hwpoison to the filesystem to provide the precise reason
> >> for the fault.
> > 
> > It's not yet clear to me by this description why this is an improvement
> > or will not cause other confusion. In this case the reason for the
> > SIGBUS is because the driver wants to prevent access to poison, not that
> > the CPU consumed poison. Can you clarify what is lost by *not* making
> > this change?
> 
> Elsewhere when hwpoison is detected by page fault handler and helpers as 
> the direct cause to failure, VM_FAULT_HWPOISON or 
> VM_FAULT_HWPOISON_LARGE is flagged to ensure accurate SIGBUS payload is 
> produced, such as wp_page_copy() in COW case, do_swap_page() from 
> handle_pte_fault(), hugetlb_fault() in hugetlb page fault case where the 
> huge fault size would be indicated in the payload.
> 
> But dax fault has been an exception in that the SIGBUS payload does not 
> indicate poison, nor fault size.  I don't see why it should be though,
> recall an internal user expressing confusion regarding the different 
> SIGBUS payloads.

...but again this the typical behavior with block devices. If a block
device has badblock that causes page cache page not to be populated
that's a SIGBUS without hwpoison information. If the page cache is
properly populated and then the CPU consumes poison that's a SIGBUS with
the additional hwpoison information.

Applications should have a consistent error response regardless of pmem
or dax.