[PATCH v2 1/2] mm: avoid spurious 'bad pmd' warning messages

essages, and add a comment explaining why the ordering is important. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Reviewed-by: Jan Kara <j...@suse.cz> Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map") Cc: sta...@vger.kernel.o

[PATCH v2 2/2] dax: Fix race between colliding PMD & PTE entries

rss-counter state mm:8800a817d280 idx:1 val:1 BUG: non-zero nr_ptes on freeing mm: 15 Fix this issue by having the DAX fault handlers verify that it is safe to continue their fault after they have taken an entry lock to block other racing faults. Signed-off-by: Ross Zwisler <ross.zwis...@linux

Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

On Mon, May 22, 2017 at 04:37:48PM +0200, Jan Kara wrote: > On Thu 18-05-17 15:29:39, Ross Zwisler wrote: > > On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote: > > > On Wed 17-05-17 11:16:39, Ross Zwisler wrote: <> > > > The first scenario seems to

Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

On Mon, May 22, 2017 at 04:44:57PM +0200, Jan Kara wrote: > On Wed 17-05-17 11:16:39, Ross Zwisler wrote: > > We currently have two related PMD vs PTE races in the DAX code. These can > > both be easily triggered by having two threads reading and writing > > simultaneousl

Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote: > On Wed 17-05-17 11:16:39, Ross Zwisler wrote: > > We currently have two related PMD vs PTE races in the DAX code. These can > > both be easily triggered by having two threads reading and writing > > simultaneousl

[PATCH] generic: add regression test for DAX PTE/PMD races

ting Filesystem Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- .gitignore| 1 + src/Makefile | 3 +- src/t_mmap_cow_race.c | 106 ++ tests/generic/435 | 61 + tests/gener

[PATCH 2/2] dax: Fix race between colliding PMD & PTE entries

t handlers verify that it is safe to continue their fault after they have taken an entry lock to block other racing faults. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Reported-by: Pawel Lebioda <pawel.lebi...@intel.com> Cc: sta...@vger.kernel.org --- I've written a new xfstest for

[PATCH 1/2] mm: avoid spurious 'bad pmd' warning messages

ut a warning and returns 1. So, we do end up doing the right thing, but only after spamming dmesg with suspicious looking messages: mm/pgtable-generic.c:39: bad pmd 8808daa49b88(8401006000a5) Reorder these checks so that pmd_devmap() is checked first, avoiding the error messages. S

Re: [PATCH] filesystem-dax: fix broken __dax_zero_page_range() conversion

() operation. The dax mapping length is assumed to be hard > coded as PAGE_SIZE. > > Without this fix any page unaligned zeroing request will trigger a > -EINVAL return from bdev_dax_pgoff(). > > Cc: Jan Kara <j...@suse.com> > Cc: Christoph Hellwig <h...@lst.

[PATCH 5/4] dax: Fix PMD data corruption when fault races with write

apping blocks for the fault. That way we are sure invalidate_inode_pages2_range() call for racing write will either block on entry lock waiting for the fault to finish (and unmap stale page tables after that) or read fault will see already allocated blocks by write(2). Signed-off-by: Ross Zwisler <

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

; > Cc: Christoph Hellwig <h...@lst.de> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Al Viro <v...@zeniv.linux.org.uk> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Matthew Wilcox <mawil...@microsoft.com> > Cc: Ross Zwisler <ross.zwis...@

Re: [PATCH 4/4] dax: Fix data corruption when fault races with write

r read fault will see > already allocated blocks by write(2). > > Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956 > CC: sta...@vger.kernel.org > Signed-off-by: Jan Kara <j...@suse.cz> Yep, this looks correct to me. Thanks! Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> _

Re: [PATCH v2 1/2] dax: prevent invalidation of mapped DAX entries

On Fri, May 05, 2017 at 09:29:12AM +0200, Jan Kara wrote: > On Thu 04-05-17 13:59:09, Ross Zwisler wrote: > > dax_invalidate_mapping_entry() currently removes DAX exceptional entries > > only if they are clean and unlocked. This is done via: > > > &g

