Linus Walleij pointed out that a new comer might be confused about the
difference between set_bit() and __set_bit(). Add a comment explaining
the difference.
Link: https://lore.kernel.org/all/CACRpkdZFPG_YLici-BmYfk9HZ36f4WavCN3JNotkk8cPgCODCg@mail.gmail.com/
Signed-off-by: Dan Carpenter <[email protected]>
---
v2: re-word the comment, put it right next to the macros and add a blank
line in front of the test_bit() macros so it's not mixed in with the
non-atomic macros
include/linux/bitops.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 46d4bdc634c0..ba35bbf07798 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -47,12 +47,17 @@ extern unsigned long __sw_hweight64(__u64 w);
__builtin_constant_p(*(const unsigned long *)(addr))) ? \
const##op(nr, addr) : op(nr, addr))
+/*
+ * The following macros are non-atomic versions of their non-underscored
+ * counterparts.
+ */
#define __set_bit(nr, addr) bitop(___set_bit, nr, addr)
#define __clear_bit(nr, addr) bitop(___clear_bit, nr, addr)
#define __change_bit(nr, addr) bitop(___change_bit, nr, addr)
#define __test_and_set_bit(nr, addr) bitop(___test_and_set_bit, nr, addr)
#define __test_and_clear_bit(nr, addr) bitop(___test_and_clear_bit, nr, addr)
#define __test_and_change_bit(nr, addr) bitop(___test_and_change_bit, nr, addr)
+
#define test_bit(nr, addr) bitop(_test_bit, nr, addr)
#define test_bit_acquire(nr, addr) bitop(_test_bit_acquire, nr, addr)
--
2.39.2
On Tue, Jun 11, 2024 at 2:38 PM Dan Carpenter <[email protected]> wrote:
> Linus Walleij pointed out that a new comer might be confused about the
> difference between set_bit() and __set_bit(). Add a comment explaining
> the difference.
>
> Link: https://lore.kernel.org/all/CACRpkdZFPG_YLici-BmYfk9HZ36f4WavCN3JNotkk8cPgCODCg@mail.gmail.com/
> Signed-off-by: Dan Carpenter <[email protected]>
> ---
> v2: re-word the comment, put it right next to the macros and add a blank
> line in front of the test_bit() macros so it's not mixed in with the
> non-atomic macros
Thanks Dan! This makes the kernel a better place.
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
On Tue, Jun 11, 2024 at 03:38:12PM +0300, Dan Carpenter wrote:
> Linus Walleij pointed out that a new comer might be confused about the
> difference between set_bit() and __set_bit(). Add a comment explaining
> the difference.
>
> Link: https://lore.kernel.org/all/CACRpkdZFPG_YLici-BmYfk9HZ36f4WavCN3JNotkk8cPgCODCg@mail.gmail.com/
> Signed-off-by: Dan Carpenter <[email protected]>
> ---
> v2: re-word the comment, put it right next to the macros and add a blank
> line in front of the test_bit() macros so it's not mixed in with the
> non-atomic macros
>
> include/linux/bitops.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index 46d4bdc634c0..ba35bbf07798 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -47,12 +47,17 @@ extern unsigned long __sw_hweight64(__u64 w);
> __builtin_constant_p(*(const unsigned long *)(addr))) ? \
> const##op(nr, addr) : op(nr, addr))
>
> +/*
> + * The following macros are non-atomic versions of their non-underscored
> + * counterparts.
> + */
> #define __set_bit(nr, addr) bitop(___set_bit, nr, addr)
> #define __clear_bit(nr, addr) bitop(___clear_bit, nr, addr)
> #define __change_bit(nr, addr) bitop(___change_bit, nr, addr)
> #define __test_and_set_bit(nr, addr) bitop(___test_and_set_bit, nr, addr)
> #define __test_and_clear_bit(nr, addr) bitop(___test_and_clear_bit, nr, addr)
> #define __test_and_change_bit(nr, addr) bitop(___test_and_change_bit, nr, addr)
> +
> #define test_bit(nr, addr) bitop(_test_bit, nr, addr)
> #define test_bit_acquire(nr, addr) bitop(_test_bit_acquire, nr, addr)
>
> --
> 2.39.2
Applied in bitmap-for-next. For the next time please make the subject
prefix [PATCH v2], then [PATCH v3], and so on. The motivation is to
avoid sending emails with identical subjects as some (not mine) email
clients consider one as a reply to another.
Thanks,
Yury
On Tue, Jun 11, 2024 at 01:42:09PM -0700, Yury Norov wrote:
>
> Applied in bitmap-for-next. For the next time please make the subject
> prefix [PATCH v2], then [PATCH v3], and so on. The motivation is to
> avoid sending emails with identical subjects as some (not mine) email
> clients consider one as a reply to another.
Oops. Sorry. I meant to do it that way, but I messed up. Thanks!
regards,
dan carpenter