Several tests related to unlinkable temporary files seem to fail when shiftfs is used #14861

evverx · 2020-02-11T23:45:29Z

Trying to run the unit tests on Travis CI on arm64/s390x/ppc64le @mrc0mmand discovered a few issues (mentioned in #13785 (comment)) reproducible with shiftfs only. I'm not sure whether it's a bug in systemd or in shiftfs (or somewhere in between) but I'll leave it here so that it would be possible to refer to it in commit messages.

I'll go ahead and add the "lxc" label because it appears shiftfs is used in LXD containers on Travis CI by default.

Here's how it goes sideways in test-xattr-util:

openat(AT_FDCWD, "/tmp", O_RDWR|O_EXCL|O_TMPFILE, 0600) = -1 EOPNOTSUPP (Operation not supported)
umask(077)                              = 022
getpid()                                = 29361
openat(AT_FDCWD, "/tmp/systemd-tmp-7950fL", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 3</tmp/systemd-tmp-7950fL>
umask(022)                              = 077
unlinkat(AT_FDCWD, "/tmp/systemd-tmp-7950fL", 0) = 0
statx(3</tmp/systemd-tmp-7950fL (deleted)>, "", AT_STATX_DONT_SYNC|AT_EMPTY_PATH, STATX_BTIME, 0xffffdba7c2e8) = -1 ESTALE (Stale file handle)
getxattr("/proc/self/fd/3", "user.crtime_usec", 0xffffdba7c2c0, 8) = -1 ESTALE (Stale file handle)
fsetxattr(3</tmp/systemd-tmp-7950fL (deleted)>, "user.crtime_usec", "\200\307.0\243e\5", 8, 0) = 0
statx(3</tmp/systemd-tmp-7950fL (deleted)>, "", AT_STATX_DONT_SYNC|AT_EMPTY_PATH, STATX_BTIME, 0xffffdba7c2e8) = -1 ESTALE (Stale file handle)
getxattr("/proc/self/fd/3", "user.crtime_usec", 0xffffdba7c2c0, 8) = -1 ESTALE (Stale file handle)
writev(2<pipe:[241902836]>, [{iov_base="Assertion 'fd_getcrtime(fd, &usec) >= 0' failed at src/test/test-xattr-util.c:40, function test_getcrtime(). Aborting.", iov_len=118}, {iov_base="\n", iov_len=1}], 2Assertion 'fd_getcrtime(fd, &usec) >= 0' failed at src/test/test-xattr-util.c:40, function test_getcrtime(). Aborting.
) = 119

cc @brauner

The text was updated successfully, but these errors were encountered:

brauner · 2020-02-12T10:55:55Z

See #13785 (comment). :)

evverx · 2020-02-12T12:21:33Z

Thank you!

It's not our bug, then :-) Let's wait for Travis to roll the fix out. @mrc0mmand in the meantime, to keep the ball rolling we can mount tmpfs onto /tmp and /var/tmp. I ran

unshare -m bash -x -c "
mount -t tmpfs tmpfs /tmp/
mount -t tmpfs tmpfs /var/tmp/

meson --werror \
      --optimization=0 \
      --buildtype=debug \
      -Dc_args='-fno-omit-frame-pointer -ftrapv' \
      -Dtests=unsafe \
      -Dsplit-usr=true \
      -Dman=true \
      build
ninja -v -C build
meson test -C build --print-errorlogs --timeout-multiplier=4"

mrc0mmand · 2020-02-12T12:32:41Z

Thanks a lot for getting down this rabbit hole!

in the meantime, to keep the ball rolling we can mount tmpfs onto /tmp and /var/tmp.

Will do!

Temporary workaround for bugged shiftfs used in Travis LXD containers See: - systemd#14861 - systemd#13785 (comment)

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin >evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

evverx · 2020-04-15T01:47:17Z

As far as I can tell, it was reported somewhere else and should be addressed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757. Closing. @brauner thank you!

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kelsey Skunberg <kelsey.skunberg@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Ondrej Kubik <ondrej.kubik@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Our revalidate methods were very opinionated about whether or not a dentry was valid when we really should've just let the underlay tell us what's what. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. I had also foolishly provided a .tmpfile method which so far only has caused us trouble. If we really need this then we can reimplement it properly but I doubt it. Remove it for now. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/1872757 Users reported that creating temporary files shiftfs reports ESTALE. This can be reproduced via: import tempfile import os def test(): with tempfile.TemporaryFile() as fd: fd.write("data".encode('utf-8')) # re-open the file to get a read-only file descriptor return open(f"/proc/self/fd/{fd.fileno()}", "r") def main(): fd = test() fd.close() if __name__ == "__main__": main() a similar issue was reported here: systemd/systemd#14861 Our revalidate methods were very opinionated about whether or not a lower dentry was valid especially when it became unlinked we simply invalidated the lower dentry which caused above bug to surface. This has led to bugs where a ESTALE was returned for e.g. temporary files that were created and directly re-opened afterwards through /proc/<pid>/fd/<nr-of-deleted-file>. When a file is re-opened through /proc/<pid>/fd/<nr> LOOKUP_JUMP is set and the vfs will revalidate via d_weak_revalidate(). Since the file has been unhashed or even already gone negative we'd fail the open when we should've succeeded. Reported-by: Christian Kellner <ckellner@redhat.com> Reported-by: Evgeny Vereshchagin <evvers@ya.ru> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Seth Forshee <seth.forshee@canonical.com> Link: systemd/systemd#14861 Signed-off-by: Seth Forshee <seth.forshee@canonical.com>

evverx added the lxc/lxd label Feb 11, 2020

evverx mentioned this issue Feb 12, 2020

travis: add aarch64, s390x, and ppc64le jobs #13785

Closed

evverx added the not-our-bug label Feb 12, 2020

mrc0mmand added a commit to mrc0mmand/systemd that referenced this issue Feb 12, 2020

travis: mount (/var)/tmp as tmpfs instead of shiftfs in LXD

e83d09b

Temporary workaround for bugged shiftfs used in Travis LXD containers See: - systemd#14861 - systemd#13785 (comment)

mrc0mmand added a commit to mrc0mmand/systemd that referenced this issue Feb 12, 2020

travis: mount (/var)/tmp as tmpfs instead of shiftfs in LXD

7cc60f4

Temporary workaround for bugged shiftfs used in Travis LXD containers See: - systemd#14861 - systemd#13785 (comment)

mrc0mmand added a commit to mrc0mmand/systemd that referenced this issue Mar 4, 2020

travis: mount (/var)/tmp as tmpfs instead of shiftfs in LXD

7def15e

Temporary workaround for bugged shiftfs used in Travis LXD containers See: - systemd#14861 - systemd#13785 (comment)

evverx closed this as completed Apr 15, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Several tests related to unlinkable temporary files seem to fail when shiftfs is used #14861

Several tests related to unlinkable temporary files seem to fail when shiftfs is used #14861

evverx commented Feb 11, 2020 •

edited

Loading

brauner commented Feb 12, 2020

evverx commented Feb 12, 2020

mrc0mmand commented Feb 12, 2020

evverx commented Apr 15, 2020

Several tests related to unlinkable temporary files seem to fail when shiftfs is used #14861

Several tests related to unlinkable temporary files seem to fail when shiftfs is used #14861

Comments

evverx commented Feb 11, 2020 • edited Loading

brauner commented Feb 12, 2020

evverx commented Feb 12, 2020

mrc0mmand commented Feb 12, 2020

evverx commented Apr 15, 2020

evverx commented Feb 11, 2020 •

edited

Loading