Returned mail: see transcript for details

2017-09-11 Thread siwu 
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 From:s...@hrz.tu-chemnitz.de
<<< 501 s...@hrz.tu-chemnitz.de... Refused



___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3207333..525dd63 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4577,6 +4577,21 @@ int ext4_get_inode_loc(struct inode *inode, struct 
ext4_iloc *iloc)
!ext4_test_inode_state(inode, EXT4_STATE_XATTR));
 }
 
+static bool ext4_should_use_dax(struct inode *inode)
+{
+   if (!test_opt(inode->i_sb, DAX))
+   return false;
+   if (!S_ISREG(inode->i_mode))
+   return false;
+   if (ext4_should_journal_data(inode))
+   return false;
+   if (ext4_has_inline_data(inode))
+   return false;
+   if (ext4_encrypted_inode(inode))
+   return false;
+   return true;
+}
+
 void ext4_set_inode_flags(struct inode *inode)
 {
unsigned int flags = EXT4_I(inode)->i_flags;
@@ -4592,9 +4607,7 @@ void ext4_set_inode_flags(struct inode *inode)
new_fl |= S_NOATIME;
if (flags & EXT4_DIRSYNC_FL)
new_fl |= S_DIRSYNC;
-   if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode) &&
-   !ext4_should_journal_data(inode) && !ext4_has_inline_data(inode) &&
-   !ext4_encrypted_inode(inode))
+   if (ext4_should_use_dax(inode))
new_fl |= S_DAX;
inode_set_flags(inode, new_fl,
S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 project quota... */

Those uapi changes were merged by this commit:

commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR
promotion")

so all the definitions needed by ext4 are available in
include/uapi/linux/fs.h.  Remove the duplicates from ext4.h.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Cc: Li Xi 
Cc: Theodore Ts'o 
Cc: Andreas Dilger 
Cc: Jan Kara 
Cc: Dave Chinner 
---
 fs/ext4/ext4.h | 37 -
 1 file changed, 37 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 84b9da1..83a857f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -644,43 +644,6 @@ enum {
 #define EXT4_IOC_GET_ENCRYPTION_PWSALT FS_IOC_GET_ENCRYPTION_PWSALT
 #define EXT4_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
 
-#ifndef FS_IOC_FSGETXATTR
-/* Until the uapi changes get merged for project quota... */
-
-#define FS_IOC_FSGETXATTR  _IOR('X', 31, struct fsxattr)
-#define FS_IOC_FSSETXATTR  _IOW('X', 32, struct fsxattr)
-
-/*
- * Structure for FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR.
- */
-struct fsxattr {
-   __u32   fsx_xflags; /* xflags field value (get/set) */
-   __u32   fsx_extsize;/* extsize field value (get/set)*/
-   __u32   fsx_nextents;   /* nextents field value (get)   */
-   __u32   fsx_projid; /* project identifier (get/set) */
-   unsigned char   fsx_pad[12];
-};
-
-/*
- * Flags for the fsx_xflags field
- */
-#define FS_XFLAG_REALTIME  0x0001  /* data in realtime volume */
-#define FS_XFLAG_PREALLOC  0x0002  /* preallocated file extents */
-#define FS_XFLAG_IMMUTABLE 0x0008  /* file cannot be modified */
-#define FS_XFLAG_APPEND0x0010  /* all writes append */
-#define FS_XFLAG_SYNC  0x0020  /* all writes synchronous */
-#define FS_XFLAG_NOATIME   0x0040  /* do not update access time */
-#define FS_XFLAG_NODUMP0x0080  /* do not include in 
backups */
-#define FS_XFLAG_RTINHERIT 0x0100  /* create with rt bit set */
-#define FS_XFLAG_PROJINHERIT   0x0200  /* create with parents projid */
-#define FS_XFLAG_NOSYMLINKS0x0400  /* disallow symlink creation */
-#define FS_XFLAG_EXTSIZE   0x0800  /* extent size allocator hint */
-#define FS_XFLAG_EXTSZINHERIT  0x1000  /* inherit inode extent size */
-#define FS_XFLAG_NODEFRAG  0x2000  /* do not defragment */
-#define FS_XFLAG_FILESTREAM0x4000  /* use filestream allocator */
-#define FS_XFLAG_HASATTR   0x8000  /* no DIFLAG for this */
-#endif /* !defined(FS_IOC_FSGETXATTR) */
-
 #define EXT4_IOC_FSGETXATTRFS_IOC_FSGETXATTR
 #define EXT4_IOC_FSSETXATTRFS_IOC_FSSETXATTR
 
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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.

There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

I actually think we are safe in this case because of the following:

1) You can't encrypt an existing file.  Encryption can only be set on an
empty directory, with new inodes in that directory being created with
encryption turned on, so I don't think it's possible to turn encryption on
for a file that has open DAX mmaps or outstanding I/Os.

2) There is no way to turn encryption off on a given file.  Once an inode
is encrypted, it stays encrypted for the life of that inode, so we don't
have to worry about the case where we turn encryption off and S_DAX
suddenly turns on.

3) The only way we end up in ext4_set_context() to turn on encryption is
when we are creating a new file in the encrypted directory.  This happens
as part of ext4_create() before the inode has been allowed to do any I/O.
Here's the call tree:

 ext4_create()
   __ext4_new_inode()
 ext4_set_inode_flags() // sets S_DAX
 fscrypt_inherit_context()
fscrypt_get_encryption_info();
ext4_set_context() // sets EXT4_INODE_ENCRYPT, clears S_DAX

So, I actually think it's safe to transition S_DAX in ext4_set_context()
without any locking, writebacks or invalidations.  I've added a
WARN_ON_ONCE() sanity check to make sure that we are notified if we ever
encounter a case where we are encrypting an inode that already has data,
in which case we need to add code to safely transition S_DAX.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/super.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 4251e50..c090780 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1159,6 +1159,9 @@ static int ext4_set_context(struct inode *inode, const 
void *ctx, size_t len,
if (inode->i_ino == EXT4_ROOT_INO)
return -EPERM;
 
+   if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
+   return -EINVAL;
+
res = ext4_convert_inline_data(inode);
if (res)
return res;
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 unsafe because we don't hold off page faults
and I/O, write back dirty radix tree entries and invalidate all mappings.
There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

The unsafe transition of S_DAX can reliably cause data corruption, as shown
by the following fstest:

https://patchwork.kernel.org/patch/9948381/

Fix this issue by preventing the DAX mount option from being used on
filesystems that were created to support inline data.  Inline data is an
option given to mkfs.ext4.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/inline.c | 10 --
 fs/ext4/super.c  |  5 +
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 28c5c3a..fd95019 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -302,11 +302,6 @@ static int ext4_create_inline_data(handle_t *handle,
EXT4_I(inode)->i_inline_size = len + EXT4_MIN_INLINE_DATA_SIZE;
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get cleared
-*/
-   ext4_set_inode_flags(inode);
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
 
@@ -451,11 +446,6 @@ static int ext4_destroy_inline_data_nolock(handle_t 
*handle,
}
}
ext4_clear_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get set.
-*/
-   ext4_set_inode_flags(inode);
 
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c9e7be5..4251e50 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3707,6 +3707,11 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
}
 
if (sbi->s_mount_opt & EXT4_MOUNT_DAX) {
+   if (ext4_has_feature_inline_data(sb)) {
+   ext4_msg(sb, KERN_ERR, "Cannot use DAX on a filesystem"
+   " that may contain inline data");
+   goto failed_mount;
+   }
err = bdev_dax_supported(sb, blocksize);
if (err)
goto failed_mount;
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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:

https://patchwork.kernel.org/patch/9948377/
https://patchwork.kernel.org/patch/9948381/

My opinion is that the first three patches in this series should be applied
to the v4.14 RC series and backported to stable.  The last two patches in
this series are just cleanup and can probably wait until v4.15.

Ross Zwisler (5):
  ext4: prevent data corruption with inline data + DAX
  ext4: prevent data corruption with journaling + DAX
  ext4: add sanity check for encryption + DAX
  ext4: add ext4_should_use_dax()
  ext4: remove duplicate extended attributes defs

 fs/ext4/ext4.h   | 37 -
 fs/ext4/inline.c | 10 --
 fs/ext4/inode.c  | 24 
 fs/ext4/ioctl.c  | 16 +---
 fs/ext4/super.c  |  8 
 5 files changed, 37 insertions(+), 58 deletions(-)

-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 corruption from happening by disallowing changes to the
journaling mode if the '-o dax' mount option was used.  This means that for
a given filesystem we could have a mix of inodes using either DAX or
data journaling, but whatever state the inodes are in will be held for the
duration of the mount.

Signed-off-by: Ross Zwisler 
Suggested-by: Jan Kara 
---
 fs/ext4/inode.c |  5 -
 fs/ext4/ioctl.c | 16 +---
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e963508..3207333 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5971,11 +5971,6 @@ int ext4_change_inode_journal_flag(struct inode *inode, 
int val)
ext4_clear_inode_flag(inode, EXT4_INODE_JOURNAL_DATA);
}
ext4_set_aops(inode);
-   /*
-* Update inode->i_flags after EXT4_INODE_JOURNAL_DATA was updated.
-* E.g. S_DAX may get cleared / set.
-*/
-   ext4_set_inode_flags(inode);
 
jbd2_journal_unlock_updates(journal);
percpu_up_write(>s_journal_flag_rwsem);
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index afb66d4..b0b754b 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -290,10 +290,20 @@ static int ext4_ioctl_setflags(struct inode *inode,
if (err)
goto flags_out;
 
-   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL))
+   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL)) {
+   /*
+* Changes to the journaling mode can cause unsafe changes to
+* S_DAX if we are using the DAX mount option.
+*/
+   if (test_opt(inode->i_sb, DAX)) {
+   err = -EBUSY;
+   goto flags_out;
+   }
+
err = ext4_change_inode_journal_flag(inode, jflag);
-   if (err)
-   goto flags_out;
+   if (err)
+   goto flags_out;
+   }
if (migrate) {
if (flags & EXT4_EXTENTS_FL)
err = ext4_ext_migrate(inode);
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 or off journaling.  The latter is how we
prevent this issue in the kernel.

Signed-off-by: Ross Zwisler 
---
 .gitignore  |  1 +
 src/Makefile|  2 +-
 src/t_ext4_dax_journal_corruption.c | 93 +
 tests/ext4/030  | 68 +++
 tests/ext4/030.out  |  2 +
 tests/ext4/group|  1 +
 6 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_journal_corruption.c
 create mode 100755 tests/ext4/030
 create mode 100644 tests/ext4/030.out

diff --git a/.gitignore b/.gitignore
index 2accc37..4bdc5bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -154,6 +154,7 @@
 /src/t_mmap_stale_pmd
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
+/src/t_ext4_dax_journal_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index b8aff49..e6558e2 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err
+   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_journal_corruption.c 
b/src/t_ext4_dax_journal_corruption.c
new file mode 100644
index 000..e0d63f8
--- /dev/null
+++ b/src/t_ext4_dax_journal_corruption.c
@@ -0,0 +1,93 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+void chattr_cmd(char *chattr, char *cmd, char *file)
+{
+   int ret;
+   char command[STRLEN];
+
+   ret = snprintf(command, STRLEN, "%s %s %s 2>/dev/null", chattr, cmd, 
file);
+   if (ret < 0)
+   err_exit("snprintf");
+
+   ret = system(command);
+   if (ret) /* Success - the kernel fix is to have this chattr fail */
+   exit(77);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *data, *dax_data, *chattr, *file;
+   char string[STRLEN];
+
+   if (argc < 3) {
+   printf("Usage: %s  \n", 
basename(argv[0]));
+   exit(0);
+   }
+
+   chattr = argv[1];
+   file = argv[2];
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
+   if (fd < 0)
+   err_exit("fd");
+
+   /* begin with journaling off and DAX on */
+   chattr_cmd(chattr, "-j", file);
+
+   ftruncate(fd, 0);
+   fallocate(fd, 0, 0, len);
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /* turns on journaling, and turns off DAX */
+   chattr_cmd(chattr, "+j", file);
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/030 b/tests/ext4/030
new file mode 100755
index 000..3ac4952
--- /dev/null
+++ b/tests/ext4/030
@@ -0,0 +1,68 @@
+#! /bin/bash
+# FS QA Test ext4/030
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with journaling + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public

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

2017-09-11 Thread Ross Zwisler 
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: Ross Zwisler 
---
 .gitignore |  1 +
 src/Makefile   |  3 +-
 src/t_ext4_dax_inline_corruption.c | 70 +++
 tests/ext4/031 | 84 ++
 tests/ext4/031.out |  2 +
 tests/ext4/group   |  1 +
 6 files changed, 160 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_inline_corruption.c
 create mode 100755 tests/ext4/031
 create mode 100644 tests/ext4/031.out

diff --git a/.gitignore b/.gitignore
index 4bdc5bf..37670e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -155,6 +155,7 @@
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
 /src/t_ext4_dax_journal_corruption
+/src/t_ext4_dax_inline_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index e6558e2..bcfae01 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,8 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
+   t_mmap_cow_race t_mmap_fallocate fsync-err 
t_ext4_dax_journal_corruption \
+   t_ext4_dax_inline_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_inline_corruption.c 
b/src/t_ext4_dax_inline_corruption.c
new file mode 100644
index 000..4b7d893
--- /dev/null
+++ b/src/t_ext4_dax_inline_corruption.c
@@ -0,0 +1,70 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *dax_data, *data;
+   char string[STRLEN];
+
+   if (argc < 2) {
+   printf("Usage: %s \n", basename(argv[0]));
+   exit(0);
+   }
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0)
+   err_exit("fd");
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /* this fallocate turns off inline data and turns on DAX */
+   fallocate(fd, 0, 0, PAGE(2));
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/031 b/tests/ext4/031
new file mode 100755
index 000..95a5c65
--- /dev/null
+++ b/tests/ext4/031
@@ -0,0 +1,84 @@
+#! /bin/bash
+# FS QA Test ext4/031
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with inline data + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq

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

2017-09-11 Thread Ross Zwisler 
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
+
+# cscope files
+cscope.*
+ncscope.*
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Jan Kara 
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
> > > open mappings or any open file handles.
> > 
> > You have to have an open fd to change the flag. :)
> 
> What if we only allow the S_DAX flag to be *set*, when i_size and
> i_blocks is zero?  We could also require that only one file descriptor
> be open against the inode, and that it be opened O_RDONLY.

