summaryrefslogtreecommitdiff
path: root/Documentation/filesystems/overlayfs.rst
diff options
context:
space:
mode:
authorChengguang Xu <cgxu519@mykernel.net>2021-04-24 17:03:15 +0300
committerMiklos Szeredi <mszeredi@redhat.com>2021-08-17 12:47:44 +0300
commitb71759ef1e1730db81dab98e9dab9455e8c7f5a2 (patch)
tree5488afd94a375880b955372a98dc2d401aec73e7 /Documentation/filesystems/overlayfs.rst
parentffb24e3c657869b256c3f90792d262fe09f49628 (diff)
downloadlinux-b71759ef1e1730db81dab98e9dab9455e8c7f5a2.tar.xz
ovl: skip checking lower file's i_writecount on truncate
It is possible that a directory tree is shared between multiple overlay instances as a lower layer. In this case when one instance executes a file residing on the lower layer, the other instance denies a truncate(2) call on this file. This only happens for truncate(2) and not for open(2) with the O_TRUNC flag. Fix this interference and inconsistency by removing the preliminary i_writecount check before copy-up. This means that unlike on normal filesystems truncate(argv[0]) will now succeed. If this ever causes a regression in a real world use case this needs to be revisited. One way to fix this properly would be to keep a correct i_writecount in the overlay inode, but that is difficult due to memory mapping code only dealing with the real file/inode. Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'Documentation/filesystems/overlayfs.rst')
-rw-r--r--Documentation/filesystems/overlayfs.rst3
1 files changed, 3 insertions, 0 deletions
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 455ca86eb4fc..7da6c30ed596 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -427,6 +427,9 @@ b) If a file residing on a lower layer is opened for read-only and then
memory mapped with MAP_SHARED, then subsequent changes to the file are not
reflected in the memory mapping.
+c) If a file residing on a lower layer is being executed, then opening that
+file for write or truncating the file will not be denied with ETXTBSY.
+
The following options allow overlayfs to act more like a standards
compliant filesystem: