Hi @laurazard. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

Oh no I'm still having issues with review requests 😅 I'll just ping @dmcgowan @AkihiroSuda @rumpl @thaJeztah

flag provided but not defined: -test.root

(https://github.com/containerd/containerd/actions/runs/4428569995/jobs/7768037954?pr=8259#step:13:287)

Not sure what's going on here, looks like the test is being run with -test.root but that doesn't work on Windows?

Looks like mount is getting picked up as a TEST_REQUIRES_ROOT_PACKAGES in

I'll add the testutil import to register the -test.root flag so this won't fail.

The other failures were fixed, and these look unrelated –

• https://github.com/containerd/containerd/actions/runs/4449274521/jobs/7813342111

=== FAIL: . TestContentClient/CommitErrorState (3.75s)
testsuite.go:122: Cleanup failed: failed to abort c1-commiterror-state: unlinkat /var/lib/containerd-test/io.containerd.content.v1.content/ingest/9101c5f249b4cb38a50dddda86a787c09f31099573c87c525fc50774ac21d05d: directory not empty: unknown

• https://github.com/containerd/containerd/actions/runs/4449274521/jobs/7813338070?pr=8259

=== FAIL: . TestContainerPTY (10.66s)
container_test.go:2574: expected \x00 in output

I marked this PR for cherry-picking for 1.6 and 1.7. Discussed with @laurazard and we'd like to use this functionality and as far as we can see, this should probably be safe to include.

(of course backports will still need to be reviewed, and I asked @laurazard to call out potential concerns on the backports 👍 )

With this patch applied, the kernel throws another warning [509574.194814] overlayfs: lowerdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.. Is it normal?

I haven't noticed that warning, but before this change, as described in #6077, you would get:

kernel: [42256.430385] overlayfs: upperdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
kernel: [42256.430389] overlayfs: workdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.

Which (in practice) is a bigger problem than remounting as lowerdir – as described in #6077:

And later for that container we observe this "undefined behavior" as the RootFS of that container becoming partially not-writable (an attempt to create a file results in "No such file or directory" error).

Are you seeing issues like that?

I haven't noticed that warning, but before this change, as described in #6077, you would get:

kernel: [42256.430385] overlayfs: upperdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.
kernel: [42256.430389] overlayfs: workdir is in-use as upperdir/workdir of another mount, accessing files from both mounts will result in undefined behavior.

Which (in practice) is a bigger problem than remounting as lowerdir – as described in #6077:

And later for that container we observe this "undefined behavior" as the RootFS of that container becoming partially not-writable (an attempt to create a file results in "No such file or directory" error).

Are you seeing issues like that?

Yes, I also got the error "No such file or directory" when reproducing the problem as #6077 said

The only functional change introduced in this patch is in diff/walking/differ.go – which changes the behaviour there from creating the new mount "normally" to creating the new mount "read-only", which just means without an upper/workdir layer. If the issue you're describing didn't happen before this change, maybe you could share reproduction steps/explain under what scenario you're running into this so we can take a look at it?