On Tue, Jun 26, 2018 at 02:58:30PM -0400, Mike Snitzer wrote:
On Tue, Jun 26 2018 at 2:52pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 10:59 AM, Ross Zwisler ross.zwisler@linux.intel.com wrote:
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 ross.zwisler@linux.intel.com Suggested-by: Mike Snitzer snitzer@redhat.com 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.
Mike
Because in patch 3 of this series we now use the full bdev_dax_supported() instead of just checking the queue flag in device_supports_dax(), I agree that this isn't strictly necessary for stable. device_supports_dax() will still notice that the raw/sector namespaces don't support DAX because bdev_dax_supported() will fail, and we'll end up doing the right thing and not setting QUEUE_FLAG_DAX on the DM device.
I think maybe it's good to have in stable for completeness (and it's a very small change), but if we drop it from stable the code will still do the right thing AFAICT.