linux-kernel - Re: [PATCH] Re: /proc/uptime idle counter remains at 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Sep 2009 22:58:58 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Michael Abbott <michael@...neidae.co.uk>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Johan van Baarlen <JF@...baarlen.demon.nl>
Subject: Re: [PATCH] Re: /proc/uptime idle counter remains at 0

On Fri, 14 Aug 2009 13:18:08 +0100 (BST) Michael Abbott <michael@...neidae.co.uk> wrote:

> Reviving this:
> 
> On Sat, 9 May 2009, Jan Engelhardt wrote:
> > starting from v2.6.28-4930-g79741dd lasting thru at least v2.6.29.1,
> > the second field of /proc/uptime always shows 0.00. This happens for
> > both the typical i386 (my case) and on an ARM (according to Michael,
> > cc'ed).
> > 
> > >From the commit log of 79741dd:
> > 
> > 	"""The cpu time spent by the idle process actually doing
> > 	something is currently accounted as idle time. This is plain
> > 	wrong, the architectures that support VIRT_CPU_ACCOUNTING=y
> > 	can do better: distinguish between the time spent doing
> > 	nothing and the time spent by idle doing work. The first is
> > 	accounted with account_idle_time and the second with
> > 	account_system_time."""
> > 
> > Citing Michael from our irc conversation:
> > 
> > 	"""the writer[committer] [says] that [the] idle process time
> > 	isn't really idle time ... but that's all that /proc/uptime
> > 	looks at. I guess fs/proc/uptime.c needs to catch up."""
> > 
> > So, were the updates to uptime.c missed, or do we now live on with
> > /proc/uptime constantly having 0?
> 
> My previous patch seems to have run into the sand.  It every so nearly got 
> pulled into mainstream as far as I can tell, but didn't seem to make it; 
> no idea what happened.
> 
> So here we go again:
> 

Imagine my surprise to find a version of this patch lurking in Martin's
tree since June 22.  It's a regression fix!

Johan, does this patch help with the regression you reported in
http://bugzilla.kernel.org/show_bug.cgi?id=14131 ?

Thanks.


commit 27bf8712477db47c891e6198000c985631cd18de
Author:     Michael Abbott <michael.abbott@...mond.ac.uk>
AuthorDate: Mon Jun 22 12:19:25 2009 +0200
Commit:     Martin Schwidefsky <schwidefsky@...ibm.com>
CommitDate: Mon Jun 22 12:20:44 2009 +0200

    [PATCH] Fix idle time field in /proc/uptime
    
    Git commit 79741dd changes idle cputime accounting, but unfortunately
    the /proc/uptime file hasn't caught up.  Here the idle time calculation
    from /proc/stat is copied over.
    
    Signed-off-by: Michael Abbott <michael.abbott@...mond.ac.uk>
    Signed-off-by: Martin Schwidefsky <schwidefsky@...ibm.com>

diff --git a/fs/proc/uptime.c b/fs/proc/uptime.c
index 0c10a0b..766b1d4 100644
--- a/fs/proc/uptime.c
+++ b/fs/proc/uptime.c
@@ -4,13 +4,18 @@
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <linux/time.h>
+#include <linux/kernel_stat.h>
 #include <asm/cputime.h>
 
 static int uptime_proc_show(struct seq_file *m, void *v)
 {
 	struct timespec uptime;
 	struct timespec idle;
-	cputime_t idletime = cputime_add(init_task.utime, init_task.stime);
+	int i;
+	cputime_t idletime = cputime_zero;
+
+	for_each_possible_cpu(i)
+		idletime = cputime64_add(idletime, kstat_cpu(i).cpustat.idle);
 
 	do_posix_clock_monotonic_gettime(&uptime);
 	monotonic_to_bootbased(&uptime);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/