On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:

On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi [off-list ref] wrote:

quoted

On Tue, 2018-06-26 at 15:13 -0400, Mike Snitzer wrote:

quoted

On Tue, Jun 26 2018 at  3:07pm -0400,
Dan Williams [off-list ref] wrote:

quoted

On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer [off-list ref] wrote:

quoted

On Tue, Jun 26 2018 at  2:52pm -0400,
Dan Williams [off-list ref] wrote:

quoted

On Tue, Jun 26, 2018 at 10:59 AM, Ross Zwisler
[off-list ref] wrote:

quoted

QUEUE_FLAG_DAX is an indication that a given block device supports
filesystem DAX and should not be set for PMEM namespaces which are in "raw"
or "sector" modes.  These namespaces lack struct page and are prevented
from participating in filesystem DAX.

Signed-off-by: Ross Zwisler <redacted>
Suggested-by: Mike Snitzer <redacted>
Cc: stable@vger.kernel.org

Why is this cc: stable? What is the user visible impact of this change
especially given the requirement to validate QUEUE_FLAG_DAX with
bdev_dax_supported()? Patch looks good, but it's just a cosmetic fixup
afaics.

This isn't cosmetic when you consider that stacking up a DM device is
looking at this flag to determine whether a table does or does _not_
support DAX.

So this patch, in conjunction with the other changes in the series, is
certainly something I'd consider appropriate for stable.

I think this classifies as something that never worked correctly and
is not a regression. It does not identify which commit it is repairing
or the user visible failure mode.

So you're taking issue with making stacked dax configs work in older
kernels?  That's fine.  We can drop the stable cc if you like.

But I mean we intended for this to work.. so the Fixes commit references
can easily be added, e.g.: 545ed20e6df68a4d2584a29a2a28ee8b2f7e9547
("dm: add infrastructure for DAX support")

When this dm change was made, the pmem driver supported DAX for both raw
and memory modes (note: sector mode does not use the pmem driver).  I
think the issue was introduced when we dropped DAX support from raw
mode.

Still DAX with raw mode never really worked any way. It was also
something that was broken from day one. So what happens to someone who
happened to avoid all the problems with page-less DAX and enabled
device-mapper on top? That failure mode detail needs to be added to
this changelog if we want to propose this for -stable.

My point is that the behavior should be consistent between pmem and
device-mapper.  When -o dax succeeds on a pmem, then it should succeed
on a device-mapper on top of that pmem.

Has the drop of dax support from raw mode made to -stable back to the
baseline accepted 545ed20e6df6?  It will introduce inconsistency,
otherwise.

Thanks,
-Toshi