Thread (5 messages) 5 messages, 3 authors, 2025-03-03

Re: mismatch of type of ut_tv.tv_sec between glibc-2.41 and utmp(5)

From: Alejandro Colomar <alx@kernel.org>
Date: 2025-02-28 14:06:38

Hi Thomas,

On Fri, Feb 28, 2025 at 10:36:10AM +0100, Dr. Thomas Orgis wrote:
Dear man-pages,

while investigating some old bad usage of time(&ut,ut_time) I noticed
that my glibc-2.41 headers define that part of the utmp struct like this:

#if __WORDSIZE_TIME64_COMPAT32
  int32_t ut_session;           /* Session ID, used for windowing.  */
  struct
  {
    __uint32_t tv_sec;          /* Seconds.  */
    int32_t tv_usec;            /* Microseconds.  */
  } ut_tv;                      /* Time entry was made.  */
#else
  long int ut_session;          /* Session ID, used for windowing.  */
  struct timeval ut_tv;         /* Time entry was made.  */
#endif

The man page claims this:

           #if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
               int32_t ut_session;           /* Session ID (getsid(2)),
                                                used for windowing */
               struct {
                   int32_t tv_sec;           /* Seconds */
                   int32_t tv_usec;          /* Microseconds */
               } ut_tv;                      /* Time entry was made */
           #else
                long   ut_session;           /* Session ID */
                struct timeval ut_tv;        /* Time entry was made */
           #endif
It seems your suspicion was right.  Someone decided to borrow some time,
according to the commit message that changed that code in glibc:

	alx@debian:~/src/gnu/glibc/master$ grep -rn '__uint32_t tv_sec;' -l \
		| xargs -L1 git blame -- \
		| grep '__uint32_t tv_sec;';
	5361ad3910c bits/utmp.h                (Florian Weimer 2024-04-19 14:38:17 +0200  79)     __uint32_t tv_sec;		/* Seconds.  */
	5361ad3910c (Florian Weimer 2024-04-19 14:38:17 +0200  77)     __uint32_t tv_sec;		/* Seconds.  */
	alx@debian:~/src/gnu/glibc/master$ git log -1 5361ad3910c --stat;
	commit 5361ad3910c257bc327567be76fde532ed238e42
	Author: Florian Weimer [off-list ref]
	Date:   Fri Apr 19 14:38:17 2024 +0200

	    login: Use unsigned 32-bit types for seconds-since-epoch
	    
	    These fields store timestamps when the system was running.  No Linux
	    systems existed before 1970, so these values are unused.  Switching
	    to unsigned types allows continued use of the existing struct layouts
	    beyond the year 2038.
	    
	    The intent is to give distributions more time to switch to improved
	    interfaces that also avoid locking/data corruption issues.
	    
	    Reviewed-by: Adhemerval Zanella  [off-list ref]

	 NEWS                         |  9 ++++++++-
	 bits/utmp.h                  |  4 ++--
	 login/Makefile               |  4 +++-
	 login/tst-utmp-unsigned-64.c |  1 +
	 login/tst-utmp-unsigned.c    | 40 ++++++++++++++++++++++++++++++++++++++++
	 sysdeps/gnu/bits/utmpx.h     |  2 +-
	 6 files changed, 55 insertions(+), 5 deletions(-)

I don't know the history … did it use to be a signed integer and
someone decided to buy some time by making it unsigned? This is a minor
detail for the bad time() usage, where 32 bit vs. 64 bit time_t might
be more serious. Also the macros being checked for this compatibility
mode differ, but I am not sure how closely the man page want to follow
glibc here.
We should document the change.  If anyone wants to send a patch, I'll
review it.  I won't write it myself, because I'm not an expert in
compatibility code between 32 and 64 bits, so I prefer if someone more
expert makes sure the documentation is correct.
At least the type of tv_sec should match, I guess.
Yes.  And we should probably document the old type in the HISTORY
section.
Now I have to think how elaborately I want to handle possible overflow
from time_t assigning to uint32_t with the recommended way of using
gettimeofday() for utmp …
If you show some code, we can have a look at it.  :)


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help