path: root/Documentation
diff options
authorLinus Torvalds <>2016-09-02 09:32:15 -0700
committerLinus Torvalds <>2016-09-02 09:32:15 -0700
commitf28929ba36b7b35feffd3f282ba17fbc0c4cc83e (patch)
tree0fff1d846975b8cc5d59dd1ef314f46d5dba4b1e /Documentation
parentac8103840b7bf9cca48b437fd5a8cb8b14b6bd02 (diff)
parent026e5e0cc12474495515275d9c176ef823238c70 (diff)
Merge branch 'overlayfs-linus' of git://
Pull overlayfs fixes from Miklos Szeredi: "Most of this is regression fixes for posix acl behavior introduced in 4.8-rc1 (these were caught by the pjd-fstest suite). The are also miscellaneous fixes marked as stable material and cleanups. Other than overlayfs code, it touches <linux/fs.h> to add a constant with which to disable posix acl caching. No changes needed to the actual caching code, it automatically does the right thing, although later we may want to optimize this case. I'm now testing overlayfs with the following test suites to catch regressions: - unionmount-testsuite - xfstests - pjd-fstest" * 'overlayfs-linus' of git:// ovl: update doc ovl: listxattr: use strnlen() ovl: Switch to generic_getxattr ovl: copyattr after setting POSIX ACL ovl: Switch to generic_removexattr ovl: Get rid of ovl_xattr_noacl_handlers array ovl: Fix OVL_XATTR_PREFIX ovl: fix spelling mistake: "directries" -> "directories" ovl: don't cache acl on overlay layer ovl: use cached acl on underlying layer ovl: proper cleanup of workdir ovl: remove posix_acl_default from workdir ovl: handle umask and posix_acl_default correctly on creation ovl: don't copy up opaqueness
Diffstat (limited to 'Documentation')
1 files changed, 3 insertions, 5 deletions
diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt
index d6259c786316..bcbf9710e4af 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -183,12 +183,10 @@ The copy_up operation essentially creates a new, identical file and
moves it over to the old name. The new file may be on a different
filesystem, so both st_dev and st_ino of the file may change.
-Any open files referring to this inode will access the old data and
-metadata. Similarly any file locks obtained before copy_up will not
-apply to the copied up file.
+Any open files referring to this inode will access the old data.
-On a file opened with O_RDONLY fchmod(2), fchown(2), futimesat(2) and
-fsetxattr(2) will fail with EROFS.
+Any file locks (and leases) obtained before copy_up will not apply
+to the copied up file.
If a file with multiple hard links is copied up, then this will
"break" the link. Changes will not be propagated to other names