| Message ID | 5082760.FgB9zHNfte@wuerfel (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: > The virtgpu driver prints the last_seq variable using the %ld or > %lu format string, which does not work correctly on all architectures > and causes this compiler warning on ARM: > > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] > snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); > ^ > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] > seq_printf(m, "fence %ld %lld\n", > ^ > > In order to avoid the warnings, this changes the format strings to %llu > and adds a cast to u64, which makes it work the same way everywhere. You have to wonder why atomic64_* functions do not use u64 types. If they're not reliant on manipulating 64-bit quantities, then what's the point of calling them atomic _64_.
On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote: > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: > > The virtgpu driver prints the last_seq variable using the %ld or > > %lu format string, which does not work correctly on all architectures > > and causes this compiler warning on ARM: > > > > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': > > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] > > snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); > > ^ > > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': > > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] > > seq_printf(m, "fence %ld %lld\n", > > ^ > > > > In order to avoid the warnings, this changes the format strings to %llu > > and adds a cast to u64, which makes it work the same way everywhere. > > You have to wonder why atomic64_* functions do not use u64 types. > If they're not reliant on manipulating 64-bit quantities, then what's > the point of calling them atomic _64_. I haven't checked all architectures, but I assume what happens is that 64-bit ones just #define atomic64_t atomic_long_t, so they don't have to provide three sets of functions. Arnd
On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote: > On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote: > > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: > > > The virtgpu driver prints the last_seq variable using the %ld or > > > %lu format string, which does not work correctly on all architectures > > > and causes this compiler warning on ARM: > > > > > > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': > > > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] > > > snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); > > > ^ > > > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': > > > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] > > > seq_printf(m, "fence %ld %lld\n", > > > ^ > > > > > > In order to avoid the warnings, this changes the format strings to %llu > > > and adds a cast to u64, which makes it work the same way everywhere. > > > > You have to wonder why atomic64_* functions do not use u64 types. > > If they're not reliant on manipulating 64-bit quantities, then what's > > the point of calling them atomic _64_. > > I haven't checked all architectures, but I assume what happens is that > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > to provide three sets of functions. scratch that, I just looked at all the architectures and found that it's just completely arbitrary, even within one architecture you get a mix of 'long' and 'long long', plus this gem from MIPS: static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) which truncates the result to 32 bit. Arnd
On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote: >> On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote: >> > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote: >> > > The virtgpu driver prints the last_seq variable using the %ld or >> > > %lu format string, which does not work correctly on all architectures >> > > and causes this compiler warning on ARM: >> > > >> > > drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': >> > > drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] >> > > snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); >> > > ^ >> > > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': >> > > drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] >> > > seq_printf(m, "fence %ld %lld\n", >> > > ^ >> > > >> > > In order to avoid the warnings, this changes the format strings to %llu >> > > and adds a cast to u64, which makes it work the same way everywhere. >> > >> > You have to wonder why atomic64_* functions do not use u64 types. >> > If they're not reliant on manipulating 64-bit quantities, then what's >> > the point of calling them atomic _64_. >> >> I haven't checked all architectures, but I assume what happens is that >> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have >> to provide three sets of functions. > > scratch that, I just looked at all the architectures and found that it's > just completely arbitrary, even within one architecture you get a mix > of 'long' and 'long long', plus this gem from MIPS: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Woops. See also my unanswered question in "atomic64 on 32-bit vs 64-bit (was: Re: Add virtio gpu driver.)", which is still valid: https://lkml.org/lkml/2015/6/28/18 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > I haven't checked all architectures, but I assume what happens is that > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > to provide three sets of functions. > > scratch that, I just looked at all the architectures and found that it's > just completely arbitrary, even within one architecture you get a mix > of 'long' and 'long long', plus this gem from MIPS: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Eh... The result is 0/1 so nothing is truncated. Alpha, MIPS, PARISC and PowerPC are using the same prototype and x86 only differs in the use of inline instead __inline__. And anyway, that function on MIPS is only built for CONFIG_64BIT. What's wrong on MIPS is the comment describing the function's return value which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move atomic_add_unless to generic code) and I've queued up a patch to fix that since a few days. I guess that was a cut and paste error from __atomic_add_unless which indeed does return the old value. Ralf
On Monday 19 October 2015 11:37:00 Ralf Baechle wrote: > On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > > > I haven't checked all architectures, but I assume what happens is that > > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > > to provide three sets of functions. > > > > scratch that, I just looked at all the architectures and found that it's > > just completely arbitrary, even within one architecture you get a mix > > of 'long' and 'long long', plus this gem from MIPS: > > > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > > > which truncates the result to 32 bit. > > Eh... The result is 0/1 so nothing is truncated. Alpha, MIPS, > PARISC and PowerPC are using the same prototype and x86 only differs > in the use of inline instead __inline__. And anyway, that function on > MIPS is only built for CONFIG_64BIT. Ah, got it. Sorry about that. > What's wrong on MIPS is the comment describing the function's return value > which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move > atomic_add_unless to generic code) and I've queued up a patch to fix that > since a few days. I guess that was a cut and paste error from > __atomic_add_unless which indeed does return the old value. Thanks! Arnd
On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote: > On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > > > which truncates the result to 32 bit. > > Woops. > > See also my unanswered question in "atomic64 on 32-bit vs 64-bit (was: > Re: Add virtio gpu driver.)", which is still valid: > https://lkml.org/lkml/2015/6/28/18 > Regarding your question of > Instead of sprinkling casts, is there any good reason why atomic64_read() > and atomic64_t aren't "long long" everywhere, cfr. u64? I assume the answer is that some (all?) 64-bit architectures intentionally return 'long' here, in order for atomic_long_read() to return 'long' on all architectures, given the definitions from include/asm-generic/atomic-long.h We would have to either change those, or we have to pick between atomic_long_* or atomic64_* to have a consistent return type. Arnd
On Mon, Oct 19, 2015 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote: >> On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) >> > >> > which truncates the result to 32 bit. >> >> Woops. >> >> See also my unanswered question in "atomic64 on 32-bit vs 64-bit (was: >> Re: Add virtio gpu driver.)", which is still valid: >> https://lkml.org/lkml/2015/6/28/18 >> > > Regarding your question of > >> Instead of sprinkling casts, is there any good reason why atomic64_read() >> and atomic64_t aren't "long long" everywhere, cfr. u64? > > > I assume the answer is that some (all?) 64-bit architectures intentionally > return 'long' here, in order for atomic_long_read() to return 'long' on > all architectures, given the definitions from > include/asm-generic/atomic-long.h > > We would have to either change those, or we have to pick between > atomic_long_* or atomic64_* to have a consistent return type. I guess the main reason is this comment in include/asm-generic/atomic-long.h, which I hadn't noticed before: * Casts for parameters are avoided for existing atomic functions in order to * avoid issues with cast-as-lval under gcc 4.x and other limitations that the * macros of a platform may have. Still, it's a pity, as printing atomic_64 is one more place where casts are needed in callers. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c b/drivers/gpu/drm/virtio/virtgpu_debugfs.c index db8b49101a8b..512263919282 100644 --- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c +++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c @@ -34,8 +34,8 @@ virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data) struct drm_info_node *node = (struct drm_info_node *) m->private; struct virtio_gpu_device *vgdev = node->minor->dev->dev_private; - seq_printf(m, "fence %ld %lld\n", - atomic64_read(&vgdev->fence_drv.last_seq), + seq_printf(m, "fence %llu %lld\n", + (u64)atomic64_read(&vgdev->fence_drv.last_seq), vgdev->fence_drv.sync_seq); return 0; } diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c b/drivers/gpu/drm/virtio/virtgpu_fence.c index 1da632631dac..67097c9ce9c1 100644 --- a/drivers/gpu/drm/virtio/virtgpu_fence.c +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c @@ -61,7 +61,7 @@ static void virtio_timeline_value_str(struct fence *f, char *str, int size) { struct virtio_gpu_fence *fence = to_virtio_fence(f); - snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); + snprintf(str, size, "%llu", (u64)atomic64_read(&fence->drv->last_seq)); } static const struct fence_ops virtio_fence_ops = {
The virtgpu driver prints the last_seq variable using the %ld or %lu format string, which does not work correctly on all architectures and causes this compiler warning on ARM: drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); ^ drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] seq_printf(m, "fence %ld %lld\n", ^ In order to avoid the warnings, this changes the format strings to %llu and adds a cast to u64, which makes it work the same way everywhere. Signed-off-by: Arnd Bergmann <arnd@arndb.de>