[v5,0/1] dax: enable dax fault handler to report VM_FAULT_HWPOISON

Message

Jane Chu June 15, 2023, 6:13 p.m. UTC

Change from v4:
Add comments describing when and why dax_mem2blk_err() is used.
Suggested by Dan.

Change from v3:
Prevent leaking EHWPOISON to user level block IO calls such as
zero_range_range, and truncate.  Suggested by Dan.

Change from v2:
Convert EHWPOISON to EIO to prevent EHWPOISON errno from leaking
out to block read(2). Suggested by Matthew.

Jane Chu (1):
  dax: enable dax fault handler to report VM_FAULT_HWPOISON

 drivers/dax/super.c          |  5 ++++-
 drivers/nvdimm/pmem.c        |  2 +-
 drivers/s390/block/dcssblk.c |  3 ++-
 fs/dax.c                     | 11 ++++++-----
 fs/fuse/virtio_fs.c          |  3 ++-
 include/linux/dax.h          | 13 +++++++++++++
 include/linux/mm.h           |  2 ++
 7 files changed, 30 insertions(+), 9 deletions(-)

Comments

Jane Chu June 26, 2023, 5:49 p.m. UTC | #1

On 6/24/2023 11:25 PM, Markus Elfring wrote:
>> Change from v4:
> …
> 
> I suggest to omit the cover letter for a single patch.
> 
> Will any patch series evolve for your proposed changes?
> 

No. The thought was to put descriptions unsuitable for commit header in 
the cover letter.

thanks,
jane

> Regards,
> Markus

Matthew Wilcox June 27, 2023, 3:22 p.m. UTC | #2

On Tue, Jun 27, 2023 at 08:08:19AM +0200, Markus Elfring wrote:
> > The thought was to put descriptions unsuitable for commit header in the cover letter.
> 
> How do you think about to put additional information below triple dashes
> (or even into improved change descriptions)?
> 
> See also:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.4#n686

Markus,

Please go away.  Your feedback is not helpful.  Thank you.

Matthew Wilcox June 27, 2023, 4:24 p.m. UTC | #3

On Tue, Jun 27, 2023 at 06:22:47PM +0200, Markus Elfring wrote:
> >> How do you think about to put additional information below triple dashes
> >> (or even into improved change descriptions)?
> >>
> >> See also:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.4#n686
> >
> > Markus,
> >
> > Please go away.  Your feedback is not helpful.
> 
> Would you insist on the usage of cover letters also for single patches?

I would neither insist on it, nor prohibit it.  It simply does not
make enough difference.

Dan Williams June 27, 2023, 5:25 p.m. UTC | #4

Markus Elfring wrote:
> >> Would you insist on the usage of cover letters also for single patches?
> >
> > I would neither insist on it, nor prohibit it.
> 
> It seems that you can tolerate an extra message here.
> 
> 
> > It simply does not make enough difference.
> 
> Can it occasionally be a bit nicer to receive all relevant information within a single patch
> instead of a combination of two messages?

No, I am the maintainer of this code and everything I needed to judge
this patch was provided. This cover letter only included inter-version
details and anything relevant for the kernel history is included in the
patch itself.

For any code I maintain inter-version details below the --- line or in a
0/1 cover letter are perfectly acceptable.

Please, if the review feedback is arbitrary, as it is in this case,
strongly consider not offering it.