Comment 12 for bug 2033892

Considerations for the SRU team:

I confirmed that the behavior in Jammy is different than
Focal and Mantic, the previous / next supported releases.
(Steps in the next comment.)

So, although this SRU changes behavior in a stable release
(generally not OK in SRUs), it is actually Jammy that changed
behavior _across_ stable releases (and to a buggy one!).

Thus, the SRU is reasonably _restoring_ (arguably, _fixing_)
the _expected_ behavior. So, this looks OK for SRU, IMHO.

Additionally, I considered two points before sponsoring this.

1) The impact of the code changes to non-autofs/non-automount:

And it seems virtually zero, considering the man pages explain
the flag now used in statx() is used in other related syscalls
(stat, lstat, fstatat), which have it implied since Linux 4.11.
And it indeed only affects automount (note the flag name).

So, even though this change is "new" in Jammy, it's been tested
in older and later releases for a long time (pre-Bionic kernels).

 stat(2):

        AT_NO_AUTOMOUNT (since Linux 2.6.38)
        [...] Since Linux 4.11 this flag is implied.

 statx(2):

        AT_NO_AUTOMOUNT
        [...]
        All of stat(2), lstat(2), and fstatat(2) act as though AT_NO_AUTOMOUNT
        was set.

2) Whether users may have started to rely on this behavior

I agree this is unlikely, and think so because of 3 points:

2.1) This behavior did not exist in previous releases,
which reduces the chances it has been 'learned' before.

2.2) The usage of autofs/automount rely on access to be made
_to a particular mountpoint_ in order for it to be _mounted_.

This is reflected in different documentation sources online,
so it is likely that this is the way that has been 'learned'.

2.3) The safe side is, _even if_ an user started to rely on
this behavior to automount the subdirs, the very next thing
they will do (if they actually need that subdir mounted) is
to _access_ that subdir - which can mount it just as before!