We could do something like that but IMHO it will be a pain to use (e.g.
think how difficult it would be to switch your existing database to use DAX
for data files). We can make transition reliable whenever
inode->i_mapping->i_mmap RB tree is empty (effectively: whenever the file
is not mmaped). And that should be relaxed enough for most usecases... But
I agree that it will be somewhat tricky to prevent creation of new mappings
while we are switching S_DAX flag so it needs more though.

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Jan Kara 
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 new MAP_SHARED_VALIDATE flag pattern that
> is guaranteed to fail on all legacy mmap implementations.
> 
> With this in place new flags can be defined as:
> 
> #define MAP_new (MAP_SHARED_VALIDATE | val)

Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
type, I'd expect we define new flags just as any other mapping flags...
I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.

> It is worth noting that the original proposal was for a standalone
> MAP_VALIDATE flag. However, when that  could not be supported by all
> archs Linus observed:
> 
> I see why you *think* you want a bitmap. You think you want
> a bitmap because you want to make MAP_VALIDATE be part of MAP_SYNC
> etc, so that people can do
> 
> ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED
>   | MAP_SYNC, fd, 0);
> 
> and "know" that MAP_SYNC actually takes.
> 
> And I'm saying that whole wish is bogus. You're fundamentally
> depending on special semantics, just make it explicit. It's already
> not portable, so don't try to make it so.
> 
> Rename that MAP_VALIDATE as MAP_SHARED_VALIDATE, make it have a value
> of 0x3, and make people do
> 
> ret = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED_VALIDATE
>   | MAP_SYNC, fd, 0);
> 
> and then the kernel side is easier too (none of that random garbage
> playing games with looking at the "MAP_VALIDATE bit", but just another
> case statement in that map type thing.
> 
> Boom. Done.
> 
> Similar to ->fallocate() we also want the ability to validate the
> support for new flags on a per ->mmap() 'struct file_operations'
> instance basis.  Towards that end arrange for flags to be generically
> validated against a mmap_supported_mask exported by 'struct
> file_operations'. By default all existing flags are implicitly
> supported, but new flags require MAP_SHARED_VALIDATE and
> per-instance-opt-in.
> 
> Cc: Jan Kara 
> Cc: Arnd Bergmann 
> Cc: Andy Lutomirski 
> Cc: Andrew Morton 
> Suggested-by: Christoph Hellwig 
> Suggested-by: Linus Torvalds 
> Signed-off-by: Dan Williams 
> ---
>  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 |   44 
> ++
>  include/uapi/asm-generic/mman-common.h   |1 +
>  mm/mmap.c|   10 +-
>  tools/include/uapi/asm-generic/mman-common.h |1 +
>  9 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/alpha/include/uapi/asm/mman.h 
> b/arch/alpha/include/uapi/asm/mman.h
> index 3b26cc62dadb..c32276c4196a 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -14,6 +14,7 @@
>  #define MAP_TYPE 0x0f/* Mask for type of mapping (OSF/1 is 
> _wrong_) */
>  #define MAP_FIXED0x100   /* Interpret addr exactly */
>  #define MAP_ANONYMOUS0x10/* don't use a file */
> +#define MAP_SHARED_VALIDATE (MAP_SHARED|MAP_PRIVATE) /* validate extension 
> flags */

And I'd explicitely define MAP_SHARED_VALIDATE as the first unused value
among mapping types (which is in fact enum embedded inside mapping flags).
I.e. 0x03 on alpha, x86, and probably all other archs - it has nothing to
do with MAP_SHARED|MAP_PRIVATE - it is just another type of the mapping
which happens to have most of the MAP_SHARED semantics...

Honza

-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Christoph Hellwig 
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 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.
> > 
> > With this in place new flags can be defined as:
> > 
> > #define MAP_new (MAP_SHARED_VALIDATE | val)
> 
> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> type, I'd expect we define new flags just as any other mapping flags...
> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.

Btw, I still think it should be a new hidden flag and not a new mapping
type.  I brought this up last time, so maybe I missed the answer
to my concern.

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Jan Kara 
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 MAP_DIRECT need a
> > > mechanism to define new behavior that is known to fail on older kernels
> > > without the support. Define a new MAP_SHARED_VALIDATE flag pattern that
> > > is guaranteed to fail on all legacy mmap implementations.
> > > 
> > > With this in place new flags can be defined as:
> > > 
> > > #define MAP_new (MAP_SHARED_VALIDATE | val)
> > 
> > Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> > type, I'd expect we define new flags just as any other mapping flags...
> > I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.
> 
> Btw, I still think it should be a new hidden flag and not a new mapping
> type.  I brought this up last time, so maybe I missed the answer
> to my concern.

Hum, I don't remember your concern and the only comment from you to the
last posting which I've found is:

"no mmap3 syscall here :)

Do you also need to update the nommu mmap implementation?"

So I guess it's something else. So can you remind me or send a link?
Thanks!

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Dan Williams 
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 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 anything.
>>
>> Signed-off-by: Ross Zwisler 
>> Suggested-by: Christoph Hellwig 
>
> <>
>
>> +# disable tracing, clear the existing trace buffer and turn on dax 
>> tracepoints
>> +echo 0 > /sys/kernel/debug/tracing/tracing_on
>> +echo > /sys/kernel/debug/tracing/trace
>> +echo 1 > /sys/kernel/debug/tracing/events/fs_dax/enable
>
> I think I can do a better job of:
>
> a) detecting whether debugfs is present, and if not just bail the test as not
> run
>
> b) recording the current state of the debugfs (tracing_on, fs_dax/enable),
> doing what I need to do, then restoring the previous state.
>
> Before I work on a v2, though, I'd love to get feedback on whether or not
> using tracepoints is okay in fstests.

I think it is more straightforward to use "perf record -e fs_dax
$test". Then you know the events are filtered to your test pid and you
don't need to worry about managing the trace interface.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Mike Snitzer 
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
> when CONFIG_DAX=n. With that in place we can simply handle the
> alloc_dax() error as expected and ifdef out the other device-mapper-dax
> support code.
> 
> Now, if dax is provided by a leaf driver that driver may only arrange to
> compile the dax core as a module. Since device-mapper dax support is
> consumed by the always-built-in portion of the device-mapper
> implementation we need to upgrade from DAX=m to DAX=y.

I applied the patches and then got nervous once I dug in.. this last
paragraph makes little sense to me.  "the always-built-in portion of the
device-mapper implementation" is why: DM core can happily be compiled as
a module (dm-mod.ko).

And I'm not sure why you're referencing DAX related
drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that?
I'm not seeing where that is actually happening.

