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