diff options
| author | Chengguang Xu <cgxu519@mykernel.net> | 2021-04-24 17:03:15 +0300 |
|---|---|---|
| committer | Miklos Szeredi <mszeredi@redhat.com> | 2021-08-17 12:47:44 +0300 |
| commit | b71759ef1e1730db81dab98e9dab9455e8c7f5a2 (patch) | |
| tree | 5488afd94a375880b955372a98dc2d401aec73e7 /Documentation/filesystems | |
| parent | ffb24e3c657869b256c3f90792d262fe09f49628 (diff) | |
| download | linux-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')
| -rw-r--r-- | Documentation/filesystems/overlayfs.rst | 3 |
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: |