I don't see why DM's support for DAX would need to force DAX to be
builtin rather than just a module.

Sorry I didn't get around to looking at this until now, but it seems you
went wrong along the way?  Or maybe I'm just missing something?

Mike
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 (but not removed), so the
> "chattr -x" to turn off DAX doesn't actually do anything.
> 
> Signed-off-by: Ross Zwisler 
> Suggested-by: Christoph Hellwig 

<>

> +# disable tracing, clear the existing trace buffer and turn on dax 
> tracepoints
> +echo 0 > /sys/kernel/debug/tracing/tracing_on
> +echo > /sys/kernel/debug/tracing/trace
> +echo 1 > /sys/kernel/debug/tracing/events/fs_dax/enable

I think I can do a better job of:

a) detecting whether debugfs is present, and if not just bail the test as not
run

b) recording the current state of the debugfs (tracing_on, fs_dax/enable),
doing what I need to do, then restoring the previous state.

Before I work on a v2, though, I'd love to get feedback on whether or not
using tracepoints is okay in fstests.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Dan Williams 
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 device-mapper dax
>> support. We arrange for all the dax core routines to compile to nops
>> when CONFIG_DAX=n. With that in place we can simply handle the
>> alloc_dax() error as expected and ifdef out the other device-mapper-dax
>> support code.
>>
>> Now, if dax is provided by a leaf driver that driver may only arrange to
>> compile the dax core as a module. Since device-mapper dax support is
>> consumed by the always-built-in portion of the device-mapper
>> implementation we need to upgrade from DAX=m to DAX=y.
>
> I applied the patches and then got nervous once I dug in.. this last
> paragraph makes little sense to me.  "the always-built-in portion of the
> device-mapper implementation" is why: DM core can happily be compiled as
> a module (dm-mod.ko).
>
> And I'm not sure why you're referencing DAX related
> drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that?
> I'm not seeing where that is actually happening.
>
> I don't see why DM's support for DAX would need to force DAX to be
> builtin rather than just a module.
>
> Sorry I didn't get around to looking at this until now, but it seems you
> went wrong along the way?  Or maybe I'm just missing something?
>

No, my fault, I didn't track BLK_DEV_DM_BUILTIN correctly and we can
safely make DAX a module when CONFIG_BLK_DEV_DM=m. I'll fix that up,
thanks for the catch.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Dan Williams 
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 like MAP_SYNC and MAP_DIRECT need a
>> > mechanism to define new behavior that is known to fail on older kernels
>> > without the support. Define a new MAP_SHARED_VALIDATE flag pattern that
>> > is guaranteed to fail on all legacy mmap implementations.
>> >
>> > With this in place new flags can be defined as:
>> >
>> > #define MAP_new (MAP_SHARED_VALIDATE | val)
>>
>> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
>> type, I'd expect we define new flags just as any other mapping flags...
>> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.
>
> Btw, I still think it should be a new hidden flag and not a new mapping
> type.  I brought this up last time, so maybe I missed the answer
> to my concern.
>

I thought you agreed to MAP_SHARED_VALIDATE here:

https://marc.info/?l=linux-mm=150425124907931=2
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[GIT PULL] libnvdimm for 4.14

2017-09-11 Thread Williams, Dan J 
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 warning fixups as a result. There are no known
merge conflicts, and the touches to fs/ have reviewed-by tags.

---

The following changes since commit 14ccee78fc82f5512908f4424f541549a5705b89:

  Linux 4.13-rc6 (2017-08-20 14:13:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
tags/libnvdimm-for-4.14

for you to fetch changes up to 04c3c982fcc0151ed3574d7ae4f1e62278054d72:

  libnvdimm, btt: fix format string warnings (2017-09-09 11:31:39 -0700)


libnvdimm for 4.14

* Media error handling support in the Block Translation Table (BTT)
  driver is reworked to address sleeping-while-atomic locking and
  memory-allocation-context conflicts.

* The dax_device lookup overhead for xfs and ext4 is moved out of the
  iomap hot-path to a mount-time lookup.

* A new 'ecc_unit_size' sysfs attribute is added to advertise the
  read-modify-write boundary property of a persistent memory range.

* Preparatory fix-ups for arm and powerpc pmem support are included
  along with other miscellaneous fixes.


Christophe Jaillet (1):
  libnvdimm, btt: check memory allocation failure

Colin Ian King (1):
  ext4: fix null pointer dereference on sbi

Dan Williams (13):
  nfit, libnvdimm, region: export 'position' in mapping info
  nfit: cleanup long de-reference chains in acpi_nfit_init_interleave_set
  libnvdimm: rename nd_sector_size_{show,store} to 
nd_size_select_{show,store}
  libnvdimm, pfn, dax: limit namespace alignments to the supported set
  libnvdimm, label: fix index block size calculation
  dax: introduce a fs_dax_get_by_bdev() helper
  xfs: perform dax_device lookup at mount
  ext2: perform dax_device lookup at mount
  ext4: perform dax_device lookup at mount
  libnvdimm, nfit: export an 'ecc_unit_size' sysfs attribute
  libnvdimm: fix integer overflow static analysis warning
  Merge branch 'for-4.14/fs' into libnvdimm-for-next
  dax: fix FS_DAX=n BLOCK=y compilation

Meng Xu (1):
  libnvdimm, nfit: move the check on nd_reserved2 to the endpoint

Oliver O'Halloran (2):
  libnvdimm: Stop using HPAGE_SIZE
  libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs

Randy Dunlap (1):
  libnvdimm, btt: fix format string warnings

Robin Murphy (1):
  libnvdimm, nd_blk: remove mmio_flush_range()

Vishal Verma (7):
  libnvdimm, btt: fix a missed NVDIMM_IO_ATOMIC case in the write path
  libnvdimm, btt: refactor map entry operations with macros
  libnvdimm, btt: ensure that flags were also unchanged during a map_read
  libnvdimm, btt: cache sector_size in arena_info
  libnvdimm: fix potential deadlock while clearing errors
  libnvdimm, btt: rework error clearing
  libnvdimm, btt: clean up warning and error messages

 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/cacheflush.h |   2 -
 drivers/acpi/nfit/Kconfig |   2 +-
 drivers/acpi/nfit/core.c  |  50 --
 drivers/dax/super.c   |  12 +++
 drivers/nvdimm/btt.c  | 197 ++
 drivers/nvdimm/btt.h  |  11 +++
 drivers/nvdimm/btt_devs.c |   4 +-
 drivers/nvdimm/bus.c  |  27 +++---
 drivers/nvdimm/claim.c|   9 +-
 drivers/nvdimm/core.c |  10 +-
 drivers/nvdimm/label.c|  30 +++---
 drivers/nvdimm/namespace_devs.c   |   6 +-
 drivers/nvdimm/nd.h   |  16 +++-
 drivers/nvdimm/pfn_devs.c |  53 ++
 drivers/nvdimm/pmem.h |  14 ---
 drivers/nvdimm/region_devs.c  |   6 +-
 fs/ext2/ext2.h|   1 +
 fs/ext2/inode.c   |  11 +--
 fs/ext2/super.c   |   4 +
 fs/ext4/ext4.h|   1 +
 fs/ext4/inode.c   |  11 +--
 fs/ext4/super.c   |   4 +
 fs/xfs/xfs_aops.c |  13 +++
 fs/xfs/xfs_aops.h |   1 +
 fs/xfs/xfs_buf.c  |   4 +-
 fs/xfs/xfs_buf.h  |   3 +-
 fs/xfs/xfs_iomap.c|  10 +-
 fs/xfs/xfs_super.c|  25 -
 include/linux/dax.h   |   6 ++
 include/linux/libnvdimm.h |  16 
 lib/Kconfig   |   3 -
 tools/testing/nvdimm/test/nfit.c  |   4 +-
 33 files changed, 397 insertions(+), 170 deletions(-)
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Dan Williams 
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 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.
>>
>> With this in place new flags can be defined as:
>>
>> #define MAP_new (MAP_SHARED_VALIDATE | val)
>
> Is this changelog stale? Given MAP_SHARED_VALIDATE will be new mapping
> type, I'd expect we define new flags just as any other mapping flags...
> I see no reason why MAP_SHARED_VALIDATE should be or'ed to that.

True, it will just by a new MAP_TYPE plus new flags. I will fix this up comment.

[..]
>> diff --git a/arch/alpha/include/uapi/asm/mman.h 
>> b/arch/alpha/include/uapi/asm/mman.h
>> index 3b26cc62dadb..c32276c4196a 100644
>> --- a/arch/alpha/include/uapi/asm/mman.h
>> +++ b/arch/alpha/include/uapi/asm/mman.h
>> @@ -14,6 +14,7 @@
>>  #define MAP_TYPE 0x0f/* Mask for type of mapping (OSF/1 is 
>> _wrong_) */
>>  #define MAP_FIXED0x100   /* Interpret addr exactly */
>>  #define MAP_ANONYMOUS0x10/* don't use a file */
>> +#define MAP_SHARED_VALIDATE (MAP_SHARED|MAP_PRIVATE) /* validate extension 
>> flags */
>
> And I'd explicitely define MAP_SHARED_VALIDATE as the first unused value
> among mapping types (which is in fact enum embedded inside mapping flags).
> I.e. 0x03 on alpha, x86, and probably all other archs - it has nothing to
> do with MAP_SHARED|MAP_PRIVATE - it is just another type of the mapping
> which happens to have most of the MAP_SHARED semantics...

