[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZEsJxwbIeq3jHDBT@casper.infradead.org>
Date: Fri, 28 Apr 2023 00:48:23 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Jane Chu <jane.chu@...cle.com>
Cc: Dan Williams <dan.j.williams@...el.com>, vishal.l.verma@...el.com,
dave.jiang@...el.com, ira.weiny@...el.com, 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
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.
Powered by blists - more mailing lists