MAP_DIRECT is an mmap(2) flag with the following semantics:
MAP_DIRECT
When specified with MAP_SHARED a successful fault in this range
indicates that the kernel is maintaining the block map (user linear
address to file offset to physical address relationship) in a manner
that no external
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 mmap3 syscall that checks for
unsupported flags at
When a filesystem sees this flag set it will not allow changes to the
file-offset to physical-block-offset relationship of any extent in the
file. The extent of the extents covered by the global S_IOMAP_SEALED is
filesystem specific. In other words it is similar to the inode-wide
XFS_DIFLAG2_REFLIN
A common pattern for granting a privilege to an unprivileged process is
to pass it an established file descriptor over a unix domain socket.
This enables fine grained access to the MAP_DIRECT mechanism instead of
requiring the mapping process have CAP_LINUX_IMMUTABLE.
Cc: Jan Kara
Cc: Jeff Moyer
We are running running short of vma->vm_flags. We can avoid needing a
new VM_* flag in some cases if the original @flags submitted to mmap(2)
is made available to the ->mmap() 'struct file_operations'
implementation. For example, the proposed addition of MAP_DIRECT can be
implemented without taking
Changes since v5 [1]:
* Compile fixes from a much improved coccinelle semantic patch (thanks
Julia!) that adds a 'flags' argument to all the ->mmap()
implementations in the kernel. (0day-kbuild-robot)
* Make the deprecated MAP_DENYWRITE and MAP_EXECUTABLE flags return
EOPNOTSUPP with the new
On Wed, Aug 23, 2017 at 8:25 AM, Boqun Feng wrote:
> There is no need to use COMPLETION_INITIALIZER_ONSTACK() in
> acpi_nfit_flush_probe(), replace it with init_completion().
Now that I see the better version of this patch with the improved
changelog in the -mm tree...
Acked-by: Dan Williams
__
From: Randy Dodgen
If an ext4 filesystem is mounted with both the DAX and read-only
options, executables on that filesystem will fail to start (claiming
'Segmentation fault') due to the fault handler returning
VM_FAULT_SIGBUS.
This is due to the DAX fault handler (see ext4_dax_huge_fault)
attemp
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fetch while missing checks after the sec
That's a nice simplification. I started cautiously by replicating the same
checks for dax.c (dax_iomap_pte_fault checks for cow_page specifically). I
recall that it used to be possible for COW pages to appear in VM_SHARED
mappings, but I'm glad to see that went away in cda540ace6a19. I'll send a ne
On Wed, Aug 23, 2017 at 12:56 PM, Dave Jiang wrote:
>
>
> On 08/23/2017 11:39 AM, Dan Williams wrote:
>> On Mon, Aug 21, 2017 at 2:11 PM, Dave Jiang wrote:
>>> Adding a DMA supported blk-mq driver for pmem.
>>
>> "Add support for offloading pmem block-device I/O operations to a DMA
>> engine."
>
On 08/23/2017 11:39 AM, Dan Williams wrote:
> On Mon, Aug 21, 2017 at 2:11 PM, Dave Jiang wrote:
>> Adding a DMA supported blk-mq driver for pmem.
>
> "Add support for offloading pmem block-device I/O operations to a DMA engine."
>
>> This provides signficant CPU
>
> *significant
>
>> utiliz
On Thu, Aug 17, 2017 at 06:08:12PM +0200, Jan Kara wrote:
> Pretty crude for now...
>
> Signed-off-by: Jan Kara
> ---
> fs/ext4/file.c | 2 ++
> include/linux/mm.h | 1 +
> include/linux/mman.h| 3 ++-
> include/uapi/asm-generic/mman.h | 1 +
> mm/mmap.c
On Mon, Aug 21, 2017 at 2:11 PM, Dave Jiang wrote:
> Adding a DMA supported blk-mq driver for pmem.
"Add support for offloading pmem block-device I/O operations to a DMA engine."
> This provides signficant CPU
*significant
> utilization reduction.
"at the cost of some increased latency and ba
> + pfn_t pfn;
>
> if (write) {
> sb_start_pagefault(sb);
> @@ -287,16 +288,39 @@ static int ext4_dax_huge_fault(struct vm_fault *vmf,
> down_read(&EXT4_I(inode)->i_mmap_sem);
> handle = ext4_journal_start_sb(sb, EXT4_HT_WRITE_PAGE,
>
> @@ -1416,6 +1416,7 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> * @vmf: The description of the fault
> * @pe_size: Size of the page to fault in
> * @ops: Iomap ops passed from the file system
> + * @pfnp: PFN to insert for synchronous faults if fsync is required
> *
> * Whe
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Looks good,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
The daxctl io option allows I/Os to be performed between file descriptor to
and from device dax files. It also provides a way to zero a device dax
device.
i.e. daxctl io --input=/home/myfile --output=/dev/dax1.0
Signed-off-by: Dave Jiang
---
v3:
- Added support for size suffix suggested by Ross
On Tue, 2017-08-22 at 16:19 -0600, Vishal Verma wrote:
:
> +
> + /* The block had a media error, and needs to be
> cleared */
> + if (btt_is_badblock(btt, arena, arena-
> >freelist[lane].block)) {
> + arena->freelist[lane].has_err = 1;
> +
On Wed, Aug 23, 2017 at 9:47 AM, Ross Zwisler
wrote:
> On Tue, Aug 22, 2017 at 05:06:15PM -0700, Dave Jiang wrote:
>> The daxctl io option allows I/Os to be performed between file descriptor to
>> and from device dax files. It also provides a way to zero a device dax
>> device.
>>
>> i.e. daxctl i
On Tue, Aug 22, 2017 at 05:06:15PM -0700, Dave Jiang wrote:
> The daxctl io option allows I/Os to be performed between file descriptor to
> and from device dax files. It also provides a way to zero a device dax
> device.
>
> i.e. daxctl io --input=/home/myfile --output=/dev/dax1.0
>
> Signed-off-
On Tue, Aug 22, 2017 at 08:37:04PM -0700, rdod...@gmail.com wrote:
> From: Randy Dodgen
>
> If an ext4 filesystem is mounted with both the DAX and read-only
> options, executables on that filesystem will fail to start (claiming
> 'Segmentation fault') due to the fault handler returning
> VM_FAULT
On Wed, Aug 23, 2017 at 11:57:33AM +0200, Jan Kara wrote:
> On Tue 22-08-17 16:24:35, Ross Zwisler wrote:
> > In DAX there are two separate places where the 2MiB range of a PMD is
> > defined.
> >
> > The first is in the page tables, where a PMD mapping inserted for a given
> > address spans from
There is no need to use COMPLETION_INITIALIZER_ONSTACK() in
acpi_nfit_flush_probe(), replace it with init_completion().
Signed-off-by: Boqun Feng
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
i
On Tue 22-08-17 16:24:36, Ross Zwisler wrote:
> Use ~PG_PMD_COLOUR in dax_entry_waitqueue() instead of open coding an
> equivalent page offset mask.
>
> Signed-off-by: Ross Zwisler
Looks good. You can add:
Reviewed-by: Jan Kara
H
On Tue 22-08-17 16:24:35, Ross Zwisler wrote:
> In DAX there are two separate places where the 2MiB range of a PMD is
> defined.
>
> The first is in the page tables, where a PMD mapping inserted for a given
> address spans from (vmf->address & PMD_MASK) to
> ((vmf->address & PMD_MASK) + PMD_SIZE -
31 matches
Mail list logo
