linux-kernel - Re: [PATCH v2] dax: enable dax fault handler to report VM_FAULT

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Apr 2023 18:35:57 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jane Chu <jane.chu@...cle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        <vishal.l.verma@...el.com>, <dave.jiang@...el.com>,
        <ira.weiny@...el.com>, <willy@...radead.org>,
        <viro@...iv.linux.org.uk>, <brauner@...nel.org>,
        <nvdimm@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
        <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2] dax: enable dax fault handler to report
 VM_FAULT_HWPOISON

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.