sched: Fix print format for u64
PATCH v2 1/1 sched: Fix print format for u64
From: Fabio Estevam <[email protected]>
commit c566e8e9 (sched: Aggregate total task_group load) introduced the following build warning:
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Wformat] kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'u64' [-Wformat]
Use %llu format to print a u64 value as per Documentation/printk-formats.txt.
---
Changes since v1:
- Use llu instead of lld
kernel/sched/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/debug.c +1 -1
@@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq->runnable_load_avg);SEQ_printf (m," .%-30s: %lld\n" ,"blocked_load_avg" , cfs_rq->blocked_load_avg); -SEQ_printf (m," .%-30s: %ld\n" ,"tg_load_avg" , +SEQ_printf (m," .%-30s: %llu\n" ,"tg_load_avg" ,atomic64_read (&cfs_rq->tg->load_avg));SEQ_printf (m," .%-30s: %lld\n" ,"tg_load_contrib" , cfs_rq->tg_load_contrib);
Signature · 1 line
1.7.9.5
Hi Ingo,
Quoted 11 lines · Fabio Estevam
From: Fabio Estevam <[email protected]>
commit
c566e8e9(sched: Aggregate totaltask_groupload) introduced the following build warning:
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Wformat]kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'u64' [-Wformat]Use %llu format to print a u64 value as per
Documentation/printk-formats.txt.Signed-off-by Fabio Estevam <[email protected]>
Does this one look good?
Regards,
Fabio Estevam
Quoted 8 lines · Fabio Estevam
Hi Ingo,
Quoted 5 lines · Fabio Estevam
From: Fabio Estevam <[email protected]>
commit
c566e8e9(sched: Aggregate totaltask_groupload) introduced the following build warning:
Quoted 8 lines
Quoted 6 lines
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Wformat]kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'u64' [-Wformat]Use %llu format to print a u64 value as per
Documentation/printk-formats.txt.Signed-off-by Fabio Estevam <[email protected]>Does this one look good?
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Thanks,
Ingo
Quoted 2 lines · Ingo Molnar
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Yes, just confirmed that this patch is warning-free on both 64-bit and 32-bit machines.
Regards,
Fabio Estevam
Quoted 7 lines · Fabio Estevam
Quoted 2 lines · Ingo Molnar
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Yes, just confirmed that this patch is warning-free on both 64-bit and 32-bit machines.
Apparently it's not all good, see the warning attached below.
Thanks,
Ingo
----- Forwarded message from kbuild test robot <[email protected]> -----
Date: Fri, 25 Jan 2013 14:02:05 +0800
From: kbuild test robot <[email protected]>
To: Fabio Estevam <[email protected]>
Cc: Ingo Molnar <[email protected]>
Subject: [next:akpm 188/817] kernel/sched/debug.c:225:2: warning: format '%llu' expects argument
of type 'long long unsigned int', but argument 4 has type 'long int'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm head: 5d2ee7d8b03bfe3b90325d736d8e544d0394efa7 commit: 2d58000fd2020255af63ee92c8d0ef615f6c4ade [188/817] sched: Fix print format for u64 config: make ARCH=x86_64 allmodconfig
All warnings:
kernel/sched/debug.c: In function 'print_cfs_rq':
Quoted 2 lines
Quoted 2 lines
kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long int' [-Wformat]kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'long int' [-Wformat]
vim +225 kernel/sched/debug.c
209 spread = max_vruntime - MIN_vruntime;
210 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread",
211 SPLIT_NS(spread));
212 spread0 = min_vruntime - rq0_min_vruntime;
213 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread0",
214 SPLIT_NS(spread0));
215 SEQ_printf(m, " .%-30s: %d\n", "nr_spread_over",
216 cfs_rq->nr_spread_over);
217 SEQ_printf(m, " .%-30s: %d\n", "nr_running", cfs_rq->nr_running);
218 SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight);
219 #ifdef CONFIG_FAIR_GROUP_SCHED
220 #ifdef CONFIG_SMP
221 SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg",
222 cfs_rq->runnable_load_avg);
223 SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg",
224 cfs_rq->blocked_load_avg);
Quoted 1 line
225 SEQ_printf(m, " .%-30s: %llu\n", "
tg_load_avg",
226 atomic64_read(&cfs_rq->tg->load_avg));
227 SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib",
228 cfs_rq->tg_load_contrib);
229 SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib",
230 cfs_rq->tg_runnable_contrib);
231 SEQ_printf(m, " .%-30s: %d\n", "tg->runnable_avg",
232 atomic_read(&cfs_rq->tg->runnable_avg));
233 #endif
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
----- End forwarded message -----
Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Fabio Estevam
On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar <[email protected]> wrote:
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Yes, just confirmed that this patch is warning-free on both 64-bit and 32-bit machines.
Apparently it's not all good, see the warning attached below.
Yeah this patch is broken; this is not properly fixable as is without #ifdefs (or fixing the insanity that is atomic64_read).
Specifically:
On some architectures (e.g. x86_64) atomic64_read is typed long On some others (e.g. x86-32) it's typed long long
On yet others (e.g. arm) it's typed u64
I think the easiest way to fix it would be instead to promote the read into a local u64 and print that.
Quoted 59 lines
Thanks,
Ingo
----- Forwarded message from kbuild test robot <[email protected]> -----
Date: Fri, 25 Jan 2013 14:02:05 +0800
From: kbuild test robot <[email protected]>
To: Fabio Estevam <[email protected]>
Cc: Ingo Molnar <[email protected]>
Subject: [next:akpm 188/817]kernel/sched/debug.c:225:2: warning: format '%llu' expects argument
of type 'long long unsigned int', but argument 4 has type 'long int'tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm head: 5d2ee7d8b03bfe3b90325d736d8e544d0394efa7 commit: 2d58000fd2020255af63ee92c8d0ef615f6c4ade [188/817] sched: Fix print format for u64 config: make ARCH=x86_64 allmodconfigAll warnings:
kernel/sched/debug.c: In function 'print_cfs_rq':Quoted 2 lines
Quoted 2 lines
kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long int' [-Wformat]kernel/sched/debug.c:225:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'long int' [-Wformat]vim +225
kernel/sched/debug.c209 spread = max_vruntime - MIN_vruntime; 210 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread", 211 SPLIT_NS(spread)); 212 spread0 = min_vruntime - rq0_min_vruntime; 213 SEQ_printf(m, " .%-30s: %Ld.%06ld\n", "spread0", 214 SPLIT_NS(spread0)); 215 SEQ_printf(m, " .%-30s: %d\n", "nr_spread_over", 216 cfs_rq->nr_spread_over); 217 SEQ_printf(m, " .%-30s: %d\n", "nr_running", cfs_rq->nr_running); 218 SEQ_printf(m, " .%-30s: %ld\n", "load", cfs_rq->load.weight); 219 #ifdef CONFIG_FAIR_GROUP_SCHED 220 #ifdef CONFIG_SMP 221 SEQ_printf(m, " .%-30s: %lld\n", "runnable_load_avg", 222 cfs_rq->runnable_load_avg); 223 SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", 224 cfs_rq->blocked_load_avg);Quoted 1 line
225 SEQ_printf(m, " .%-30s: %llu\n", "
tg_load_avg",226 atomic64_read(&cfs_rq->tg->load_avg)); 227 SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", 228 cfs_rq->tg_load_contrib); 229 SEQ_printf(m, " .%-30s: %d\n", "tg_runnable_contrib", 230 cfs_rq->tg_runnable_contrib); 231 SEQ_printf(m, " .%-30s: %d\n", "tg->runnable_avg", 232 atomic_read(&cfs_rq->tg->runnable_avg)); 233 #endif---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation----- End forwarded message -----
Quoted 14 lines · Paul Turner
Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Fabio Estevam
On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar <[email protected]> wrote:
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Yes, just confirmed that this patch is warning-free on both 64-bit and 32-bit machines.
Apparently it's not all good, see the warning attached below.
Quoted 8 lines
Yeah this patch is broken; this is not properly fixable as is without #ifdefs (or fixing the insanity that is
atomic64_read).Specifically:
On some architectures (e.g.
x86_64)atomic64_readis typed long On some others (e.g. x86-32) it's typed long long
On yet others (e.g. arm) it's typed u64
Hm, cannot we type atomic64_read() to u64 on x86-64 as well, and fix other architectures? How widespread is this problem, have you checked that perhaps?
I'm all for clean, consistent types instead of #ifdef or temporary variable uglies.
Thanks,
Ingo
Quoted 22 lines · Ingo Molnar
Quoted 19 lines · Paul Turner
Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Fabio Estevam
On Thu, Jan 24, 2013 at 12:19 PM, Ingo Molnar <[email protected]> wrote:
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I suppose - is this patch warning-free both on 64-bit and 32-bit systems?
Yes, just confirmed that this patch is warning-free on both 64-bit and 32-bit machines.
Apparently it's not all good, see the warning attached below.
Yeah this patch is broken; this is not properly fixable as is without #ifdefs (or fixing the insanity that is
atomic64_read).Specifically:
Quoted 7 lines
Quoted 3 lines
On some architectures (e.g.
x86_64)atomic64_readis typed long On some others (e.g. x86-32) it's typed long long
On yet others (e.g. arm) it's typed u64Hm, cannot we type
atomic64_read()to u64 on x86-64 as well, and fix other architectures? How widespread is this problem, have you checked that perhaps?
I have not looked at how much fall-out this would cause. Ideally someone with a cross-compiing tool-chain or from the specific arches could take ownership of cleaning up their atomic64 implementations to avoid introducing more build pain.
Theoretically, given the list above x86-64 is actually the outlier in assuming that it's just a long type; perhaps we can gain sufficient mileage by changing only the x86-64 implementation; which is much easier for us to validate :-).
Quoted 3 lines
I'm all for clean, consistent types instead of #ifdef or temporary variable uglies.
Yes I agree this would be the best solution.
Quoted 4 lines
Thanks,
Ingo
Commit-ID: 2d58000fd2020255af63ee92c8d0ef615f6c4ade Gitweb: http://git.kernel.org/tip/2d58000fd2020255af63ee92c8d0ef615f6c4ade Author: Fabio Estevam <[email protected]> AuthorDate: Tue, 25 Dec 2012 09:24:40 -0200 Committer: Ingo Molnar <[email protected]> CommitDate: Thu, 24 Jan 2013 15:50:08 +0100
sched: Fix print format for u64
commit c566e8e9 ("sched: Aggregate total task_group load") introduced the following build warnings:
kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Wformat] kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'u64' [-Wformat]
Use %llu format to print a u64 value as perDocumentation/printk-formats.txt.
--- kernel/sched/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/debug.c +1 -1
@@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq->runnable_load_avg);SEQ_printf (m," .%-30s: %lld\n" ,"blocked_load_avg" , cfs_rq->blocked_load_avg); -SEQ_printf (m," .%-30s: %ld\n" ,"tg_load_avg" , +SEQ_printf (m," .%-30s: %llu\n" ,"tg_load_avg" ,atomic64_read (&cfs_rq->tg->load_avg));SEQ_printf (m," .%-30s: %lld\n" ,"tg_load_contrib" , cfs_rq->tg_load_contrib);