Date: Fri, 29 Jul 2022 03:03:18 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 232914] kern/kern_resource: Integer overflow in function calcru1 Message-ID: <bug-232914-227-f9KD0jokMS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-232914-227@https.bugs.freebsd.org/bugzilla/> References: <bug-232914-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232914 Kubilay Kocak <koobs@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |maintainer-feedback?(sjg@Fr | |eeBSD.org), | |maintainer-feedback?(cem@fr | |eebsd.org), | |maintainer-feedback?(jhb@Fr | |eeBSD.org) Version|CURRENT |12.3-STABLE CC| |cem@freebsd.org, | |jhb@FreeBSD.org, | |sjg@FreeBSD.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D7= 697 | |2 Severity|Affects Only Me |Affects Some People Status|New |Open Summary|Integer overflow in |kern/kern_resource: Integer |function calcru1 |overflow in function | |calcru1 Keywords| |needs-qa --- Comment #1 from Kubilay Kocak <koobs@FreeBSD.org> --- I believe I've reproduced this on a 12.3-RELEASE-p5 GENERIC amd64 virtualbox virtual machine. After suspending the guest and upgrading virtualbox (on host) and resuming,= the following was logged in /var/log/messages: Jul 28 00:34:10 123-RELEASE-p5-amd64-9e36 kernel: calcru: runtime went backwards from 5425487903787745 usec to 18518189771 usec for pid 11 (idle) Additionally, the following is observed in top output: PID JID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME= =20=20=20 WCPU COMMAND 11 0 root 2 155 ki31 0B 32K 0B RUN 0 ??? 199.70% [idle] Originally running `ps -p` on the idle process id showed time and system not changing: [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 17087 -o comm,time,systi= me COMMAND TIME SYSTIME=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424922:45.67 90424922:45.67 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424922:45.67 90424922:45.67 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424922:45.67 90424922:45.67 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424922:45.67 90424922:45.67 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424922:45.67 90424922:45.67 But after a small period of time started changing again: [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424939:04.68 90424939:04.68 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424939:05.76 90424939:05.76 [koobs@123-RELEASE-p5-amd64-9e36:/usr/ports] ps -p 11 -o comm,time,systime COMMAND TIME SYSTIME idle 90424939:06.43 90424939:06.43 Looking at kern/kern_resource history: 1) Conrad (cem) resolved a calcru1 overflow in base 23e5e43ccd0f via bug 76= 972 (Bruce followed up with base 23e5e43ccd0f) 2) Simon (sjg) disabled the message for virtual machines in base bacb140f31= aa via review D33902 (unsure whether this was eventually MFC'd or not, the com= mit didn't include MFC tag) There may be behaviour improvements possible in this case, particularly for= the '???' reported times in top. In particular: 1) Had the message been disabled in my (VM) case, I would not have been abl= e to correlate/isolate the cause via dmesg 2) What could we report for runtime in the event of overflow instead of '??= ?' What do other OS's do? With dynamic frequency/power scaling being the norm these days, increasing heterogeneity in system hardware (big.little etc) in the future, and given = this message appears to only be an (intended) 'report' or diagnostic message sol= ely to indicate the state change (and not a fatal error) ... 3) What other ways might FreeBSD more broadly/gracefully handle timing chan= ges going forward? ^Triage: Request feedback from Conrad re (remaining?) calcru1 overflow and Simon/John re virtual machine situation. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232914-227-f9KD0jokMS>