Re: [PATCH v4] linux: Fix ancillary 64-bit time timestamp conversion (BZ #28349, BZ #28350)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 24/01/2022 09:38, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 24/01/2022 09:13, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>>> typo: MSG_[C]TRUNC
>>>>>
>>>>> (I think this MSG_CTRUNC result is a remaining bug we need to fix
>>>>> separately for time32 mode.)
>>>>
>>>> Do you mean not returning the MSG_CTRUNC?
>>>
>>> No, if the caller uses CMSG_SPACE to allocate space for the expected
>>> ancillary data, we should not produce MSG_CTRUNC by stuffing in
>>> ancillary data that has not been requested.  Maybe we can do this for
>>> time32 code only.  Again it seems that userspace emulation is rather
>>> questionable here.
>>
>> But this would be only an issue for applications using _TIME_BITS=64
>> running on older kernels (so 32 bit timestamps would be visible to
>> the caller).  Since 64 bit is a opt-in feature, I think users will
>> see way more potential issues running _TIME_BITS=64 on older kernels.
> 
> As far as I can see, it is currently an issue for time32 applications
> running on old and new kernels.  We synthesize the time64 control
> messages unconditionally.

time32 applications running on any kernel will continue to see the 
timestamps because they will use the old SO_ constants and kernel will
synthesize them on the ancillary buffer.  

It might be a problem only when time32 application use the new 64 bit 
time_t SO_ constants either though a library built with _TIME_SIZE=64
or by using it directly (which should not be straightforward since both
kernel and glibc only define the 64 bit constants for _TIME_BITS=64).