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 <[email protected]>
---
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 <[email protected]> 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 <[email protected]>
Acked-by: Marco Elver <[email protected]>
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 [email protected].
> 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 <[email protected]> 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 <[email protected]>
>
> Acked-by: Marco Elver <[email protected]>
>
> 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 [email protected].
> > 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 <[email protected]> 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 <[email protected]>
> >
> > Acked-by: Marco Elver <[email protected]>
> >
> > 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!