[PATCH v2 2/2] dax: fix data corruption due to stale mmap reads

invalidate_inode_pages2_range() so that it properly unmaps the DAX entries being removed from the radix tree. This is based on an initial patch from Jan Kara. I've written an fstest that triggers this error: http://www.spinics.net/lists/linux-mm/msg126276.html Signed-off-by: Ross Zwisler <ross.z

[PATCH v2 1/2] dax: prevent invalidation of mapped DAX entries

rth it. So, just remove dax_invalidate_mapping_entry() and leave the DAX entries in the radix tree. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate") Reported-by: Jan Kara <j...@suse.cz>

Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads

On Thu, Apr 27, 2017 at 09:26:59AM +0200, Jan Kara wrote: > On Wed 26-04-17 16:52:36, Ross Zwisler wrote: <> > > I don't think this alone is enough to save us. The I/O path doesn't > > currently > > take any DAX radix tree entry locks, so our race would just beco

Re: [PATCH 1/2] dax: prevent invalidation of mapped DAX entries

On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote: > On Thu 20-04-17 21:44:36, Ross Zwisler wrote: > > dax_invalidate_mapping_entry() currently removes DAX exceptional entries > > only if they are clean and unlocked. This is done via: > > > &g

Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads

On Wed, Apr 26, 2017 at 10:52:35AM +0200, Jan Kara wrote: > On Tue 25-04-17 16:59:36, Ross Zwisler wrote: > > On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote: > > <> > > > Hum, but now thinking more about it I have hard time figuring out why > > &g

[PATCH v3 1/2] xfs: fix incorrect argument count check

t_mmap_dio.c actually requires 4 arguments, not 3 as the current check enforces: # ./src/t_mmap_dio usage: t_mmap_dio # ./src/t_mmap_dio one two three open src(No such file or directory) len 0 (null) Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.

[PATCH v3 2/2] dax: add regression test for stale mmap reads

. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- .gitignore | 1 + src/Makefile | 2 +- src/t_mmap_stale_pmd.c | 73 ++ tests/generic/427 | 59 tests/generic/427.out

Re: [PATCH v2 2/2] dax: add regression test for stale mmap reads

