| Message ID | 20200218214841.10076-5-vgoyal@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dax/pmem: Provide a dax operation to zero range of memory | expand |
On Tue, Feb 18, 2020 at 1:49 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > Add a dax operation zero_page_range, to zero a range of memory. This will > also clear any poison in the range being zeroed. > > As of now, zeroing of up to one page is allowed in a single call. There > are no callers which are trying to zero more than a page in a single call. > Once we grow the callers which zero more than a page in single call, we > can add that support. Primary reason for not doing that yet is that this > will add little complexity in dm implementation where a range might be > spanning multiple underlying targets and one will have to split the range > into multiple sub ranges and call zero_page_range() on individual targets. > > Suggested-by: Christoph Hellwig <hch@infradead.org> > Reviewed-by: Christoph Hellwig <hch@lst.de> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com> > --- > drivers/dax/super.c | 19 +++++++++++++++++++ > drivers/nvdimm/pmem.c | 10 ++++++++++ > include/linux/dax.h | 3 +++ > 3 files changed, 32 insertions(+) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 0aa4b6bc5101..c912808bc886 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -344,6 +344,25 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > } > EXPORT_SYMBOL_GPL(dax_copy_to_iter); > > +int dax_zero_page_range(struct dax_device *dax_dev, u64 offset, size_t len) > +{ > + if (!dax_alive(dax_dev)) > + return -ENXIO; > + > + if (!dax_dev->ops->zero_page_range) > + return -EOPNOTSUPP; This seems too late to be doing the validation. It would be odd for random filesystem operations to see this error. I would move the check to alloc_dax() and fail that if the caller fails to implement the operation. An incremental patch on top to fix this up would be ok. Something like "Now that all dax_operations providers implement zero_page_range() mandate it at alloc_dax time".
On Tue, Mar 31, 2020 at 12:38:16PM -0700, Dan Williams wrote: > On Tue, Feb 18, 2020 at 1:49 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > > > Add a dax operation zero_page_range, to zero a range of memory. This will > > also clear any poison in the range being zeroed. > > > > As of now, zeroing of up to one page is allowed in a single call. There > > are no callers which are trying to zero more than a page in a single call. > > Once we grow the callers which zero more than a page in single call, we > > can add that support. Primary reason for not doing that yet is that this > > will add little complexity in dm implementation where a range might be > > spanning multiple underlying targets and one will have to split the range > > into multiple sub ranges and call zero_page_range() on individual targets. > > > > Suggested-by: Christoph Hellwig <hch@infradead.org> > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > Signed-off-by: Vivek Goyal <vgoyal@redhat.com> > > --- > > drivers/dax/super.c | 19 +++++++++++++++++++ > > drivers/nvdimm/pmem.c | 10 ++++++++++ > > include/linux/dax.h | 3 +++ > > 3 files changed, 32 insertions(+) > > > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > > index 0aa4b6bc5101..c912808bc886 100644 > > --- a/drivers/dax/super.c > > +++ b/drivers/dax/super.c > > @@ -344,6 +344,25 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > > } > > EXPORT_SYMBOL_GPL(dax_copy_to_iter); > > > > +int dax_zero_page_range(struct dax_device *dax_dev, u64 offset, size_t len) > > +{ > > + if (!dax_alive(dax_dev)) > > + return -ENXIO; > > + > > + if (!dax_dev->ops->zero_page_range) > > + return -EOPNOTSUPP; > > This seems too late to be doing the validation. It would be odd for > random filesystem operations to see this error. I would move the check > to alloc_dax() and fail that if the caller fails to implement the > operation. > > An incremental patch on top to fix this up would be ok. Something like > "Now that all dax_operations providers implement zero_page_range() > mandate it at alloc_dax time". Hi Dan, Ok, I will send an incremental patch for this. BTW, I have posted V6 of this patch series and you might want to look at that instead of V5. https://lore.kernel.org/linux-fsdevel/20200228163456.1587-1-vgoyal@redhat.com/ Vivek
On Tue, Mar 31, 2020 at 12:38:16PM -0700, Dan Williams wrote: > On Tue, Feb 18, 2020 at 1:49 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > > > Add a dax operation zero_page_range, to zero a range of memory. This will > > also clear any poison in the range being zeroed. > > > > As of now, zeroing of up to one page is allowed in a single call. There > > are no callers which are trying to zero more than a page in a single call. > > Once we grow the callers which zero more than a page in single call, we > > can add that support. Primary reason for not doing that yet is that this > > will add little complexity in dm implementation where a range might be > > spanning multiple underlying targets and one will have to split the range > > into multiple sub ranges and call zero_page_range() on individual targets. > > > > Suggested-by: Christoph Hellwig <hch@infradead.org> > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > Signed-off-by: Vivek Goyal <vgoyal@redhat.com> > > --- > > drivers/dax/super.c | 19 +++++++++++++++++++ > > drivers/nvdimm/pmem.c | 10 ++++++++++ > > include/linux/dax.h | 3 +++ > > 3 files changed, 32 insertions(+) > > > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > > index 0aa4b6bc5101..c912808bc886 100644 > > --- a/drivers/dax/super.c > > +++ b/drivers/dax/super.c > > @@ -344,6 +344,25 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > > } > > EXPORT_SYMBOL_GPL(dax_copy_to_iter); > > > > +int dax_zero_page_range(struct dax_device *dax_dev, u64 offset, size_t len) > > +{ > > + if (!dax_alive(dax_dev)) > > + return -ENXIO; > > + > > + if (!dax_dev->ops->zero_page_range) > > + return -EOPNOTSUPP; > > This seems too late to be doing the validation. It would be odd for > random filesystem operations to see this error. I would move the check > to alloc_dax() and fail that if the caller fails to implement the > operation. > > An incremental patch on top to fix this up would be ok. Something like > "Now that all dax_operations providers implement zero_page_range() > mandate it at alloc_dax time". Hi Dan, Posted an extra patch in same patch series for this. https://lore.kernel.org/linux-fsdevel/20200228163456.1587-1-vgoyal@redhat.com/T/#m624680cbb5e714266d4b34ade2d6c390dae69598 Vivek >
diff --git a/drivers/dax/super.c b/drivers/dax/super.c index 0aa4b6bc5101..c912808bc886 100644 --- a/drivers/dax/super.c +++ b/drivers/dax/super.c @@ -344,6 +344,25 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, } EXPORT_SYMBOL_GPL(dax_copy_to_iter); +int dax_zero_page_range(struct dax_device *dax_dev, u64 offset, size_t len) +{ + if (!dax_alive(dax_dev)) + return -ENXIO; + + if (!dax_dev->ops->zero_page_range) + return -EOPNOTSUPP; + /* + * There are no callers that want to zero across a page boundary as of + * now. Once users are there, this check can be removed after the + * device mapper code has been updated to split ranges across targets. + */ + if (offset_in_page(offset) + len > PAGE_SIZE) + return -EIO; + + return dax_dev->ops->zero_page_range(dax_dev, offset, len); +} +EXPORT_SYMBOL_GPL(dax_zero_page_range); + #ifdef CONFIG_ARCH_HAS_PMEM_API void arch_wb_cache_pmem(void *addr, size_t size); void dax_flush(struct dax_device *dax_dev, void *addr, size_t size) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 3c46e9e6d04c..e17f9f56d6fe 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -304,6 +304,15 @@ static const struct block_device_operations pmem_fops = { .revalidate_disk = nvdimm_revalidate_disk, }; +static int pmem_dax_zero_page_range(struct dax_device *dax_dev, u64 offset, + size_t len) +{ + struct pmem_device *pmem = dax_get_private(dax_dev); + + return blk_status_to_errno(pmem_do_write(pmem, ZERO_PAGE(0), 0, offset, + len)); +} + static long pmem_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long nr_pages, void **kaddr, pfn_t *pfn) { @@ -335,6 +344,7 @@ static const struct dax_operations pmem_dax_ops = { .dax_supported = generic_fsdax_supported, .copy_from_iter = pmem_copy_from_iter, .copy_to_iter = pmem_copy_to_iter, + .zero_page_range = pmem_dax_zero_page_range, }; static const struct attribute_group *pmem_attribute_groups[] = { diff --git a/include/linux/dax.h b/include/linux/dax.h index 328c2dbb4409..93a663c26d6a 100644 --- a/include/linux/dax.h +++ b/include/linux/dax.h @@ -34,6 +34,8 @@ struct dax_operations { /* copy_to_iter: required operation for fs-dax direct-i/o */ size_t (*copy_to_iter)(struct dax_device *, pgoff_t, void *, size_t, struct iov_iter *); + /* zero_page_range: required operation. Zero range with-in a page */ + int (*zero_page_range)(struct dax_device *, u64, size_t); }; extern struct attribute_group dax_attribute_group; @@ -199,6 +201,7 @@ size_t dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i); size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, size_t bytes, struct iov_iter *i); +int dax_zero_page_range(struct dax_device *dax_dev, u64 offset, size_t len); void dax_flush(struct dax_device *dax_dev, void *addr, size_t size); ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,