-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible regression when lower layer is under the target mountpoint #364
Comments
Didn't realize the RH issue was public, it's here: https://bugzilla.redhat.com/show_bug.cgi?id=2111285 |
@giuseppe given that you were the one that answered on the RH bugzilla, I imagine it means that you are saying this is not a supported use case then? And it used to work by chance but it won't be fixed? |
@flx42 we could fix this simple case to use the fd based syscalls, but I am not sure that would be enough because there might be other cases where it might break since it was never planned to be used this way. I think it is safer if the lower dir is not under the merged directory |
instead of using the lgetxattr and llistxattr system calls on the entire file path, use the /proc/self/fd/$FD/$RELATIVE_PATH path instead so that the lookup is relative to the lower dir file descriptor that is already open. Closes: containers#364 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
I've opened a PR to address this specific case: #366 I don't promise it doesn't break in other weird ways :-) so please do not use a lower dir that is below the mount directory. but this was an easy one to address, and probably it simplifies the lookup as well. |
I will talk with @3XX0 on how to proceed for enroot, but I agree we should change our approach. Thank you for fixing this particular case! |
instead of using the lgetxattr and llistxattr system calls on the entire file path, use the /proc/self/fd/$FD/$RELATIVE_PATH path instead so that the lookup is relative to the lower dir file descriptor that is already open. Closes: containers#364 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
instead of using the lgetxattr and llistxattr system calls on the entire file path, use the /proc/self/fd/$FD/$RELATIVE_PATH path instead so that the lookup is relative to the lower dir file descriptor that is already open. Closes: containers#364 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
See NVIDIA/enroot#130 for the full details and how it creates an almost-unkillable
fuse-overlafys
process when the mountpoint is above the lower dir, Red Hat support mentioned that this is an invalid use case, but I went back and verified it worked fine in fuse-overlayfs v0.7 -> v1.6, and it started hanging since this seemingly unrelated commit in v1.7 so I wanted to verify if this pattern should not be used indeed:The repro code (tested on Ubuntu 5.17 and 5.15 kernels):
Output with fuse-overlayfs 1.5, it works fine:
Output with fuse-overlayfs 1.7.1, the
ls
hangs:And a little while later in the kernel log:
And the process is unkillable:
The text was updated successfully, but these errors were encountered: