I can reproduce the bolt testcase problem in a podman container, with overlay driver, using ext4, xfs, and btrfs. So I think I can drop linux-btrfs@ from this thread. Also I can reproduce the title of this thread simply by 'podman system reset' and see the kernel messages before doing the actual reset. I have a strace here of what it's doing: https://drive.google.com/file/d/1L9lEm5n4-d9qemgCq3ijqoBstM-PP1By/view?usp=sharing It may be something intentional. The failing testcase, :../tests/test-common.c:1413:test_io_dir_is_empty also has more instances of this line, but I don't know they are related. So I'll keep looking into that. On Sat, Apr 10, 2021 at 2:04 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > As the first step, can you try the suggested fix to ovl_dentry_version_inc() > and/or adding the missing pr_debug() and including those prints in > your report? I'll work with bolt upstream and try to further narrow down when it is and isn't happening. > > I can reproduce this with 5.12.0-0.rc6.184.fc35.x86_64+debug and at > > approximately the same time I see one, sometimes more, kernel > > messages: > > > > [ 6295.379283] overlayfs: upper fs does not support xattr, falling > > back to index=off and metacopy=off. > > > > Can you say why there is no xattr support? I'm not sure. It could be podman specific or fuse-overlayfs related. Maybe something is using /tmp in one case and not another for some reason? > Is the overlayfs mount executed without privileges to create trusted.* xattrs? > The answer to that may be the key to understanding the bug. Yep. I think tmpfs supports xattr but not user xattr? And this example is rootless podman, so it's all unprivileged. > My guess is it has to do with changes related to mounting overlayfs > inside userns, but I couldn't find any immediate suspects. > > Do you have any idea since when the regression appeared? > A bisect would have been helpful here. Yep. All good ideas. Thanks for the fast reply. I'll report back once this has been narrowed down futher. -- Chris Murphy
