Messages in this thread Patch in this message | | | From | Jane Chu <> | Subject | Re: [PATCH v2 2/2] dax,pmem: Implement pmem based dax data recovery | Date | Mon, 8 Nov 2021 20:53:39 +0000 |
| |
On 11/5/2021 7:04 PM, Darrick J. Wong wrote: <snip> >> >> diff --git a/drivers/md/dm.c b/drivers/md/dm.c >> index dc354db22ef9..9b3dac916f22 100644 >> --- a/drivers/md/dm.c >> +++ b/drivers/md/dm.c >> @@ -1043,6 +1043,7 @@ static size_t dm_dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, >> if (!ti) >> goto out; >> if (!ti->type->dax_copy_from_iter) { >> + WARN_ON(mode == DAX_OP_RECOVERY); >> ret = copy_from_iter(addr, bytes, i); >> goto out; >> } >> @@ -1067,6 +1068,7 @@ static size_t dm_dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, >> if (!ti) >> goto out; >> if (!ti->type->dax_copy_to_iter) { >> + WARN_ON(mode == DAX_OP_RECOVERY); > > Maybe just return -EOPNOTSUPP here? > > Warnings are kinda loud. >
Indeed. Looks like the "if (!ti->type->dax_copy_to_iter) {" clause was to allow mixed dax targets in dm, such as dcss, fuse and virtio_fs targets. These targets either don't export .dax_copy_from/to_iter, or don't need to. And their .dax_direct_access don't check poison, and can't repair poison anyway.
I think these targets may safely ignore the flag. However, returning -EOPNOTSUPP is helpful to catch future bug, such as someone add a method to detect poison, but didn't add a method to clear poison, in that case, we fail the call.
Dan, do you have a preference?
thanks! -jane
| |