Ok, I'll make it 0x3 everywhere.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread Ross Zwisler 
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 page_entry_size pe_size)
> {
> ...
>  bool write = vmf->flags & FAULT_FLAG_WRITE;
> Based on the following Mount documentation below, I did mount this ext fs
> with ro and noloadAre there any other options that I could use to totally
> eliminate those unexpected writes?
>
>- -r, --read-only
>   - Mount the filesystem read-only. A synonym is -o ro.Note that,
>   depending on the filesystem type, state and kernel behavior, the
>   system may still write to the device. For example, Ext3 or ext4 will
>   replay itsjournal if the filesystem is dirty. To prevent this kind of
>   write access, you may want to mount ext3 or ext4 filesystem with
>   "ro,noload" mount options or setthe block device to read-only mode,
>   see command blockdev(8).  -
> 
> Related DMESG output...
> 
> [    0.891653] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at 
> your own risk
> [    0.892736] EXT4-fs (pmem0): mounted filesystem without journal. Opts: 
> noload,dax
> [    0.898293] EXT4-fs (sda): mounted filesystem without journal. Opts: (null)
> [    0.902574] random: fast init done
> [    0.926157] IPVS: ftp: loaded support on port[0] = 21
> // My private debug messages
> [    0.997224] EXT4-fs (pmem0): write is 1 handle = 0xffe2 
> <--read-only device 
> [    0.998052] EXT4-fs (pmem0): write is 1 handle = 0xffe2
> [    0.998787] EXT4-fs (pmem0): write is 1 handle = 0xffe2
> [    0.999720] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.004626] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.005359] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.006128] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.006824] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.007499] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    1.008149] EXT4-fs (pmem0): write is 0 handle = 0x0
> [    7.320626] random: crng init done
> [   18.780447] EXT4-fs: 53 callbacks suppressed
> [   18.781900] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.783392] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.790661] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.792042] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.793321] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.795005] EXT4-fs (pmem0): write is 0 handle = 0x0
> [   18.795204] EXT4-fs (pmem0): write is 1 handle = 0xffe2
> [   18.795209] EXT4-fs (pmem0): write is 1 handle = 0xffe2
> [   18.795213] EXT4-fs (pmem0): write is 1 handle = 0xffe2
> [   18.795257] EXT4-fs (pmem0): write is 0 handle = 0x0

Adding the ext4 list.

I'm pretty sure that this is ext4/mm behavior that is independent of DAX.  DAX
doesn't really have any impact on whether or not write page faults happen on a
RO ext4 filesystem, though this fix from Randy Dodgen:

https://www.spinics.net/lists/linux-ext4/msg58075.html

shows that FAULT_FLAG_WRITE can be set on DAX read-only ext4 mounts when
executing binaries, though in this case the write is going to a COW page.

- Ross
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

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

2017-09-11 Thread 徐�O玩 
Ö£ºlinux-nvdimm@lists.01.org

Ïêϸ ¿Î³Ìʱ¼ä ¼°±¨ÃûÐÅÏ¢ Çë²éÔĸ½¼þ


°¢Ãװ;­ÓªÄܹ»ÏµÍ³Æƽ⵱ÏÂÆóÒµ¾­ÓªµÄÄÑÌ⣡
Ëùν°¢Ãװ;­ÓªÄ£Ê½¾ÍÊǽ«Õû¸ö¹«Ë¾·Ö¸î³ÉÐí¶à¸ö±»³ÆΪ°¢Ãװ͵ÄСÐÍ×éÖ¯£¬Ã¿¸öСÐÍ×éÖ¯¶¼×÷Ϊһ¸ö¶ÀÁ¢µÄÀûÈóÖÐÐÄ£¬°´ÕÕСÆóÒµ¡¢Ð¡É̵êµÄ·½Ê½½øÐжÀÁ¢¾­Óª¡£
ÒÔ¸÷¸ö"°¢Ã×°Í"ΪºËÐÄ£¬×ÔÐÐÖƶ©¾­Óª¼Æ»®£¬¶ÀÁ¢ºËË㣬³ÖÐø×ÔÖ÷³É³¤£¬ÈÃÿһλԱ¹¤³ÉΪÖ÷½Ç£¬È«Ô±²ÎÓë¾­Óª¡£ÊµÊ©°¢Ãװ;­ÓªÄ£Ê½½áºÏÖйú±¾ÍÁÎÄ»¯Äܺܺõؽ«Êг¡¾ºÕùѹÁ¦´«µ¼¸øÈ«Ô±£¬½â¾öÔ±¹¤µÄ¶¯Á¦ÎÊÌâ!

¿Î³Ì±³¾°£º
µ¾Ê¢ºÍ·òÊÇÈÕ±¾µÄ"¾­ÓªÖ®Éñ"
°×ÊÖÆð¼Ò´´½¨¶þ¼ÒÊÀ½ç500Ç¿ÆóÒµ£¬Õü¾ÈÁËÈÕº½¿Õ£»
µ¾Ê¢ºÍ·ò²ÉÓð¢Ã×°Í£¬´øÁìÆóÒµ¶þ´ÎÍ»ÆÆʯÓÍΣ»ú£¬ÈÕÔªÉýֵΣ»ú£¬ÈÕ±¾ÅÝÄ­¾­¼Ã£¬ÊÀ½ç½ðÈÚΣ»ú£¬ÈÕ±¾Î£»ú£¬ÔÚÑϺ®Öз¢Õ¹×³´ó£¬ÒÙÁ¢²»µ¹£»
50¶àÄêÆóÒµ´Óδ¿÷Ë𣬾»ÀûÈóÔ¶´óÓÚ10%¡£
µ¾Ê¢ºÍ·òÔÚÎÞÈκκ½¿Õ¾­ÑéµÄÇé¿öϽÓÊÖÆóÒµ£¬µ¼Èë°¢Ã×°ÍÒ»ÄêÄÚÈþ޿÷µÄ"ÈÕº½¿Õ"ʵÏÖŤ¿÷ΪӯʵÏÖ1884ÒÚÈÕÔª¾Þ¶îÓ¯Àû¡£
º£¶ûÊÇÖйúµÄ±êÖ¾ÐÔÆóÒµ£¬Ò²ÊÇ×îÔçÏòÈÕÆóѧϰµÄÖйúÆóÒµÖ®Ò»¡£
1998Ä꣬ÕÅÈðÃôÕýʽÌá³öÆóÒµµÄ"ÄÚ²¿Ä£ÄâÊг¡»¯"£¬ÔÚº£¶ûÄÚ²¿È«ÃæÍÆÐÐ"Êг¡Á´"Á÷³ÌÔÙÔ죬²¢Ìá³öÁË"ÈËÈËÊÇÈ˲ţ¬ÈüÂí²»ÏàÂí"µÄÈ«ÐÂÓÃÈËÀíÄî¡£ÊÂÒµ²¿SBUÕâ¸ö¸ÅÄî´Ó´ËÊܵ½ÁËÖйúÆóÒµ½çµÄÃÜÇйØ×¢¡£
º£¶ûÍê³É´Ó´«Í³µÄOEC¹ÜÀíÏòÊÂÒµ²¿SBUÁ¿»¯·ÖȨ¾­ÓªµÄת±äÖ®ºó£¬¼«´óµØÊÍ·ÅÁËÆóÒµ¹ÜÀí²ãÖǻۣ¬ÊÕ»ñÁ˷ḻµÄ¾­Óª³É¹û¡£1998¡«2005Ä꣬º£¶û½öÓÃÁË7Äêʱ¼ä¾ÍËɵØʵÏÖÁË´Ó100ÒÚµ½1000ÒڵĿçÔ½¡£
Ä¿Ç°£¬º£¶ûÕýÔÚÈ«ÃæÍÆÐÐÒ»¸öÀàËÆÓÚ¾©´É"°¢Ãװ;­Óª"µÄģʽ£¬²¢Îª´ËÈ¥ÁËÒ»¸öͨË×Ò׶®µÄÃû×Ö--"×ÔÖ÷¾­ÓªÌå"¡£

¿Î³Ì¼ò½é£º
ÆðÔ´ÓÚ¾©´ÉµÄ°¢Ãװ;­ÓªÄ£Ê½ÊÇÖ¸½«¹«Ë¾·Ö³ÉÐí¶àµÄÿ¸öÒµÎñµ¥Ôª£¨¿ÉÒÔÊÇÒ»¸ö²¿ÃÅ¡¢Ò»ÌõÉú²úÏß¡¢Ò»¸ö°à×éÉõÖÁµ½Ã¿¸öÔ±¹¤£©£¬Ã¿¸öµ¥Ôª¾ÍÊÇÒ»¸ö°¢Ã×°Í£¬¶¼ÊÇÒ»¸ö¶ÀÁ¢µÄÀûÈóÖÐÐÄ£¬¾ÍÏñÒ»¸öÖÐСÆóÒµÄÇÑù»î¶¯£¬¾­Óª¼Æ»®¡¢Êµ¼¨¹ÜÀí¡¢ÀÍÎñ¹ÜÀíµÈËùÓо­ÓªÉϵÄÊÂÇ鶼ÓÉËûÃÇ×ÔÐÐÔË×÷£¬ÄÜÈù«Ë¾¶ÔÊг¡µÄ±ä»¯×ö³öѸ½Ý·´Ó¦¡£
°¢Ãװ;­ÓªÄ£Ê½ÒѾ­±»ÖÚ¶àÐÐÒµºÍÆóÒµÖ¤Ã÷ÊÇÐÐÖ®ÓÐЧµÄ¡£ÆäÌØÕ÷¼È·Ç³£ÊʺϹúÄÚÆóÒµ¾­ÓªµÄÐèÇó£¬ÓÖÓÉÓÚÆäÎÄ»¯µÄÌØÊâÐÔ£¬µ¼ÈëÖйú²¢²»ÄÜÔ­ÑùÕհᣬÐèÒªÕÒµ½ÊʺÏÖйú¹úÇéµÄģʽ¡£
°²¶«ÀÏʦ½áºÏ°ËÄêËÉϵçÆ÷ʵս¾­Ñ飬һÄêÈÕ±¾¾­ÓªÑÐÐ޳ɹû£¬²¢ÇÒ½áºÏÆßÄêÀ´ÔÚ¹úÄÚ¸ø¼¸Ê®¼ÒÆóÒµ³É¹¦µ¼ÈëµÄ×ÉѯÏîÄ¿¾­Ñ飬Äý¾Û³É±¾¿Î³Ì£¡
±¾¿Î³ÌµÄÄÚÈݳɹ¦¾­¹ýÁ˹ÜÀí×ÉѯÏîÄ¿µÄʵս¼ìÑ飬²¢½áºÏ´óÁ¿ÆóÒµ°¸Àý£¬ÊǹúÄÚÉÙÓеİ¢Ã×°Íʵսµ¼ÈëµÄ¿Î³Ì£¡

¿Î³ÌÄ¿µÄ£º
Àí½â°¢Ãװ;­ÓªµÄ¾«Ëè
ÕÆÎÕÆóÒµ°¢Ã×°Í×éÖ¯¹¹½¨µÄ·½·¨
ÕÆÎÕ°¢Ãװͳɱ¾»á¼Æ·½·¨
ÕýÈ·ÔËÓð¢Ã×°ÍģʽÌá¸ßÆóÒµ¼¨Ð§
ͨ¹ýÔËÓø÷ÖÖ¹¤¾ßÌá¸ß¸÷¸ö°¢Ãװ͵¥ÔªµÄÓ¯Àûˮƽ

