All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] locking/atomic: atomic64: remove unusable atomics
@ 2021-11-26 11:59 Mark Rutland
  2021-11-28  8:49 ` Boqun Feng
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Mark Rutland @ 2021-11-26 11:59 UTC (permalink / raw)
  To: linux-kernel, Peter Zijlstra; +Cc: arnd, boqun.feng, lkp, mark.rutland, will

The generic atomic64 implementation provides:

* atomic64_and_return()
* atomic64_or_return()
* atomic64_xor_return()

... but none of these exist in the standard atomic64 API as described by
scripts/atomic/atomics.tbl, and none of these have prototypes exposed by
<asm-generic/atomic64.h>.

The lkp kernel test robot noted this results in warnings when building with
W=1:

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_and_return' [-Wmissing-prototypes]

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_or_return' [-Wmissing-prototypes]

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_xor_return' [-Wmissing-prototypes]

This appears to have been a thinko in commit:

  28aa2bda2211f432 ("locking/atomic: Implement atomic{,64,_long}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()")

... where we grouped add/sub separately from and/ox/xor, so that we could avoid
implementing _return forms for the latter group, but forgot to remove
ATOMIC64_OP_RETURN() for that group.

This doesn't cause any functional problem, but it's pointless to build code
which cannot be used. Remove the unusable code. This does not affect add/sub,
for which _return forms will still be built.

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202111120712.RtQHZohY-lkp@intel.com
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
---
 lib/atomic64.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/atomic64.c b/lib/atomic64.c
index 3df653994177..caf895789a1e 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -118,7 +118,6 @@ ATOMIC64_OPS(sub, -=)
 #undef ATOMIC64_OPS
 #define ATOMIC64_OPS(op, c_op)						\
 	ATOMIC64_OP(op, c_op)						\
-	ATOMIC64_OP_RETURN(op, c_op)					\
 	ATOMIC64_FETCH_OP(op, c_op)
 
 ATOMIC64_OPS(and, &=)
@@ -127,7 +126,6 @@ ATOMIC64_OPS(xor, ^=)
 
 #undef ATOMIC64_OPS
 #undef ATOMIC64_FETCH_OP
-#undef ATOMIC64_OP_RETURN
 #undef ATOMIC64_OP
 
 s64 generic_atomic64_dec_if_positive(atomic64_t *v)
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] locking/atomic: atomic64: remove unusable atomics
  2021-11-26 11:59 [PATCH] locking/atomic: atomic64: remove unusable atomics Mark Rutland
@ 2021-11-28  8:49 ` Boqun Feng
  2021-12-08 18:20 ` Mark Rutland
  2021-12-13 10:03 ` [tip: locking/core] locking/atomic: atomic64: Remove unusable atomic ops tip-bot2 for Mark Rutland
  2 siblings, 0 replies; 5+ messages in thread
From: Boqun Feng @ 2021-11-28  8:49 UTC (permalink / raw)
  To: Mark Rutland; +Cc: linux-kernel, Peter Zijlstra, arnd, lkp, will

On Fri, Nov 26, 2021 at 11:59:23AM +0000, Mark Rutland wrote:
> The generic atomic64 implementation provides:
> 
> * atomic64_and_return()
> * atomic64_or_return()
> * atomic64_xor_return()
> 
> ... but none of these exist in the standard atomic64 API as described by
> scripts/atomic/atomics.tbl, and none of these have prototypes exposed by
> <asm-generic/atomic64.h>.
> 
> The lkp kernel test robot noted this results in warnings when building with
> W=1:
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_and_return' [-Wmissing-prototypes]
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_or_return' [-Wmissing-prototypes]
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_xor_return' [-Wmissing-prototypes]
> 
> This appears to have been a thinko in commit:
> 
>   28aa2bda2211f432 ("locking/atomic: Implement atomic{,64,_long}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()")
> 
> ... where we grouped add/sub separately from and/ox/xor, so that we could avoid
> implementing _return forms for the latter group, but forgot to remove
> ATOMIC64_OP_RETURN() for that group.
> 
> This doesn't cause any functional problem, but it's pointless to build code
> which cannot be used. Remove the unusable code. This does not affect add/sub,
> for which _return forms will still be built.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/r/202111120712.RtQHZohY-lkp@intel.com
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>

FWIW

Acked-by: Boqun Feng <boqun.feng@gmail.com>

Regards,
Boqun

> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Will Deacon <will@kernel.org>
> ---
>  lib/atomic64.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/atomic64.c b/lib/atomic64.c
> index 3df653994177..caf895789a1e 100644
> --- a/lib/atomic64.c
> +++ b/lib/atomic64.c
> @@ -118,7 +118,6 @@ ATOMIC64_OPS(sub, -=)
>  #undef ATOMIC64_OPS
>  #define ATOMIC64_OPS(op, c_op)						\
>  	ATOMIC64_OP(op, c_op)						\
> -	ATOMIC64_OP_RETURN(op, c_op)					\
>  	ATOMIC64_FETCH_OP(op, c_op)
>  
>  ATOMIC64_OPS(and, &=)
> @@ -127,7 +126,6 @@ ATOMIC64_OPS(xor, ^=)
>  
>  #undef ATOMIC64_OPS
>  #undef ATOMIC64_FETCH_OP
> -#undef ATOMIC64_OP_RETURN
>  #undef ATOMIC64_OP
>  
>  s64 generic_atomic64_dec_if_positive(atomic64_t *v)
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] locking/atomic: atomic64: remove unusable atomics
  2021-11-26 11:59 [PATCH] locking/atomic: atomic64: remove unusable atomics Mark Rutland
  2021-11-28  8:49 ` Boqun Feng
@ 2021-12-08 18:20 ` Mark Rutland
  2021-12-08 18:44   ` Peter Zijlstra
  2021-12-13 10:03 ` [tip: locking/core] locking/atomic: atomic64: Remove unusable atomic ops tip-bot2 for Mark Rutland
  2 siblings, 1 reply; 5+ messages in thread
From: Mark Rutland @ 2021-12-08 18:20 UTC (permalink / raw)
  To: linux-kernel, Peter Zijlstra; +Cc: arnd, boqun.feng, lkp, will

Peter, did you have any thoughts on this, or would you be happy to pick it as a
cleanup?

If there's anything on your queue that I can help to get out of the way, please
let me know!

Thanks,
Mark.

On Fri, Nov 26, 2021 at 11:59:23AM +0000, Mark Rutland wrote:
> The generic atomic64 implementation provides:
> 
> * atomic64_and_return()
> * atomic64_or_return()
> * atomic64_xor_return()
> 
> ... but none of these exist in the standard atomic64 API as described by
> scripts/atomic/atomics.tbl, and none of these have prototypes exposed by
> <asm-generic/atomic64.h>.
> 
> The lkp kernel test robot noted this results in warnings when building with
> W=1:
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_and_return' [-Wmissing-prototypes]
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_or_return' [-Wmissing-prototypes]
> 
>   lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_xor_return' [-Wmissing-prototypes]
> 
> This appears to have been a thinko in commit:
> 
>   28aa2bda2211f432 ("locking/atomic: Implement atomic{,64,_long}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()")
> 
> ... where we grouped add/sub separately from and/ox/xor, so that we could avoid
> implementing _return forms for the latter group, but forgot to remove
> ATOMIC64_OP_RETURN() for that group.
> 
> This doesn't cause any functional problem, but it's pointless to build code
> which cannot be used. Remove the unusable code. This does not affect add/sub,
> for which _return forms will still be built.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/r/202111120712.RtQHZohY-lkp@intel.com
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Will Deacon <will@kernel.org>
> ---
>  lib/atomic64.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/atomic64.c b/lib/atomic64.c
> index 3df653994177..caf895789a1e 100644
> --- a/lib/atomic64.c
> +++ b/lib/atomic64.c
> @@ -118,7 +118,6 @@ ATOMIC64_OPS(sub, -=)
>  #undef ATOMIC64_OPS
>  #define ATOMIC64_OPS(op, c_op)						\
>  	ATOMIC64_OP(op, c_op)						\
> -	ATOMIC64_OP_RETURN(op, c_op)					\
>  	ATOMIC64_FETCH_OP(op, c_op)
>  
>  ATOMIC64_OPS(and, &=)
> @@ -127,7 +126,6 @@ ATOMIC64_OPS(xor, ^=)
>  
>  #undef ATOMIC64_OPS
>  #undef ATOMIC64_FETCH_OP
> -#undef ATOMIC64_OP_RETURN
>  #undef ATOMIC64_OP
>  
>  s64 generic_atomic64_dec_if_positive(atomic64_t *v)
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] locking/atomic: atomic64: remove unusable atomics
  2021-12-08 18:20 ` Mark Rutland
@ 2021-12-08 18:44   ` Peter Zijlstra
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Zijlstra @ 2021-12-08 18:44 UTC (permalink / raw)
  To: Mark Rutland; +Cc: linux-kernel, arnd, boqun.feng, lkp, will

