linux-kernel - 2.6.21-rc5-mm3 - cpuidle, acpi, and C-states

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200703310805.l2V85PA4004332@turing-police.cc.vt.edu>
Date:	Sat, 31 Mar 2007 04:05:25 -0400
From:	Valdis.Kletnieks@...edu
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Len Brown <len.brown@...el.com>
Cc:	linux-kernel@...r.kernel.org
Subject: 2.6.21-rc5-mm3 - cpuidle, acpi, and C-states

On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/

Somebody is confused (possibly me).  Running an x86_64 kernel, and I have:

% cat /proc/acpi/processor/CPU0/power
active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000 usec
states:
    C1:                  type[C1] promotion[--] demotion[--] latency[001] usage[00000003] duration[00000000000000000000]
    C2:                  type[C2] promotion[--] demotion[--] latency[001] usage[00166266] duration[00000000000000000000]
    C3:                  type[C3] promotion[--] demotion[--] latency[057] usage[02045938] duration[00000000000000000000]

Wow. Lots of zeros in that last column..

The 'duration' is output by this code in drivers/acpi/processor_idle.c that
thinks the value is an 'unsigned long long':

                seq_printf(seq, "latency[%03d] usage[%08d] duration[%020llu]\n",
                           pr->power.states[i].latency,
                           pr->power.states[i].usage,
                           (unsigned long long)pr->power.states[i].time);

However, over in /sys, we have non-zero values for the usage/time:

%  cat /sys/devices/system/cpu/cpu0/cpuidle/state?/time
0
110861364
-2091818383

That's because in drivers/cpuidle/sysfs.c, we have this code that thinks
a %d is suitable to output that number:

#define define_show_state_function(_name) static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) { \     
        return sprintf(buf, "%d\n", state->_name);\
}
...
define_one_state_ro(time, show_state_time);

But the negative number for state2/time indicates that *this* isn't right either....

Content of type "application/pgp-signature" skipped