Fix subtle macro variable shadowing in min_not_zero()
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 9 Apr 2018 17:34:07 +0000 (10:34 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 9 Apr 2018 17:34:07 +0000 (10:34 -0700)
Commit 3c8ba0d61d04 ("kernel.h: Retain constant expression output for
max()/min()") rewrote our min/max macros to be very clever, but in the
meantime resurrected a variable name shadow issue that we had had
previously fixed in commit 589a9785ee3a ("min/max: remove sparse
warnings when they're nested").

That commit talks about the sparse warnings that this shadowing causes,
which we ignored as just a minor annoyance.  But it turns out that the
sparse warning is the least of our problems.  We actually have a real
bug due to the shadowing through the interaction with "min_not_zero()",
which ends up doing

   min(__x, __y)

internally, and then the new declaration of "__x" and "__y" as new
variables in __cmp_once() results in a complete mess of an expression,
and "min_not_zero()" doesn't work at all.

For some odd reason, this only ever caused (reported) problems on s390,
even though it is a generic issue and most of the (obviously successful)
testing of the problematic commit had happened on other architectures.

Quoting Sebastian Ott:
 "What happened is that the bio build by the partition detection code
  was attempted to be split by the block layer because the block queue
  had a max_sector setting of 0. blk_queue_max_hw_sectors uses
  min_not_zero."

So re-introduce the use of __UNIQUE_ID() to make sure that the min/max
macros do not have these kinds of clashes.

[ That said, __UNIQUE_ID() itself has several issues that make it less
  than wonderful.

  In particular, the "uniqueness" has a fallback on the line number,
  which means that it's not actually unique in more complex cases if you
  don't build with gcc or clang (which have working unique counters that
  aren't tied to line numbers).

  That historical broken fallback also means that we have that pointless
  "prefix" argument that doesn't actually make much sense _except_ for
  the known-broken case. Oh well. ]

Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()")
Reported-and-tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
include/linux/kernel.h

index 4ae1dfd9bf0519ff0a2785e41e6f5c0d7ad5ceb1..52b70894eaa53fe9d827481e1f96104fa77c1654 100644 (file)
@@ -822,14 +822,15 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
 
 #define __cmp(x, y, op)        ((x) op (y) ? (x) : (y))
 
-#define __cmp_once(x, y, op) ({                \
-               typeof(x) __x = (x);    \
-               typeof(y) __y = (y);    \
-               __cmp(__x, __y, op); })
-
-#define __careful_cmp(x, y, op)                                \
-               __builtin_choose_expr(__safe_cmp(x, y), \
-                                     __cmp(x, y, op), __cmp_once(x, y, op))
+#define __cmp_once(x, y, unique_x, unique_y, op) ({    \
+               typeof(x) unique_x = (x);               \
+               typeof(y) unique_y = (y);               \
+               __cmp(unique_x, unique_y, op); })
+
+#define __careful_cmp(x, y, op) \
+       __builtin_choose_expr(__safe_cmp(x, y), \
+               __cmp(x, y, op), \
+               __cmp_once(x, y, __UNIQUE_ID(__x), __UNIQUE_ID(__y), op))
 
 /**
  * min - return minimum of two values of the same or compatible types