From: Dan Williams <hidden> Date: 2017-10-06 22:35:13
Changes since v6 [1]:
* Abandon the concept of immutable files and rework the implementation
to reuse same FL_LAYOUT file lease mechanism that coordinates pnfsd
layouts vs local filesystem changes. This establishes an interface where
the kernel is always in control of the block-map and is free to
invalidate MAP_DIRECT mappings when a lease breaker arrives. (Christoph)
* Introduce a new ->mmap_validate() file operation since we need both
the original @flags and @fd passed to mmap(2) to setup a MAP_DIRECT
mapping.
* Introduce a ->lease_direct() vm operation to allow the RDMA core to
safely register memory against DAX and tear down the mapping when the
lease is broken. This can be reused by any sub-system that follows a
memory registration semantic.
[1]: https://lkml.org/lkml/2017/8/23/754
---
MAP_DIRECT is a mechanism that allows an application to establish a
mapping where the kernel will not change the block-map, or otherwise
dirty the block-map metadata of a file without notification. It supports
a "flush from userspace" model where persistent memory applications can
bypass the overhead of ongoing coordination of writes with the
filesystem, and it provides safety to RDMA operations involving DAX
mappings.
The kernel always has the ability to revoke access and convert the file
back to normal operation after performing a "lease break". Similar to
fcntl leases, there is no way for userspace to to cancel the lease break
process once it has started, it can only delay it via the
/proc/sys/fs/lease-break-time setting.
MAP_DIRECT enables XFS to supplant the device-dax interface for
mmap-write access to persistent memory with no ongoing coordination with
the filesystem via fsync/msync syscalls.
---
Dan Williams (12):
mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags
fs, mm: pass fd to ->mmap_validate()
fs: introduce i_mapdcount
fs: MAP_DIRECT core
xfs: prepare xfs_break_layouts() for reuse with MAP_DIRECT
xfs: wire up MAP_DIRECT
dma-mapping: introduce dma_has_iommu()
fs, mapdirect: introduce ->lease_direct()
xfs: wire up ->lease_direct()
device-dax: wire up ->lease_direct()
IB/core: use MAP_DIRECT to fix / enable RDMA to DAX mappings
tools/testing/nvdimm: enable rdma unit tests
arch/alpha/include/uapi/asm/mman.h | 1
arch/mips/include/uapi/asm/mman.h | 1
arch/mips/kernel/vdso.c | 2
arch/parisc/include/uapi/asm/mman.h | 1
arch/tile/mm/elf.c | 3
arch/x86/mm/mpx.c | 3
arch/xtensa/include/uapi/asm/mman.h | 1
drivers/base/dma-mapping.c | 10 +
drivers/dax/device.c | 4
drivers/infiniband/core/umem.c | 90 ++++++-
drivers/iommu/amd_iommu.c | 6
drivers/iommu/intel-iommu.c | 6
fs/Kconfig | 4
fs/Makefile | 1
fs/aio.c | 2
fs/mapdirect.c | 349 ++++++++++++++++++++++++++
fs/xfs/Kconfig | 4
fs/xfs/Makefile | 1
fs/xfs/xfs_file.c | 130 ++++++++++
fs/xfs/xfs_iomap.c | 9 +
fs/xfs/xfs_layout.c | 42 +++
fs/xfs/xfs_layout.h | 13 +
fs/xfs/xfs_pnfs.c | 30 --
fs/xfs/xfs_pnfs.h | 10 -
include/linux/dma-mapping.h | 3
include/linux/fs.h | 33 ++
include/linux/mapdirect.h | 68 +++++
include/linux/mm.h | 15 +
include/linux/mman.h | 42 +++
include/rdma/ib_umem.h | 8 +
include/uapi/asm-generic/mman-common.h | 1
include/uapi/asm-generic/mman.h | 1
ipc/shm.c | 3
mm/internal.h | 2
mm/mmap.c | 28 ++
mm/nommu.c | 5
mm/util.c | 7 -
tools/include/uapi/asm-generic/mman-common.h | 1
tools/testing/nvdimm/Kbuild | 31 ++
tools/testing/nvdimm/config_check.c | 2
tools/testing/nvdimm/test/iomap.c | 6
41 files changed, 906 insertions(+), 73 deletions(-)
create mode 100644 fs/mapdirect.c
create mode 100644 fs/xfs/xfs_layout.c
create mode 100644 fs/xfs/xfs_layout.h
create mode 100644 include/linux/mapdirect.h
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dan Williams <hidden> Date: 2017-10-06 22:35:19
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a
mechanism to define new behavior that is known to fail on older kernels
without the support. Define a new MAP_SHARED_VALIDATE flag pattern that
is guaranteed to fail on all legacy mmap implementations.
It is worth noting that the original proposal was for a standalone
MAP_VALIDATE flag. However, when that could not be supported by all
archs Linus observed:
I see why you *think* you want a bitmap. You think you want
a bitmap because you want to make MAP_VALIDATE be part of MAP_SYNC
etc, so that people can do
ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED
| MAP_SYNC, fd, 0);
and "know" that MAP_SYNC actually takes.
And I'm saying that whole wish is bogus. You're fundamentally
depending on special semantics, just make it explicit. It's already
not portable, so don't try to make it so.
Rename that MAP_VALIDATE as MAP_SHARED_VALIDATE, make it have a value
of 0x3, and make people do
ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED_VALIDATE
| MAP_SYNC, fd, 0);
and then the kernel side is easier too (none of that random garbage
playing games with looking at the "MAP_VALIDATE bit", but just another
case statement in that map type thing.
Boom. Done.
Similar to ->fallocate() we also want the ability to validate the
support for new flags on a per ->mmap() 'struct file_operations'
instance basis. Towards that end arrange for flags to be generically
validated against a mmap_supported_mask exported by 'struct
file_operations'. By default all existing flags are implicitly
supported, but new flags require MAP_SHARED_VALIDATE and
per-instance-opt-in.
Cc: Jan Kara <redacted>
Cc: Arnd Bergmann <redacted>
Cc: Andy Lutomirski <redacted>
Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Suggested-by: Christoph Hellwig <redacted>
Suggested-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
---
arch/alpha/include/uapi/asm/mman.h | 1 +
arch/mips/include/uapi/asm/mman.h | 1 +
arch/mips/kernel/vdso.c | 2 +
arch/parisc/include/uapi/asm/mman.h | 1 +
arch/tile/mm/elf.c | 3 +-
arch/xtensa/include/uapi/asm/mman.h | 1 +
include/linux/fs.h | 2 +
include/linux/mm.h | 2 +
include/linux/mman.h | 39 ++++++++++++++++++++++++++
include/uapi/asm-generic/mman-common.h | 1 +
mm/mmap.c | 21 ++++++++++++--
tools/include/uapi/asm-generic/mman-common.h | 1 +
12 files changed, 69 insertions(+), 6 deletions(-)
@@ -14,6 +14,7 @@#define MAP_TYPE 0x0f /* Mask for type of mapping (OSF/1 is _wrong_) */#define MAP_FIXED 0x100 /* Interpret addr exactly */#define MAP_ANONYMOUS 0x10 /* don't use a file */+#define MAP_SHARED_VALIDATE 0x3 /* share + validate extension flags *//* not used by linux, but here to make sure we don't clash with OSF/1 defines */#define _MAP_HASSEMAPHORE 0x0200
@@ -30,6 +30,7 @@#define MAP_PRIVATE 0x002 /* Changes are private */#define MAP_TYPE 0x00f /* Mask for type of mapping */#define MAP_FIXED 0x010 /* Interpret addr exactly */+#define MAP_SHARED_VALIDATE 0x3 /* share + validate extension flags *//* not used by linux, but here to make sure we don't clash with ABI defines */#define MAP_RENAME 0x020 /* Assign page to file */
@@ -110,7 +110,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)base=mmap_region(NULL,STACK_TOP,PAGE_SIZE,VM_READ|VM_WRITE|VM_EXEC|VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,-0,NULL);+0,NULL,0);if(IS_ERR_VALUE(base)){ret=base;gotoout;
@@ -37,6 +37,7 @@#define MAP_PRIVATE 0x002 /* Changes are private */#define MAP_TYPE 0x00f /* Mask for type of mapping */#define MAP_FIXED 0x010 /* Interpret addr exactly */+#define MAP_SHARED_VALIDATE 0x3 /* share + validate extension flags *//* not used by linux, but here to make sure we don't clash with ABI defines */#define MAP_RENAME 0x020 /* Assign page to file */
@@ -1389,6 +1389,18 @@ unsigned long do_mmap(struct file *file, unsigned long addr,structinode*inode=file_inode(file);switch(flags&MAP_TYPE){+case(MAP_SHARED_VALIDATE):+if((flags&~LEGACY_MAP_MASK)==0){+/*+*Ifalllegacymmapflags,downgrade+*toMAP_SHARED,i.e.invoke->mmap()+*insteadof->mmap_validate()+*/+flags&=~MAP_TYPE;+flags|=MAP_SHARED;+}elseif(!file->f_op->mmap_validate)+return-EOPNOTSUPP;+/* fall through */caseMAP_SHARED:if((prot&PROT_WRITE)&&!(file->f_mode&FMODE_WRITE))return-EACCES;
@@ -1465,7 +1477,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr,vm_flags|=VM_NORESERVE;}-addr=mmap_region(file,addr,len,vm_flags,pgoff,uf);+addr=mmap_region(file,addr,len,vm_flags,pgoff,uf,flags);if(!IS_ERR_VALUE(addr)&&((vm_flags&VM_LOCKED)||(flags&(MAP_POPULATE|MAP_NONBLOCK))==MAP_POPULATE))
@@ -24,6 +24,7 @@#else# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */#endif+#define MAP_SHARED_VALIDATE 0x3 /* share + validate extension flags *//**Flagsformlock--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dan Williams <hidden> Date: 2017-10-06 22:35:27
The MAP_DIRECT mechanism for mmap intends to use a file lease to prevent
block map changes while the file is mapped. It requires the fd to setup
an fasync_struct for signalling lease break events to the lease holder.
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
---
arch/mips/kernel/vdso.c | 2 +-
arch/tile/mm/elf.c | 2 +-
arch/x86/mm/mpx.c | 3 ++-
fs/aio.c | 2 +-
include/linux/fs.h | 2 +-
include/linux/mm.h | 9 +++++----
ipc/shm.c | 3 ++-
mm/internal.h | 2 +-
mm/mmap.c | 13 +++++++------
mm/nommu.c | 5 +++--
mm/util.c | 7 ++++---
11 files changed, 28 insertions(+), 22 deletions(-)
@@ -110,7 +110,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)base=mmap_region(NULL,STACK_TOP,PAGE_SIZE,VM_READ|VM_WRITE|VM_EXEC|VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,-0,NULL,0);+0,NULL,0,-1);if(IS_ERR_VALUE(base)){ret=base;gotoout;
@@ -52,7 +52,8 @@ static unsigned long mpx_mmap(unsigned long len)down_write(&mm->mmap_sem);addr=do_mmap(NULL,0,len,PROT_READ|PROT_WRITE,-MAP_ANONYMOUS|MAP_PRIVATE,VM_MPX,0,&populate,NULL);+MAP_ANONYMOUS|MAP_PRIVATE,VM_MPX,0,&populate,+NULL,-1);up_write(&mm->mmap_sem);if(populate)mm_populate(addr,populate);
From: Dan Williams <hidden> Date: 2017-10-06 22:35:32
When ->iomap_begin() sees this count being non-zero and determines that
the block map of the file needs to be modified to satisfy the I/O
request it will instead return an error. This is needed for MAP_DIRECT
where, due to locking constraints, we can't rely on xfs_break_layouts()
to protect against allocating write-faults either from the process that
setup the MAP_DIRECT mapping nor other processes that have the file
mapped. xfs_break_layouts() requires XFS_IOLOCK which is problematic to
mix with the XFS_MMAPLOCK in the fault path.
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/xfs_iomap.c | 9 +++++++++
include/linux/fs.h | 31 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:35:38
Introduce a set of helper apis for filesystems to establish FL_LAYOUT
leases to protect against writes and block map updates while a
MAP_DIRECT mapping is established. While the lease protects against the
syscall write path and fallocate it does not protect against allocating
write-faults, so this relies on i_mapdcount to disable block map updates
from write faults.
Like the pnfs case MAP_DIRECT does its own timeout of the lease since we
need to have a process context for running map_direct_invalidate().
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/Makefile | 2
fs/mapdirect.c | 232 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mapdirect.h | 45 +++++++++
3 files changed, 278 insertions(+), 1 deletion(-)
create mode 100644 fs/mapdirect.c
create mode 100644 include/linux/mapdirect.h
@@ -0,0 +1,232 @@+/*+*Copyright(c)2017IntelCorporation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsofversion2oftheGNUGeneralPublicLicenseas+*publishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,but+*WITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.SeetheGNU+*GeneralPublicLicenseformoredetails.+*/+#include<linux/mapdirect.h>+#include<linux/workqueue.h>+#include<linux/signal.h>+#include<linux/mutex.h>+#include<linux/sched.h>+#include<linux/slab.h>+#include<linux/fs.h>+#include<linux/mm.h>++#define MAPDIRECT_BREAK 0+#define MAPDIRECT_VALID 1++structmap_direct_state{+atomic_tmds_ref;+atomic_tmds_vmaref;+unsignedlongmds_state;+structinode*mds_inode;+structdelayed_workmds_work;+structfasync_struct*mds_fa;+structvm_area_struct*mds_vma;+};++boolis_map_direct_valid(structmap_direct_state*mds)+{+returntest_bit(MAPDIRECT_VALID,&mds->mds_state);+}+EXPORT_SYMBOL_GPL(is_map_direct_valid);++staticvoidput_map_direct(structmap_direct_state*mds)+{+if(!atomic_dec_and_test(&mds->mds_ref))+return;+kfree(mds);+}++intput_map_direct_vma(structmap_direct_state*mds)+{+structvm_area_struct*vma=mds->mds_vma;+structfile*file=vma->vm_file;+structinode*inode=file_inode(file);+void*owner=mds;++if(!atomic_dec_and_test(&mds->mds_vmaref))+return0;++/*+*Flushin-flight+forcedlm_breakeventsthatmaybe+*referencingthisdyingvma.+*/+mds->mds_vma=NULL;+set_bit(MAPDIRECT_BREAK,&mds->mds_state);+vfs_setlease(vma->vm_file,F_UNLCK,NULL,&owner);+flush_delayed_work(&mds->mds_work);+iput(inode);++put_map_direct(mds);+return1;+}+EXPORT_SYMBOL_GPL(put_map_direct_vma);++voidget_map_direct_vma(structmap_direct_state*mds)+{+atomic_inc(&mds->mds_vmaref);+}+EXPORT_SYMBOL_GPL(get_map_direct_vma);++staticvoidmap_direct_invalidate(structwork_struct*work)+{+structmap_direct_state*mds;+structvm_area_struct*vma;+structinode*inode;+void*owner;++mds=container_of(work,typeof(*mds),mds_work.work);++clear_bit(MAPDIRECT_VALID,&mds->mds_state);++vma=ACCESS_ONCE(mds->mds_vma);+inode=mds->mds_inode;+if(vma){+unsignedlonglen=vma->vm_end-vma->vm_start;+loff_tstart=(loff_t)vma->vm_pgoff*PAGE_SIZE;++unmap_mapping_range(inode->i_mapping,start,len,1);+}+owner=mds;+vfs_setlease(vma->vm_file,F_UNLCK,NULL,&owner);++put_map_direct(mds);+}++staticboolmap_direct_lm_break(structfile_lock*fl)+{+structmap_direct_state*mds=fl->fl_owner;++/*+*Giventhatweneedtotakesleepinglockstoinvalidatethe+*mappingweschedulethatworkwiththeoriginaltimeoutset+*bythefile-lockscore.Thenwetellthecoretoholdoffon+*continuingwiththeleasebreakuntilthedelayedwork+*completestheinvalidationandtheleaseunlock.+*+*Notethatthisassumesthati_mapdcountisprotectingagainst+*block-mapmodifyingwrite-faultssinceweareunabletouse+*leasesinthatpathduetolockingconstraints.+*/+if(!test_and_set_bit(MAPDIRECT_BREAK,&mds->mds_state)){+schedule_delayed_work(&mds->mds_work,lease_break_time*HZ);+kill_fasync(&fl->fl_fasync,SIGIO,POLL_MSG);+}++/* Tell the core lease code to wait for delayed work completion */+fl->fl_break_time=0;++returnfalse;+}++staticintmap_direct_lm_change(structfile_lock*fl,intarg,+structlist_head*dispose)+{+structmap_direct_state*mds=fl->fl_owner;++WARN_ON(!(arg&F_UNLCK));++i_mapdcount_dec(mds->mds_inode);+returnlease_modify(fl,arg,dispose);+}++staticvoidmap_direct_lm_setup(structfile_lock*fl,void**priv)+{+structfile*file=fl->fl_file;+structmap_direct_state*mds=*priv;+structfasync_struct*fa=mds->mds_fa;++/*+*Commentcopiedfromlease_setup():+*fasync_insert_entry()returnstheoldentryifany.Iftherewasno+*oldentry,thenitused"priv"andinserteditintothefasynclist.+*Clearthepointertoindicatethatitshouldn'tbefreed.+*/+if(!fasync_insert_entry(fa->fa_fd,file,&fl->fl_fasync,fa))+*priv=NULL;++__f_setown(file,task_pid(current),PIDTYPE_PID,0);+}++staticconststructlock_manager_operationsmap_direct_lm_ops={+.lm_break=map_direct_lm_break,+.lm_change=map_direct_lm_change,+.lm_setup=map_direct_lm_setup,+};++structmap_direct_state*map_direct_register(intfd,structvm_area_struct*vma)+{+structmap_direct_state*mds=kzalloc(sizeof(*mds),GFP_KERNEL);+structfile*file=vma->vm_file;+structinode*inode=file_inode(file);+structfasync_struct*fa;+structfile_lock*fl;+void*owner=mds;+intrc=-ENOMEM;++if(!mds)+returnERR_PTR(-ENOMEM);++mds->mds_vma=vma;+atomic_set(&mds->mds_ref,1);+atomic_set(&mds->mds_vmaref,1);+set_bit(MAPDIRECT_VALID,&mds->mds_state);+mds->mds_inode=inode;+ihold(inode);+INIT_DELAYED_WORK(&mds->mds_work,map_direct_invalidate);++fa=fasync_alloc();+if(!fa)+gotoerr_fasync_alloc;+mds->mds_fa=fa;+fa->fa_fd=fd;++fl=locks_alloc_lock();+if(!fl)+gotoerr_lock_alloc;++locks_init_lock(fl);+fl->fl_lmops=&map_direct_lm_ops;+fl->fl_flags=FL_LAYOUT;+fl->fl_type=F_RDLCK;+fl->fl_end=OFFSET_MAX;+fl->fl_owner=mds;+atomic_inc(&mds->mds_ref);+fl->fl_pid=current->tgid;+fl->fl_file=file;++rc=vfs_setlease(file,fl->fl_type,&fl,&owner);+if(rc)+gotoerr_setlease;+if(fl){+WARN_ON(1);+owner=mds;+vfs_setlease(file,F_UNLCK,NULL,&owner);+owner=NULL;+rc=-ENXIO;+gotoerr_setlease;+}++i_mapdcount_inc(inode);+returnmds;++err_setlease:+locks_free_lock(fl);+err_lock_alloc:+/* if owner is NULL then the lease machinery is reponsible @fa */+if(owner)+fasync_free(fa);+err_fasync_alloc:+iput(inode);+kfree(mds);+returnERR_PTR(rc);+}+EXPORT_SYMBOL_GPL(map_direct_register);
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dan Williams <hidden> Date: 2017-10-06 22:35:44
Move xfs_break_layouts() to its own compilation unit so that it can be
used for both pnfs layouts and MAP_DIRECT mappings.
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/Kconfig | 4 ++++
fs/xfs/Makefile | 1 +
fs/xfs/xfs_layout.c | 42 ++++++++++++++++++++++++++++++++++++++++++
fs/xfs/xfs_layout.h | 13 +++++++++++++
fs/xfs/xfs_pnfs.c | 30 ------------------------------
fs/xfs/xfs_pnfs.h | 10 ++--------
6 files changed, 62 insertions(+), 38 deletions(-)
create mode 100644 fs/xfs/xfs_layout.c
create mode 100644 fs/xfs/xfs_layout.h
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:35:49
MAP_DIRECT is an mmap(2) flag with the following semantics:
MAP_DIRECT
When specified with MAP_SHARED_VALIDATE, sets up a file lease with the
same lifetime as the mapping. Unlike a typical F_RDLCK lease this lease
is broken when a "lease breaker" attempts to write(2), change the block
map (fallocate), or change the size of the file. Otherwise the mechanism
of a lease break is identical to the typical lease break case where the
lease needs to be removed (munmap) within the number of seconds
specified by /proc/sys/fs/lease-break-time. If the lease holder fails to
remove the lease in time the kernel will invalidate the mapping and
force all future accesses to the mapping to trigger SIGBUS.
In addition to lease break timeouts causing faults in the mapping to
result in SIGBUS, other states of the file will trigger SIGBUS at fault
time:
* The file is not DAX capable
* The file has reflinked (copy-on-write) blocks
* The fault would trigger the filesystem to allocate blocks
* The fault would trigger the filesystem to perform extent conversion
In other words, MAP_DIRECT expects and enforces a fully allocated file
where faults can be satisfied without modifying block map metadata.
An unprivileged process may establish a MAP_DIRECT mapping on a file
whose UID (owner) matches the filesystem UID of the process. A process
with the CAP_LEASE capability may establish a MAP_DIRECT mapping on
arbitrary files
ERRORS
EACCES Beyond the typical mmap(2) conditions that trigger EACCES
MAP_DIRECT also requires the permission to set a file lease.
EOPNOTSUPP The filesystem explicitly does not support the flag
SIGBUS Attempted to write a MAP_DIRECT mapping at a file offset that
might require block-map updates, or the lease timed out and the
kernel invalidated the mapping.
Cc: Jan Kara <jack@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/Kconfig | 2 -
fs/xfs/xfs_file.c | 102 +++++++++++++++++++++++++++++++++++++++
include/linux/mman.h | 3 +
include/uapi/asm-generic/mman.h | 1
4 files changed, 106 insertions(+), 2 deletions(-)
@@ -12,6 +12,7 @@#define MAP_NONBLOCK 0x10000 /* do not block on IO */#define MAP_STACK 0x20000 /* give out an address that is best suited for process/thread stacks */#define MAP_HUGETLB 0x40000 /* create a huge page mapping */+#define MAP_DIRECT 0x80000 /* leased block map (layout) for DAX *//* Bits [26:31] are reserved, see mman-common.h for MAP_HUGETLB usage */--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:35:54
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
Since PMEM+DAX is currently only enabled for x86, we only update the x86
iommu drivers.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ashok Raj <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Signed-off-by: Dan Williams <redacted>
---
drivers/base/dma-mapping.c | 10 ++++++++++
drivers/iommu/amd_iommu.c | 6 ++++++
drivers/iommu/intel-iommu.c | 6 ++++++
include/linux/dma-mapping.h | 3 +++
4 files changed, 25 insertions(+)
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:36:00
Provide a vma operation that registers a lease that is broken by
break_layout(). This is motivated by a need to stop in-progress RDMA
when the block-map of a DAX-file changes. I.e. since DAX gives
direct-access to filesystem blocks we can not allow those blocks to move
or change state while they are under active RDMA. So, if the filesystem
determines it needs to move blocks it can revoke device access before
proceeding.
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/mapdirect.c | 117 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mapdirect.h | 23 +++++++++
include/linux/mm.h | 6 ++
3 files changed, 146 insertions(+)
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dan Williams <hidden> Date: 2017-10-06 22:36:06
A 'lease_direct' lease requires that the vma have a valid MAP_DIRECT
mapping established. For xfs we establish a new lease and then check if
the MAP_DIRECT mapping has been broken. We want to be sure that the
process will receive notification that the MAP_DIRECT mapping is being
torn down so it knows why other code paths are throwing failures.
For example in the RDMA/ibverbs case we want ibv_reg_mr() to fail if the
MAP_DIRECT mapping is invalid or in the process of being invalidated.
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/xfs_file.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:36:11
The only event that will break a lease_direct lease in the device-dax
case is the device shutdown path where the physical pages might get
assigned to another device.
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
---
drivers/dax/device.c | 4 ++++
fs/Kconfig | 4 ++++
fs/Makefile | 3 ++-
include/linux/mapdirect.h | 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
From: Dan Williams <hidden> Date: 2017-10-06 22:36:17
Currently the ibverbs core in the kernel is completely unaware of the
dangers of filesystem-DAX mappings. Specifically, the filesystem is free
to move file blocks at will. In the case of DAX, it means that RDMA to a
given file offset can dynamically switch to another file offset, another
file, or free space with no notification to RDMA device to cease
operations. Historically, this lack of communication between the ibverbs
core and filesystem was not a problem because RDMA always targeted
dynamically allocated page cache, so at least the RDMA device would have
valid memory to target even if the file was being modified. With DAX we
need to add coordination since RDMA is bypassing page-cache and going
direct to on-media pages of the file. RDMA to DAX can cause damage if
filesystem blocks move / change state.
Use the new ->lease_direct() operation to get a notification when the
filesystem is invalidating the block map of the file and needs RDMA
operations to stop. Given that the kernel can not be in a position where
it needs to wait indefinitely for userspace to stop a device we need a
mechanism where the kernel can force-revoke access. Towards that end, use
the new dma_has_iommu() helper to determine if ib_dma_unmap_sg() is
sufficient for revoking access. Once we have that assurance and a
->lease_direct() lease we can safely allow RDMA to DAX.
Cc: Sean Hefty <redacted>
Cc: Doug Ledford <redacted>
Cc: Hal Rosenstock <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
drivers/infiniband/core/umem.c | 90 ++++++++++++++++++++++++++++++++++------
include/rdma/ib_umem.h | 8 ++++
2 files changed, 85 insertions(+), 13 deletions(-)
@@ -55,6 +56,13 @@ struct ib_umem {structsg_tablesg_head;intnmap;intnpages;+/*+*Note:nolockprotectsthislistsinceweassumememory+*registrationneverracesunregistrationforagivenib_umem+*instance.+*/+structlist_headleases;+unsignedlongstate;};/* Returns the offset of the umem start relative to the first page. */--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 22:36:22
Provide a mock dma_has_iommu() for the ibverbs core. Enable
ib_umem_get() to satisfy its DAX safety checks for a controlled test.
Signed-off-by: Dan Williams <redacted>
---
tools/testing/nvdimm/Kbuild | 31 +++++++++++++++++++++++++++++++
tools/testing/nvdimm/config_check.c | 2 ++
tools/testing/nvdimm/test/iomap.c | 6 ++++++
3 files changed, 39 insertions(+)
From: David Woodhouse <dwmw2@infradead.org> Date: 2017-10-06 22:45:39
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
From: Dan Williams <hidden> Date: 2017-10-06 22:52:34
On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse [off-list ref] wrote:
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
quoted
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
I'm assuming the next map will be to other physical addresses and a
different requester device since the memory is still registered
exclusively.
From: David Woodhouse <dwmw2@infradead.org> Date: 2017-10-06 23:10:34
On Fri, 2017-10-06 at 15:52 -0700, Dan Williams wrote:
On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse [off-list ref] wrote:
quoted
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
quoted
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
I'm assuming the next map will be to other physical addresses and a
different requester device since the memory is still registered
exclusively.
I meant the next map for this device/group.
It may well use the same virtual DMA address as the one you just
unmapped, yet actually map to a different physical address. So if the
DMA still occurs to the "old" address, that isn't revoked at all — it's
just going to the wrong physical location.
And if you are sure that the DMA will never happen, why do you need to
revoke the mapping in the first place?
From: Dan Williams <hidden> Date: 2017-10-06 23:12:27
On Fri, Oct 6, 2017 at 3:52 PM, Dan Williams [off-list ref] wrote:
On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse [off-list ref] wrote:
quoted
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
quoted
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
I'm assuming the next map will be to other physical addresses and a
different requester device since the memory is still registered
exclusively.
[ chatted with Ashok ]
Yes, it seems we need a way to pin that IOVA as in use, but invalidate
it. Then we can wait for the unmap to occur when the memory is
unregistered to avoid this IOVA reuse problem.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-06 23:15:08
On Fri, Oct 6, 2017 at 4:10 PM, David Woodhouse [off-list ref] wrote:
On Fri, 2017-10-06 at 15:52 -0700, Dan Williams wrote:
quoted
On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse [off-list ref] wrote:
quoted
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
quoted
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
I'm assuming the next map will be to other physical addresses and a
different requester device since the memory is still registered
exclusively.
I meant the next map for this device/group.
It may well use the same virtual DMA address as the one you just
unmapped, yet actually map to a different physical address. So if the
DMA still occurs to the "old" address, that isn't revoked at all — it's
just going to the wrong physical location.
And if you are sure that the DMA will never happen, why do you need to
revoke the mapping in the first place?
Right, crossed mails. The semantic I want is that the IOVA is
invalidated / starts throwing errors to the device because the address
it thought it was talking to has been remapped in the file. Once
userspace wakes up and responds to this invalidation event it can do
the actual unmap to make the IOVA reusable again.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
From: David Woodhouse <dwmw2@infradead.org> Date: 2017-10-07 11:08:44
On Fri, 2017-10-06 at 16:15 -0700, Dan Williams wrote:
Right, crossed mails. The semantic I want is that the IOVA is
invalidated / starts throwing errors to the device because the address
it thought it was talking to has been remapped in the file. Once
userspace wakes up and responds to this invalidation event it can do
the actual unmap to make the IOVA reusable again.
So basically you want to unmap it by removing it from the page tables
and flushing the IOTLB, but you want the IOVA to still be reserved.
The normal device-facing DMA API doesn't give you that today. You could
do it with the IOMMU API though — that one does let you manage the IOVA
space yourself. You don't want that IOVA used again? Well don't use it
as the IOVA in a subsequent iommu_map() call then :)
From: Dan Williams <hidden> Date: 2017-10-07 23:33:36
On Sat, Oct 7, 2017 at 4:08 AM, David Woodhouse [off-list ref] wrote:
On Fri, 2017-10-06 at 16:15 -0700, Dan Williams wrote:
quoted
Right, crossed mails. The semantic I want is that the IOVA is
invalidated / starts throwing errors to the device because the address
it thought it was talking to has been remapped in the file. Once
userspace wakes up and responds to this invalidation event it can do
the actual unmap to make the IOVA reusable again.
So basically you want to unmap it by removing it from the page tables
and flushing the IOTLB, but you want the IOVA to still be reserved.
The normal device-facing DMA API doesn't give you that today. You could
do it with the IOMMU API though — that one does let you manage the IOVA
space yourself. You don't want that IOVA used again? Well don't use it
as the IOVA in a subsequent iommu_map() call then :)
Ah, nice. So I think I'll just add a dma_get_iommu_domain() so the
dma_ops implementation can exclude identity-mapped devices, and then
iommu_unmap() does the rest. Thanks for the pointer.
From: Dan Williams <hidden> Date: 2017-10-08 03:45:00
Add a dma-mapping api helper to retrieve the generic iommu_domain for a device.
The motivation for this interface is making RDMA transfers to DAX mappings
safe. If the DAX file's block map changes we need to be to reliably stop
accesses to blocks that have been freed or re-assigned to a new file. With the
iommu_domain and a callback from the DAX filesystem the kernel can safely
revoke access to a DMA device. The process that performed the RDMA memory
registration is also notified of this revocation event, but the kernel can not
otherwise be in the position of waiting for userspace to quiesce the device.
Since PMEM+DAX is currently only enabled for x86, we only update the x86
iommu drivers.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ashok Raj <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Signed-off-by: Dan Williams <redacted>
---
Changes since v7:
* retrieve the iommu_domain so that we can later pass the results of
dma_map_* to iommu_unmap() in advance of the actual dma_unmap_*.
drivers/base/dma-mapping.c | 10 ++++++++++
drivers/iommu/amd_iommu.c | 10 ++++++++++
drivers/iommu/intel-iommu.c | 15 +++++++++++++++
include/linux/dma-mapping.h | 3 +++
4 files changed, 38 insertions(+)
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-08 04:02:45
iommu_sg_num_pages() is a helper that walks a scattlerlist and counts
pages taking segment boundaries and iommu_num_pages() into account.
Up-level it for determining the IOVA range that dma_map_ops established
at dma_map_sg() time. The intent is to iommu_unmap() the IOVA range in
advance of freeing IOVA range.
Cc: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Dan Williams <redacted>
---
New patch in v8.
drivers/iommu/amd_iommu.c | 30 ++----------------------------
drivers/iommu/iommu.c | 27 +++++++++++++++++++++++++++
include/linux/iommu.h | 2 ++
3 files changed, 31 insertions(+), 28 deletions(-)
From: Dan Williams <hidden> Date: 2017-10-08 04:04:04
Currently the ibverbs core in the kernel is completely unaware of the
dangers of filesystem-DAX mappings. Specifically, the filesystem is free
to move file blocks at will. In the case of DAX, it means that RDMA to a
given file offset can dynamically switch to another file offset, another
file, or free space with no notification to RDMA device to cease
operations. Historically, this lack of communication between the ibverbs
core and filesystem was not a problem because RDMA always targeted
dynamically allocated page cache, so at least the RDMA device would have
valid memory to target even if the file was being modified. With DAX we
need to add coordination since RDMA is bypassing page-cache and going
direct to on-media pages of the file. RDMA to DAX can cause damage if
filesystem blocks move / change state.
Use the new ->lease_direct() operation to get a notification when the
filesystem is invalidating the block map of the file and needs RDMA
operations to stop. Given that the kernel can not be in a position where
it needs to wait indefinitely for userspace to stop a device we need a
mechanism where the kernel can force-revoke access. Towards that end, use
the dma_get_iommu_domain() to both check if the device has domain
mappings that can be invalidated and retrieve the iommu_domain for use
with iommu_unmap.
Once we have that assurance that we can block in-flight I/O when the
file's block map changes then we can safely allow RDMA to DAX.
Cc: Sean Hefty <redacted>
Cc: Doug Ledford <redacted>
Cc: Hal Rosenstock <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ashok Raj <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
Changes since v7:
* Switch from dma_has_iommu() to dma_get_iommu_domain().
* Switch from dma_unmap_sg() at lease break time, to iommu_unmap() so
that the IOVA remains allocated while the device might still be
sending transactions.
drivers/infiniband/core/umem.c | 90 +++++++++++++++++++++++++++++++++++-----
include/rdma/ib_umem.h | 8 ++++
2 files changed, 86 insertions(+), 12 deletions(-)
@@ -55,6 +56,13 @@ struct ib_umem {structsg_tablesg_head;intnmap;intnpages;+/*+*Note:nolockprotectsthislistsinceweassumememory+*registrationneverracesunregistrationforagivenib_umem+*instance.+*/+structlist_headleases;+structiommu_domain*iommu;};/* Returns the offset of the umem start relative to the first page. */--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-08 15:49:33
On Sat, Oct 7, 2017 at 11:45 PM, kbuild test robot [off-list ref] wrote:
Hi Dan,
[auto build test ERROR on rdma/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
This was a fixed up resend of patch [v7 11/12]. It's not clear how to
teach the kbuild robot to be aware of patch-replies to individual
patches in the series. I.e. reworked patches without resending the
complete series?
drivers/infiniband/core/umem.c:39:29: fatal error: linux/mapdirect.h: No such file or directory
#include <linux/mapdirect.h>
mapdirect.h indeed does not exist when missing the earlier patches in
the series. It would be slick if the 0day-robot read the the
"in-reply-to" header and auto replaced a patch in a series, but that
would be a feature approaching magic.
compilation terminated.
vim +39 drivers/infiniband/core/umem.c
> 39 #include <linux/mapdirect.h>
40 #include <linux/export.h>
41 #include <linux/hugetlb.h>
42 #include <linux/slab.h>
43 #include <rdma/ib_umem_odp.h>
44
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: Dave Chinner <david@fromorbit.com> Date: 2017-10-09 03:08:24
On Fri, Oct 06, 2017 at 03:35:32PM -0700, Dan Williams wrote:
quoted hunk
When ->iomap_begin() sees this count being non-zero and determines that
the block map of the file needs to be modified to satisfy the I/O
request it will instead return an error. This is needed for MAP_DIRECT
where, due to locking constraints, we can't rely on xfs_break_layouts()
to protect against allocating write-faults either from the process that
setup the MAP_DIRECT mapping nor other processes that have the file
mapped. xfs_break_layouts() requires XFS_IOLOCK which is problematic to
mix with the XFS_MMAPLOCK in the fault path.
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/xfs_iomap.c | 9 +++++++++
include/linux/fs.h | 31 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
That looks really fragile. For one, it's going to miss modifications
to reflinked files altogether. Ignoring that, however, I don't want to
have to care one bit about the internals of the MAP_DIRECT
implementation in the filesystem code. Hide it behind something with
an obvious name that returns the appropriate error and the
filesystem code becomes self documenting:
if ((flags & IOMAP_WRITE) && imap_needs_alloc(inode, &imap, nimaps)) {
.....
error = iomap_can_allocate(inode);
if (error)
goto out_unlock;
Then you can put all the MAP_DIRECT stuff and the comments
explaining what is does inside the generic function that determines
if we are allowed to allocate on that inode or not.
quoted hunk
+ /*
* We cap the maximum length we map here to MAX_WRITEBACK_PAGES
* pages to keep the chunks of work done where somewhat symmetric
* with the work writeback does. This is a completely arbitrary
Is there any way to avoid growing the struct inode for this?
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dave Chinner <david@fromorbit.com> Date: 2017-10-09 03:40:30
On Fri, Oct 06, 2017 at 03:35:49PM -0700, Dan Williams wrote:
quoted hunk
MAP_DIRECT is an mmap(2) flag with the following semantics:
MAP_DIRECT
When specified with MAP_SHARED_VALIDATE, sets up a file lease with the
same lifetime as the mapping. Unlike a typical F_RDLCK lease this lease
is broken when a "lease breaker" attempts to write(2), change the block
map (fallocate), or change the size of the file. Otherwise the mechanism
of a lease break is identical to the typical lease break case where the
lease needs to be removed (munmap) within the number of seconds
specified by /proc/sys/fs/lease-break-time. If the lease holder fails to
remove the lease in time the kernel will invalidate the mapping and
force all future accesses to the mapping to trigger SIGBUS.
In addition to lease break timeouts causing faults in the mapping to
result in SIGBUS, other states of the file will trigger SIGBUS at fault
time:
* The file is not DAX capable
* The file has reflinked (copy-on-write) blocks
* The fault would trigger the filesystem to allocate blocks
* The fault would trigger the filesystem to perform extent conversion
In other words, MAP_DIRECT expects and enforces a fully allocated file
where faults can be satisfied without modifying block map metadata.
An unprivileged process may establish a MAP_DIRECT mapping on a file
whose UID (owner) matches the filesystem UID of the process. A process
with the CAP_LEASE capability may establish a MAP_DIRECT mapping on
arbitrary files
ERRORS
EACCES Beyond the typical mmap(2) conditions that trigger EACCES
MAP_DIRECT also requires the permission to set a file lease.
EOPNOTSUPP The filesystem explicitly does not support the flag
SIGBUS Attempted to write a MAP_DIRECT mapping at a file offset that
might require block-map updates, or the lease timed out and the
kernel invalidated the mapping.
Cc: Jan Kara <jack@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/Kconfig | 2 -
fs/xfs/xfs_file.c | 102 +++++++++++++++++++++++++++++++++++++++
include/linux/mman.h | 3 +
include/uapi/asm-generic/mman.h | 1
4 files changed, 106 insertions(+), 2 deletions(-)
Urk. That's nasty. And why is it even necessary? Please explain why
this is necessary in the comment, because it's not at all obvious to
me...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
From: Dave Chinner <david@fromorbit.com> Date: 2017-10-09 03:45:06
On Fri, Oct 06, 2017 at 03:36:06PM -0700, Dan Williams wrote:
quoted hunk
A 'lease_direct' lease requires that the vma have a valid MAP_DIRECT
mapping established. For xfs we establish a new lease and then check if
the MAP_DIRECT mapping has been broken. We want to be sure that the
process will receive notification that the MAP_DIRECT mapping is being
torn down so it knows why other code paths are throwing failures.
For example in the RDMA/ibverbs case we want ibv_reg_mr() to fail if the
MAP_DIRECT mapping is invalid or in the process of being invalidated.
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/xfs_file.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
What's any of this got to do with XFS? Shouldn't it be in generic
code, and called generic_filemap_direct_lease()?
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
From: Robin Murphy <robin.murphy@arm.com> Date: 2017-10-09 10:37:04
Hi Dan,
On 08/10/17 04:45, Dan Williams wrote:
Add a dma-mapping api helper to retrieve the generic iommu_domain for a device.
The motivation for this interface is making RDMA transfers to DAX mappings
safe. If the DAX file's block map changes we need to be to reliably stop
accesses to blocks that have been freed or re-assigned to a new file.
...which is also going to require some way to force the IOMMU drivers
(on x86 at least) to do a fully-synchronous unmap, instead of just
throwing the IOVA onto a flush queue to invalidate the TLBs at some
point in the future. Assuming of course that there's an IOMMU both
present and performing DMA translation in the first place.
With the
iommu_domain and a callback from the DAX filesystem the kernel can safely
revoke access to a DMA device. The process that performed the RDMA memory
registration is also notified of this revocation event, but the kernel can not
otherwise be in the position of waiting for userspace to quiesce the device.
OK, but why reinvent iommu_get_domain_for_dev()?
Since PMEM+DAX is currently only enabled for x86, we only update the x86
iommu drivers.
Note in particular that those two drivers happen to be the *only* place
this approach could work - everyone else is going to have to fall back
to the generic IOMMU API function anyway.
Robin.
quoted hunk
Cc: Marek Szyprowski <redacted>
Cc: Robin Murphy <redacted>
Cc: Greg Kroah-Hartman <redacted>
Cc: Joerg Roedel <redacted>
Cc: David Woodhouse <redacted>
Cc: Ashok Raj <redacted>
Cc: Jan Kara <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
---
Changes since v7:
* retrieve the iommu_domain so that we can later pass the results of
dma_map_* to iommu_unmap() in advance of the actual dma_unmap_*.
drivers/base/dma-mapping.c | 10 ++++++++++
drivers/iommu/amd_iommu.c | 10 ++++++++++
drivers/iommu/intel-iommu.c | 15 +++++++++++++++
include/linux/dma-mapping.h | 3 +++
4 files changed, 38 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Dan Williams <hidden> Date: 2017-10-09 17:08:40
On Sun, Oct 8, 2017 at 8:40 PM, Dave Chinner [off-list ref] wrote:
Thanks for the review Dave.
On Fri, Oct 06, 2017 at 03:35:49PM -0700, Dan Williams wrote:
quoted
MAP_DIRECT is an mmap(2) flag with the following semantics:
MAP_DIRECT
When specified with MAP_SHARED_VALIDATE, sets up a file lease with the
same lifetime as the mapping. Unlike a typical F_RDLCK lease this lease
is broken when a "lease breaker" attempts to write(2), change the block
map (fallocate), or change the size of the file. Otherwise the mechanism
of a lease break is identical to the typical lease break case where the
lease needs to be removed (munmap) within the number of seconds
specified by /proc/sys/fs/lease-break-time. If the lease holder fails to
remove the lease in time the kernel will invalidate the mapping and
force all future accesses to the mapping to trigger SIGBUS.
In addition to lease break timeouts causing faults in the mapping to
result in SIGBUS, other states of the file will trigger SIGBUS at fault
time:
* The file is not DAX capable
* The file has reflinked (copy-on-write) blocks
* The fault would trigger the filesystem to allocate blocks
* The fault would trigger the filesystem to perform extent conversion
In other words, MAP_DIRECT expects and enforces a fully allocated file
where faults can be satisfied without modifying block map metadata.
An unprivileged process may establish a MAP_DIRECT mapping on a file
whose UID (owner) matches the filesystem UID of the process. A process
with the CAP_LEASE capability may establish a MAP_DIRECT mapping on
arbitrary files
ERRORS
EACCES Beyond the typical mmap(2) conditions that trigger EACCES
MAP_DIRECT also requires the permission to set a file lease.
EOPNOTSUPP The filesystem explicitly does not support the flag
SIGBUS Attempted to write a MAP_DIRECT mapping at a file offset that
might require block-map updates, or the lease timed out and the
kernel invalidated the mapping.
Cc: Jan Kara <redacted>
Cc: Arnd Bergmann <redacted>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <redacted>
Cc: Dave Chinner <redacted>
Cc: Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/Kconfig | 2 -
fs/xfs/xfs_file.c | 102 +++++++++++++++++++++++++++++++++++++++
include/linux/mman.h | 3 +
include/uapi/asm-generic/mman.h | 1
4 files changed, 106 insertions(+), 2 deletions(-)
Exactly what are we checking for - function name doesn't tell me,
and there's no comments, either?
Ok, I'll improve this.
quoted
+{
+ if (!is_xfs_map_direct(vma))
+ return 0;
+
+ if (!is_map_direct_valid(vma->vm_private_data))
+ return VM_FAULT_SIGBUS;
+
+ if (xfs_is_reflink_inode(XFS_I(inode)))
+ return VM_FAULT_SIGBUS;
+
+ if (!IS_DAX(inode))
+ return VM_FAULT_SIGBUS;
And how do we get is_xfs_map_direct() set to true if we don't have a
DAX inode or the inode has shared extents?
So, this was my way of trying to satisfy the request you made here:
https://lkml.org/lkml/2017/8/11/876
i.e. allow MAP_DIRECT on non-dax files to enable a use case of
freezing the block-map to examine which file extents are linked. If
you don't want to use MAP_DIRECT for this, we can move these checks to
mmap time.
quoted
+
+ return 0;
+}
+
/*
* Locking for serialisation of IO during page faults. This results in a lock
* ordering of:
And if it isn't a DAX inode? what is MAP_DIRECT supposed to do then?
In the non-DAX case it just takes the FL_LAYOUT file lease... although
we could also just have an fcntl for that purpose. The use case of
just freezing the block map does not need a mapping.
Urk. That's nasty. And why is it even necessary? Please explain why
this is necessary in the comment, because it's not at all obvious to
me...
This is related to your other observation about i_mapdcount and adding
an iomap_can_allocate() helper. I think I can clean both of these up
by using a call to break_layout(inode, false) and bailing in
->iomap_begin() if it returns EWOULDBLOCK. This would also fix the
current problem that allocating write-faults don't start the lease
break process.
From: Dan Williams <hidden> Date: 2017-10-09 17:10:42
On Sun, Oct 8, 2017 at 8:45 PM, Dave Chinner [off-list ref] wrote:
On Fri, Oct 06, 2017 at 03:36:06PM -0700, Dan Williams wrote:
quoted
A 'lease_direct' lease requires that the vma have a valid MAP_DIRECT
mapping established. For xfs we establish a new lease and then check if
the MAP_DIRECT mapping has been broken. We want to be sure that the
process will receive notification that the MAP_DIRECT mapping is being
torn down so it knows why other code paths are throwing failures.
For example in the RDMA/ibverbs case we want ibv_reg_mr() to fail if the
MAP_DIRECT mapping is invalid or in the process of being invalidated.
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Cc: Jeff Layton <redacted>
Cc: "J. Bruce Fields" <redacted>
Signed-off-by: Dan Williams <redacted>
---
fs/xfs/xfs_file.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
What's any of this got to do with XFS? Shouldn't it be in generic
code, and called generic_filemap_direct_lease()?
True, I can move this to generic code. The filesystem is in charge of
where it wants to store the 'struct map_direct_state' context, but for
generic_filemap_direct_lease() it can just assume that it is stored in
->vm_private_data. I'll add comments to this effect on the new
routine.
From: Dan Williams <hidden> Date: 2017-10-09 17:32:10
On Mon, Oct 9, 2017 at 3:37 AM, Robin Murphy [off-list ref] wrote:
Hi Dan,
On 08/10/17 04:45, Dan Williams wrote:
quoted
Add a dma-mapping api helper to retrieve the generic iommu_domain for a device.
The motivation for this interface is making RDMA transfers to DAX mappings
safe. If the DAX file's block map changes we need to be to reliably stop
accesses to blocks that have been freed or re-assigned to a new file.
...which is also going to require some way to force the IOMMU drivers
(on x86 at least) to do a fully-synchronous unmap, instead of just
throwing the IOVA onto a flush queue to invalidate the TLBs at some
point in the future.
Isn't that the difference between iommu_unmap() and
iommu_unmap_fast()? As far as I can tell amd-iommu and intel-iommu
both flush iotlbs on iommu_unmap() and don't support fast unmaps.
Assuming of course that there's an IOMMU both
present and performing DMA translation in the first place.
That's why I want to call through the dma api to see if the iommu is
being used to satisfy dma mappings.
quoted
With the
iommu_domain and a callback from the DAX filesystem the kernel can safely
revoke access to a DMA device. The process that performed the RDMA memory
registration is also notified of this revocation event, but the kernel can not
otherwise be in the position of waiting for userspace to quiesce the device.
OK, but why reinvent iommu_get_domain_for_dev()?
How do I know if the iommu returned from that routine is the one being
used for dma mapping operations for the device? Specifically, how
would I discover that the result of dma_map_sg() can be passed as an
IOVA range to iommu_unmap()?
quoted
Since PMEM+DAX is currently only enabled for x86, we only update the x86
iommu drivers.
Note in particular that those two drivers happen to be the *only* place
this approach could work - everyone else is going to have to fall back
to the generic IOMMU API function anyway.
I want to make this functionality generic, but I'm not familiar with
the iommu sub-system. How are dma mapping operations routed to the
iommu driver in those other imlementations?
From: Jason Gunthorpe <hidden> Date: 2017-10-09 18:58:40
On Fri, Oct 06, 2017 at 03:35:54PM -0700, Dan Williams wrote:
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
If RDMA is driving this need, why not invalidate backing RDMA MRs
instead of requiring a IOMMU to do it? RDMA MR are finer grained and
do not suffer from the re-use problem David W. brought up with IOVAs..
Jason
From: Dan Williams <hidden> Date: 2017-10-09 19:05:30
On Mon, Oct 9, 2017 at 11:58 AM, Jason Gunthorpe
[off-list ref] wrote:
On Fri, Oct 06, 2017 at 03:35:54PM -0700, Dan Williams wrote:
quoted
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
If RDMA is driving this need, why not invalidate backing RDMA MRs
instead of requiring a IOMMU to do it? RDMA MR are finer grained and
do not suffer from the re-use problem David W. brought up with IOVAs..
Sounds promising. All I want in the end is to be sure that the kernel
is enabled to stop any in-flight RDMA at will without asking
userspace. Does this require per-RDMA driver opt-in or is there a
common call that can be made?
Outside of that the re-use problem is already solved by just unmapping
(iommu_unmap()) the IOVA, but keeping it allocated until the eventual
dma_unmap_sg() at memory un-registration time frees it.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Jason Gunthorpe <hidden> Date: 2017-10-09 19:18:20
On Mon, Oct 09, 2017 at 12:05:30PM -0700, Dan Williams wrote:
On Mon, Oct 9, 2017 at 11:58 AM, Jason Gunthorpe
[off-list ref] wrote:
quoted
On Fri, Oct 06, 2017 at 03:35:54PM -0700, Dan Williams wrote:
quoted
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
If RDMA is driving this need, why not invalidate backing RDMA MRs
instead of requiring a IOMMU to do it? RDMA MR are finer grained and
do not suffer from the re-use problem David W. brought up with IOVAs..
Sounds promising. All I want in the end is to be sure that the kernel
is enabled to stop any in-flight RDMA at will without asking
userspace. Does this require per-RDMA driver opt-in or is there a
common call that can be made?
I don't think this has ever come up in the context of an all-device MR
invalidate requirement. Drivers already have code to invalidate
specifc MRs, but to find all MRs that touch certain pages and then
invalidate them would be new code.
We also have ODP aware drivers that can retarget a MR to new
physical pages. If the block map changes DAX should synchronously
retarget the ODP MR, not halt DMA.
Most likely ODP & DAX would need to be used together to get robust
user applications, as having the user QP's go to an error state at
random times (due to DMA failures) during operation is never going to
be acceptable...
Perhaps you might want to initially only support ODP MR mappings with
DAX and then the DMA fencing issue goes away?
Cheers,
Jason
From: Dan Williams <hidden> Date: 2017-10-09 19:28:29
On Mon, Oct 9, 2017 at 12:18 PM, Jason Gunthorpe
[off-list ref] wrote:
On Mon, Oct 09, 2017 at 12:05:30PM -0700, Dan Williams wrote:
quoted
On Mon, Oct 9, 2017 at 11:58 AM, Jason Gunthorpe
[off-list ref] wrote:
quoted
On Fri, Oct 06, 2017 at 03:35:54PM -0700, Dan Williams wrote:
quoted
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
If RDMA is driving this need, why not invalidate backing RDMA MRs
instead of requiring a IOMMU to do it? RDMA MR are finer grained and
do not suffer from the re-use problem David W. brought up with IOVAs..
Sounds promising. All I want in the end is to be sure that the kernel
is enabled to stop any in-flight RDMA at will without asking
userspace. Does this require per-RDMA driver opt-in or is there a
common call that can be made?
I don't think this has ever come up in the context of an all-device MR
invalidate requirement. Drivers already have code to invalidate
specifc MRs, but to find all MRs that touch certain pages and then
invalidate them would be new code.
We also have ODP aware drivers that can retarget a MR to new
physical pages. If the block map changes DAX should synchronously
retarget the ODP MR, not halt DMA.
Have a look at the patch [1], I don't touch the ODP path.
Most likely ODP & DAX would need to be used together to get robust
user applications, as having the user QP's go to an error state at
random times (due to DMA failures) during operation is never going to
be acceptable...
It's not random. The process that set up the mapping and registered
the memory gets SIGIO when someone else tries to modify the file map.
That process then gets /proc/sys/fs/lease-break-time seconds to fix
the problem before the kernel force revokes the DMA access.
It's otherwise not acceptable to allow DMA into random locations when
the file map changes.
Perhaps you might want to initially only support ODP MR mappings with
DAX and then the DMA fencing issue goes away?
I'd rather try to fix the non-ODP DAX case instead of just turning it off.
[1]: https://patchwork.kernel.org/patch/9991681/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Exactly what are we checking for - function name doesn't tell me,
and there's no comments, either?
Ok, I'll improve this.
quoted
quoted
+{
+ if (!is_xfs_map_direct(vma))
+ return 0;
+
+ if (!is_map_direct_valid(vma->vm_private_data))
+ return VM_FAULT_SIGBUS;
+
+ if (xfs_is_reflink_inode(XFS_I(inode)))
+ return VM_FAULT_SIGBUS;
+
+ if (!IS_DAX(inode))
+ return VM_FAULT_SIGBUS;
And how do we get is_xfs_map_direct() set to true if we don't have a
DAX inode or the inode has shared extents?
So, this was my way of trying to satisfy the request you made here:
https://lkml.org/lkml/2017/8/11/876
i.e. allow MAP_DIRECT on non-dax files to enable a use case of
freezing the block-map to examine which file extents are linked. If
you don't want to use MAP_DIRECT for this, we can move these checks to
mmap time.
Ok, but I don't want to use mmap to deal with this, nor do I care
whether DAX is in use or not. So I don't think this is really
necessary for MAP_DIRECT.
And if it isn't a DAX inode? what is MAP_DIRECT supposed to do then?
In the non-DAX case it just takes the FL_LAYOUT file lease... although
we could also just have an fcntl for that purpose. The use case of
just freezing the block map does not need a mapping.
RIght, so I think we should just add a fcntl for the non-DAX case I
have in mind, and not complicate the MAP_DIRECT implementation right
now. We can alsways extend the scope of MAP_DIRECT in future if we
actually need to do so.
Urk. That's nasty. And why is it even necessary? Please explain why
this is necessary in the comment, because it's not at all obvious to
me...
This is related to your other observation about i_mapdcount and adding
an iomap_can_allocate() helper. I think I can clean both of these up
by using a call to break_layout(inode, false) and bailing in
->iomap_begin() if it returns EWOULDBLOCK. This would also fix the
current problem that allocating write-faults don't start the lease
break process.
OK.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
Hi Dan
On Sat, Oct 07, 2017 at 08:45:00PM -0700, Dan Williams wrote:
quoted hunk
Add a dma-mapping api helper to retrieve the generic iommu_domain for a device.
The motivation for this interface is making RDMA transfers to DAX mappings
safe. If the DAX file's block map changes we need to be to reliably stop
accesses to blocks that have been freed or re-assigned to a new file. With the
iommu_domain and a callback from the DAX filesystem the kernel can safely
revoke access to a DMA device. The process that performed the RDMA memory
registration is also notified of this revocation event, but the kernel can not
otherwise be in the position of waiting for userspace to quiesce the device.
Since PMEM+DAX is currently only enabled for x86, we only update the x86
iommu drivers.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ashok Raj <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <redacted>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <redacted>
Cc: Ross Zwisler <redacted>
Signed-off-by: Dan Williams <redacted>
---
Changes since v7:
* retrieve the iommu_domain so that we can later pass the results of
dma_map_* to iommu_unmap() in advance of the actual dma_unmap_*.
drivers/base/dma-mapping.c | 10 ++++++++++
drivers/iommu/amd_iommu.c | 10 ++++++++++
drivers/iommu/intel-iommu.c | 15 +++++++++++++++
include/linux/dma-mapping.h | 3 +++
4 files changed, 38 insertions(+)
From: Jason Gunthorpe <hidden> Date: 2017-10-10 17:25:16
On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:
quoted
I don't think this has ever come up in the context of an all-device MR
invalidate requirement. Drivers already have code to invalidate
specifc MRs, but to find all MRs that touch certain pages and then
invalidate them would be new code.
We also have ODP aware drivers that can retarget a MR to new
physical pages. If the block map changes DAX should synchronously
retarget the ODP MR, not halt DMA.
Have a look at the patch [1], I don't touch the ODP path.
But, does ODP work OK already? I'm not clear on that..
quoted
Most likely ODP & DAX would need to be used together to get robust
user applications, as having the user QP's go to an error state at
random times (due to DMA failures) during operation is never going to
be acceptable...
It's not random. The process that set up the mapping and registered
the memory gets SIGIO when someone else tries to modify the file map.
That process then gets /proc/sys/fs/lease-break-time seconds to fix
the problem before the kernel force revokes the DMA access.
Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.
MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(
This is why ODP should be the focus because this cannot work fully
reliably otherwise..
quoted
Perhaps you might want to initially only support ODP MR mappings with
DAX and then the DMA fencing issue goes away?
I'd rather try to fix the non-ODP DAX case instead of just turning it off.
Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.
But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...
Jason
From: Dan Williams <hidden> Date: 2017-10-10 17:39:27
On Tue, Oct 10, 2017 at 10:25 AM, Jason Gunthorpe
[off-list ref] wrote:
On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:
quoted
quoted
I don't think this has ever come up in the context of an all-device MR
invalidate requirement. Drivers already have code to invalidate
specifc MRs, but to find all MRs that touch certain pages and then
invalidate them would be new code.
We also have ODP aware drivers that can retarget a MR to new
physical pages. If the block map changes DAX should synchronously
retarget the ODP MR, not halt DMA.
Have a look at the patch [1], I don't touch the ODP path.
But, does ODP work OK already? I'm not clear on that..
It had better. If the mapping is invalidated I would hope that
generates an io fault that gets handled by the driver to setup the new
mapping. I don't see how it can work otherwise.
quoted
quoted
Most likely ODP & DAX would need to be used together to get robust
user applications, as having the user QP's go to an error state at
random times (due to DMA failures) during operation is never going to
be acceptable...
It's not random. The process that set up the mapping and registered
the memory gets SIGIO when someone else tries to modify the file map.
That process then gets /proc/sys/fs/lease-break-time seconds to fix
the problem before the kernel force revokes the DMA access.
Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.
MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(
This is why ODP should be the focus because this cannot work fully
reliably otherwise..
The lease break time is configurable. If that application can't
respond to a stop request within a timeout of its own choosing then it
should not be using DAX mappings.
quoted
quoted
Perhaps you might want to initially only support ODP MR mappings with
DAX and then the DMA fencing issue goes away?
I'd rather try to fix the non-ODP DAX case instead of just turning it off.
Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.
Can you point me to where the MR cleanup code fences DMA and quiesces
the device?
But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...
If there's a better routine for handling ib_umem_lease_break() I'd
love to use it. Right now I'm reaching for the only tool I know for
kernel enforced revocation of DMA access.
From: Jason Gunthorpe <hidden> Date: 2017-10-10 18:05:12
On Tue, Oct 10, 2017 at 10:39:27AM -0700, Dan Williams wrote:
On Tue, Oct 10, 2017 at 10:25 AM, Jason Gunthorpe
quoted
quoted
Have a look at the patch [1], I don't touch the ODP path.
But, does ODP work OK already? I'm not clear on that..
It had better. If the mapping is invalidated I would hope that
generates an io fault that gets handled by the driver to setup the new
mapping. I don't see how it can work otherwise.
I would assume so too...
quoted
This is why ODP should be the focus because this cannot work fully
reliably otherwise..
The lease break time is configurable. If that application can't
respond to a stop request within a timeout of its own choosing then it
should not be using DAX mappings.
Well, no RDMA application can really do this, unless you set the
timeout to multiple minutes, on par with network timeouts.
Again, these details are why I think this kind of DAX and non ODP-MRs
are probably practically not too useful for a production system. Great
for test of course, but in that case SIGKILL would be fine too...
quoted
Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.
Can you point me to where the MR cleanup code fences DMA and quiesces
the device?
Yes. The MR's are associated with an fd. When the fd is closed
ib_uverbs_close triggers ib_uverbs_cleanup_ucontext which runs through
all the objects, including MRs, and deletes them.
The specification for deleting a MR requires a synchronous fence with
the hardware. After MR deletion the hardware will not DMA to any pages
described by the old MR, and those pages will be unpinned.
quoted
But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...
If there's a better routine for handling ib_umem_lease_break() I'd
love to use it. Right now I'm reaching for the only tool I know for
kernel enforced revocation of DMA access.
Well, you'd have to code something in the MR code to keep track of DAX
MRs and issue an out of band invalidate to impacted MRs to create the
fence.
This probably needs some driver work, I'm not sure if all the hardware
can do out of band invalidate to any MR or not..
Generally speaking, in RDMA, when a new feature like this comes along
we have to push a lot of the work down to the driver authors, and the
approach has historically been that new features only work on some
hardware (as much as I dislike this, it is pragmatic)
So, not being able to support DAX on certain RDMA hardware is not
an unreasonable situation in our space.
Jason
From: Dan Williams <hidden> Date: 2017-10-10 20:17:26
On Tue, Oct 10, 2017 at 11:05 AM, Jason Gunthorpe
[off-list ref] wrote:
On Tue, Oct 10, 2017 at 10:39:27AM -0700, Dan Williams wrote:
quoted
On Tue, Oct 10, 2017 at 10:25 AM, Jason Gunthorpe
quoted
quoted
quoted
Have a look at the patch [1], I don't touch the ODP path.
But, does ODP work OK already? I'm not clear on that..
It had better. If the mapping is invalidated I would hope that
generates an io fault that gets handled by the driver to setup the new
mapping. I don't see how it can work otherwise.
I would assume so too...
quoted
quoted
This is why ODP should be the focus because this cannot work fully
reliably otherwise..
The lease break time is configurable. If that application can't
respond to a stop request within a timeout of its own choosing then it
should not be using DAX mappings.
Well, no RDMA application can really do this, unless you set the
timeout to multiple minutes, on par with network timeouts.
The default lease break timeout is 45 seconds on my system, so minutes
does not seem out of the question.
Also keep in mind that what triggers the lease break is another
application trying to write or punch holes in a file that is mapped
for RDMA. So, if the hardware can't handle the iommu mapping getting
invalidated asynchronously and the application can't react in the
lease break timeout period then the administrator should arrange for
the file to not be written or truncated while it is mapped.
It's already the case that get_user_pages() does not lock down file
associations, so if your application is contending with these types of
file changes it likely already has a problem keeping transactions in
sync with the file state even without DAX.
Again, these details are why I think this kind of DAX and non ODP-MRs
are probably practically not too useful for a production system. Great
for test of course, but in that case SIGKILL would be fine too...
quoted
quoted
Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.
Can you point me to where the MR cleanup code fences DMA and quiesces
the device?
Yes. The MR's are associated with an fd. When the fd is closed
ib_uverbs_close triggers ib_uverbs_cleanup_ucontext which runs through
all the objects, including MRs, and deletes them.
The specification for deleting a MR requires a synchronous fence with
the hardware. After MR deletion the hardware will not DMA to any pages
described by the old MR, and those pages will be unpinned.
quoted
quoted
But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...
If there's a better routine for handling ib_umem_lease_break() I'd
love to use it. Right now I'm reaching for the only tool I know for
kernel enforced revocation of DMA access.
Well, you'd have to code something in the MR code to keep track of DAX
MRs and issue an out of band invalidate to impacted MRs to create the
fence.
This probably needs some driver work, I'm not sure if all the hardware
can do out of band invalidate to any MR or not..
Ok.
Generally speaking, in RDMA, when a new feature like this comes along
we have to push a lot of the work down to the driver authors, and the
approach has historically been that new features only work on some
hardware (as much as I dislike this, it is pragmatic)
So, not being able to support DAX on certain RDMA hardware is not
an unreasonable situation in our space.
That makes sense, but it still seems to me that this proposed solution
allows more than enough ways to avoid that worst case scenario where
hardware reacts badly to iommu invalidation. Drivers that can do
better than iommu invalidation can arrange for a callback to do their
driver-specific action at lease break time. Hardware that can't should
be blacklisted from supporting DAX altogether. In other words this is
a starting point to incrementally enhance or disable specific drivers,
but with the assurance that the kernel can always do the safe thing
when / if the driver is missing a finer grained solution.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Jason Gunthorpe <hidden> Date: 2017-10-12 18:27:12
On Tue, Oct 10, 2017 at 01:17:26PM -0700, Dan Williams wrote:
Also keep in mind that what triggers the lease break is another
application trying to write or punch holes in a file that is mapped
for RDMA. So, if the hardware can't handle the iommu mapping getting
invalidated asynchronously and the application can't react in the
lease break timeout period then the administrator should arrange for
the file to not be written or truncated while it is mapped.
That makes sense, but why not return ENOSYS or something to the app
trying to alter the file if the RDMA hardware can't support this
instead of having the RDMA app deal with this lease break weirdness?
It's already the case that get_user_pages() does not lock down file
associations, so if your application is contending with these types of
file changes it likely already has a problem keeping transactions in
sync with the file state even without DAX.
Yes, things go weird in non-ODP RDMA cases like this..
Also, just to clear, I would expect an app using the SIGIO interface
to basically halt ongoing RDMA, wait for MRs to become unused locally
and remotely, destroy the MRs, then somehow, establish new MRs that
cover the same logical map (eg what ODP would do transparently) after
the lease breaker has made their changes, then restart their IO.
Does your SIGIO approach have a race-free way to do that last steps?
quoted
So, not being able to support DAX on certain RDMA hardware is not
an unreasonable situation in our space.
That makes sense, but it still seems to me that this proposed solution
allows more than enough ways to avoid that worst case scenario where
hardware reacts badly to iommu invalidation.
Yes, although I am concerned that returning PCI-E errors is such an
unusual and untested path for some of our RDMA drivers that they may
malfunction badly...
Again, going back to the question of who would ever use this, I would
be very relucant to deploy a production configuration relying on the iommu
invalidate or SIGIO techniques, when ODP HW is available and works
flawlessly.
be blacklisted from supporting DAX altogether. In other words this is
a starting point to incrementally enhance or disable specific drivers,
but with the assurance that the kernel can always do the safe thing
when / if the driver is missing a finer grained solution.
Seems reasonable.. I think existing HW will have an easier time adding
invalidate, while new hardware really should implement ODP.
Jason
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Dan Williams <hidden> Date: 2017-10-12 20:10:33
On Thu, Oct 12, 2017 at 11:27 AM, Jason Gunthorpe
[off-list ref] wrote:
On Tue, Oct 10, 2017 at 01:17:26PM -0700, Dan Williams wrote:
quoted
Also keep in mind that what triggers the lease break is another
application trying to write or punch holes in a file that is mapped
for RDMA. So, if the hardware can't handle the iommu mapping getting
invalidated asynchronously and the application can't react in the
lease break timeout period then the administrator should arrange for
the file to not be written or truncated while it is mapped.
That makes sense, but why not return ENOSYS or something to the app
trying to alter the file if the RDMA hardware can't support this
instead of having the RDMA app deal with this lease break weirdness?
That's where I started, an inode flag that said "hands off, this file
is busy", but Christoph pointed out that we should reuse the same
mechanisms that pnfs is using. The pnfs protection scheme uses file
leases, and once the kernel decides that a lease needs to be broken /
layout needs to be recalled there is no stopping it, only delaying.
quoted
It's already the case that get_user_pages() does not lock down file
associations, so if your application is contending with these types of
file changes it likely already has a problem keeping transactions in
sync with the file state even without DAX.
Yes, things go weird in non-ODP RDMA cases like this..
Also, just to clear, I would expect an app using the SIGIO interface
to basically halt ongoing RDMA, wait for MRs to become unused locally
and remotely, destroy the MRs, then somehow, establish new MRs that
cover the same logical map (eg what ODP would do transparently) after
the lease breaker has made their changes, then restart their IO.
Does your SIGIO approach have a race-free way to do that last steps?
After the SIGIO that's becomes a userspace / driver problem to quiesce
the I/O...
However, chatting this over with a few more people I have an alternate
solution that effectively behaves the same as how non-ODP hardware
handles this case of hole punch / truncation today. So, today if this
scenario happens on a page-cache backed mapping, the file blocks are
unmapped and the RDMA continues into pinned pages that are no longer
part of the file. We can achieve the same thing with the iommu, just
re-target the I/O into memory that isn't part of the file. That way
hardware does not see I/O errors and the DAX data consistency model is
no worse than the page-cache case.
quoted
quoted
So, not being able to support DAX on certain RDMA hardware is not
an unreasonable situation in our space.
That makes sense, but it still seems to me that this proposed solution
allows more than enough ways to avoid that worst case scenario where
hardware reacts badly to iommu invalidation.
Yes, although I am concerned that returning PCI-E errors is such an
unusual and untested path for some of our RDMA drivers that they may
malfunction badly...
Again, going back to the question of who would ever use this, I would
be very relucant to deploy a production configuration relying on the iommu
invalidate or SIGIO techniques, when ODP HW is available and works
flawlessly.
I don't think it is reasonable to tell people you need to throw away
your old hardware just because you want to target a DAX mapping.
quoted
be blacklisted from supporting DAX altogether. In other words this is
a starting point to incrementally enhance or disable specific drivers,
but with the assurance that the kernel can always do the safe thing
when / if the driver is missing a finer grained solution.
Seems reasonable.. I think existing HW will have an easier time adding
invalidate, while new hardware really should implement ODP.
Yeah, so if we go with 'remap' instead of 'invalidate' does that
address your concerns?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Christoph Hellwig <hch@lst.de> Date: 2017-10-13 06:50:47
On Thu, Oct 12, 2017 at 01:10:33PM -0700, Dan Williams wrote:
On Thu, Oct 12, 2017 at 11:27 AM, Jason Gunthorpe
[off-list ref] wrote:
quoted
On Tue, Oct 10, 2017 at 01:17:26PM -0700, Dan Williams wrote:
quoted
Also keep in mind that what triggers the lease break is another
application trying to write or punch holes in a file that is mapped
for RDMA. So, if the hardware can't handle the iommu mapping getting
invalidated asynchronously and the application can't react in the
lease break timeout period then the administrator should arrange for
the file to not be written or truncated while it is mapped.
That makes sense, but why not return ENOSYS or something to the app
trying to alter the file if the RDMA hardware can't support this
instead of having the RDMA app deal with this lease break weirdness?
That's where I started, an inode flag that said "hands off, this file
is busy", but Christoph pointed out that we should reuse the same
mechanisms that pnfs is using. The pnfs protection scheme uses file
leases, and once the kernel decides that a lease needs to be broken /
layout needs to be recalled there is no stopping it, only delaying.
That was just a suggestion - the important statement is that a hands
off flag is just a no-go.
However, chatting this over with a few more people I have an alternate
solution that effectively behaves the same as how non-ODP hardware
handles this case of hole punch / truncation today. So, today if this
scenario happens on a page-cache backed mapping, the file blocks are
unmapped and the RDMA continues into pinned pages that are no longer
part of the file. We can achieve the same thing with the iommu, just
re-target the I/O into memory that isn't part of the file. That way
hardware does not see I/O errors and the DAX data consistency model is
no worse than the page-cache case.
Yikes.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Christoph Hellwig <hch@lst.de> Date: 2017-10-13 07:09:29
On Mon, Oct 09, 2017 at 01:18:20PM -0600, Jason Gunthorpe wrote:
quoted
quoted
If RDMA is driving this need, why not invalidate backing RDMA MRs
instead of requiring a IOMMU to do it? RDMA MR are finer grained and
do not suffer from the re-use problem David W. brought up with IOVAs..
Sounds promising. All I want in the end is to be sure that the kernel
is enabled to stop any in-flight RDMA at will without asking
userspace. Does this require per-RDMA driver opt-in or is there a
common call that can be made?
I don't think this has ever come up in the context of an all-device MR
invalidate requirement. Drivers already have code to invalidate
specifc MRs, but to find all MRs that touch certain pages and then
invalidate them would be new code.
The whole point is that we should not need that IFF we provide the
right interface.
If we have a new 'register memory with a lease', the driver (or in fact
probably the umem core for the drivers using it) has the lease associated
with the ib_umem structure, which will just need a backpointer from the
ib_umem to the to the MR to unregister it.
Which might be a good opportunity to break the user MR from the in-kernel
ones and merge it with ib_umem, but that's a different story..
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jason Gunthorpe <hidden> Date: 2017-10-13 15:03:48
On Fri, Oct 13, 2017 at 08:50:47AM +0200, Christoph Hellwig wrote:
quoted
However, chatting this over with a few more people I have an alternate
solution that effectively behaves the same as how non-ODP hardware
handles this case of hole punch / truncation today. So, today if this
scenario happens on a page-cache backed mapping, the file blocks are
unmapped and the RDMA continues into pinned pages that are no longer
part of the file. We can achieve the same thing with the iommu, just
re-target the I/O into memory that isn't part of the file. That way
hardware does not see I/O errors and the DAX data consistency model is
no worse than the page-cache case.
Yikes.
Well, as much as you say Yikes, Dan is correct, this does match the
semantics RDMA MR's already have. They become non-coherent if their
underlying object is changed, and there are many ways to get there.
I've never thought about it, but it does sound like ftruncate,
fallocate, etc on a normal file would break the MR coherency too??
There have been efforts in the past driven by the MPI people to
create, essentially, something like lease-break' SIGIO. Except it was
intended to be general, and wanted solve all the problems related with
MR de-coherence. This was complicated and never became acceptable to
mainline.
Instead ODP was developed, and ODP actually solves all the problem
sanely.
Thinking about it some more, and with your other comments on
get_user_pages in this thread, I tend to agree. It doesn't make sense
to develop a user space lease break API for MR's that is a DAX
specific feature.
Along the some lines, it also doesn't make sense to force-invalidate
MR's linked to DAX regions, while leaving MR's linked to other
regions that have the same problem alone.
If you want to make non-ODP MR's work better, then you need to have a
general overall solution to tell userspace when the MR becomes (or I
guess, is becoming) non-coherent, that covers all the cases that break
MR coherence, not just via DAX.
Otherwise, I think Dan is right, keeping the current semantic of
having MRs just do something wrong, but not corrupt memory, when they
loose coherence, is broadly consistent with how non-ODP MRs work today.
Jason
On Fri, Oct 13, 2017 at 6:03 PM, Jason Gunthorpe
[off-list ref] wrote:
On Fri, Oct 13, 2017 at 08:50:47AM +0200, Christoph Hellwig wrote:
quoted
quoted
However, chatting this over with a few more people I have an alternate
solution that effectively behaves the same as how non-ODP hardware
handles this case of hole punch / truncation today. So, today if this
scenario happens on a page-cache backed mapping, the file blocks are
unmapped and the RDMA continues into pinned pages that are no longer
part of the file. We can achieve the same thing with the iommu, just
re-target the I/O into memory that isn't part of the file. That way
hardware does not see I/O errors and the DAX data consistency model is
no worse than the page-cache case.
Yikes.
Well, as much as you say Yikes, Dan is correct, this does match the
semantics RDMA MR's already have. They become non-coherent if their
underlying object is changed, and there are many ways to get there.
I've never thought about it, but it does sound like ftruncate,
fallocate, etc on a normal file would break the MR coherency too??
There have been efforts in the past driven by the MPI people to
create, essentially, something like lease-break' SIGIO. Except it was
intended to be general, and wanted solve all the problems related with
MR de-coherence. This was complicated and never became acceptable to
mainline.
Instead ODP was developed, and ODP actually solves all the problem
sanely.
Thinking about it some more, and with your other comments on
get_user_pages in this thread, I tend to agree. It doesn't make sense
to develop a user space lease break API for MR's that is a DAX
specific feature.
Along the some lines, it also doesn't make sense to force-invalidate
MR's linked to DAX regions, while leaving MR's linked to other
regions that have the same problem alone.
If you want to make non-ODP MR's work better, then you need to have a
general overall solution to tell userspace when the MR becomes (or I
guess, is becoming) non-coherent, that covers all the cases that break
MR coherence, not just via DAX.
Otherwise, I think Dan is right, keeping the current semantic of
having MRs just do something wrong, but not corrupt memory, when they
loose coherence, is broadly consistent with how non-ODP MRs work today.
I agree, keeping the current semantics is probably the best thing we
could do. It's a trade-off between breaking existing applications,
having a new lease API for DAX or just failing DAX in particular (as
opposed to other cases). For stable mappings, what we have is probably
sufficient. For mappings which could be changed, it's unclear to me
how you could guarantee non-racy behavior that is bounded by a
pre-defined time and guarantee no user-space errors. On top of that,
ODP (should) already solve that problem transparently.
IMHO, using iommu for that and causing DMA errors just because the
lease broke isn't the right thing to do.
Jason
Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html