On Wed, Apr 26, 2017 at 05:09:07PM +0800, Xiong Zhou wrote: > On Tue, Apr 25, 2017 at 02:51:06PM -0600, Ross Zwisler wrote: <> > > + /* > > +* Try and use the mmap to read back the data we just wrote with > > +* pwrite(). If the kernel bug is presen

Re: [PATCH 2/2] dax: fix data corruption due to stale mmap reads

On Tue, Apr 25, 2017 at 01:10:43PM +0200, Jan Kara wrote: <> > Hum, but now thinking more about it I have hard time figuring out why write > vs fault cannot actually still race: > > CPU1 - write(2) CPU2 - read fault > >

[PATCH v2 2/2] dax: add regression test for stale mmap reads

. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- .gitignore| 1 + src/Makefile | 2 +- src/t_dax_stale_pmd.c | 59 + tests/generic/427 | 67 +++ tests/generic/4

[PATCH v2 1/2] xfs: fix incorrect argument count check

t_mmap_dio.c actually requires 4 arguments, not 3 as the current check enforces: # ./src/t_mmap_dio usage: t_mmap_dio # ./src/t_mmap_dio one two three open src(No such file or directory) len 0 (null) Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.

Re: [PATCH 2/2] dax: add regression test for stale mmap reads

On Tue, Apr 25, 2017 at 07:27:39PM +0800, Eryu Guan wrote: > On Mon, Apr 24, 2017 at 11:49:32AM -0600, Ross Zwisler wrote: > > This adds a regression test for the following kernel patch: > > > > dax: fix data corruption due to stale mmap reads > > > > Seems t

[PATCH 2/2] dax: add regression test for stale mmap reads

. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- .gitignore| 1 + src/Makefile | 2 +- src/t_dax_stale_pmd.c | 56 ++ tests/generic/427 | 68 +++ tests/generic/427.ou

[PATCH 1/2] xfs: fix incorrect argument count check

t_mmap_dio.c actually requires 4 arguments, not 3 as the current check enforces: usage: t_mmap_dio open src(No such file or directory) len 0 (null) Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Fixes: 456581661b4d ("xfs: test per-inode DAX flag by IO") --- src/

[PATCH 1/2] dax: prevent invalidation of mapped DAX entries

() isn't allowed to block, and unmap_mapping_range() takes a write lock on the mapping->i_mmap_rwsem. Since we essentially never have unmapped DAX entries to evict from the radix tree, just remove dax_invalidate_mapping_entry(). Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com&

Re: [PATCH v3] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions

Anvin" <h...@zytor.com> > Cc: Al Viro <v...@zeniv.linux.org.uk> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Matthew Wilcox <mawil...@microsoft.com> > Cc: Ross Zwisler <ross.zwis...@linux.intel.com> > Signed-off-by: Toshi Kan

[PATCH] dax: fix radix tree insertion race

s made it through a clean xfstests run with the current v4.11-rc5 based linux/master, and it also ran generic/340 500 times in a loop. It used to fail within the first 10 iterations. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Cc: <sta...@vger.kernel.org>[4.10+]

Re: [PATCH] acpi, nfit: fix acpi_get_table leak

> acpi_get_table_with_size()/early_acpi_os_unmap_memory() users") > Cc: Lv Zheng <lv.zh...@intel.com> > Reported-by: Ross Zwisler <ross.zwis...@linux.intel.com> > Signed-off-by: Dan Williams <dan.j.willi...@intel.com> > --- > drivers/acpi/nfit/core.c |9 +++

Re: [PATCH 08/13] x86, libnvdimm, dax: stop abusing __copy_user_nocache

On Thu, Jan 19, 2017 at 07:50:56PM -0800, Dan Williams wrote: <> > diff --git a/drivers/nvdimm/x86-asm.S b/drivers/nvdimm/x86-asm.S > new file mode 100644 > index ..23c5ec94e896 > --- /dev/null > +++ b/drivers/nvdimm/x86-asm.S > @@ -0,0 +1,71 @@ > +/* > + * Copyright (c) 2017, Intel

Re: fsx tests on DAX started to fail with msync failure on 0307 -next tree

On Tue, Mar 14, 2017 at 11:36:10AM -0600, Ross Zwisler wrote: > On Tue, Mar 14, 2017 at 10:56:42AM +0800, Xiong Zhou wrote: > > Hi, > > > > xfstests cases: > > generic/075 generic/112 generic/127 generic/231 generic/263 > > > > fail with

[PATCH] dax: fix regression in dax_writeback_mapping_range()

eneric/075 generic/112 generic/127 generic/231 generic/263) are resolved. Reported-by: Xiong Zhou <xz...@redhat.com> Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dax.c b/fs/dax.c index 1

Re: fsx tests on DAX started to fail with msync failure on 0307 -next tree

On Tue, Mar 14, 2017 at 10:56:42AM +0800, Xiong Zhou wrote: > Hi, > > xfstests cases: > generic/075 generic/112 generic/127 generic/231 generic/263 > > fail with DAX, pass without it. Both xfs and ext4. > > It was okay on 0306 -next tree. Thanks for the report. I'm looking into it. -next is

[PATCH 5/6] dax: add tracepoint to dax_writeback_one()

Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 1 + include/trace/events/fs_dax.h | 24 2 files changed, 25 insertions(+) diff --git a/fs/dax.c b/fs/dax.c index 7ca1989..d340389 100644 --- a/fs/dax.c +++ b/fs/dax.c @@

[PATCH 3/6] dax: add tracepoints to dax_load_hole()

-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 16 +++- include/trace/events/fs_dax.h | 1 + 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index b52732fb..bcfa11a 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -

[PATCH 2/6] dax: add tracepoints to dax_pfn_mkwrite()

|KILLABLE|USER address 0x1040 pgoff 0x200 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 3 +++ include/trace/events/fs_dax.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/fs/dax.c b/fs/dax.c index bf70d4d..b52732fb 100644 --

[PATCH 4/6] dax: add tracepoints to dax_writeback_mapping_range()

: dax_writeback_range_done: dev 259:0 ino 0x1003 pgoff 0x200-0x2ff Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 8 ++-- include/trace/events/fs_dax.h | 32 2 files changed, 38 insertions(+), 2 deletions(-) diff --git a/fs

[PATCH 6/6] dax: add tracepoint to dax_insert_mapping()

: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x1042 pgoff 0x220 MAJOR|NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 1 + include/trace/events/fs_dax.h | 30 ++ 2 files chang

[PATCH 1/6] dax: add tracepoints to dax_iomap_pte_fault()

pgoff 0x220 small-1086 [005] 71.140396: dax_pte_fault_done: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x1042 pgoff 0x220 MAJOR|NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- fs/dax.c | 15 +++ include

Re: question about ext4 block allocation

On Thu, Feb 09, 2017 at 02:29:48PM -0500, Theodore Ts'o wrote: > On Thu, Feb 09, 2017 at 10:52:28AM -0700, Ross Zwisler wrote: > > I've pared down his xfstest to be a pretty minimal reproducer, and you can > > find it here: > > > > https://git.kernel.org/cgit/linux/

Re: question about ext4 block allocation

On Thu, Feb 09, 2017 at 04:30:09PM +0100, Jan Kara wrote: > Hi Ross, > > On Mon 06-02-17 16:14:09, Ross Zwisler wrote: > > I recently hit an issue in my DAX testing where I was unable to get ext4 to > > give me 2 MiB sized and aligned block allocations in a situation where I

Re: [PATCH v5 2/2] generic: test mmap io through DAX and non-DAX

On Sun, Feb 05, 2017 at 02:21:44PM +0800, Xiong Zhou wrote: > Mount TEST_DEV as non-DAX, SCRATCH_DEV as DAX, then > do some IO between them. In this case we use mmap > and dio/buffered IO read/write test programme. > > Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com&g

Re: [PATCH v5 1/2] xfs: test per-inode DAX flag by IO

. > > Add help _require_scratch_dax to make sure we can > test DAX feature on SCRATCH_DEV. > > Add mmap dio test programme to test read/write > between a mmap area of one file and another file > directly or buffered, with different size. > > Signed-off-by: Ross Zwisler <

Re: [PATCH v4 0/2] mmap dio and DAX

On Fri, Feb 03, 2017 at 01:57:17PM +0800, Xiong Zhou wrote: > On Tue, Jan 24, 2017 at 03:28:55PM -0700, Ross Zwisler wrote: > > On Fri, Jan 20, 2017 at 02:15:48PM +0800, Xiong Zhou wrote: > > > common/rc : requires SCRATCH_DEV support DAX > > > src/t_mmap_dio.c

Re: [PATCH v2 1/3] mm,fs,dax: Change ->pmd_fault to ->huge_fault

On Thu, Jan 26, 2017 at 10:09:47AM -0700, Dave Jiang wrote: > In preparation for adding the ability to handle PUD pages, convert > ->pmd_fault to ->huge_fault. The vm_fault structure is extended to > include a union of the different page table pointers that may be needed, > and three flag bits

[PATCH] ext4: Remove unused function ext4_dax_huge_fault()

ult() and remove the unused function. This fix also quiets the following compilation warning: /ext4/file.c:279:1: warning: ‘ext4_dax_huge_fault’ defined but not used [-Wunused-function] ext4_dax_huge_fault(struct vm_fault *vmf) Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Fixes

Re: No Persistent Memory (legacy) even persistent (type 12) was found

On Thu, Jan 26, 2017 at 07:56:58AM +, Soccer Liu wrote: > Hi: > >  I am trying to play with the NVDIMM driver and follow instructions in > https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system > and >

Re: [PATCH] dax: put back __GFP_IO in the dax fault handler

On Mon, Jan 23, 2017 at 05:06:30PM -0700, Dave Jiang wrote: > __GFP_IO got accidentally dropped in the dax fault handler during the > vmf parameter conversion. Putting it back. > > Signed-off-by: Dave Jiang I don't see why this is needed? We already have an overly

Re: [PATCH] mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf

t to do when the 'vma' you're passed in doesn't match 'vmf->vma'. Having one source of truth seems good, and it reduces the amount of args we are passing around. Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] ndctl: add a BTT check utility

On Fri, Jan 20, 2017 at 12:04:46PM -0800, Dan Williams wrote: > [ adding Jeff ] > > Some comments on boilerplate / organization items... > > > On Thu, Jan 19, 2017 at 7:12 PM, Vishal Verma > wrote: > > Add the check-namespace command to ndctl. This will check the BTT

Re: [PATCH v2 1/2] xfs: test per-inode DAX flag by IO

On Thu, Jan 19, 2017 at 06:13:57PM +0800, Xiong Zhou wrote: > In a DAX mountpoint, do IO betwen files with and > without DAX per-inode flag. We do mmap and O_DIRECT > read/write IO in this case. Then test again in the > same device without dax mountoption. > > Add help _require_scratch_dax to

Re: [LSF/MM TOPIC] Future direction of DAX

On Tue, Jan 17, 2017 at 09:25:33PM -0800, wi...@bombadil.infradead.org wrote: > On Fri, Jan 13, 2017 at 05:20:08PM -0700, Ross Zwisler wrote: > > We still have a lot of work to do, though, and I'd like to propose a > > discussion > > around what features people woul

[LSF/MM TOPIC] Future direction of DAX

This past year has seen a lot of new DAX development. We have added support for fsync/msync, moved to the new iomap I/O data structure, introduced radix tree based locking, re-enabled PMD support (twice!), and have fixed a bunch of bugs. We still have a lot of work to do, though, and I'd like to

[PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP

depend on iomap support being present for DAX. Make this explicit by selecting FS_IOMAP if we compile in DAX support. This allows us to remove conditional selections of FS_IOMAP when FS_DAX was present for ext2 and ext4, and to remove an #ifdef in fs/dax.c. Signed-off-by: Ross Zwisler <ross.z

[PATCH v4 4/7] dax: add tracepoints to dax_pmd_load_hole()

radix_entry 0x1e read_big-1478 [004] 238.242392: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared ALLOW_RETRY|KILLABLE|USER address 0x1040 vm_start 0x1020 vm_end 0x1060 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Re

[PATCH v4 6/7] mm, dax: make pmd_fault() and friends to be the same as fault()

dified to do the same. Signed-off-by: Dave Jiang <dave.ji...@intel.com> Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> Reviewed-by: Jan Kara <j...@suse.cz> --- drivers/dax/dax.c | 16 +++- fs/dax.c | 42 ++

[PATCH v4 5/7] dax: add tracepoints to dax_pmd_insert_mapping()

0x100600 DEV|MAP radix_entry 0xc000e big-1504 [001] 326.960986: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.z

[PATCH v4 7/7] mm, dax: move pmd_fault() to take only vmf parameter

intel.com> Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> Reviewed-by: Jan Kara <j...@suse.cz> --- drivers/dax/dax.c | 18 +++ fs/dax.c | 54 --- fs/ext4/file.c| 8 ++

[PATCH v4 1/7] tracing: add __print_flags_u64()

] #define PFN_SG_CHAIN (1ULL << (BITS_PER_LONG_LONG - 1)) ^ Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Reviewed-by: Steven Rostedt <rost...@goodmis.org> --- include/linux/trace_events.h | 4 include/trace/trace_events.h | 11 +++ kernel/trace/tr

[PATCH v4 3/7] dax: update MAINTAINERS entries for FS DAX

Add the new include/trace/events/fs_dax.h tracepoint header, the existing include/linux/dax.h header, update Matthew's email address and add myself as a maintainer for filesystem DAX. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Matthew Wilcox <mawil...@micr

[PATCH v4 0/7] DAX tracepoints, mm argument simplification

() to take only vmf parameter Ross Zwisler (5): tracing: add __print_flags_u64() dax: add tracepoint infrastructure, PMD tracing dax: update MAINTAINERS entries for FS DAX dax: add tracepoints to dax_pmd_load_hole() dax: add tracepoints to dax_pmd_insert_mapping() MAINTAINERS

Re: [PATCH v2 0/4] Write protect DAX PMDs in *sync path

On Thu, Jan 05, 2017 at 05:27:34PM -0800, Andrew Morton wrote: > On Tue, 3 Jan 2017 17:13:49 -0700 Ross Zwisler <ross.zwis...@linux.intel.com> > wrote: > > > On Thu, Dec 22, 2016 at 02:18:52PM -0700, Ross Zwisler wrote: > > > Currently dax_mapping_entry_mkclean() fa

Re: LTP rwtest01 blocks on DAX mountpoint

On Wed, Jan 04, 2017 at 05:48:34PM +0800, Xiong Zhou wrote: > On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > > On M

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote: > > > > On Sat, Dec 24, 2016 a

Re: [PATCH] x86: fix kaslr and memmap collision

On Tue, Jan 03, 2017 at 04:31:37PM +0800, Baoquan He wrote: > Hi Dan, > > On 11/22/16 at 09:26am, Dan Williams wrote: > > [ replying for Dave since he's offline today and tomorrow ] > > > > On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar wrote: > > > > > > * Dave Jiang

Re: LTP rwtest01 blocks on DAX mountpoint

On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > On Fri 30-12-16 17:33:53, Xiong Zhou wrote: > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote: > > > Hi lists, > > > > > > Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks > > > on linux-next tree, now on

[PATCH v2 4/4] dax: wrprotect pmd_t in dax_mapping_entry_mkclean

as part of the fsync operation 2). This will cause the writes in step 3) above to generate page faults where we'll re-dirty the PMD radix tree entry, resulting in flushes in the fsync that happens in step 4). Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Cc: Jan Kara <j...@suse.

[PATCH v2 0/4] Write protect DAX PMDs in *sync path

CONFIG_TRANSPARENT_HUGEPAGE isn't defined. (Dan & Jan) Dan Williams (1): dax: kill uml support Ross Zwisler (3): dax: add stub for pmdp_huge_clear_flush() mm: add follow_pte_pmd() dax: wrprotect pmd_t in dax_mapping_entry_mkclean fs/Kconfig| 2 +- fs/d

[PATCH v2 3/4] mm: add follow_pte_pmd()

Similar to follow_pte(), follow_pte_pmd() allows either a PTE leaf or a huge page PMD leaf to be found and returned. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Dave Hansen <dave.han...@intel.com> --- include/linux/mm.h | 2 ++ mm/memory.c

[PATCH v2 1/4] dax: kill uml support

toph Hellwig <h...@lst.de> Cc: Dave Chinner <da...@fromorbit.com> Cc: Dave Hansen <dave.han...@intel.com> Cc: Matthew Wilcox <mawil...@microsoft.com> Cc: Alexander Viro <v...@zeniv.linux.org.uk> Cc: Ross Zwisler <ross.zwis...@linux.intel.com> Signed-off-by: Dan Wi

[PATCH 2/2] dax: wrprotect pmd_t in dax_mapping_entry_mkclean

as part of the fsync operation 2). This will cause the writes in step 3) above to generate page faults where we'll re-dirty the PMD radix tree entry, resulting in flushes in the fsync that happens in step 4). Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Cc: Jan Kara <j...@suse.

[PATCH 1/2] mm: add follow_pte_pmd()

Similar to follow_pte(), follow_pte_pmd() allows either a PTE leaf or a huge page PMD leaf to be found and returned. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Dave Hansen <dave.han...@intel.com> --- include/linux/mm.h | 2 ++ mm/memory.c

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote: <> > Definitely the first step would be your simple preallocated per > inode approach until it is shown to be insufficient. Reviving this thread a few months later... Dave, we're interested in taking a serious look at what it would

Re: [PATCH v3 0/5] introduce DAX tracepoint support

On Thu, Dec 01, 2016 at 09:37:46AM -0700, Ross Zwisler wrote: > Tracepoints are the standard way to capture debugging and tracing > information in many parts of the kernel, including the XFS and ext4 > filesystems. This series creates a tracepoint header for FS DAX and add > the f

Re: [PATCH v3 3/3] mm, dax: move pmd_fault() to take only vmf parameter

ed-off-by: Dave Jiang <dave.ji...@intel.com> This seems correct to me. Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v2 1/3] dax: masking off __GFP_FS in fs DAX handlers

Jiang <dave.ji...@intel.com> This seems correct to me. Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [ext4] e2ae766c1b: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c

On Mon, Dec 12, 2016 at 06:00:20PM -0500, Theodore Ts'o wrote: > On Mon, Dec 12, 2016 at 03:48:51PM -0700, Ross Zwisler wrote: > > On Mon, Dec 12, 2016 at 05:37:36PM -0500, Theodore Ts'o wrote: > > > Is this problem likely to happen in other file systems? Should I take >

Re: [ext4] e2ae766c1b: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c

On Mon, Dec 12, 2016 at 05:37:36PM -0500, Theodore Ts'o wrote: > Is this problem likely to happen in other file systems? Should I take > this path through the ext4 tree, or would it be better via some other > git tree? > > - Ted The problem is in the

Re: [ext4] e2ae766c1b: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c

4-00045-ge2ae766 #1 > > kern :warn : [ 325.608916] Hardware name: Intel Corporation LH > > Pass/S4600LH, BIOS SE5C600.86B.99.02.1047.032320122259 03/23/2012 > > kern :warn : [ 325.608922] c9002c1f7be0 > > kern :warn : [ 325.608923] 81466af9 > > kern

Re: [PATCH 5/6] dax: Call ->iomap_begin without entry lock during dax fault

On Thu, Dec 01, 2016 at 03:24:47PM -0700, Ross Zwisler wrote: > On Thu, Nov 24, 2016 at 10:46:35AM +0100, Jan Kara wrote: > > Currently ->iomap_begin() handler is called with entry lock held. If the > > filesystem held any locks between ->iomap_begin() and ->iomap_end()

Re: [PATCH 5/6] dax: Call ->iomap_begin without entry lock during dax fault

On Thu, Nov 24, 2016 at 10:46:35AM +0100, Jan Kara wrote: > Currently ->iomap_begin() handler is called with entry lock held. If the > filesystem held any locks between ->iomap_begin() and ->iomap_end() > (such as ext4 which will want to hold transaction open), this would cause > lock inversion

[PATCH v3 0/5] introduce DAX tracepoint support

the entires. (Steve) - Fixed 'mask' in trace_print_flags_seq_u64() to be an unsigned long long. (Steve) Ross Zwisler (5): tracing: add __print_flags_u64() dax: add tracepoint infrastructure, PMD tracing dax: update MAINTAINERS entries for FS DAX dax: add tracepoints to dax_pmd_load_hole()

[PATCH v3 2/5] dax: add tracepoint infrastructure, PMD tracing

ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Dave Chinner <da...@fromorbit.com> Reviewed-by: Jan Kara <j.

[PATCH v3 3/5] dax: update MAINTAINERS entries for FS DAX

Add the new include/trace/events/fs_dax.h tracepoint header, the existing include/linux/dax.h header, update Matthew's email address and add myself as a maintainer for filesystem DAX. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Matthew Wilcox <mawil...@micr

[PATCH v3 5/5] dax: add tracepoints to dax_pmd_insert_mapping()

0x100600 DEV|MAP radix_entry 0xc000e big-1504 [001] 326.960986: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.z

[PATCH v3 4/5] dax: add tracepoints to dax_pmd_load_hole()

radix_entry 0x1e read_big-1478 [004] 238.242392: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared ALLOW_RETRY|KILLABLE|USER address 0x1040 vm_start 0x1020 vm_end 0x1060 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Re

Re: [PATCH v2 3/6] dax: add tracepoint infrastructure, PMD tracing

On Thu, Dec 01, 2016 at 09:16:28AM -0500, Steven Rostedt wrote: > On Wed, 30 Nov 2016 16:45:30 -0700 > Ross Zwisler <ross.zwis...@linux.intel.com> wrote: > > > > --- /dev/null > > +++ b/include/trace/events/fs_dax.h > > @@ -0,0 +1,68 @@ > > +#undef TRA

Re: [PATCH v2 6/6] dax: add tracepoints to dax_pmd_insert_mapping()

On Thu, Dec 01, 2016 at 09:19:30AM -0500, Steven Rostedt wrote: > On Wed, 30 Nov 2016 16:45:33 -0700 > Ross Zwisler <ross.zwis...@linux.intel.com> wrote: > > > diff --git a/include/linux/pfn_t.h b/include/linux/pfn_t.h > > index a3d90b9..033fc7b 100644 > > ---

Re: [PATCH v2 1/6] tracing: add __print_flags_u64()

On Thu, Dec 01, 2016 at 09:12:54AM -0500, Steven Rostedt wrote: > On Wed, 30 Nov 2016 16:45:28 -0700 > Ross Zwisler <ross.zwis...@linux.intel.com> wrote: > > diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c > > index 3fc2042..ed4398f 10064

Re: [PATCH v2 2/6] dax: remove leading space from labels

On Thu, Dec 01, 2016 at 09:11:44AM +0100, Jan Kara wrote: > On Wed 30-11-16 16:45:29, Ross Zwisler wrote: > > No functional change. > > > > As of this commit: > > > > commit 218dd85887da (".gitattributes: set git diff driver for C source code > > fi

[PATCH v2 4/6] dax: update MAINTAINERS entries for FS DAX

Add the new include/trace/events/fs_dax.h tracepoint header, the existing include/linux/dax.h header, update Matthew's email address and add myself as a maintainer for filesystem DAX. Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Matthew Wilcox <mawil...@micr

[PATCH v2 0/6] introduce DAX tracepoint support

necessary helpers to the tracing infrastructure. These functions allow us to print symbols associated with flags that are 64 bits wide even on 32 bit machines. We need this for the pfn_t flags. Ross Zwisler (6): tracing: add __print_flags_u64() dax: remove leading space from labels

[PATCH v2 3/6] dax: add tracepoint infrastructure, PMD tracing

ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Suggested-by: Dave Chinner <da...@fromorbit.com> --- fs/dax.c

[PATCH v2 5/6] dax: add tracepoints to dax_pmd_load_hole()

radix_entry 0x1e read_big-1478 [004] 238.242392: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared ALLOW_RETRY|KILLABLE|USER address 0x1040 vm_start 0x1020 vm_end 0x1060 pgoff 0x200 max_pgoff 0x1400 NOPAGE Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> Re

[PATCH v2 1/6] tracing: add __print_flags_u64()

] #define PFN_SG_CHAIN (1ULL << (BITS_PER_LONG_LONG - 1)) ^ Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- include/linux/trace_events.h | 4 include/trace/trace_events.h | 11 +++ kernel/trace/trace_output.c | 38 ++ 3 f

Re: [PATCH 1/6] dax: fix build breakage with ext4, dax and !iomap

On Tue, Nov 29, 2016 at 09:53:03AM +0100, Jan Kara wrote: > On Mon 28-11-16 12:15:04, Ross Zwisler wrote: > > On Thu, Nov 24, 2016 at 10:02:39AM +0100, Jan Kara wrote: > > > On Wed 23-11-16 11:44:17, Ross Zwisler wrote: > > > > With the current Kconfig setup it is

Re: [PATCH 3/6] dax: Avoid page invalidation races and unnecessary radix tree traversals

called dax_iomap_rw(), and no filesystems still use generic_file_direct_write() for DAX so you can probably remove it from the changelog - up to you. Aside from that: Reviewed-by: Ross Zwisler <ross.zwis...@linux.intel.com> > hole pages from the radix tree when write(2) to the file happens. This

Re: [PATCH 2/6] mm: Invalidate DAX radix tree entries only if appropriate

> > Create appropriate DAX functions to handle invalidation of DAX entries > for invalidate_inode_pages2_range() and invalidate_mapping_pages() and > wire them up into the corresponding mm functions. > > Signed-off-by: Jan Kara <j...@suse.cz> For the DAX bits: Reviewe

<    1   2   3   4   5   6   7   8   >