On Wed, Dec 08, 2021 at 06:20:47PM +0000, Mark Rutland wrote:
> Peter, did you have any thoughts on this, or would you be happy to pick it as a
> cleanup?
> 
> If there's anything on your queue that I can help to get out of the way, please
> let me know!
> 

I think it's good, it just got lost in this trainwreck of an inbox. I'll
try not to loose it again :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [tip: locking/core] locking/atomic: atomic64: Remove unusable atomic ops
  2021-11-26 11:59 [PATCH] locking/atomic: atomic64: remove unusable atomics Mark Rutland
  2021-11-28  8:49 ` Boqun Feng
  2021-12-08 18:20 ` Mark Rutland
@ 2021-12-13 10:03 ` tip-bot2 for Mark Rutland
  2 siblings, 0 replies; 5+ messages in thread
From: tip-bot2 for Mark Rutland @ 2021-12-13 10:03 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: kernel test robot, Mark Rutland, Peter Zijlstra (Intel),
	Boqun Feng, x86, linux-kernel

The following commit has been merged into the locking/core branch of tip:

Commit-ID:     5fb6e8cf53b005d287d4c2d137a415ff7d025a81
Gitweb:        https://git.kernel.org/tip/5fb6e8cf53b005d287d4c2d137a415ff7d025a81
Author:        Mark Rutland <mark.rutland@arm.com>
AuthorDate:    Fri, 26 Nov 2021 11:59:23 
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Mon, 13 Dec 2021 10:56:09 +01:00

locking/atomic: atomic64: Remove unusable atomic ops

The generic atomic64 implementation provides:

* atomic64_and_return()
* atomic64_or_return()
* atomic64_xor_return()

... but none of these exist in the standard atomic64 API as described by
scripts/atomic/atomics.tbl, and none of these have prototypes exposed by
<asm-generic/atomic64.h>.

The lkp kernel test robot noted this results in warnings when building with
W=1:

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_and_return' [-Wmissing-prototypes]

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_or_return' [-Wmissing-prototypes]

  lib/atomic64.c:82:5: warning: no previous prototype for 'generic_atomic64_xor_return' [-Wmissing-prototypes]

This appears to have been a thinko in commit:

  28aa2bda2211f432 ("locking/atomic: Implement atomic{,64,_long}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()")

... where we grouped add/sub separately from and/ox/xor, so that we could avoid
implementing _return forms for the latter group, but forgot to remove
ATOMIC64_OP_RETURN() for that group.

This doesn't cause any functional problem, but it's pointless to build code
which cannot be used. Remove the unusable code. This does not affect add/sub,
for which _return forms will still be built.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20211126115923.41489-1-mark.rutland@arm.com
---
 lib/atomic64.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/atomic64.c b/lib/atomic64.c
index 3df6539..caf8957 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -118,7 +118,6 @@ ATOMIC64_OPS(sub, -=)
 #undef ATOMIC64_OPS
 #define ATOMIC64_OPS(op, c_op)						\
 	ATOMIC64_OP(op, c_op)						\
-	ATOMIC64_OP_RETURN(op, c_op)					\
 	ATOMIC64_FETCH_OP(op, c_op)
 
 ATOMIC64_OPS(and, &=)
@@ -127,7 +126,6 @@ ATOMIC64_OPS(xor, ^=)
 
 #undef ATOMIC64_OPS
 #undef ATOMIC64_FETCH_OP
-#undef ATOMIC64_OP_RETURN
 #undef ATOMIC64_OP
 
 s64 generic_atomic64_dec_if_positive(atomic64_t *v)

^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-12-13 10:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-26 11:59 [PATCH] locking/atomic: atomic64: remove unusable atomics Mark Rutland
2021-11-28  8:49 ` Boqun Feng
2021-12-08 18:20 ` Mark Rutland
2021-12-08 18:44   ` Peter Zijlstra
2021-12-13 10:03 ` [tip: locking/core] locking/atomic: atomic64: Remove unusable atomic ops tip-bot2 for Mark Rutland

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.