[OpenAFS-devel] OpenAFS release team weekly meeting

[Mark Vitale]

> On Apr 21, 2020, at 3:31 AM, Christof Hanke <christof.hanke@mpcdf.mpg.de>=
 wrote:
>=20
> Am Dienstag, 21. April 2020, 09:12:12 CEST schrieb Christof Hanke:
>> Am Dienstag, 21. April 2020, 05:05:45 CEST schrieb Benjamin Kaduk:
>>> On Sat, Apr 18, 2020 at 09:44:24AM +0200, Christof Hanke wrote:
>>>> Hi all,
>>>>=20
>>>> thanks for the work & updates.
>>>>=20
>>>> Am Freitag, 17. April 2020, 18:40:47 CEST schrieb Michael Meffie:
>>>>=20
>>>>>=20
>>>>> 1.8.x series
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>=20
>>>>> * The Release Team asks developers to refrain from pushing non-critic=
al patches
>>>>>  to the openafs-stable-1_8_x branch on gerrit.openafs.org until the 1=
.8.6
>>>>>  release has been finalized.
>>>>>=20
>>>>> * a9e26acf742cf49e2a773ffbb3f4f62a334950c tagged as openafs-stable-1_=
8_6pre2
>>>>>=20
>>>>=20
>>>> openafs-stable-1_8_6pre2 does not build on a 32Bit architecture.
>>>> Apparently the typedef for "osi_timeval32_t"  is missing.
>>>=20
>>> It seems to be complaining about osi_timeval_t as well as osi_tiemval32=
_t,
>>> hmm.
>>>=20
>>> But afs_osi.h should be included before lock.h, and should be providing
>>> those typedefs.
>>>=20
>> The ifdef in afs_osi.h reads:
>>=20
>> #if defined(AFS_HPUX_ENV) || defined(AFS_LINUX_64BIT_KERNEL) || (defined=
(AFS_SGI61_ENV) && defined(KERNEL) && defined(_K64U64))
>> typedef struct {
>>    afs_int32 tv_sec;
>>    afs_int32 tv_usec;
>> } osi_timeval_t;
>> typedef struct {
>>    afs_int32 tv_sec;
>>    afs_int32 tv_usec;
>> } osi_timeval32_t;
>> #elif defined(AFS_SUN5_ENV)
>> typedef struct timeval32 osi_timeval_t;
>> typedef struct timeval32 osi_timeval32_t;
>> #else
>> typedef struct timeval osi_timeval_t;
>> typedef struct timeval osi_timeval32_t;
>> #endif /* AFS_SGI61_ENV */
>>=20
>>=20
>> Thus, for a 32bit-machine, osi_timeval[32]_t  is defined as "struct time=
val"
>>=20
>> In the Linux-kernel log=20
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/=
include/linux/time.h?h=3Dv5.6.5&id=3D5dbf20127f8cca8588ad0b0e3e8ded587ac7af=
a0
>> it says:
>>=20
>> [...snip..]
>> Interfaces based on 'struct timespec' or 'struct timeval' should no
>> longer be used for new code, which can use either ktime_t or 'struct
>> timespec64' instead.
>>=20
>> To make this a little clearer, this moves the various helpers into a new
>> time32.h header. For the moment, this gets included by the normal time.h=
,
>> but we may be able to separate it entirely when most users of time32.h
>> are gone.
>> [..snip...]
>>=20
>> I come to this below again.
>>=20
>>> I guess it looks like we don't have any 32-bit linux builders in the 1.=
8.x
>>> triggered build list, though, and possibly not any 32-bit linux builder=
s
>>> that are active at all (https://buildbot.openafs.org/#/builders).
>>=20
>> The builder  opensuse-tumbleweed-i386
>> e.g.
>>=20
>> https://buildbot.openafs.org/#/builders/34/builds/1459/steps/6/logs/stdi=
o
>>=20
>> is showing the same problem.
>>=20
>>=20
>>>=20
>>> That said, the 32-bit builds for debian of 1.8.6pre1 have gone through
>>> fine, so we don't seem to be completely broken.
>> Looking at the header file "linux/time.h" for opensuse-tumbleweed,
>> time32.h is no longer included. Therefore the type "struct timeval"  is =
no longer defined
>> This might be the difference between debian and opensuse.
>>=20
> no, I was wrong here, time32.h is still included, but somehow the "struct=
 timeval" is gone.
>=20

The problem here is that the conditionals in afs_osi.h for osi_timeval_t an=
d osi_timeval32_t
need updating.  The intent is that we only define them explicitly as 32-bit=
 for platforms that we know
have a 64-bit 'timeval'; otherwise, we default to native implementations we=
 "know" to be 32-bit.
But this is a moving target, and has been for some time.   In Christof's ca=
se, I presume that arch
i586 forces a 32-bit kernel, so AFS_LINUX_64BIT_KERNEL is undefined.  This =
results in a fallthrough
to the default case which typedef's osi_timeval_t to (native Linux) timeval=
. =20
However, this timeval no longer exists on y2038-compliant Linux kernels.  S=
o a fix is=20
definitely needed here.

For a different-but-related osi_timeval_t problem in UKERNEL based code, I =
am currently working
on ways to improve our osi_timeval_t definitions.  I will keep this problem=
 in mind as well;
perhaps I can kill two birds with one stone.


--
Mark Vitale
mvitale@sinenomine.net