[OpenAFS] Strange DNS SRV traffic resulting from stat() in
1.8.13.2
Cheyenne Wills
cwills@sinenomine.net
Tue, 26 Aug 2025 15:11:49 -0600
Thank you Jeff and Marc for identifying the area that was causing a
problem.
The cause is a little more subtle than described. =20
The Linux 6.14 commit (5be1fa8abd7b049f51e6e98e75a37eef5ae2c296) that
was responsible for the OpenAFS commit
(0306f3fdac736e15620f5802bdce510d25bb2450) added a new parameters for
the dop.d_revalidate() function. The new parameter, 'name', is, as
mentioned a qstr, but the string that it points to is NUL
terminated as well (according to Linux's porting documentation).
However the length of the qstr does match the "strlen" of the entire
string -- which is the root cause of the problem.=20
Prior to the 0306f3fdac73 commit, OpenAFS's d_validate routine was using
the d_name.name from the dentry parameter. Using the d_name.name from
the dentry parameter fixes the behavior (basically it reverts part of
the 0306f3fdac73 change). I'm working on a patch for OpenAFS to
correct the problem.
Again thank you Jeff and Marc for your analysis. I was looking through
the 1.8.10 -> 1.8.13.2 differences to try to determine the cause of the
problem.
--=20
Cheyenne Wills
cwills@sinenomine.net
On Tue, 26 Aug 2025 10:59:32 -0400
Jeffrey Altman <jaltman@auristor.com> wrote:
> [...] =20
> [...] =20
> [...] =20
> [...] =20
> [=E2=80=A6]
>=20
> [...] =20
>=20
> Ryan observes the behavior on 25.04 and you observe it on 24.04.
> Both running 6.14.0 based kernels. =20
>=20
> The bug was introduced to OpenAFS in commit
> 0306f3fdac736e15620f5802bdce510d25bb2450 which must have been
> cherry-picked into the Ubuntu builds.
>=20
> 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.
>=20
> 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.
>=20
> Marc Dionne should be credited with identifying the mistake.
>=20
> This mistake is not present in the AuriStorFS client.
>=20
> Jeffrey Altman
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info