On 8/4/20 10:25 AM, Emmanuel Vadot wrote:
Author: manu
Date: Tue Aug 4 15:25:22 2020
New Revision: 363842
URL: https://svnweb.freebsd.org/changeset/base/363842
Log:
linuxkpi: Add clear_bit_unlock
This calls clear_bit and adds a memory barrier.
Sponsored by: The FreeBSD Foundation
Reviewed by: hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25943
Modified:
head/sys/compat/linuxkpi/common/include/linux/bitops.h
Modified: head/sys/compat/linuxkpi/common/include/linux/bitops.h
==============================================================================
--- head/sys/compat/linuxkpi/common/include/linux/bitops.h Tue Aug 4
15:00:02 2020 (r363841)
+++ head/sys/compat/linuxkpi/common/include/linux/bitops.h Tue Aug 4
15:25:22 2020 (r363842)
@@ -275,6 +275,13 @@ find_next_zero_bit(const unsigned long *addr, unsigned
#define test_bit(i, a)
\
!!(READ_ONCE(((volatile const unsigned long *)(a))[BIT_WORD(i)]) &
BIT_MASK(i))
+static inline void
+clear_bit_unlock(long bit, volatile unsigned long *var)
+{
+ clear_bit(bit, var);
+ wmb();
For an unlock operation, the memory barrier should come before the
clear_bit() call, not after. See, for example, the alpha implementation
in Linux. Also, the correct "spelling" for this memory barrier in
FreeBSD would be atomic_thread_fence_rel(). See, for example, the
comment at the top of sys/amd64/include/atomic.h.
+}
+
static inline int
test_and_clear_bit(long bit, volatile unsigned long *var)
{
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
