Re: [REGRESSION] Return change in 6.12.80+ with volatile mounting

Chenglong Tang <[email protected]>
Newsgroups org.kernel.vger.linux-unionfs,dev.linux.lists.regressions,org.kernel.vger.stable
Message-ID <CAOdxtTaWWu_7eJWu68zf28zHQP3Y--vXTfbGFsceO47BpN3qxA@mail.gmail.com>
Hi, Amir,

Thanks for looking into this! To answer your questions:

1. Production vs. Test Suite Impact

The immediate failure we encountered is in containerd's integration
test suite (TestImageVolumeCheckVolatileOption). The test explicitly
reads /proc/mounts and expects the exact string "volatile".

In default production, containerd passes the legacy "volatile" string
to the mount syscall, which your patch correctly handles under the
hood. So the standard "happy path" is not broken in production.

2. The purpose of WithTempMount() / RemoveVolatileOption

Containerd regularly makes temporary overlay mounts (e.g., for
unpacking layers). Because overlayfs rejects reusing upper/work dirs
from a volatile mount, containerd uses RemoveVolatileOption to strip
the volatile flag before these temporary mounts.

Currently, containerd's RemoveVolatileOption does an exact string
match for "volatile". While it works for the default path, there is a
production edge case: if a user explicitly configures their container
runtime to use the new "fsync=volatile" option, older containerd
binaries will fail to strip it, and the temporary mounts will be
rejected by the kernel.

Conclusion

While containerd could theoretically patch their code to accept
strings.Contains() or fsync=volatile going forward, there are many
existing containerd binaries in the wild. Given that this patch breaks
containerd's CI tests and introduces an edge case for
RemoveVolatileOption, it might be safest to fix ovl_show_options in
the kernel to continue outputting the legacy "volatile" string to
strictly guarantee backwards compatibility with userspace.

Thanks,
Chenglong

On Sat, Apr 18, 2026 at 8:40 AM Amir Goldstein <[email protected]> wrote:
>
> On Sat, Apr 18, 2026 at 1:33 AM Chenglong Tang <[email protected]> wrote:
> >
> > CC Amir,
> >
> > For example, containerd 2.2.0 uses `volatile` instead of `fsync=volatile`:
> > https://github.com/containerd/containerd/blob/main/core/mount/temp.go#L91C1-L92C1
> >
> > On Fri, Apr 17, 2026 at 3:41 PM Derek Taylor <[email protected]> wrote:
> > >
> > > This change seems to have so far affected at least containerd in an
> > > issue reported here
> > > https://github.com/containerd/containerd/issues/13250.
> > >
> > > In stable versions 6.12.80+, commit
> > > 6c0cfbe020c0fcd2a544fcd2931fbc366ee3cd12 with the specific change
> > > being:
> > > [*] The mount option "volatile" is an alias to "fsync=volatile".
> > > In this scenario, code relying on checking "volatile" will now fail
> > > due to the return being "fsync=volatile".
> > >
> > > #regzbot introduced:v6.12.80
>
> Hi Chenglong,
>
> Thanks for the report.
>
> Is this problem in production containerd or in a test suite?
> I did not understand the purpose of WithTempMount().
>
> Is it possible to fix this function to use string.Contains() instead of
> exact match to the "volatile" mount option?
>
> If needed I can fix the kernel to show the legacy "volatile" option,
> but I would like to first understand how bad the impact of this regression
> is on real production workloads.
>
> Thanks,
> Amir.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.