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 --- drivers/nvdimm/pmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 68940356cad3..8b1fd7f1a224 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -414,7 +414,8 @@ static int pmem_attach_disk(struct device *dev, blk_queue_logical_block_size(q, pmem_sector_size(ndns)); blk_queue_max_hw_sectors(q, UINT_MAX); blk_queue_flag_set(QUEUE_FLAG_NONROT, q); - blk_queue_flag_set(QUEUE_FLAG_DAX, q); + if (pmem->pfn_flags & PFN_MAP) + blk_queue_flag_set(QUEUE_FLAG_DAX, q); q->queuedata = pmem;
disk = alloc_disk_node(0, nid);
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.
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
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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.
On Tue, Jun 26, 2018 at 12:07:40PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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.
Ah, do I need a Fixes: tag for patch 2, then? That one *does* need to go to stable, I think.
On Tue, Jun 26 2018 at 3:07pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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")
On Tue, Jun 26, 2018 at 12:13 PM, Mike Snitzer snitzer@redhat.com wrote:
On Tue, Jun 26 2018 at 3:07pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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")
...but to be clear stacked DAX configs are not broken, right? They just happen not to work in this corner case of pmem devices without pages. Given we dropped DAX support for page less devices what configurations are repaired by this change? Am I missing something? Is it a data corruption scenario if this DM gets the wrong idea about DAX support. I could be convinced to recommend this for -stable, but the changelog as written does not make a strong case.
On Tue, 2018-06-26 at 15:13 -0400, Mike Snitzer wrote:
On Tue, Jun 26 2018 at 3:07pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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.
Thanks, -Toshi
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 15:13 -0400, Mike Snitzer wrote:
On Tue, Jun 26 2018 at 3:07pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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.
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 15:13 -0400, Mike Snitzer wrote:
On Tue, Jun 26 2018 at 3:07pm -0400, Dan Williams dan.j.williams@intel.com wrote:
On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer snitzer@redhat.com 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.
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
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
-Toshi
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
> 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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
Hi Ross,
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
Thanks, -Toshi
On Thu, Jun 28 2018 at 1:42pm -0400, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote: > On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
> > 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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
Hi Ross,
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
I've staged the changes to send to Linus shortly.
The first patch has:
Fixes: 569d0365f571 ("dax: require 'struct page' by default for filesystem dax") Cc: stable@vger.kernel.org
As that is the right thing to do given the other 2 patches are marked for stable. We don't want to have a stable kernel with the last 2 patches but not the first.
Mike
On Thu, Jun 28, 2018 at 10:48 AM, Mike Snitzer snitzer@redhat.com wrote:
On Thu, Jun 28 2018 at 1:42pm -0400, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote: > On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote: > > On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..] > > > 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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
Hi Ross,
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
I've staged the changes to send to Linus shortly.
The first patch has:
Fixes: 569d0365f571 ("dax: require 'struct page' by default for filesystem dax") Cc: stable@vger.kernel.org
As that is the right thing to do given the other 2 patches are marked for stable. We don't want to have a stable kernel with the last 2 patches but not the first.
Ok, I'm still grumbling about the changelog being more clear about what the problem was, but let's just go with what you got.
On Thu, 2018-06-28 at 13:48 -0400, Mike Snitzer wrote:
On Thu, Jun 28 2018 at 1:42pm -0400, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote: > On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote: > > On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..] > > > 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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
Hi Ross,
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
I've staged the changes to send to Linus shortly.
The first patch has:
Fixes: 569d0365f571 ("dax: require 'struct page' by default for filesystem dax") Cc: stable@vger.kernel.org
As that is the right thing to do given the other 2 patches are marked for stable. We don't want to have a stable kernel with the last 2 patches but not the first.
Agreed.
Technically, all 3 patches may have "Fixes: 569d0365f571 dax..", but I think having "Fixes 545ed20e6df6 dm.." for patch 2 & 3 provide a protection in case 569d0365f571 gets backported in future.
For the series: Reviewed-by: Toshi Kani toshi.kani@hpe.com
Thanks, -Toshi
On Thu, Jun 28, 2018 at 05:42:34PM +0000, Kani, Toshi wrote:
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi toshi.kani@hpe.com wrote:
On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote: > On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi toshi.kani@hpe.com wrote:
[..]
> > 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.
That commit, 569d0365f571 "dax: require 'struct page' by default for filesystem dax", has not been tagged for -stable.
Then, Fixes tag should be set to 569d0365f571 to keep the behavior consistent.
Sure, and the failure mode is...? I'm thinking the commit log should say:
"Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to <insert user visible failure mode details here>"
Dan is correct that there is no user visible change for this. It is the right thing to do for consistency and sanity, but it doesn't actually have user visible behavior that needs to be backported to stable.
Toshi is correct that this change is only for raw mode namespaces, not btt namespaces.
I'll adjust the changelog and remove the stable flag for v5, and I'll add a Fixes: tag for patch 2.
Hi Ross,
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
I agree that the fsdax + raw mode failure mode I mentioned in my cover letter only started when we restricted filesystem DAX to having struct page, but I think that the other failure mode, fsdax + some random block driver (I used brd) was present in DM from the beginning.
In any case, I think both are fixed with the patches, and I think it's fine that all 3 get thrown at stable. Thanks, Mike, for the help.
On Thu, 2018-06-28 at 13:04 -0600, Ross Zwisler wrote:
On Thu, Jun 28, 2018 at 05:42:34PM +0000, Kani, Toshi wrote:
On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi toshi.kani@hpe.com wrote:
:
Your patches look good. But I am still not clear about the Fixes & stable handling. Talking about user visible behavior, I do not think we had any issue until dax support was dropped from raw mode. Until then, the pmem driver supported dax for all modes, and the check for direct_access worked.
I agree that the fsdax + raw mode failure mode I mentioned in my cover letter only started when we restricted filesystem DAX to having struct page, but I think that the other failure mode, fsdax + some random block driver (I used brd) was present in DM from the beginning.
Ah, I see.
In any case, I think both are fixed with the patches, and I think it's fine that all 3 get thrown at stable. Thanks, Mike, for the help.
Yup, agreed.
Thanks! -Toshi
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.
linux-stable-mirror@lists.linaro.org
-
Dan Williams -
Kani, Toshi -
Mike Snitzer -
Ross Zwisler