From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:29
Hello,
here is the sixth version of my patches to implement synchronous page faults
for DAX mappings to make flushing of DAX mappings possible from userspace so
that they can be flushed on finer than page granularity and also avoid the
overhead of a syscall.
I think we are ready to get this merged - I've talked to Dan and he said he
could take the patches through his tree. It would just be nice to get final
ack from Christoph for the first patch implementing MAP_VALIDATE and someone
from XFS folks to check patch 17 (make xfs_filemap_pfn_mkwrite use
__xfs_filemap_fault()).
---
We use a new mmap flag MAP_SYNC to indicate that page faults for the mapping
should be synchronous. The guarantee provided by this flag is: While a block
is writeably mapped into page tables of this mapping, it is guaranteed to be
visible in the file at that offset also after a crash.
How I implement this is that ->iomap_begin() indicates by a flag that inode
block mapping metadata is unstable and may need flushing (use the same test as
whether fdatasync() has metadata to write). If yes, DAX fault handler refrains
from inserting / write-enabling the page table entry and returns special flag
VM_FAULT_NEEDDSYNC together with a PFN to map to the filesystem fault handler.
The handler then calls fdatasync() (vfs_fsync_range()) for the affected range
and after that calls DAX code to update the page table entry appropriately.
I did some basic performance testing on the patches over ramdisk - timed
latency of page faults when faulting 512 pages. I did several tests: with file
preallocated / with file empty, with background file copying going on / without
it, with / without MAP_SYNC (so that we get comparison). The results are
(numbers are in microseconds):
File preallocated, no background load no MAP_SYNC:
min=9 avg=10 max=46
8 - 15 us: 508
16 - 31 us: 3
32 - 63 us: 1
File preallocated, no background load, MAP_SYNC:
min=9 avg=10 max=47
8 - 15 us: 508
16 - 31 us: 2
32 - 63 us: 2
File empty, no background load, no MAP_SYNC:
min=21 avg=22 max=70
16 - 31 us: 506
32 - 63 us: 5
64 - 127 us: 1
File empty, no background load, MAP_SYNC:
min=40 avg=124 max=242
32 - 63 us: 1
64 - 127 us: 333
128 - 255 us: 178
File empty, background load, no MAP_SYNC:
min=21 avg=23 max=67
16 - 31 us: 507
32 - 63 us: 4
64 - 127 us: 1
File empty, background load, MAP_SYNC:
min=94 avg=112 max=181
64 - 127 us: 489
128 - 255 us: 23
So here we can see the difference between MAP_SYNC vs non MAP_SYNC is about
100-200 us when we need to wait for transaction commit in this setup.
Changes since v5:
* really updated the manpage
* improved comment describing IOMAP_F_DIRTY
* fixed XFS handling of VM_FAULT_NEEDSYNC in xfs_filemap_pfn_mkwrite()
Changes since v4:
* fixed couple of minor things in the manpage
* make legacy mmap flags always supported, remove them from mask declared
to be supported by ext4 and xfs
Changes since v3:
* updated some changelogs
* folded fs support for VM_SYNC flag into patches implementing the
functionality
* removed ->mmap_validate, use ->mmap_supported_flags instead
* added some Reviewed-by tags
* added manpage patch
Changes since v2:
* avoid unnecessary flushing of faulted page (Ross) - I've realized it makes no
sense to remeasure my benchmark results (after actually doing that and seeing
no difference, sigh) since I use ramdisk and not real PMEM HW and so flushes
are ignored.
* handle nojournal mode of ext4
* other smaller cleanups & fixes (Ross)
* factor larger part of finishing of synchronous fault into a helper (Christoph)
* reorder pfnp argument of dax_iomap_fault() (Christoph)
* add XFS support from Christoph
* use proper MAP_SYNC support in mmap(2)
* rebased on top of 4.14-rc4
Changes since v1:
* switched to using mmap flag MAP_SYNC
* cleaned up fault handlers to avoid passing pfn in vmf->orig_pte
* switched to not touching page tables before we are ready to insert final
entry as it was unnecessary and not really simplifying anything
* renamed fault flag to VM_FAULT_NEEDDSYNC
* other smaller fixes found by reviewers
Honza
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:31
It is unused.
Reviewed-by: Ross Zwisler <redacted>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jan Kara <jack@suse.cz>
---
include/linux/mm.h | 2 --
1 file changed, 2 deletions(-)
@@ -1182,8 +1182,6 @@ static inline void clear_page_pfmemalloc(struct page *page)#define VM_FAULT_FALLBACK 0x0800 /* huge page fault failed, fall back to small */#define VM_FAULT_DONE_COW 0x1000 /* ->fault has fully handled COW */-#define VM_FAULT_HWPOISON_LARGE_MASK 0xf000 /* encodes hpage index for large hwpoison */-#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | \VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE|\VM_FAULT_FALLBACK)
--
2.12.3
--
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: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:32
dax_insert_mapping() has lots of arguments and a lot of them is actuall
duplicated by passing vm_fault structure as well. Change the function to
take the same arguments as dax_pmd_insert_mapping().
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Reviewed-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
@@ -820,23 +820,30 @@ int dax_writeback_mapping_range(struct address_space *mapping,}EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);-staticintdax_insert_mapping(structaddress_space*mapping,-structblock_device*bdev,structdax_device*dax_dev,-sector_tsector,size_tsize,void*entry,-structvm_area_struct*vma,structvm_fault*vmf)+staticsector_tdax_iomap_sector(structiomap*iomap,loff_tpos)+{+returniomap->blkno+(((pos&PAGE_MASK)-iomap->offset)>>9);+}++staticintdax_insert_mapping(structvm_fault*vmf,structiomap*iomap,+loff_tpos,void*entry){+constsector_tsector=dax_iomap_sector(iomap,pos);+structvm_area_struct*vma=vmf->vma;+structaddress_space*mapping=vma->vm_file->f_mapping;unsignedlongvaddr=vmf->address;void*ret,*kaddr;pgoff_tpgoff;intid,rc;pfn_tpfn;-rc=bdev_dax_pgoff(bdev,sector,size,&pgoff);+rc=bdev_dax_pgoff(iomap->bdev,sector,PAGE_SIZE,&pgoff);if(rc)returnrc;id=dax_read_lock();-rc=dax_direct_access(dax_dev,pgoff,PHYS_PFN(size),&kaddr,&pfn);+rc=dax_direct_access(iomap->dax_dev,pgoff,PHYS_PFN(PAGE_SIZE),+&kaddr,&pfn);if(rc<0){dax_read_unlock(id);returnrc;
@@ -936,11 +943,6 @@ int __dax_zero_page_range(struct block_device *bdev,}EXPORT_SYMBOL_GPL(__dax_zero_page_range);-staticsector_tdax_iomap_sector(structiomap*iomap,loff_tpos)-{-returniomap->blkno+(((pos&PAGE_MASK)-iomap->offset)>>9);-}-staticloff_tdax_iomap_actor(structinode*inode,loff_tpos,loff_tlength,void*data,structiomap*iomap)
@@ -1087,7 +1089,6 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,structinode*inode=mapping->host;unsignedlongvaddr=vmf->address;loff_tpos=(loff_t)vmf->pgoff<<PAGE_SHIFT;-sector_tsector;structiomapiomap={0};unsignedflags=IOMAP_FAULT;interror,major=0;
@@ -1140,9 +1141,9 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,gotoerror_finish_iomap;}-sector=dax_iomap_sector(&iomap,pos);-if(vmf->cow_page){+sector_tsector=dax_iomap_sector(&iomap,pos);+switch(iomap.type){caseIOMAP_HOLE:caseIOMAP_UNWRITTEN:
@@ -1175,8 +1176,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,count_memcg_event_mm(vmf->vma->vm_mm,PGMAJFAULT);major=VM_FAULT_MAJOR;}-error=dax_insert_mapping(mapping,iomap.bdev,iomap.dax_dev,-sector,PAGE_SIZE,entry,vmf->vma,vmf);+error=dax_insert_mapping(vmf,&iomap,pos,entry);/* -EBUSY is fine, somebody else faulted on the same PTE */if(error==-EBUSY)error=0;
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:33
Factor out code to get pfn out of iomap that is shared between PTE and
PMD fault path.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ross Zwisler <redacted>
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/dax.c | 83 +++++++++++++++++++++++++++++++++-------------------------------
1 file changed, 43 insertions(+), 40 deletions(-)
--
2.12.3
--
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: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:34
There are already two users and more are coming.
Reviewed-by: Christoph Hellwig <redacted>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:35
There are already two users and more are coming.
Reviewed-by: Christoph Hellwig <redacted>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:36
dax_insert_mapping() has only one callsite and we will need to further
fine tune what it does for synchronous faults. Just inline it into the
callsite so that we don't have to pass awkward bools around.
Reviewed-by: Christoph Hellwig <redacted>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 46 +++++++++++++++++++---------------------------
1 file changed, 19 insertions(+), 27 deletions(-)
@@ -1119,6 +1093,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,boolwrite=vmf->flags&FAULT_FLAG_WRITE;intvmf_ret=0;void*entry;+pfn_tpfn;trace_dax_pte_fault(inode,vmf,vmf_ret);/*
@@ -1201,7 +1176,24 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,count_memcg_event_mm(vma->vm_mm,PGMAJFAULT);major=VM_FAULT_MAJOR;}-error=dax_insert_mapping(vmf,&iomap,pos,entry);+error=dax_iomap_pfn(&iomap,pos,PAGE_SIZE,&pfn);+if(error<0)+gotoerror_finish_iomap;++entry=dax_insert_mapping_entry(mapping,vmf,entry,+dax_iomap_sector(&iomap,pos),+0);+if(IS_ERR(entry)){+error=PTR_ERR(entry);+gotoerror_finish_iomap;+}++trace_dax_insert_mapping(inode,vmf,entry);+if(write)+error=vm_insert_mixed_mkwrite(vma,vaddr,pfn);+else+error=vm_insert_mixed(vma,vaddr,pfn);+/* -EBUSY is fine, somebody else faulted on the same PTE */if(error==-EBUSY)error=0;
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:37
dax_pmd_insert_mapping() has only one callsite and we will need to
further fine tune what it does for synchronous faults. Just inline it
into the callsite so that we don't have to pass awkward bools around.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ross Zwisler <redacted>
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/dax.c | 47 +++++++++++++++++--------------------------
include/trace/events/fs_dax.h | 1 -
2 files changed, 19 insertions(+), 29 deletions(-)
--
2.12.3
--
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: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:39
For synchronous page fault dax_iomap_fault() will need to return PFN
which will then need to be inserted into page tables after fsync()
completes. Add necessary parameter to dax_iomap_fault().
Reviewed-by: Christoph Hellwig <redacted>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 13 +++++++------
fs/ext2/file.c | 2 +-
fs/ext4/file.c | 2 +-
fs/xfs/xfs_file.c | 4 ++--
include/linux/dax.h | 2 +-
5 files changed, 12 insertions(+), 11 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:40
Currently we dirty radix tree entry whenever dax_insert_mapping_entry()
gets called for a write fault. With synchronous page faults we would
like to insert clean radix tree entry and dirty it only once we call
fdatasync() and update page tables to save some unnecessary cache
flushing. Add 'dirty' argument to dax_insert_mapping_entry() for that.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Reviewed-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:41
Define new MAP_SYNC flag and corresponding VMA VM_SYNC flag. As the
MAP_SYNC flag is not part of LEGACY_MAP_MASK, currently it will be
refused by all MAP_SHARED_VALIDATE map attempts and silently ignored for
everything else.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Reviewed-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/proc/task_mmu.c | 1 +
include/linux/mm.h | 1 +
include/linux/mman.h | 8 ++++++--
include/uapi/asm-generic/mman.h | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
@@ -189,6 +189,7 @@ extern unsigned int kobjsize(const void *objp);#define VM_ACCOUNT 0x00100000 /* Is a VM accounted object */#define VM_NORESERVE 0x00200000 /* should the VM suppress accounting */#define VM_HUGETLB 0x00400000 /* Huge TLB Page VM */+#define VM_SYNC 0x00800000 /* Synchronous page faults */#define VM_ARCH_1 0x01000000 /* Architecture-specific flag */#define VM_WIPEONFORK 0x02000000 /* Wipe VMA contents in child. */#define VM_DONTDUMP 0x04000000 /* Do not include in the core dump */
@@ -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_SYNC 0x80000 /* perform synchronous page faults for the mapping *//* Bits [26:31] are reserved, see mman-common.h for MAP_HUGETLB usage */
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:42
Add a flag to iomap interface informing the caller that inode needs
fdstasync(2) for returned extent to become persistent and use it in DAX
fault code so that we don't map such extents into page tables
immediately. Instead we propagate the information that fdatasync(2) is
necessary from dax_iomap_fault() with a new VM_FAULT_NEEDDSYNC flag.
Filesystem fault handler is then responsible for calling fdatasync(2)
and inserting pfn into page tables.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Reviewed-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 39 +++++++++++++++++++++++++++++++++++++--
include/linux/iomap.h | 5 +++++
include/linux/mm.h | 6 +++++-
3 files changed, 47 insertions(+), 3 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:44
If transaction starting fails, just bail out of the function immediately
instead of checking for that condition throughout the function.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/ext4/file.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:45
We return IOMAP_F_DIRTY flag from ext4_iomap_begin() when asked to
prepare blocks for writing and the inode has some uncommitted metadata
changes. In the fault handler ext4_dax_fault() we then detect this case
(through VM_FAULT_NEEDDSYNC return value) and call helper
dax_finish_sync_fault() to flush metadata changes and insert page table
entry. Note that this will also dirty corresponding radix tree entry
which is what we want - fsync(2) will still provide data integrity
guarantees for applications not using userspace flushing. And
applications using userspace flushing can avoid calling fsync(2) and
thus avoid the performance overhead.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
---
fs/ext4/file.c | 15 ++++++++++++++-
fs/ext4/inode.c | 15 +++++++++++++++
fs/jbd2/journal.c | 17 +++++++++++++++++
include/linux/jbd2.h | 1 +
4 files changed, 47 insertions(+), 1 deletion(-)
@@ -738,6 +738,23 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid)returnerr;}+/* Return 1 when transaction with given tid has already committed. */+intjbd2_transaction_committed(journal_t*journal,tid_ttid)+{+intret=1;++read_lock(&journal->j_state_lock);+if(journal->j_running_transaction&&+journal->j_running_transaction->t_tid==tid)+ret=0;+if(journal->j_committing_transaction&&+journal->j_committing_transaction->t_tid==tid)+ret=0;+read_unlock(&journal->j_state_lock);+returnret;+}+EXPORT_SYMBOL(jbd2_transaction_committed);+/**Whenthisfunctionreturnsthetransactioncorrespondingtotid*willbecompleted.Ifthetransactionhascurrentlyrunning,start
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:46
xfs_filemap_pfn_mkwrite() duplicates a lot of __xfs_filemap_fault().
It will also need to handle flushing for synchronous page faults. So
just make that function use __xfs_filemap_fault().
Signed-off-by: Jan Kara <redacted>
---
fs/xfs/xfs_file.c | 29 ++++-------------------------
fs/xfs/xfs_trace.h | 2 --
2 files changed, 4 insertions(+), 27 deletions(-)
@@ -1085,37 +1085,16 @@ xfs_filemap_page_mkwrite(}/*-*pfn_mkwritewasoriginallyintenededtoensurewecapturetimestamp-*updatesonwritefaults.Inreality,it'sneedtoserialiseagainst-*truncatesimilartopage_mkwrite.HencewecycletheXFS_MMAPLOCK_SHARED-*toensureweserialisethefaultbarrierinplace.+*pfn_mkwritewasoriginallyintendedtoensurewecapturetimestampupdates+*onwritefaults.Inreality,itneedstoserialiseagainsttruncateand+*preparememoryforwritingsohandleisasstandardwritefault.*/staticintxfs_filemap_pfn_mkwrite(structvm_fault*vmf){-structinode*inode=file_inode(vmf->vma->vm_file);-structxfs_inode*ip=XFS_I(inode);-intret=VM_FAULT_NOPAGE;-loff_tsize;--trace_xfs_filemap_pfn_mkwrite(ip);--sb_start_pagefault(inode->i_sb);-file_update_time(vmf->vma->vm_file);--/* check if the faulting page hasn't raced with truncate */-xfs_ilock(ip,XFS_MMAPLOCK_SHARED);-size=(i_size_read(inode)+PAGE_SIZE-1)>>PAGE_SHIFT;-if(vmf->pgoff>=size)-ret=VM_FAULT_SIGBUS;-elseif(IS_DAX(inode))-ret=dax_iomap_fault(vmf,PE_SIZE_PTE,NULL,&xfs_iomap_ops);-xfs_iunlock(ip,XFS_MMAPLOCK_SHARED);-sb_end_pagefault(inode->i_sb);-returnret;-+return__xfs_filemap_fault(vmf,PE_SIZE_PTE,true);}staticconststructvm_operations_structxfs_file_vm_ops={
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:36:47
From: Christoph Hellwig <redacted>
Return IOMAP_F_DIRTY from xfs_file_iomap_begin() when asked to prepare
blocks for writing and the inode is pinned, and has dirty fields other
than the timestamps. In __xfs_filemap_fault() we then detect this case
and call dax_finish_sync_fault() to make sure all metadata is committed,
and to insert the page table entry.
Note that this will also dirty corresponding radix tree entry which is
what we want - fsync(2) will still provide data integrity guarantees for
applications not using userspace flushing. And applications using
userspace flushing can avoid calling fsync(2) and thus avoid the
performance overhead.
[JK: Added VM_SYNC flag handling]
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/xfs/xfs_file.c | 15 ++++++++++++++-
fs/xfs/xfs_iomap.c | 5 +++++
2 files changed, 19 insertions(+), 1 deletion(-)
@@ -125,6 +125,21 @@ are carried through to the underlying file. to the underlying file requires the use of .BRmsync(2).) .TP+.BRMAP_SHARED_VALIDATE" (since Linux 4.15)"+The same as+.BMAP_SHARED+except that+.BMAP_SHARED+mappings ignore unknown flags in+.IRflags.+In contrast when creating mapping of+.BMAP_SHARED_VALIDATE+mapping type, the kernel verifies all passed flags are known and fails the+mapping with+.BREOPNOTSUPP+otherwise. This mapping type is also required to be able to use some mapping+flags.+.TP .BMAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes
@@ -134,7 +149,10 @@ It is unspecified whether changes made to the file after the .BRmmap() call are visible in the mapped region. .PP-Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.+.BMAP_SHARED+and+.BMAP_PRIVATE+are described in POSIX.1-2001 and POSIX.1-2008. .PP In addition, zero or more of the following values can be ORed in .IRflags:
@@ -352,6 +370,21 @@ option. Because of the security implications, that option is normally enabled only on embedded devices (i.e., devices where one has complete control of the contents of user memory).+.TP+.BRMAP_SYNC" (since Linux 4.15)"+This flags is available only with+.BMAP_SHARED_VALIDATE+mapping type. Mappings of+.BMAP_SHARED+type will silently ignore this flag.+This flag is supported only for files supporting DAX (direct mapping of persistent+memory). For other files, creating mapping with this flag results in+.BEOPNOTSUPP+error. Shared file mappings with this flag provide the guarantee that while+some memory is writeably mapped in the address space of the process, it will+be visible in the same file at the same offset even after the system crashes or+is rebooted. This allows users of such mappings to make data modifications+persistent in a more efficient way using appropriate CPU instructions. .PP Of the above flags, only .BMAP_FIXED
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:37:05
From: Dan Williams <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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_flags 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>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
Signed-off-by: Jan Kara <redacted>
---
arch/alpha/include/uapi/asm/mman.h | 1 +
arch/mips/include/uapi/asm/mman.h | 1 +
arch/parisc/include/uapi/asm/mman.h | 1 +
arch/xtensa/include/uapi/asm/mman.h | 1 +
include/linux/fs.h | 1 +
include/linux/mman.h | 39 ++++++++++++++++++++++++++++
include/uapi/asm-generic/mman-common.h | 1 +
mm/mmap.c | 15 +++++++++++
tools/include/uapi/asm-generic/mman-common.h | 1 +
9 files changed, 61 insertions(+)
@@ -1387,9 +1387,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,if(file){structinode*inode=file_inode(file);+unsignedlongflags_mask;++flags_mask=LEGACY_MAP_MASK|file->f_op->mmap_supported_flags;switch(flags&MAP_TYPE){caseMAP_SHARED:+/*+*ForceuseofMAP_SHARED_VALIDATEwithnon-legacy+*flags.E.g.MAP_SYNCisdangeroustousewith+*MAP_SHAREDasyoudon'tknowwhichconsistencymodel+*youwillget.Wesilentlyignoreunsupportedflags+*withMAP_SHAREDtopreservebackwardcompatibility.+*/+flags&=LEGACY_MAP_MASK;+/* fall through */+caseMAP_SHARED_VALIDATE:+if(flags&~flags_mask)+return-EOPNOTSUPP;if((prot&PROT_WRITE)&&!(file->f_mode&FMODE_WRITE))return-EACCES;
From: Jan Kara <jack@suse.cz> Date: 2017-11-01 15:37:05
Implement a function that filesystems can call to finish handling of
synchronous page faults. It takes care of syncing appropriare file range
and insertion of page table entry.
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Reviewed-by: Christoph Hellwig <redacted>
Signed-off-by: Jan Kara <redacted>
---
fs/dax.c | 83 +++++++++++++++++++++++++++++++++++++++++++
include/linux/dax.h | 2 ++
include/trace/events/fs_dax.h | 2 ++
3 files changed, 87 insertions(+)
@@ -1492,3 +1492,86 @@ int dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,}}EXPORT_SYMBOL_GPL(dax_iomap_fault);++/**+*dax_insert_pfn_mkwrite-insertPTEorPMDentryintopagetables+*@vmf:Thedescriptionofthefault+*@pe_size:Sizeofentrytobeinserted+*@pfn:PFNtoinsert+*+*ThisfunctioninsertswriteablePTEorPMDentryintopagetablesformmaped+*DAXfile.Ittakescareofmarkingcorrespondingradixtreeentryasdirty+*aswell.+*/+staticintdax_insert_pfn_mkwrite(structvm_fault*vmf,+enumpage_entry_sizepe_size,+pfn_tpfn)+{+structaddress_space*mapping=vmf->vma->vm_file->f_mapping;+void*entry,**slot;+pgoff_tindex=vmf->pgoff;+intvmf_ret,error;++spin_lock_irq(&mapping->tree_lock);+entry=get_unlocked_mapping_entry(mapping,index,&slot);+/* Did we race with someone splitting entry or so? */+if(!entry||+(pe_size==PE_SIZE_PTE&&!dax_is_pte_entry(entry))||+(pe_size==PE_SIZE_PMD&&!dax_is_pmd_entry(entry))){+put_unlocked_mapping_entry(mapping,index,entry);+spin_unlock_irq(&mapping->tree_lock);+trace_dax_insert_pfn_mkwrite_no_entry(mapping->host,vmf,+VM_FAULT_NOPAGE);+returnVM_FAULT_NOPAGE;+}+radix_tree_tag_set(&mapping->page_tree,index,PAGECACHE_TAG_DIRTY);+entry=lock_slot(mapping,slot);+spin_unlock_irq(&mapping->tree_lock);+switch(pe_size){+casePE_SIZE_PTE:+error=vm_insert_mixed_mkwrite(vmf->vma,vmf->address,pfn);+vmf_ret=dax_fault_return(error);+break;+#ifdef CONFIG_FS_DAX_PMD+casePE_SIZE_PMD:+vmf_ret=vmf_insert_pfn_pmd(vmf->vma,vmf->address,vmf->pmd,+pfn,true);+break;+#endif+default:+vmf_ret=VM_FAULT_FALLBACK;+}+put_locked_mapping_entry(mapping,index);+trace_dax_insert_pfn_mkwrite(mapping->host,vmf,vmf_ret);+returnvmf_ret;+}++/**+*dax_finish_sync_fault-finishsynchronouspagefault+*@vmf:Thedescriptionofthefault+*@pe_size:Sizeofentrytobeinserted+*@pfn:PFNtoinsert+*+*Thisfunctionensuresthatthefilerangetouchedbythepagefaultis+*storedpersistentlyonthemediaandhandlesinsertingofappropriatepage+*tableentry.+*/+intdax_finish_sync_fault(structvm_fault*vmf,enumpage_entry_sizepe_size,+pfn_tpfn)+{+interr;+loff_tstart=((loff_t)vmf->pgoff)<<PAGE_SHIFT;+size_tlen=0;++if(pe_size==PE_SIZE_PTE)+len=PAGE_SIZE;+elseif(pe_size==PE_SIZE_PMD)+len=PMD_SIZE;+else+WARN_ON_ONCE(1);+err=vfs_fsync_range(vmf->vma->vm_file,start,start+len-1,1);+if(err)+returnVM_FAULT_SIGBUS;+returndax_insert_pfn_mkwrite(vmf,pe_size,pfn);+}+EXPORT_SYMBOL_GPL(dax_finish_sync_fault);
From: Darrick J. Wong <hidden> Date: 2017-11-14 02:19:13
On Wed, Nov 01, 2017 at 04:36:46PM +0100, Jan Kara wrote:
xfs_filemap_pfn_mkwrite() duplicates a lot of __xfs_filemap_fault().
It will also need to handle flushing for synchronous page faults. So
just make that function use __xfs_filemap_fault().
Signed-off-by: Jan Kara <redacted>
@@ -1085,37 +1085,16 @@ xfs_filemap_page_mkwrite(}/*-*pfn_mkwritewasoriginallyintenededtoensurewecapturetimestamp-*updatesonwritefaults.Inreality,it'sneedtoserialiseagainst-*truncatesimilartopage_mkwrite.HencewecycletheXFS_MMAPLOCK_SHARED-*toensureweserialisethefaultbarrierinplace.+*pfn_mkwritewasoriginallyintendedtoensurewecapturetimestampupdates+*onwritefaults.Inreality,itneedstoserialiseagainsttruncateand+*preparememoryforwritingsohandleisasstandardwritefault.*/staticintxfs_filemap_pfn_mkwrite(structvm_fault*vmf){-structinode*inode=file_inode(vmf->vma->vm_file);-structxfs_inode*ip=XFS_I(inode);-intret=VM_FAULT_NOPAGE;-loff_tsize;--trace_xfs_filemap_pfn_mkwrite(ip);--sb_start_pagefault(inode->i_sb);-file_update_time(vmf->vma->vm_file);--/* check if the faulting page hasn't raced with truncate */-xfs_ilock(ip,XFS_MMAPLOCK_SHARED);-size=(i_size_read(inode)+PAGE_SIZE-1)>>PAGE_SHIFT;-if(vmf->pgoff>=size)-ret=VM_FAULT_SIGBUS;-elseif(IS_DAX(inode))-ret=dax_iomap_fault(vmf,PE_SIZE_PTE,NULL,&xfs_iomap_ops);-xfs_iunlock(ip,XFS_MMAPLOCK_SHARED);-sb_end_pagefault(inode->i_sb);-returnret;-+return__xfs_filemap_fault(vmf,PE_SIZE_PTE,true);}staticconststructvm_operations_structxfs_file_vm_ops={
--
2.12.3
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Darrick J. Wong <hidden> Date: 2017-11-14 02:19:42
On Wed, Nov 01, 2017 at 04:36:47PM +0100, Jan Kara wrote:
From: Christoph Hellwig <hch@lst.de>
Return IOMAP_F_DIRTY from xfs_file_iomap_begin() when asked to prepare
blocks for writing and the inode is pinned, and has dirty fields other
than the timestamps. In __xfs_filemap_fault() we then detect this case
and call dax_finish_sync_fault() to make sure all metadata is committed,
and to insert the page table entry.
Note that this will also dirty corresponding radix tree entry which is
what we want - fsync(2) will still provide data integrity guarantees for
applications not using userspace flushing. And applications using
userspace flushing can avoid calling fsync(2) and thus avoid the
performance overhead.
[JK: Added VM_SYNC flag handling]
Reviewed-by: Ross Zwisler <redacted>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jan Kara <jack@suse.cz>
--
2.12.3
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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.
So I'm trying to make sense of this together with Michal's attempt for
MAP_FIXED_SAFE [1] where he has to introduce a completely new flag
instead of flag modifier exactly for the reason of not validating
unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE
implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a
modifier cannot build on top of this. Wouldn't thus it be really better
long-term to introduce mmap3 at this point? ...
Vlastimil
[1] https://marc.info/?l=linux-arch&m=151083448322336&w=2
quoted hunk
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_flags 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>
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Dan Williams <redacted>
Signed-off-by: Jan Kara <redacted>
---
arch/alpha/include/uapi/asm/mman.h | 1 +
arch/mips/include/uapi/asm/mman.h | 1 +
arch/parisc/include/uapi/asm/mman.h | 1 +
arch/xtensa/include/uapi/asm/mman.h | 1 +
include/linux/fs.h | 1 +
include/linux/mman.h | 39 ++++++++++++++++++++++++++++
include/uapi/asm-generic/mman-common.h | 1 +
mm/mmap.c | 15 +++++++++++
tools/include/uapi/asm-generic/mman-common.h | 1 +
9 files changed, 61 insertions(+)
@@ -1387,9 +1387,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,if(file){structinode*inode=file_inode(file);+unsignedlongflags_mask;++flags_mask=LEGACY_MAP_MASK|file->f_op->mmap_supported_flags;switch(flags&MAP_TYPE){caseMAP_SHARED:+/*+*ForceuseofMAP_SHARED_VALIDATEwithnon-legacy+*flags.E.g.MAP_SYNCisdangeroustousewith+*MAP_SHAREDasyoudon'tknowwhichconsistencymodel+*youwillget.Wesilentlyignoreunsupportedflags+*withMAP_SHAREDtopreservebackwardcompatibility.+*/+flags&=LEGACY_MAP_MASK;+/* fall through */+caseMAP_SHARED_VALIDATE:+if(flags&~flags_mask)+return-EOPNOTSUPP;if((prot&PROT_WRITE)&&!(file->f_mode&FMODE_WRITE))return-EACCES;
From: Dan Williams <hidden> Date: 2017-11-22 16:52:37
On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka [off-list ref] wrote:
On 11/01/2017 04:36 PM, Jan Kara wrote:
quoted
From: Dan Williams <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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.
So I'm trying to make sense of this together with Michal's attempt for
MAP_FIXED_SAFE [1] where he has to introduce a completely new flag
instead of flag modifier exactly for the reason of not validating
unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE
implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a
modifier cannot build on top of this. Wouldn't thus it be really better
long-term to introduce mmap3 at this point? ...
We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch
except parisc. Can we steal an extra bit for MAP_TYPE from somewhere
else on parisc?
--
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: Matthew Wilcox <willy@infradead.org> Date: 2017-11-22 19:53:18
On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote:
On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka [off-list ref] wrote:
quoted
On 11/01/2017 04:36 PM, Jan Kara wrote:
quoted
From: Dan Williams <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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.
So I'm trying to make sense of this together with Michal's attempt for
MAP_FIXED_SAFE [1] where he has to introduce a completely new flag
instead of flag modifier exactly for the reason of not validating
unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE
implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a
modifier cannot build on top of this. Wouldn't thus it be really better
long-term to introduce mmap3 at this point? ...
We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch
except parisc. Can we steal an extra bit for MAP_TYPE from somewhere
else on parisc?
It looks like 0x08 should work. But I don't have an HPUX machine around
to check that HP didn't use that bit for something else.
It'd probably help to cc the linux-parisc mailing list when asking
questions about PARISC, eh?
On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote:
quoted
On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka [off-list ref] wrote:
quoted
On 11/01/2017 04:36 PM, Jan Kara wrote:
quoted
From: Dan Williams <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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.
So I'm trying to make sense of this together with Michal's attempt for
MAP_FIXED_SAFE [1] where he has to introduce a completely new flag
instead of flag modifier exactly for the reason of not validating
unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE
implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a
modifier cannot build on top of this. Wouldn't thus it be really better
long-term to introduce mmap3 at this point? ...
We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch
except parisc. Can we steal an extra bit for MAP_TYPE from somewhere
else on parisc?
It looks like 0x08 should work.
I posted an RFC to the parisc mailing list for that:
https://patchwork.kernel.org/patch/9970553/
Basically this is (for parisc only):
-#define MAP_TYPE 0x03 /* Mask for type of mapping */
+#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */
#define MAP_FIXED 0x04 /* Interpret addr exactly */
+#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */
#define MAP_ANONYMOUS 0x10 /* don't use a file */
+#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */
But I don't have an HPUX machine around
to check that HP didn't use that bit for something else.
We completely dropped support for HPUX binaries, so it's not relvant any longer.
It'd probably help to cc the linux-parisc mailing list when asking
questions about PARISC, eh?
Yes, please.
Helge
--
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>
On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote:
quoted
On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka [off-list ref] wrote:
quoted
On 11/01/2017 04:36 PM, Jan Kara wrote:
quoted
From: Dan Williams <redacted>
The mmap(2) syscall suffers from the ABI anti-pattern of not validating
unknown flags. However, proposals like MAP_SYNC 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.
So I'm trying to make sense of this together with Michal's attempt for
MAP_FIXED_SAFE [1] where he has to introduce a completely new flag
instead of flag modifier exactly for the reason of not validating
unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE
implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a
modifier cannot build on top of this. Wouldn't thus it be really better
long-term to introduce mmap3 at this point? ...
We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch
except parisc. Can we steal an extra bit for MAP_TYPE from somewhere
else on parisc?
Thanks. BTW there doesn't seem to be much interest making MAP_FIXED_SAFE
a flag modifier after all, so MAP_PRIVATE_VALIDATE wouldn't get
immediate users.
Basically this is (for parisc only):
-#define MAP_TYPE 0x03 /* Mask for type of mapping */
+#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */
#define MAP_FIXED 0x04 /* Interpret addr exactly */
+#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */
#define MAP_ANONYMOUS 0x10 /* don't use a file */
+#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */
quoted
But I don't have an HPUX machine around
to check that HP didn't use that bit for something else.
We completely dropped support for HPUX binaries, so it's not relvant any longer.
quoted
It'd probably help to cc the linux-parisc mailing list when asking
questions about PARISC, eh?
From: Michael Kerrisk (man-pages) <hidden> Date: 2018-04-12 13:00:49
Hello Jan,
I have applied your patch, and tweaked the text a little, and pushed
the result to the git repo.
On 1 November 2017 at 16:36, Jan Kara [off-list ref] wrote:
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
@@ -125,6 +125,21 @@ are carried through to the underlying file. to the underlying file requires the use of .BRmsync(2).) .TP+.BRMAP_SHARED_VALIDATE" (since Linux 4.15)"+The same as+.BMAP_SHARED+except that+.BMAP_SHARED+mappings ignore unknown flags in+.IRflags.+In contrast when creating mapping of+.BMAP_SHARED_VALIDATE+mapping type, the kernel verifies all passed flags are known and fails the+mapping with+.BREOPNOTSUPP+otherwise. This mapping type is also required to be able to use some mapping+flags.+.TP .BMAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes
@@ -134,7 +149,10 @@ It is unspecified whether changes made to the file after the .BRmmap() call are visible in the mapped region. .PP-Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.+.BMAP_SHARED+and+.BMAP_PRIVATE+are described in POSIX.1-2001 and POSIX.1-2008. .PP In addition, zero or more of the following values can be ORed in .IRflags:
@@ -352,6 +370,21 @@ option. Because of the security implications, that option is normally enabled only on embedded devices (i.e., devices where one has complete control of the contents of user memory).+.TP+.BRMAP_SYNC" (since Linux 4.15)"+This flags is available only with+.BMAP_SHARED_VALIDATE+mapping type. Mappings of+.BMAP_SHARED+type will silently ignore this flag.+This flag is supported only for files supporting DAX (direct mapping of persistent+memory). For other files, creating mapping with this flag results in+.BEOPNOTSUPP+error. Shared file mappings with this flag provide the guarantee that while+some memory is writeably mapped in the address space of the process, it will+be visible in the same file at the same offset even after the system crashes or+is rebooted. This allows users of such mappings to make data modifications+persistent in a more efficient way using appropriate CPU instructions.
It feels like there's a word missing/unclear wording in the previous
line, before "using". Without that word, the sentence feels a bit
ambiguous.
Should it be:
persistent in a more efficient way *through the use of* appropriate
CPU instructions.
or:
persistent in a more efficient way *than using* appropriate CPU instructions.
?
Is suspect the first is correct, but need to check.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: Ross Zwisler <hidden> Date: 2018-04-12 14:00:59
On Thu, Apr 12, 2018 at 03:00:49PM +0200, Michael Kerrisk (man-pages) wrote:
Hello Jan,
I have applied your patch, and tweaked the text a little, and pushed
the result to the git repo.
On 1 November 2017 at 16:36, Jan Kara [off-list ref] wrote:
quoted
Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Jan Kara <redacted>
@@ -125,6 +125,21 @@ are carried through to the underlying file. to the underlying file requires the use of .BRmsync(2).) .TP+.BRMAP_SHARED_VALIDATE" (since Linux 4.15)"+The same as+.BMAP_SHARED+except that+.BMAP_SHARED+mappings ignore unknown flags in+.IRflags.+In contrast when creating mapping of+.BMAP_SHARED_VALIDATE+mapping type, the kernel verifies all passed flags are known and fails the+mapping with+.BREOPNOTSUPP+otherwise. This mapping type is also required to be able to use some mapping+flags.+.TP .BMAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes
@@ -134,7 +149,10 @@ It is unspecified whether changes made to the file after the .BRmmap() call are visible in the mapped region. .PP-Both of these flags are described in POSIX.1-2001 and POSIX.1-2008.+.BMAP_SHARED+and+.BMAP_PRIVATE+are described in POSIX.1-2001 and POSIX.1-2008. .PP In addition, zero or more of the following values can be ORed in .IRflags:
@@ -352,6 +370,21 @@ option. Because of the security implications, that option is normally enabled only on embedded devices (i.e., devices where one has complete control of the contents of user memory).+.TP+.BRMAP_SYNC" (since Linux 4.15)"+This flags is available only with+.BMAP_SHARED_VALIDATE+mapping type. Mappings of+.BMAP_SHARED+type will silently ignore this flag.+This flag is supported only for files supporting DAX (direct mapping of persistent+memory). For other files, creating mapping with this flag results in+.BEOPNOTSUPP+error. Shared file mappings with this flag provide the guarantee that while+some memory is writeably mapped in the address space of the process, it will+be visible in the same file at the same offset even after the system crashes or+is rebooted. This allows users of such mappings to make data modifications+persistent in a more efficient way using appropriate CPU instructions.
It feels like there's a word missing/unclear wording in the previous
line, before "using". Without that word, the sentence feels a bit
ambiguous.
Should it be:
persistent in a more efficient way *through the use of* appropriate
CPU instructions.
or:
persistent in a more efficient way *than using* appropriate CPU instructions.
?
Is suspect the first is correct, but need to check.
From: Jan Kara <jack@suse.cz> Date: 2018-04-12 14:22:14
Hello Michael!
On Thu 12-04-18 15:00:49, Michael Kerrisk (man-pages) wrote:
Hello Jan,
I have applied your patch, and tweaked the text a little, and pushed
the result to the git repo.
Thanks!
quoted
+.B MAP_SHARED
+type will silently ignore this flag.
+This flag is supported only for files supporting DAX (direct mapping of persistent
+memory). For other files, creating mapping with this flag results in
+.B EOPNOTSUPP
+error. Shared file mappings with this flag provide the guarantee that while
+some memory is writeably mapped in the address space of the process, it will
+be visible in the same file at the same offset even after the system crashes or
+is rebooted. This allows users of such mappings to make data modifications
+persistent in a more efficient way using appropriate CPU instructions.
It feels like there's a word missing/unclear wording in the previous
line, before "using". Without that word, the sentence feels a bit
ambiguous.
Should it be:
persistent in a more efficient way *through the use of* appropriate
CPU instructions.
or:
persistent in a more efficient way *than using* appropriate CPU instructions.
?
Is suspect the first is correct, but need to check.
Yes, the first is correct.
Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR
From: Michael Kerrisk (man-pages) <hidden> Date: 2018-04-12 18:20:12
Jan, Ross.
On 12 April 2018 at 16:22, Jan Kara [off-list ref] wrote:
Hello Michael!
On Thu 12-04-18 15:00:49, Michael Kerrisk (man-pages) wrote:
quoted
Hello Jan,
I have applied your patch, and tweaked the text a little, and pushed
the result to the git repo.
Thanks!
quoted
quoted
+.B MAP_SHARED
+type will silently ignore this flag.
+This flag is supported only for files supporting DAX (direct mapping of persistent
+memory). For other files, creating mapping with this flag results in
+.B EOPNOTSUPP
+error. Shared file mappings with this flag provide the guarantee that while
+some memory is writeably mapped in the address space of the process, it will
+be visible in the same file at the same offset even after the system crashes or
+is rebooted. This allows users of such mappings to make data modifications
+persistent in a more efficient way using appropriate CPU instructions.
It feels like there's a word missing/unclear wording in the previous
line, before "using". Without that word, the sentence feels a bit
ambiguous.
Should it be:
persistent in a more efficient way *through the use of* appropriate
CPU instructions.
or:
persistent in a more efficient way *than using* appropriate CPU instructions.
?
Is suspect the first is correct, but need to check.
Yes, the first is correct.
Thanks for both checking that phrasing. In the end I decided to reword
the sentence a bot more substantially:
In conjunction with the use of appropriate CPU
instructions, this provides users of such mappings
with a more efficient way of making data modifica‐
tions persistent.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
From: Jan Kara <jack@suse.cz> Date: 2018-04-13 11:17:48
On Thu 12-04-18 20:20:12, Michael Kerrisk (man-pages) wrote:
Thanks for both checking that phrasing. In the end I decided to reword
the sentence a bot more substantially:
In conjunction with the use of appropriate CPU
instructions, this provides users of such mappings
with a more efficient way of making data modifica‐
tions persistent.
Great, thanks for the improvement!
Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm