Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Feb 22, 2024 at 03:29:10PM -0500, Michael S. Tsirkin wrote:
> In a sense ... but on the other hand, the "fake DMA" metaphor seems to
> work surprisingly well, like in this instance - internal bounce buffer
> looks a bit like non-coherent DMA. A way to make this all prettier
> would I
On Mon, Feb 19, 2024 at 06:06:06PM +0100, Maxime Coquelin wrote:
> Since commit 295525e29a5b ("virtio_net: merge dma
> operations when filling mergeable buffers"), VDUSE device
> require support for DMA's .sync_single_for_cpu() operation
> as the memory is non-coherent between the device and CPU
>
On Thu, Feb 01, 2024 at 12:29:46PM +0300, Andrew Kanner wrote:
> Of course not, no new users needed.
>
> I haven't discussed it directly. I found the unused __symbol_get_gpl()
> myself, but during investigation of wether it was ever used somewhere
> found the old patch series suggested by Mauro
> EXPORT_SYMBOL_GPL modules") Christoph Hellwig switched __symbol_get()
> to process GPL symbols only, most likely this is what
> __symbol_get_gpl() was designed to do.
>
> We might either define __symbol_get_gpl() as __symbol_get() or remove
> it completely a
On Wed, Oct 18, 2023 at 01:30:18AM +0100, David Woodhouse wrote:
>
> But if we're going to tolerate the core kernel still exporting some
> stuff with EXPORT_SYMBOL, why isn't OK for a GPL-licensed module do to
> the same? Even an *in-tree* GPL-licensed module now can't export
> functionality with
On Mon, Oct 09, 2023 at 10:26:35AM +0530, Joey Jiao wrote:
> When modprobe cmds are executed one by one, the final loaded modules
> are not in fixed sequence as expected.
And why does this matter?
If this is important enough to matter it should just be the default,
and have really good reason
> needed and actually used by anyone, we can add it back later once the
> license is cleared up.
Looks good:
Acked-by: Christoph Hellwig
On Fri, Sep 15, 2023 at 09:39:05AM -0400, Prarit Bhargava wrote:
> To be clear, I am not asking for their removal, however, I do think a better
> license should be issued for these files. The files were trivially modified
> in 2006. It could be that the code in question is now unused and it is
ere generic_shutdown_super is called by the core
code, and there are extra ->shutdown_sb and ->free_sb hooks before and
after it. To remove the amount of boilerplate code ->shutdown_sb is only
called if the super has finished initialization and ->d_root is set.
Signed-off-by: Ch
callback. Note that this now makes the
set callback optional as a lot of file systems don't need it any more.
Signed-off-by: Christoph Hellwig
---
fs/9p/vfs_super.c | 2 +-
fs/afs/super.c | 12 +++-
fs/btrfs/super.c | 6 ++--
fs/ceph/super.c| 7 +
fs/ecryptfs
qibfs currently has convoluted code to allow registering HCAs while qibfs
is not mounted and vice versa. Switch to using simple_release_fs every
time an entry is added to pin the fs instance and remove all the boiler
plate code.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/qib
nfs_kill_super is only used in fs_context, so move it there.
Signed-off-by: Christoph Hellwig
---
fs/nfs/fs_context.c | 13 +
fs/nfs/internal.h | 1 -
fs/nfs/super.c | 16
fs/nfs/sysfs.h | 2 ++
4 files changed, 15 insertions(+), 17 deletions(-)
diff
ase the anon dev_t in deactivate_locked_super if
the super_block was using one.
As the freeing is done after the main call to kill_super_notify, this
removes the need for having two slightly different call sites for it.
Signed-off-by: Christoph Hellwig
---
block/bdev.c|
When ->fill_super fails, ->kill_sb is called which already cleans up
the inodes and zgroups.
Drop the extra cleanup code in zonefs_fill_super.
Signed-off-by: Christoph Hellwig
---
fs/zonefs/super.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --gi
complicated locking hierarchy.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 8db767fd80df6b..e87de519493021
Call generic_shutdown_super if ->kill_sb is not provided by the file
system. This can't currently happen but will become common soon.
Signed-off-by: Christoph Hellwig
---
fs/super.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/super.c b/fs/super.c
in
Creating new a new super_block vs freeing the old one for single instance
file systems is serialized by the wait for SB_DEAD.
Remove the superfluous sb_mutex.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/legacy/inode.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers
Convert jffs2 from ->kill_sb to ->shutdown_sb and ->free_sb. Drop
the otherwise unused kill_mtd_super helpers, as there is no benefit in
it over just calling put_mtd_device on sb->s_mtd.
Signed-off-by: Christoph Hellwig
---
drivers/mtd/mtdsuper.c| 12
fs/j
own_sb and ->free_sb to always be called
in pairs, which it currently is. The next commit will try to clean
this up.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 12 +---
fs/kernfs/mount.c | 18 --
fs/sysf
Replace kill_litter_super with litter_shutdown_sb, which is wired up to
the ->shutdown_sb method. For file systems that wrapped
kill_litter_super, ->kill_sb is replaced with ->shutdown and ->free_sb
methods as needed.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platform
Now that no instances are left, remove ->kill_sb and mark
generic_shutdown_super static.
Signed-off-by: Christoph Hellwig
---
Documentation/filesystems/locking.rst | 5 -
Documentation/filesystems/vfs.rst | 5 -
fs/super.c|
ed-off-by: Christoph Hellwig
---
fs/pstore/inode.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 585360706b335f..fd1d24b47160d0 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -467,10 +467,9 @@ static struct dentry *pstore
Replace kill_block_super with block_free_sb, which is wired up to
the ->free_sb method. For file systems that wrapped kill_block_super,
->kill_sb is replaced with ->shutdown and ->free_sb methods as needed.
Signed-off-by: Christoph Hellwig
---
fs/adfs/super.c | 2 +-
fs/
hypfs is entirely synthetic and doesn't care about i_nlink when dropping
entries from the cache. Switch to d_genocide instead of a home grown
file remove loop for unmount and write (yes, really!).
Signed-off-by: Christoph Hellwig
---
arch/s390/hypfs/inode.c | 37
Don't duplicate the dev_t in the nfs_server structure given that it can
be trivially retrieved from the super_block.
Signed-off-by: Christoph Hellwig
---
fs/nfs/client.c | 2 +-
fs/nfs/nfs4proc.c | 8
fs/nfs/nfs4trace.h| 6 +++---
fs/nfs/nfs4xdr.c
Return early for the case where the super block isn't cleaned up to
reduce level of indentation.
Signed-off-by: Christoph Hellwig
---
fs/super.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index 2d762ce67f6e6c
Convert all file systems that just called generic_shutdown_super from
->kill_sb without any state kept from before the call to after it to
->shutdown_sb and ->free_sb as needed.
Signed-off-by: Christoph Hellwig
---
fs/9p/vfs_super.c | 14 +++---
fs/af
Hi Al and Christian,
this series splits ->kill_sb into separate ->shutdown_sb and ->free_sb
methods and then calls generic_shutdown_super from common code to clean
up the file system shutdown interface.
As a first step towards that it moves allocating and freeing the
anonymous block device dev_t
On Fri, Aug 19, 2022 at 10:10:24AM -0700, Davidlohr Bueso wrote:
> index b192d917a6d0..ac4d4fd4e508 100644
> --- a/arch/x86/include/asm/cacheflush.h
> +++ b/arch/x86/include/asm/cacheflush.h
> @@ -10,4 +10,8 @@
>
> void clflush_cache_range(void *addr, unsigned int size);
>
> +/* see comments
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Jun 30, 2022 at 11:51:55AM -0600, Jane Chu wrote:
> -static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset)
> +static phys_addr_t _to_phys(struct pmem_device *pmem, phys_addr_t offset)
I'd rather call this pmem_to_phys as that is a much nicer name.
On Thu, Jun 09, 2022 at 10:34:35PM +0800, Shiyang Ruan wrote:
> Failure notification is not supported on partitions. So, when we mount
> a reflink enabled xfs on a partition with dax option, let it fail with
> -EINVAL code.
Looks good:
Reviewed-by: Christoph Hellwig
The patch numbering due looks odd due to the combination of the
two series. But otherwise this looks good to me modulo the one
minor nitpick.
ult(vmf, pe_size, pfn, NULL,
> + (write_fault && !vmf->cow_page) ?
> + _dax_write_iomap_ops :
> + _read_iomap_ops);
> +}
> +#endif
Is there any reason this is in xfs_iomap.c and not xfs_file.c?
Otherwise the patch looks good:
Reviewed-by: Christoph Hellwig
On Thu, Apr 21, 2022 at 02:35:02PM +1000, Dave Chinner wrote:
> Sure, I'm not a maintainer and just the stand-in patch shepherd for
> a single release. However, being unable to cleanly merge code we
> need integrated into our local subsystem tree for integration
> testing because a patch
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Apr 13, 2022 at 10:09:40AM -0700, Dan Williams wrote:
> Yes, sounds like we're on the same page. I had mistakenly interpreted
> "Hence these notifications need to be delayed until after the
> filesystem is mounted" as something the producer would need to handle,
> but yes, consumer is free
On Mon, Apr 11, 2022 at 01:16:23AM +0800, Shiyang Ruan wrote:
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index bd502957cfdf..72d9e69aea98 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -359,7 +359,6 @@ static void pmem_release_disk(void *__pmem)
>
> + * Set or Update the page->mapping with FS_DAX_MAPPING_COW flag.
> + * Return true if it is an Update.
> + */
> +static inline bool dax_mapping_set_cow(struct page *page)
> +{
> + if (page->mapping) {
> + /* flag already set */
> + if
t struct quotactl_ops xfs_quotactl_operations;
> +extern const struct dax_holder_operations xfs_dax_holder_operations;
This needs to be defined to NULL if at least one of CONFIG_FS_DAX or
CONFIG_MEMORY_FAILURE is not set.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
> + unmap_and_kill(_kill, pfn, page->mapping, page->index, flags);
> +unlock:
> + dax_unlock_page(page, cookie);
> + return 0;
As the buildbot points out this should probably be a "return rc".
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, Mar 30, 2022 at 11:16:10PM +0800, Shiyang Ruan wrote:
> > > +#if IS_ENABLED(CONFIG_MEMORY_FAILURE) && IS_ENABLED(CONFIG_FS_DAX)
> >
> > No real need for the IS_ENABLED. Also any reason to even build this
> > file if the options are not set? It seems like
> > xfs_dax_holder_operations
On Wed, Mar 30, 2022 at 06:58:21PM +0800, Shiyang Ruan wrote:
> As the code I pasted before, pmem driver will subtract its ->data_offset,
> which is byte-based. And the filesystem who implements ->notify_failure()
> will calculate the offset in unit of byte again.
>
> So, leave its function
On Wed, Mar 30, 2022 at 06:03:01PM +0800, Shiyang Ruan wrote:
>
> Because I am not sure if the offset between each layer is page aligned. For
> example, when pmem dirver handles ->memory_failure(), it should subtract its
> ->data_offset when it calls dax_holder_notify_failure().
If they aren't,
On Wed, Mar 30, 2022 at 03:31:37PM +0800, Muchun Song wrote:
> I saw Shiyang is ready to rebase onto this patch. So should I
> move it to linux/mm.h or let Shiyang does?
Good question. I think Andrew has this series in -mm and ready to go
to Linus, so maybe it is best if we don't change too
> @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
> list_lru_destroy(>bt_lru);
>
> blkdev_issue_flush(btp->bt_bdev);
> + if (btp->bt_daxdev)
> + dax_unregister_holder(btp->bt_daxdev, btp->bt_mount);
> fs_put_dax(btp->bt_daxdev);
>
> kmem_free(btp);
> @@ -1939,6
ping from the storage address to the file and file offset.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
> index 9b1d56c5c224..0420189e4788 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3195,6 +3195,10 @@ enum mf_flags {
> MF_SOFT_OFFLINE =
On Tue, Mar 29, 2022 at 09:48:50PM +0800, Muchun Song wrote:
> + * * Return the start of user virtual address at the specific offset within
Double "*" here.
Also Shiyang has been wanting a quite similar vma_pgoff_address for use
in dax.c. Maybe we'll need to look into moving this to linux/mm.h.
On Sun, Feb 27, 2022 at 08:07:44PM +0800, Shiyang Ruan wrote:
> Since it is not a DAX-specific function, move it into mm and rename it
> to be a generic helper.
FYI, there is a patch in -mm and linux-next:
"mm: rmap: introduce pfn_mkclean_range() to cleans PTEs"
that adds a vma_pgoff_address
On Wed, Mar 16, 2022 at 09:46:07PM +0800, Shiyang Ruan wrote:
> > Forgive me if this has been discussed before, but since dax_operations
> > are in terms of pgoff and nr pages and memory_failure() is in terms of
> > pfns what was the rationale for making the function signature byte
> > based?
>
>
On Fri, Mar 11, 2022 at 03:35:13PM -0800, Dan Williams wrote:
> > + if (!dax_dev->holder_ops) {
> > + rc = -EOPNOTSUPP;
>
> I think it is ok to return success (0) for this case. All the caller
> of dax_holder_notify_failure() wants to know is if the notification
> was
e only caller below?
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
it d92576f1167c ("dax: does not work correctly with virtual aliasing
> caches")
>
> Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
> Signed-off-by: Muchun Song
> Reviewed-by: Dan Williams
Looks good:
Reviewed-by: Christoph Hellwig
ed-by: Dan Williams
Looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Dan, can you send this to Linus for 5.17 to get it out of the queue?
On Thu, Jan 27, 2022 at 08:40:50PM +0800, Shiyang Ruan wrote:
> +void dax_register_holder(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *ops)
> +{
> + if (!dax_alive(dax_dev))
> + return;
> +
> + dax_dev->holder_data = holder;
> +
On Fri, Jan 21, 2022 at 03:55:14PM +0800, Muchun Song wrote:
> Reuse some infrastructure of page_mkclean_one() to let DAX can handle
> similar case to fix this issue.
Can you split out some of the infrastructure changes into proper
well-documented preparation patches?
> + pgoff_t pgoff_end =
On Fri, Jan 21, 2022 at 03:55:13PM +0800, Muchun Song wrote:
> + if (pvmw->pte && ((pvmw->flags & PVMW_PFN_WALK) ||
> !PageHuge(pvmw->page)))
Please avoid the overly long line here and in a few other places.
> +/*
> + * Then at what user virtual address will none of the page be found in
On Fri, Jan 21, 2022 at 03:55:12PM +0800, Muchun Song wrote:
> The flush_cache_page() only remove a PAGE_SIZE sized range from the cache.
> However, it does not cover the full pages in a THP except a head page.
> Replace it with flush_cache_range() to fix this issue.
>
> Fixes: f729c8c9b24f
On Fri, Jan 21, 2022 at 03:55:11PM +0800, Muchun Song wrote:
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index b0fd9dc19eba..65670cb805d6 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -974,7 +974,7 @@ static bool page_mkclean_one(struct page *page,
On Thu, Jan 20, 2022 at 06:22:00PM -0800, Darrick J. Wong wrote:
> Hm, so that means XFS can only support dax+pmem when there aren't
> partitions in use? Ew.
Yes. Or any sensible DAX usage going forward for that matter.
>
> > > (2) extent the holder mechanism to cover a rangeo
>
> I don't
On Fri, Jan 21, 2022 at 10:33:58AM +0800, Shiyang Ruan wrote:
> >
> > But different question, how does this not conflict with:
> >
> > #define PAGE_MAPPING_ANON 0x1
> >
> > in page-flags.h?
>
> Now we are treating dax pages, so I think its flags should be different from
> normal page.
On Sun, Dec 26, 2021 at 10:34:39PM +0800, Shiyang Ruan wrote:
> +#define FS_DAX_MAPPING_COW 1UL
> +
> +#define MAPPING_SET_COW(m) (m = (struct address_space *)FS_DAX_MAPPING_COW)
> +#define MAPPING_TEST_COW(m) (((unsigned long)m & FS_DAX_MAPPING_COW) == \
> +
Please only build the new DAX code if CONFIG_FS_DAX is set.
On Sun, Dec 26, 2021 at 10:34:36PM +0800, Shiyang Ruan wrote:
> Since it is not a DAX-specific function, move it into mm and rename it
> to be a generic helper.
>
> Signed-off-by: Shiyang Ruan
Looks good,
Reviewed-by: Christoph Hellwig
On Sun, Dec 26, 2021 at 10:34:34PM +0800, Shiyang Ruan wrote:
> The function name has been changed, so the description should be updated
> too.
>
> Signed-off-by: Shiyang Ruan
Looks good,
Reviewed-by: Christoph Hellwig
Dan, can you send this to Linux for 5.17 so that we ca
On Wed, Jan 05, 2022 at 04:12:04PM -0800, Dan Williams wrote:
> We ended up with explicit callbacks after hch balked at a notifier
> call-chain, but I think we're back to that now. The partition mistake
> might be unfixable, but at least bdev_dax_pgoff() is dead. Notifier
> call chains have their
On Wed, Dec 15, 2021 at 10:21:00AM +0800, Shiyang Ruan wrote:
>
>
> 在 2021/12/14 23:47, Christoph Hellwig 写道:
> > On Thu, Dec 02, 2021 at 04:48:54PM +0800, Shiyang Ruan wrote:
> > > Add these helper functions, and export them for filesystem use.
> >
&
On Wed, Dec 15, 2021 at 10:06:29AM +0800, Shiyang Ruan wrote:
>
>
> 在 2021/12/14 23:40, Christoph Hellwig 写道:
> > On Thu, Dec 02, 2021 at 04:48:48PM +0800, Shiyang Ruan wrote:
> > > In order to introduce dax holder registration, we need a write lock for
> > &
> + // TODO check and try to fix metadata
Please avoid //-style comments.
> +static u64
> +xfs_dax_ddev_offset(
> + struct xfs_mount*mp,
> + struct dax_device *dax_dev,
> + u64 disk_offset)
> +{
> + xfs_buftarg_t *targp;
> +
> +
On Thu, Dec 02, 2021 at 04:48:54PM +0800, Shiyang Ruan wrote:
> Add these helper functions, and export them for filesystem use.
What is the point of adding these wrappers vs just calling the
underlying functions?
On Thu, Dec 02, 2021 at 04:48:53PM +0800, Shiyang Ruan wrote:
> @@ -254,6 +254,15 @@ static inline bool dax_mapping(struct address_space
> *mapping)
> {
> return mapping->host && IS_DAX(mapping->host);
> }
> +static inline unsigned long pgoff_address(pgoff_t pgoff,
> + struct
to lock
> *
> * Context: Process context.
This should probably got into a separate trivial fix.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 02, 2021 at 04:48:48PM +0800, Shiyang Ruan wrote:
> In order to introduce dax holder registration, we need a write lock for
> dax. Change the current lock to percpu_rw_semaphore and introduce a
> write lock for registration.
Why do we need to change the existing, global locking for
Looks good:
Reviewed-by: Christoph Hellwig
; + ret = pmem_clear_poison(pmem, pmem_off, len);
> + return (ret == BLK_STS_OK) ? 0 : -EIO;
No need for the braces here (and I'd prefer a good old if anyway).
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Tue, Sep 14, 2021 at 05:31:30PM -0600, Jane Chu wrote:
> + if ((map_len == -EIO) && (iov_iter_rw(iter) == WRITE)) {
No need for the inner braces.
> + if (dax_clear_poison(dax_dev, pgoff, PHYS_PFN(size)) ==
> 0)
Overly long line.
Otherwise looks good, but it
Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Oct 14, 2021 at 10:50:00AM -0700, Dan Williams wrote:
> The other blocker was enabling mounting dax filesystems on a
> dax-device rather than a block device. I'm actively refactoring the
> nvdimm subsystem side of that equation, but could use help with the
> conversion of the xfs mount
On Fri, Sep 24, 2021 at 09:09:58PM +0800, Shiyang Ruan wrote:
> +void fs_dax_register_holder(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *ops)
> +{
> + dax_set_holder(dax_dev, holder, ops);
> +}
> +EXPORT_SYMBOL_GPL(fs_dax_register_holder);
> +
On Thu, Oct 14, 2021 at 12:24:50PM -0700, Darrick J. Wong wrote:
> It feels a little dangerous to have page->mapping for shared storage
> point to an actual address_space when there are really multiple
> potential address_spaces out there. If the mm or dax folks are ok with
> doing this this way
Except for the error code inversion noticed by Darrick this looks fine
to me:
Reviewed-by: Christoph Hellwig
d of the HMM terminology for device private memory, so
I'd reword this update the comment to follow that while you're at it.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
On Fri, Sep 24, 2021 at 09:09:52PM +0800, Shiyang Ruan wrote:
> In order to introduce dax holder registration, we need a write lock for
> dax. Because of the rarity of notification failures and the infrequency
> of registration events, it would be better to be a global lock rather
> than
On Fri, Sep 17, 2021 at 08:33:04AM -0700, Darrick J. Wong wrote:
> > More importantly before we can merge this series we also need the VM
> > level support for reflink-aware reverse mapping. So while this series
> > here is no in a good enough shape I don't see how we could merge it
> > without
On Thu, Sep 16, 2021 at 11:40:28AM -0700, Dan Williams wrote:
> > That was my gut feeling. If everyone feels 100% comfortable with
> > zeroingas the mechanism to clear poisoning I'll cave in. The most
> > important bit is that we do that through a dedicated DAX path instead
> > of abusing the
On Wed, Sep 15, 2021 at 01:27:47PM -0700, Dan Williams wrote:
> > Yeah, Christoph suggested that we make the clearing operation explicit
> > in a related thread a few weeks ago:
> > https://lore.kernel.org/linux-fsdevel/yrtnlperhfmz2...@infradead.org/
>
> That seemed to be tied to a proposal to
On Wed, Sep 15, 2021 at 05:22:27PM -0700, Darrick J. Wong wrote:
> > xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> > ret = dax_iomap_fault(vmf, pe_size, , NULL,
> > (write_fault && !vmf->cow_page) ?
> > -
On Wed, Sep 15, 2021 at 06:45:00PM +0800, Shiyang Ruan wrote:
> +static int
> +xfs_dax_write_iomap_end(
> + struct inode*inode,
> + loff_t pos,
> + loff_t length,
> + ssize_t written,
> + unsigned
> -s64 dax_iomap_zero(loff_t pos, u64 length, struct iomap *iomap)
> +s64 dax_iomap_zero(struct iomap_iter *iter, loff_t pos, u64 length)
I think we can also mark the iter const.
Otherwise looks good:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
t;addr != iomap->addr) {
Should we also check that ->dax_dev for iomap and srcmap are different
first to deal with case of file system with multiple devices?
Otherwise looks good:
Reviewed-by: Christoph Hellwig
uan
> Reviewed-by: Darrick J. Wong
Looks good,
Reviewed-by: Christoph Hellwig
On Sun, Aug 29, 2021 at 08:25:16PM +0800, Shiyang Ruan wrote:
> In fsdax mode, WRITE and ZERO on a shared extent need CoW performed.
> After that, new allocated extents needs to be remapped to the file. Add
> an implementation of ->iomap_end() for dax write ops to do the remapping
> work.
Please
> +EXPORT_SYMBOL(vfs_dedupe_file_range_compare);
I don't see why this would need to be exported.
> @@ -370,6 +384,15 @@ int generic_remap_file_range_prep(struct file *file_in,
> loff_t pos_in,
>
> return ret;
> }
> +EXPORT_SYMBOL(__generic_remap_file_range_prep);
Same here.
On Sun, Aug 29, 2021 at 08:25:14PM +0800, Shiyang Ruan wrote:
> Punch hole on a reflinked file needs dax_iomap_cow_copy() too.
> Otherwise, data in not aligned area will be not correct. So, add the
> srcmap to dax_iomap_zero() and replace memset() as dax_iomap_cow_copy().
>
> Signed-off-by:
1 - 100 of 23087 matches
Mail list logo
