[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

Markus Elfring June 25, 2023, 6:25 a.m. UTC | #1

> Change from v4:
…

I suggest to omit the cover letter for a single patch.

Will any patch series evolve for your proposed changes?

Regards,
Markus

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

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

Markus Elfring June 27, 2023, 6:08 a.m. UTC | #3

> 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

Regards,
Markus

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

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.

Markus Elfring June 27, 2023, 4:22 p.m. UTC | #5

>> 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?

Regards,
Markus

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

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.

Markus Elfring June 27, 2023, 4:34 p.m. UTC | #7

>> 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?

Regards,
Markus

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

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.