On Tue, 20 Jul 2021 at 16:35, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Sat, 24 Apr 2021 at 16:04, Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote: > > > > Lower files may be shared in overlayfs so strictly checking write > > perssmion on lower file will cause interferes between different > > overlayfs instances. > > How so? > > i_writecount on lower inode is not modified by overlayfs (at least not > in this codepath). Which means that there should be no interference > between overlayfs instances sharing a lower directory tree. I'm beginning to see what you are worrying about. So on one instance a file on lower gets executed and on another instance sharing the lower layer the file is truncated. The truncate is currently denied due to the negative i_writecount on the lower file. Also behavior is inconsistent between open(path, O_TRUNC) and truncate(path) even though the two should be equivalent. Applied with the following description: 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. Thanks, Miklos