¿Î³Ì´ó¸Ù£º
µÚһƪ ÕÜѧÅàÑø½Ó°àÈË
µÚÒ»Õ ÈÏʶ°¢Ã×°Í
µÚÒ»½Ú µ½µ×ºÎΪ°¢Ãװ;­Óª
½âÎöµ¾Ê¢ÏÈÉúÈçºÎÓð¢Ãװ;­ÓªÄ£Ê½Õü¾ÈƵÁÙÆƲúµÄÈÕº½£¿
°¢Ã×°ÍÔËÓõÄÈý´ó·¨±¦
Ô±¹¤ÎªºÎ´Ó±»¶¯¾­Óªµ½Ö÷¶¯¾­Óª
°¢Ãװ;­ÓªÄ§Á¦ÔÚÄÄ£¿
¹úÄÚÆóÒµÍÆÐа¢Ã×°Í×´¿ö
º£¶û¾­ÓªÄ£Ê½---È˵¥ºÏÒ»×ÔÖ÷¾­ÓªÌå
ÃÉÅ£¾­ÓªÄ£Ê½---³Ð°üÆÚȨÔðÈξ­Óª
°¢Ãװ;­ÓªÄ£Ê½ÔÚÖйúÆóÒµÔËÓÃËùÐèÌõ¼þ
µÚ¶þ½Ú °¢Ãװ;­ÓªÖÐÐèÒªµÄ¹Ø×¢µã
ÆóÒµ¾­Óª×îÖÕÄ¿µÄÊÇ·ñ¿¼Á¿Ô±¹¤»ñÒæ
°¢Ãװ;­ÓªÖпͻ§µÄλÖÃ
ÔÚ´¦ÀíÎÊÌâÖеÄÈý´ó»ù±¾Ô­Ôò
ʵÏÖ°¢Ãװ;­ÓªµÄ»ù±¾Ìõ¼þ
1.ÆóÒµÄÚ²¿µÄÐÅÈιØϵ
2.Êý¾ÝµÄÑϽ÷ÐÔ
3.¼°Ê±½«Êý¾Ý·´À¡¸øÏÖ³¡µÄÌåÖÆ
4.°¢Ãװ͵ķֺÏÐè·ûºÏ¹¤×÷ÌØÐÔ(Ö÷ҪΪÁ÷³Ì)
²ÆÎñÊý¾ÝÈçºÎÇиîºÏÀí
½âÎö:°¢Ã×°ÍÔËÓªÖг£¼ûÎÊÌâ½â´ð
µÚÈý½Ú °¢Ãװ;­ÓªÄ¿µÄ
ºÎΪ¾­Óª
·ûºÏ°¢Ãװ;­ÓªµÄ»ù±¾ÒªËØ
°¢Ãװ;­ÓªÄ£Ê½µ¼Èë´ø¸øÆóÒµµÄÒæ´¦
°¢Ã×°ÍģʽºÍÄ¿Ç°ÆóÒµÖÐģʽµÄ²îÒì
Á·Ï°:¾­ÓªÄ¿±êºÍ¹ÜÀíÄ¿±ê¼°Æä¹Øϵ
µÚ¶þÕ ¾­ÓªÕÜѧ
µÚÒ»½Ú ¾­ÓªÎªºÎÐèÒªÕÜѧ
ÆóÒµ¼Ò¸öÈËÐÞΪÈçºÎת»¯³É¹«Ë¾µÄÕûÌåÐÐΪ
ÆóÒµ¾­ÓªµÄÊõºÍµÀÊÇʲô£¿ÈçºÎÒÔÊõÓùµÀ£¿
¾­ÓªÐèÒªÕÜѧµÄÈý¸öÔ­Òò
½¨Á¢·ûºÏÆóҵʵ¼Ê×´¿öµÄ¾­ÓªÕÜѧ
½«¾­ÓªÕÜѧÈçºÎת»¯ÎªÉú²úÁ¦
ÈçºÎÕýȷ˼¿¼×÷ΪÈË,ºÎΪÕýȷΪһÇÐÊÂÎïÅжϵĻù×¼
¾«²Ê¹ÊÊÂ:ÁÁ½£
µÚ¶þ½Ú ÆóÒµ¼Ò¼ÛÖµ¹ÛÈçºÎÂäµØ
ÆóÒµ¼Ò¼ÛÖµ¹ÛÔõÑùÌáÁ¶
¼ÛÖµ¹ÛºÍÆóÒµÎÄ»¯¹Øϵ
ÆóÒµÎÄ»¯ÔÚÆóÒµÖеĿªÕ¹ºÍÂäµØ
ÆóÒµÎÄ»¯ÔÚÁ÷³ÌÖƶÈÖеĹ淶
ÆóÒµÎÄ»¯´ø¸øÆóÒµµÄÒæ´¦
¾­ÓªÊ®¶þÌõ
ÓÎÏ·:ÌáÁ¶ÆóÒµºËÐÄÎÄ»¯»¥¶¯»î¶¯
µÚÈý½Ú ³É¹¦·½³Ìʽ
ÈËÉú¡¤¹¤×÷½á¹û = ˼ά·½Ê½xÈÈÇéxÄÜÁ¦
˼·¾ö¶¨³ö·£¬Ë¼Â·¾ö¶¨ÃüÔË
ÁùÏ½ø
¸¶³ö²»ÑÇÓÚÈκÎÈ˵ÄŬÁ¦
¼òµ¥µÄÕÐʽ·´¸´Á·¾ÍÊǾøÕÐ
µÚËÄ½Ú Ó¦¸Ã³ÉΪʲôÑùµÄÈË
ÈËÀàÀúÊ·µÄ±äǨ
¹²ÉúºÍÀûËû¹ÛÄî
³ÉΪһλÓÅÐãµÄÁìµ¼È˱ر¸
¹ÊÊÂ:Ï£ÌØÀÕ/Ç𼪶ûÈçºÎÁìµ¼¹ú¼ÒµÄÇ°Òòºó¹û

µÚ¶þƪ ´´Ôì¸ßÊÕÒæ
µÚÈýÕ ¾­ÓªÄ¿±êÓë·ÑÓÃÔ¤Ëã
Òý×Ó£ºÂ·±ß̯λµÄ¾­Óª
µÚÒ»½Ú Á˽ⲻͬÆóÒµµÄ²ÆÎñºËËã
³É±¾ÖÐÐÄÊÕÈëµÄ½ç¶¨¡¢Í³¼Æ¹æÔòµÄÈ·¶¨
¸÷³É±¾¡¢·ÑÓõÄÏêϸ¿ÆÄ¿Ó붨Òå
°¢Ã×°Í·ÑÓ÷Ö̯µÄÔ­ÔòºÍ×¢ÒâÊÂÏî
µÚ¶þ½Ú °¢Ãװ;­ÓªÄ¿±êµÄÖƶ¨
²ÆÎñÀúÊ·Êý¾ÝÔÚÄ¿±êÖƶ©ÖеÄÓ¦ÓÃ
ÔËÓÃSWOT·ÖÎöÀúÊ·Êý¾Ý£¬ÕÒ³ö¸ÄÉÆÊý¾ÝµÄ·½·¨
ÆóÒµÕ½ÂÔÔÚÄ¿±êÖƶ©ÖеÄÓ¦ÓÃ
Öƶ¨Êʺϲ»Í¬ÐÎ̬°¢Ãװ͵ľ­ÓªÄ¿±ê
µÚÈý½Ú °¢Ãװ͵ijɱ¾·ÑÓÿØÖÆ
°¢ÃװͺËÐÄÊý¾ÝÈ·Á¢
·ÑÓýµµÍµÄ¸ÄÉÆԴȪ
ÈçºÎ³ÖÐø½«·ÑÓÿØÖÆÓÐЧ
ÌáÉýÒµ¼¨À´½µµÍÆóÒµ³É±¾
µÚËÄ½Ú µ¥Î»Ê±¼äºËËãÖƶÈ
ΪºÎÐèÒªµ¥Î»Ê±¼äºËËãÖƶÈ
µ¥Î»Ê±¼äºËËãÈçºÎÔÚ¾­ÓªÉÏÔËÓÃ
µ¥Î»Ê±¼äºËËãµÄÌصã
µ¥Î»Ê±¼äЧÒæºËËã±íµÄÒâÒå
a)ÕÆÎÕ¾­ÓªÇé¿ö  b)Äý¾ÛÈ«Ô±µÄÁ¦Á¿  c)Ìá¸ßÉú²úЧÂÊ  d)ͳһÔË×÷¹ÜÀí
ÀÍÎñ·ÑÓò»¼ÆÈ뵥λʱ¼äºËËãÖƵÄÃØÃÜ
µÚÎå½Ú ¾­Óª»á¼Æ±¨±í
¾­Óª»á¼ÆÓë¹ÜÀí»á¼ÆµÄÇø±ðºÍÁªÏµ
¾­Óª»á¼Æ±¨±í¿ÆĿ˵Ã÷
ÈçºÎÔËÓþ­Óª»á¼Æ±¨±íÀ´¼à¿Ø¾­Óª¹ý³Ì
ÈÃÿλԱ¹¤×Ô¼ºËãÕË,ÓÃÊý¾Ý˵»°,±ä³É¿ÉÊÓ»¯¾­Óª
°¸ÀýÌÖÂÛ£º¾­Óª»á¼Æ±¨±íÈçºÎÖƶ¨

µÚËÄÕ ÄÚ²¿½»Ò×Òý·¢°¢Ã×°ÍÖ®¼ä¾ºÕù
µÚÒ»½Ú °¢Ã×°ÍÖ®¼äµÄºËËãÓëÄÚ²¿Êг¡»¯
°¢Ãװ͹ÜÀí»á¼Æ¼°Æä×÷ÓÃ
°¢Ãװ͵¥Ôª¾­Óª»á¼ÆºËËãµÄ×¼Ôò
¶¨¼ÛÊǾ­ÓªÖ®±¾£º°¢Ãװ͵¥ÔªÖ®¼äµÄ¶¨¼Û
×îÖÕÊÛ¼Ûµ¹ÍÆÀ´¾ö¶¨¸÷µÀ¹¤ÐòµÄ¼Û¸ñ
¹«Ë¾¸ß²ãÔÚÄÚ²¿Êг¡¶¨¼ÛÖеÄ×÷ÓÃ
°¢Ã×°ÍÁìµ¼ÕßÔÚÄÚ²¿Êг¡»¯ÖеÄ×÷ÓÃ
°¢Ã×°Í×éÖ¯¼ä·ÑÓúËËãÐè×ñÑ­µÄÔ­Ôò
µ¥Î»Ê±¼äºËËãÖƵijö»õ¡¢²É¹ººÍ¿â´æ¹ÜÀí
µÚ¶þ½Ú Êг¡»úÖÆÒýÈëÖÆÔìÏÖ³¡
ÈËÈ˶¼ÊǾ­ÓªÕߣº°ÑÊг¡»úÖÆÒýÈ빫˾ÄÚ²¿
ÏúÊÛ°ÍÓëÉú²ú°ÍÖ®¼äµÄÀûÈó»®·Ö
¼Û¸ñµÄ¾ö¶¨ÒòËØ
ÀûÈóÀ´Ô´
ÅàÑøÈ«Ô±Êг¡Òâʶ

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

2017-09-11 Thread Ross Zwisler 
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 anything.

Signed-off-by: Ross Zwisler 
Suggested-by: Christoph Hellwig 
---

Changes since v1:
 - Use perf instead of tracepoints to detect whether DAX is used. (Dan)

---
 tests/xfs/431 | 77 +++
 tests/xfs/431.out |  2 ++
 tests/xfs/group   |  1 +
 3 files changed, 80 insertions(+)
 create mode 100755 tests/xfs/431
 create mode 100644 tests/xfs/431.out

diff --git a/tests/xfs/431 b/tests/xfs/431
new file mode 100755
index 000..2865a6d
--- /dev/null
+++ b/tests/xfs/431
@@ -0,0 +1,77 @@
+#! /bin/bash
+# FS QA Test xfs/431
+#
+# This is a regression test for kernel patch:
+#  xfs: always use DAX if mount option is used
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#---
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1   # failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+   cd /
+   rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# Modify as appropriate.
+_supported_os Linux
+_supported_fs xfs
+_require_scratch_dax
+
+# real QA test starts here
+export PERF_PROG="`set_prog_path perf`"
+[ "$PERF_PROG" = "" ] && _notrun "perf not found"
+
+_scratch_mkfs > $seqres.full 2>&1
+_scratch_mount "-o dax" >> $seqres.full 2>&1
+
+pgsize=`$here/src/feature -s`
+
+PERF_OUTPUT=$tmp.perf
+
+$PERF_PROG record -o $PERF_OUTPUT -e 'fs_dax:dax_load_hole' \
+   $XFS_IO_PROG -t -c "truncate $pgsize" \
+   -c "chattr -x" \
+   -c "mmap -r 0 $pgsize" -c "mread 0 $pgsize" -c "munmap" \
+   -f $SCRATCH_MNT/testfile  > /dev/null 2>&1
+
+$PERF_PROG script -i $PERF_OUTPUT | grep -q 'fs_dax:dax_load_hole'
+if [[ $? == 0 ]]; then
+   echo "DAX was used"
+else
+   echo "DAX was NOT used"
+fi
+
+# success, all done
+status=0
+exit
diff --git a/tests/xfs/431.out b/tests/xfs/431.out
new file mode 100644
index 000..194ae1e
--- /dev/null
+++ b/tests/xfs/431.out
@@ -0,0 +1,2 @@
+QA output created by 431
+DAX was used
diff --git a/tests/xfs/group b/tests/xfs/group
index 0a449b9..4e7019c 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -427,3 +427,4 @@
 428 dangerous_fuzzers dangerous_scrub dangerous_online_repair
 429 dangerous_fuzzers dangerous_scrub dangerous_repair
 430 dangerous_fuzzers dangerous_scrub dangerous_online_repair
+431 auto quick
-- 
2.9.5

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm