[OpenAFS] Strange DNS SRV traffic resulting from stat() in 1.8.13.2

[Jeffrey Altman]

> On Aug 26, 2025, at 9:27=E2=80=AFAM, Gunnar Krull =
<gklists@cs.uni-goettingen.de> wrote:
>=20
> Hi Jeffrey,
>=20
> On 25/08/2025 17:19, Jeffrey Altman wrote:
>>> 25-Aug-2025 07:15:47.756 client @0x7fa6b79fe168 172.27.2.4#34129 =
(_afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/=
.google_authenticator.informatik.uni-goettingen.de): query: =
_afs3-vlserver._udp.informatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.=
google_authenticator.informatik.uni-goettingen.de IN SRV +E(0) =
(134.76.81.212)
>> Likewise a lookup is being performed for =
=E2=80=9Cinformatik.uni-goettingen.de/user/a/xxxxxx/.xxxlogin/.google_auth=
enticator=E2=80=9D as a single path component.
>> An strace of the originating process would be useful to examine.
>=20
> here is one example of a strace that can be matched to the =
corresponding DNS query.
>=20
> * strace of the process:
>=20
> 11442 13:56:30.961461 faccessat2(AT_FDCWD</>, =
"/afs/informatik.uni-goettingen.de/user/m/xxxxx.xxxxx/.ifi-login/authorize=
d_keys", R_OK, AT_EACCESS) =3D -1 ENOENT (No such file or directory) =
<0.017024>
>=20
> * corresonding generated DNS queries:
>=20
> 26-Aug-2025 13:56:30.989 client @0x7fa6b799e168 172.27.2.4#39324 =
(_afs3-vlserver._udp.informatik.uni-goettingen.de/user/m/xxxx.xxxx/.ifi-lo=
gin/authorized_keys): query: =
_afs3-vlserver._udp.informatik.uni-goettingen.de/user/m/xxxx.xxxx/.ifi-log=
in/authorized_keys IN SRV +E(0) (134.76.81.212)
>=20
[=E2=80=A6]

> The process was running on Ubuntu 24.04, kernel 6.14.0-28-generic, =
OpenAFS Client 1.8.13.2-1ubuntu1.

Ryan observes the behavior on 25.04 and you observe it on 24.04.  Both =
running 6.14.0 based kernels. =20

The bug was introduced to OpenAFS in commit =
0306f3fdac736e15620f5802bdce510d25bb2450 which must have been =
cherry-picked into the Ubuntu builds.

struct qstr =E2=80=9Cquick string=E2=80=9D is a counted string not a NUL =
terminated string.   The mistake introduced in the aforementioned commit =
results in the full path being evaluated as the dentry name instead of =
just the path component the dentry actually refers to.

As a result, the d_revalidate() call will always fail, the current =
dentry will always be invalidated, and a full lookup() will be performed =
each time a cached dentry is used.

Marc Dionne should be credited with identifying the mistake.

This mistake is not present in the AuriStorFS client.

Jeffrey Altman=