Returned mail: see transcript for details

The original message was received at Tue, 12 Sep 2017 12:32:42 +0800 from hrz.tu-chemnitz.de [219.156.72.194] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.01.org.: >>> MAIL

[PATCH v2 4/5] ext4: add ext4_should_use_dax()

This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces the complex conditional in ext4_set_inode_flags(). Signed-off-by: Ross Zwisler --- fs/ext4/inode.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git

[PATCH v2 5/5] ext4: remove duplicate extended attributes defs

The following commit: commit 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support") added several defines related to extended attributes to ext4.h. They were added within an #ifndef FS_IOC_FSGETXATTR block with the comment: /* Until the uapi changes get merged for

[PATCH v2 3/5] ext4: add sanity check for encryption + DAX

We prevent DAX from being used on inodes which are using ext4's built in encryption via a check in ext4_set_inode_flags(). We do have what appears to be an unsafe transition of S_DAX in ext4_set_context(), though, where S_DAX can get disabled without us doing a proper writeback + invalidate.

[PATCH v2 1/5] ext4: prevent data corruption with inline data + DAX

If an inode has inline data it is currently prevented from using DAX by a check in ext4_set_inode_flags(). When the inode grows inline data via ext4_create_inline_data() or removes its inline data via ext4_destroy_inline_data_nolock(), the value of S_DAX can change. Currently these changes are

[PATCH v2 0/5] ext4: DAX data corruption fixes

This series prevents a pair of data corruptions with ext4 + DAX. The first such corruption happens when combining the inline data feature with DAX, and the second happens when combining data journaling with DAX. Both can be reliably reproduced with the fstests that I have posted here:

[PATCH v2 2/5] ext4: prevent data corruption with journaling + DAX

The current code has the potential for data corruption when changing an inode's journaling mode, as that can result in a subsequent unsafe change in S_DAX. I've captured an instance of this data corruption in the following fstest: https://patchwork.kernel.org/patch/9948377/ Prevent this data

[PATCH 2/3] ext4: test for DAX + journaling corruption

Add a regression test for the following kernel commit: ext4: prevent data corruption with journaling + DAX The test passes if either we successfully compare the data between the mmap with journaling turned on and the one with journaling turned off, or if we fail the chattr command to turn on

[PATCH 3/3] ext4: test for inline data + DAX corruption

Add a regression test for the following kernel commit: ext4: prevent data corruption with inline data + DAX The test passes either if we don't encounter corruption, or if mounting with DAX + inline data fails. The latter is the way that we prevent this issue in the kernel. Signed-off-by:

[PATCH 1/3] .gitignore: ignore cscope files

Signed-off-by: Ross Zwisler --- .gitignore | 4 1 file changed, 4 insertions(+) diff --git a/.gitignore b/.gitignore index 28fe84d..2accc37 100644 --- a/.gitignore +++ b/.gitignore @@ -238,3 +238,7 @@ /tests/xfs/033.out /tests/xfs/071.out /tests/xfs/096.out

Re: [PATCH 0/9] add ext4 per-inode DAX flag

On Fri 08-09-17 11:39:13, Ted Tso wrote: > On Fri, Sep 08, 2017 at 09:25:43AM +1000, Dave Chinner wrote: > > > Okay, so other ideas (which you have also probably already though of) > > > include: > > > > > > 1) Just return -EBUSY if anyone tries to change the DAX flag of an inode > > > with > >

Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Fri 08-09-17 12:35:13, Dan Williams wrote: > 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

Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote: > On Fri 08-09-17 12:35:13, Dan Williams wrote: > > 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

Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Mon 11-09-17 13:10:30, Christoph Hellwig wrote: > On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote: > > On Fri 08-09-17 12:35:13, Dan Williams wrote: > > > The mmap(2) syscall suffers from the ABI anti-pattern of not validating > > > unknown flags. However, proposals like MAP_SYNC and

Re: [PATCH] xfs: add regression test for DAX mount option usage

On Mon, Sep 11, 2017 at 8:16 AM, Ross Zwisler wrote: > On Fri, Sep 08, 2017 at 03:21:53PM -0600, Ross Zwisler wrote: >> This adds a regression test for the following kernel patch: >> >> xfs: always use DAX if mount option is used >> >> This test will also pass with

Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support

On Wed, Aug 02 2017 at 1:58pm -0400, Dan Williams wrote: > Rather than have device-mapper directly 'select DAX', let the fact that > BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax > support. We arrange for all the dax core routines to compile to nops

Re: [PATCH] xfs: add regression test for DAX mount option usage

On Fri, Sep 08, 2017 at 03:21:53PM -0600, Ross Zwisler wrote: > This adds a regression test for the following kernel patch: > > xfs: always use DAX if mount option is used > > This test will also pass with kernel v4.14-rc1 and beyond because the XFS > DAX I/O mount option has been disabled

Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support

On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams wrote: > >> Rather than have device-mapper directly 'select DAX', let the fact that >> BLK_DEV_PMEM selects dax act as a gate for the

Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Mon, Sep 11, 2017 at 4:10 AM, Christoph Hellwig wrote: > On Mon, Sep 11, 2017 at 11:47:14AM +0200, Jan Kara wrote: >> On Fri 08-09-17 12:35:13, Dan Williams wrote: >> > The mmap(2) syscall suffers from the ABI anti-pattern of not validating >> > unknown flags. However, proposals

[GIT PULL] libnvdimm for 4.14

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.14 ...to receive: A rework of media error handling in the BTT driver and other updates. It has appeared in a few -next releases and collected some late- breaking build-error and

Re: [RFC PATCH v8 2/2] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Mon, Sep 11, 2017 at 2:47 AM, Jan Kara wrote: > On Fri 08-09-17 12:35:13, Dan Williams wrote: >> 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

Re: Unexpected writes seen on a Read-only, DAX enabled EXT4 fs

On Sat, Sep 09, 2017 at 05:10:26PM +, Soccer Liu wrote: > Hi: >   I was surprised to see a few write operations called into > ext4_dax_huge_fault with FAULT_FLAG_WRITE set on vmf->flags > Are those writes expected at all? > static int ext4_dax_huge_fault(struct vm_fault *vmf, > enum

阿米巴-破解当下企业经营的难题

Ö£ºlinux-nvdimm@lists.01.org Ïêϸ ¿Î³Ìʱ¼ä ¼°±¨ÃûÐÅÏ¢ Çë²éÔĸ½¼þ °¢Ãװ;­ÓªÄܹ»ÏµÍ³Æƽ⵱ÏÂÆóÒµ¾­ÓªµÄÄÑÌ⣡ Ëùν°¢Ãװ;­ÓªÄ£Ê½¾ÍÊǽ«Õû¸ö¹«Ë¾·Ö¸î³ÉÐí¶à¸ö±»³ÆΪ°¢Ãװ͵ÄСÐÍ×éÖ¯£¬Ã¿¸öСÐÍ×éÖ¯¶¼×÷Ϊһ¸ö¶ÀÁ¢µÄÀûÈóÖÐÐÄ£¬°´ÕÕСÆóÒµ¡¢Ð¡É̵êµÄ·½Ê½½øÐжÀÁ¢¾­Óª¡£

[fstests PATCH v2] xfs: add regression test for DAX mount option usage

This adds a regression test for the following kernel patch: xfs: always use DAX if mount option is used This test will also pass with kernel v4.14-rc1 and beyond because the XFS DAX I/O mount option has been disabled (but not removed), so the "chattr -x" to turn off DAX doesn't actually do