From: Matthew Wilcox <willy@infradead.org>
To: Jane Chu <jane.chu@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
vishal.l.verma@intel.com, dave.jiang@intel.com,
ira.weiny@intel.com, 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
Date: Fri, 28 Apr 2023 00:48:23 +0100 [thread overview]
Message-ID: <ZEsJxwbIeq3jHDBT@casper.infradead.org> (raw)
In-Reply-To: <a3c1bef3-4226-7c24-905a-d58bd67b89f1@oracle.com>
On Thu, Apr 27, 2023 at 04:36:58PM -0700, Jane Chu wrote:
> > This change results in EHWPOISON leaking to usersapce in the case of
> > read(2), that's not a return code that block I/O applications have ever
> > had to contend with before. Just as badblocks cause EIO to be returned,
> > so should poisoned cachelines for pmem.
>
> The read(2) man page (https://man.archlinux.org/man/read.2) says
> "On error, -1 is returned, and errno is set to indicate the error. In this
> case, it is left unspecified whether the file position (if any) changes."
>
> If read(2) users haven't dealt with EHWPOISON before, they may discover that
> with pmem backed dax file, it's possible.
I don't think they should. While syscalls are allowed to return errnos
other than the ones listed in POSIX, I don't think this is a worthwhile
difference. We should be abstracting from the user that this is pmem
rather than spinning rust or nand. So we should convert the EHWPOISON
to EIO as Dan suggests.
next prev parent reply other threads:[~2023-04-27 23:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 23:01 [PATCH v2] dax: enable dax fault handler to report VM_FAULT_HWPOISON Jane Chu
2023-04-18 18:55 ` Jane Chu
2023-04-27 21:36 ` Dan Williams
2023-04-27 23:36 ` Jane Chu
2023-04-27 23:48 ` Matthew Wilcox [this message]
2023-04-28 1:26 ` Jane Chu
2023-04-28 1:35 ` Dan Williams
2023-04-28 2:50 ` Matthew Wilcox
2023-04-28 4:02 ` Dan Williams
2023-04-27 23:38 ` Jane Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEsJxwbIeq3jHDBT@casper.infradead.org \
--to=willy@infradead.org \
--cc=brauner@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=jane.chu@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).