On 10/21/2021 5:49 PM, Jane Chu wrote:

On 10/21/2021 4:27 AM, Christoph Hellwig wrote:

quoted

On Wed, Oct 20, 2021 at 06:10:57PM -0600, Jane Chu wrote:

quoted

Prepare dax_copy_to/from_iter() APIs with DAXDEV_F_RECOVERY flag
such that when the flag is set, the underlying driver implementation
of the APIs may deal with potential poison in a given address
range and read partial data or write after clearing poison.

FYI, I've been wondering for a while if we could just kill off these
methods entirely.  Basically the driver interaction consists of two
parts:

   a) wether to use the flushcache/mcsafe variants of the generic helpers
   b) actually doing remapping for device mapper

to me it seems like we should handle a) with flags in dax_operations,
and only have a remap callback for device mapper.  That way we'd avoid
the indirect calls for the native case, and also avoid tons of
boilerplate code.  "futher decouple DAX from block devices" series
already massages the device mapper into a form suitable for such
callbacks.

I've looked through your "futher decouple DAX from block devices" series
and likes the use of xarray in place of the host hash list.
Which upstream version is the series based upon?
If it's based on your development repo, I'd be happy to take a clone
and rebase my patches on yours if you provide a link. Please let me
know the best way to cooperate.

That said, I'm unclear at what you're trying to suggest with respect
to the 'DAXDEV_F_RECOVERY' flag.  The flag came from upper dax-fs
call stack to the dm target layer, and the dm targets are equipped
with handling pmem driver specific task, so it appears that the flag

Apologies. The above line should be
"..., and the dm targets are _not_ equipped with handling pmem driver
specific task,"

-jane

would need to be passed down to the native pmem layer, right?
Am I totally missing your point?

thanks,
-jane