Merge pull request torvalds#330 from geofft/improve-guard

rust: helpers: Clarify comment on size_t = uintptr_t guard

Author: ojeda

rust/helpers.c

@@ -117,8 +117,24 @@ long rust_helper_ptr_err(__force const void *ptr)
 }
 EXPORT_SYMBOL_GPL(rust_helper_ptr_err);
 
-#if !defined(CONFIG_ARM)
-// See https://github.com/rust-lang/rust-bindgen/issues/1671
-static_assert(__builtin_types_compatible_p(size_t, uintptr_t),
-	"size_t must match uintptr_t, what architecture is this??");
-#endif
+/* We use bindgen's --size_t-is-usize option to bind the C size_t type
+ * as the Rust usize type, so we can use it in contexts where Rust
+ * expects a usize like slice (array) indices. usize is defined to be
+ * the same as C's uintptr_t type (can hold any pointer) but not
+ * necessarily the same as size_t (can hold the size of any single
+ * object). Most modern platforms use the same concrete integer type for
+ * both of them, but in case we find ourselves on a platform where
+ * that's not true, fail early instead of risking ABI or
+ * integer-overflow issues.
+ *
+ * If your platform fails this assertion, it means that you are in
+ * danger of integer-overflow bugs (even if you attempt to remove
+ * --size_t-is-usize). It may be easiest to change the kernel ABI on
+ * your platform such that size_t matches uintptr_t (i.e., to increase
+ * size_t, because uintptr_t has to be at least as big as size_t).
+*/
+static_assert(
+	sizeof(size_t) == sizeof(uintptr_t) &&
+	__alignof__(size_t) == __alignof__(uintptr_t),
+	"Rust code expects C size_t to match Rust usize"
+);