On Fri, Sep 8, 2023 at 10:08 AM Alexander Larsson <alexl@xxxxxxxxxx> wrote: > > > > On Thu, Sep 7, 2023 at 3:22 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >> On Thu, Sep 7, 2023 at 11:44 AM Alexander Larsson <alexl@xxxxxxxxxx> wrote: >> > >> > There are cases where you want to use an overlayfs mount as a lowerdir for >> > another overlayfs mount. For example, if the system rootfs is on overlayfs due >> > to composefs, or to make it volatile (via tmpfs), then you cannot currently store >> > a lowerdir on the rootfs, becasue the inner overlayfs will eat all the whiteouts >> > and overlay xattrs. This means you can't e.g. store on the rootfs a prepared >> > container image for use with overlayfs. >> > >> > This patch series adds support for nesting of overlayfs mounts by escaping the >> > problematic features and unescaping them when exposing to the overlayfs user. >> > >> > This series is also available here: >> > https://github.com/alexlarsson/linux/tree/ovl-nesting >> > >> > And xfstest to test it is available here: >> > https://github.com/alexlarsson/xfstests/tree/overlayfs-nesting >> > >> > The overlay/083 test checks both xattr escaping, the new whiteouts as well as >> > actual nesting of overlayfs. >> > >> >> This test look good. Left minor comments in github. >> Missing test for the perplexing "escaped xwhiteouts across layers" use case. > > > It's kinda hidden, but the creation of $middir/mid actually does test this. > The whiteouts xattr is set on $lowerdir/mid, and this is shadowed by the $middir/mid, so > if that change is removed from the tree, then the "ls" in do_test_xwhiteout" breaks due to the readdir not seeing the xwhiteouts on the mid dir when $lowerdir and $middir are merged. > > We could perhaps point it out more clearly though. > >> > Note that this series breaks the overlay/026 test which validates that >> > writing overlay.* xattrs is not supported, but it now is. I'm not sure >> > if we should fix this test to not fail, or if we should make this an >> > opt-in mount feature. >> >> I think we don't need an opt-in mount option, but would like to know >> what Miklos thinks? >> >> We can fix the test this way: >> >> setfattr trusted.overlayfsrz >> verify success >> getfattr trusted.overlayfsrz >> verify success AND that xattr was not escaped >> >> setfattr trusted.overlay.fsz >> verify failure OR that xattr was escaped >> getfattr trusted.overlay.fsz >> verify failure OR that xattr was escaped > > > Yes, it's fixable in a new xfstest. My question is more about how much we care about older xfstest versions showing a regression. Don't worry about that - it happens quite often when tests are encoding expectations that is not a SPEC and we change behavior. Yes it can be a nuisance to testers, but testers should update to recent xfstests or at least check what changed in recent xfstests when they see a regression. If there is an actual application that breaks because of the behavior change it is a different story, but I doubt there is. Thanks, Amir.
