On Tue, Aug 22, 2017 at 11:27:31AM +0200, Peter Zijlstra wrote:

On Tue, Aug 22, 2017 at 10:30:50AM +0200, Lukas Wunner wrote:

quoted

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index a83c822c35c2..097af36887c0 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h

@@ -226,6 +226,30 @@ static inline unsigned long __ffs64(u64 word)
 	return __ffs((unsigned long)word);
 }
 
+/**
+ * assign_bit - Assign value to a bit in memory
+ * @value: the value to assign
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ */
+static __always_inline void assign_bit(bool value, long nr,
+				       volatile unsigned long *addr)
+{
+	if (value)
+		set_bit(nr, addr);
+	else
+		clear_bit(nr, addr);
+}
+
+static __always_inline void __assign_bit(bool value, long nr,
+					 volatile unsigned long *addr)
+{
+	if (value)
+		__set_bit(nr, addr);
+	else
+		__clear_bit(nr, addr);
+}
+

I dislike the argument order, in C you naturally write: dst = src. So I
would have expected:

	assign_bit(nr, addr, val);

but we have quite a few of these backwards functions in the kernel (like
most of the atomic_t family) and I didn't check to see if the existing
bitops are part of that 'tradition'.

The functions in include/linux/bitmap.h do follow the dst-then-src
pattern.  I carried over the argument order from Bart's function
to minimize the impact on the md subsystem, but will be happy to
respin with the order you're suggesting.  Will wait a bit though
to see if there are further comments.

Thanks,

Lukas