cycles_t has a different type across architectures: unsigned int, unsinged long, or unsigned long long. Depending on architecture this will generate this warning: kernel/kcsan/debugfs.c: In function ‘microbenchmark’: ./include/linux/kern_levels.h:5:25: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘cycles_t’ {aka ‘long unsigned int’} [-Wformat=] To avoid this simple change the type of cycle to u64 in microbenchmark(), since u64 is of type unsigned long long for all architectures. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> --- kernel/kcsan/debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcsan/debugfs.c b/kernel/kcsan/debugfs.c index e65de172ccf7..1d1d1b0e4248 100644 --- a/kernel/kcsan/debugfs.c +++ b/kernel/kcsan/debugfs.c @@ -64,7 +64,7 @@ static noinline void microbenchmark(unsigned long iters) { const struct kcsan_ctx ctx_save = current->kcsan_ctx; const bool was_enabled = READ_ONCE(kcsan_enabled); - cycles_t cycles; + u64 cycles; /* We may have been called from an atomic region; reset context. */ memset(¤t->kcsan_ctx, 0, sizeof(current->kcsan_ctx)); -- 2.25.1
+Cc: Paul On Thu, 29 Jul 2021 at 16:28, Heiko Carstens <hca@linux.ibm.com> wrote: > > cycles_t has a different type across architectures: unsigned int, > unsinged long, or unsigned long long. Depending on architecture this > will generate this warning: > > kernel/kcsan/debugfs.c: In function ‘microbenchmark’: > ./include/linux/kern_levels.h:5:25: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘cycles_t’ {aka ‘long unsigned int’} [-Wformat=] > > To avoid this simple change the type of cycle to u64 in > microbenchmark(), since u64 is of type unsigned long long for all > architectures. > > Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Marco Elver <elver@google.com> Do you have a series adding KCSAN support for s390, i.e. would you like to keep it together with those changes? Otherwise this would go the usual route through Paul's -rcu tree. Thanks, -- Marco > --- > kernel/kcsan/debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kcsan/debugfs.c b/kernel/kcsan/debugfs.c > index e65de172ccf7..1d1d1b0e4248 100644 > --- a/kernel/kcsan/debugfs.c > +++ b/kernel/kcsan/debugfs.c > @@ -64,7 +64,7 @@ static noinline void microbenchmark(unsigned long iters) > { > const struct kcsan_ctx ctx_save = current->kcsan_ctx; > const bool was_enabled = READ_ONCE(kcsan_enabled); > - cycles_t cycles; > + u64 cycles; > > /* We may have been called from an atomic region; reset context. */ > memset(¤t->kcsan_ctx, 0, sizeof(current->kcsan_ctx)); > -- > 2.25.1 > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210729142811.1309391-1-hca%40linux.ibm.com.
On Thu, Jul 29, 2021 at 04:53:10PM +0200, Marco Elver wrote: > +Cc: Paul > > On Thu, 29 Jul 2021 at 16:28, Heiko Carstens <hca@linux.ibm.com> wrote: > > > > cycles_t has a different type across architectures: unsigned int, > > unsinged long, or unsigned long long. Depending on architecture this > > will generate this warning: > > > > kernel/kcsan/debugfs.c: In function ‘microbenchmark’: > > ./include/linux/kern_levels.h:5:25: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘cycles_t’ {aka ‘long unsigned int’} [-Wformat=] > > > > To avoid this simple change the type of cycle to u64 in > > microbenchmark(), since u64 is of type unsigned long long for all > > architectures. > > > > Signed-off-by: Heiko Carstens <hca@linux.ibm.com> > > Acked-by: Marco Elver <elver@google.com> > > Do you have a series adding KCSAN support for s390, i.e. would you > like to keep it together with those changes? > > Otherwise this would go the usual route through Paul's -rcu tree. Either way, please let me know! Thanx, Paul > Thanks, > -- Marco > > > --- > > kernel/kcsan/debugfs.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/kcsan/debugfs.c b/kernel/kcsan/debugfs.c > > index e65de172ccf7..1d1d1b0e4248 100644 > > --- a/kernel/kcsan/debugfs.c > > +++ b/kernel/kcsan/debugfs.c > > @@ -64,7 +64,7 @@ static noinline void microbenchmark(unsigned long iters) > > { > > const struct kcsan_ctx ctx_save = current->kcsan_ctx; > > const bool was_enabled = READ_ONCE(kcsan_enabled); > > - cycles_t cycles; > > + u64 cycles; > > > > /* We may have been called from an atomic region; reset context. */ > > memset(¤t->kcsan_ctx, 0, sizeof(current->kcsan_ctx)); > > -- > > 2.25.1 > > > > -- > > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210729142811.1309391-1-hca%40linux.ibm.com.
On Thu, Jul 29, 2021 at 08:58:34AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 29, 2021 at 04:53:10PM +0200, Marco Elver wrote:
> > +Cc: Paul
> >
> > On Thu, 29 Jul 2021 at 16:28, Heiko Carstens <hca@linux.ibm.com> wrote:
> > >
> > > cycles_t has a different type across architectures: unsigned int,
> > > unsinged long, or unsigned long long. Depending on architecture this
> > > will generate this warning:
> > >
> > > kernel/kcsan/debugfs.c: In function ‘microbenchmark’:
> > > ./include/linux/kern_levels.h:5:25: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘cycles_t’ {aka ‘long unsigned int’} [-Wformat=]
> > >
> > > To avoid this simple change the type of cycle to u64 in
> > > microbenchmark(), since u64 is of type unsigned long long for all
> > > architectures.
> > >
> > > Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> >
> > Acked-by: Marco Elver <elver@google.com>
> >
> > Do you have a series adding KCSAN support for s390, i.e. would you
> > like to keep it together with those changes?
> >
> > Otherwise this would go the usual route through Paul's -rcu tree.
>
> Either way, please let me know!
We will enable KCSAN support for s390 with the next merge window, so
I'll queue this patch also on the s390 tree.
Thanks!