NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/58633: heartbeat(9) makes unnecessary use of time_uptime



>Number:         58633
>Category:       kern
>Synopsis:       heartbeat(9) makes unnecessary use of time_uptime
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 24 20:40:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The HeartBSD 2038 Foundation
>Environment:
>Description:
kern_heartbeat.c checks to make sure time_uptime has advanced.  But it checks very frequently, and caches it at least once every fifteen seconds, there's no need for it to use the full precision (which is a little costlier on LP32 platforms where that requires a seqlocked loop with memory barriers).  So the low 32 bits of time_uptime are good enough to check for progress: if we've been stuck for 136 years, the heartbeat panic really should have triggered by now.

Incorrectly reported by the well-meaning Coverity as a high impact Y2K38_SAFETY issue, CID 1597793:

*** CID 1597793:  High impact quality  (Y2K38_SAFETY)
/sys/kern/kern_heartbeat.c: 648 in heartbeat()
642     	/*
643     	 * If the uptime hasn't changed, make sure that we haven't
644     	 * counted too many of our own heartbeats since the uptime last
645     	 * changed, and stop here -- we only do the cross-CPU work once
646     	 * per second.
647     	 */
>>>     CID 1597793:  High impact quality  (Y2K38_SAFETY)
>>>     A "time_t" value is stored in an integer with too few bits to accommodate it.  The expression "getuptime()" is cast to "unsigned int".
648     	uptime = time_uptime;
>How-To-Repeat:
code inspection
>Fix:
s/time_uptime/time_uptime32/g and leave a comment saying why this is OK



Home | Main Index | Thread Index | Old Index