Messages in this thread | | | Date | Thu, 22 Dec 2011 10:55:04 +0100 | From | Martin Schwidefsky <> | Subject | Re: [resend PATCH for 3.2] procfs: do not confuse jiffies with cputime64_t |
| |
On Wed, 21 Dec 2011 11:59:19 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 21 Dec 2011 11:03:34 +0100 > Michal Hocko <mhocko@suse.cz> wrote: > > > Hmm, it seems that this bugfix (for 3.2) stalled. I guess that it is > > primarily because it is multiarch fix. > > I am sorry to bother you Andrew but could we push this through you, > > please? > > > > The full patch for reference: > > --- > > >From 1fca39b21f3b344c90c30d98db6dcdcdc6815797 Mon Sep 17 00:00:00 2001 > > From: Andreas Schwab <schwab@linux-m68k.org> > > Date: Mon, 12 Dec 2011 14:07:53 +0100 > > Subject: [PATCH] procfs: do not confuse jiffies with cputime64_t > > > > get_{idle,iowait}_time are supposed to return cputime64_t values, not > > jiffies. Add usecs_to_cputime64 for this. > > This makes a huge mess when mixed with Martin's "cputime: add sparse > checking and cleanup" in linux-next. I think I got it fixed up but it > needs careful checking - I don't _think_ I needed to add more __force > thingies. The version against today's linux-next is below.
As long as cputime_t and cputime64_t have the same base type my version of sparse does not warn if you mix the two types.
> (I did party tricks with this so I could carry the against-mainline and > against-next versions in the same tree). > > > Also, in include/asm-generic/cputime.h we have: > > #define usecs_to_cputime64(__msecs) nsecs_to_jiffies64((__msecs) * 1000) > > But it would be neater to have used nsecs_to_cputime64(), surely.
It would be cleaner to do an explicit cast to cputime64_t for all of the usecs_to_cputime64() definitions.
-- blue skies, Martin.
"Reality continues to ruin my life." - Calvin.
| |