-Wframe-larger-than= in arch/x86/kernel/kvm.c

[nickdesaulniers]

mm/memcontrol.c:5541:12: warning: stack frame size of 1032 bytes in function 'memory_stat_show' [-Wframe-larger-than=]
static int memory_stat_show(struct seq_file *m, void *v)
           ^
mm/memcontrol.c:3388:12: warning: stack frame size of 1064 bytes in function 'memcg_stat_show' [-Wframe-larger-than=]
static int memcg_stat_show(struct seq_file *m, void *v)
           ^
2 warnings generated.

Not a dupe of #39 , KASAN not enabled.

[arndb]

I have to look again, but I think I'm not seeing any -Wframe-larger-than= warnings with clang-8 once asan-stack is disabled. This means I probably have a bugfix for this one and many others somewhere in my tree.

[arndb]

From 240a0792ff1d0bd4afc71869f9d1c5006559f4fc Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 14 Feb 2017 13:52:42 +0100
Subject: [PATCH] rewrite READ_ONCE/WRITE_ONCE

When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
rather large kernel stacks, e.g.:

mm/vmscan.c: In function 'shrink_page_list':
mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
block/cfq-iosched.c: In function 'cfqg_stats_add_aux':
block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/disk-io.c: In function 'open_ctree':
fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/relocation.c: In function 'build_backref_tree':
fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
fs/fscache/stats.c: In function 'fscache_stats_show':
fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction':
fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

This attempts a rewrite of the two macros, using a simpler implementation
for the most common case of having a naturally aligned 1, 2, 4, or (on
64-bit architectures) 8  byte object that can be accessed with a single
instruction.  For these, we go back to a volatile pointer dereference
that we had with the ACCESS_ONCE macro.

READ_ONCE/WRITE_ONCE also try to handle unaligned objects and objects
of other sizes by forcing either a word-size access (which may trap
on some architectures) or doing a non-atomic memcpy. I could not figure
out what these are actually used for, but they appear to be done
intentionally, so I'm leaving that code untouched.

I had to fix up a couple of files that either use WRITE_ONCE() as an
implicit typecast, or ignore the result of READ_ONCE(). In all cases,
the modified code seems no worse to me than the original.

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 36bd243843d6..d96bdb7e5f7a 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -32,7 +32,7 @@ static inline void prepare_switch_to(struct task_struct *next)
 	 *
 	 * To minimize cache pollution, just follow the stack pointer.
 	 */
-	READ_ONCE(*(unsigned char *)next->thread.sp);
+	(void)READ_ONCE(*(unsigned char *)next->thread.sp);
 #endif
 }
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7a52e2aba1d4..fc958b0f5688 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -210,6 +210,10 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
 	}
 }
 
+#define __ALIGNED_WORD(x)						\
+	((sizeof(x) == 1 || sizeof(x) == 2 || sizeof(x) == 4 ||		\
+	  sizeof(x) == sizeof(long)) && (sizeof(x) == __alignof__(x)))	\
+
 /*
  * Prevent the compiler from merging or refetching reads or writes. The
  * compiler is also forbidden from reordering successive instances of
@@ -231,6 +235,12 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
  * mutilate accesses that either do not require ordering or that interact
  * with an explicit memory barrier or atomic instruction that provides the
  * required ordering.
+ *
+ * Unaligned data is particularly tricky here: if the type that gets
+ * passed in is not naturally aligned, we cast to a type of higher
+ * alignment, which is not well-defined in C. This is fine as long
+ * as the actual data is aligned, but otherwise might require a trap
+ * to satisfy the load.
  */
 #include <asm/barrier.h>
 #include <linux/kasan-checks.h>
@@ -245,7 +255,32 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
 	smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
 	__u.__val;							\
 })
-#define READ_ONCE(x) __READ_ONCE(x, 1)
+
+#define __WRITE_ONCE(x, val)						\
+({									\
+	union { typeof(x) __val; char __c[1]; } __u =			\
+		{ .__val = (__force typeof(x)) (val) };			\
+	__write_once_size(&(x), __u.__c, sizeof(x));			\
+	__u.__val;							\
+})
+
+
+/*
+ * the common case is simple: x is naturally aligned, not an array,
+ * and accessible with a single load, avoiding the need for local
+ * variables. With KASAN, this is important as any call to
+ *__write_once_size(),__read_once_size_nocheck() or __read_once_size()
+ * uses significant amounts of stack space for checking that we don't
+ * overflow the union.
+ */
+#define __READ_ONCE_SIMPLE(x)						\
+	(typeof(x))(*(volatile typeof(&(x)))&(x))
+
+#define __WRITE_ONCE_SIMPLE(x, val)					\
+	({*(volatile typeof(&(x)))&(x) = (val); })
+
+#define READ_ONCE(x) __builtin_choose_expr(__ALIGNED_WORD(x), 		\
+	__READ_ONCE_SIMPLE(x), __READ_ONCE(x, 1))
 
 /*
  * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
@@ -260,13 +295,8 @@ unsigned long read_word_at_a_time(const void *addr)
 	return *(unsigned long *)addr;
 }
 
-#define WRITE_ONCE(x, val) \
-({							\
-	union { typeof(x) __val; char __c[1]; } __u =	\
-		{ .__val = (__force typeof(x)) (val) }; \
-	__write_once_size(&(x), __u.__c, sizeof(x));	\
-	__u.__val;					\
-})
+#define WRITE_ONCE(x, val) do { __builtin_choose_expr(__ALIGNED_WORD(x), \
+	__WRITE_ONCE_SIMPLE(x, val), __WRITE_ONCE(x, val)); } while (0)
 
 #endif /* __KERNEL__ */

[arndb]

I tried to reply with a patch above, that didn't go well. Please see https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=y2038-4.20-next&id=9485431c7f8e537e6b6b7350b7b0bb3724397183 for a patch I did a while ago that might address this.

[nickdesaulniers]

heh, no worries. I think you can attach a file to comments on github. alternatively, just point me to a tree/branch/sha to add as a remote, fetch from, and cherry pick.

[nickdesaulniers]

Just checking, the comment message mentions When CONFIG_KASAN is enabled but I don't have KASAN enabled. What's your CONFIG_FRAME_WARN set to?

[arndb]

On Thu, Oct 11, 2018 at 7:44 PM Nick Desaulniers ***@***.***> wrote: Just checking, the comment message mentions When CONFIG_KASAN is enabled but I don't have KASAN enabled. What's your CONFIG_FRAME_WARN set to?

I run with the default FRAME_WARN settings, 1024 bytes for 32-bit and 2048 bytes for 64-bit. I used to have patches to make those smaller and address all warnings, but I'm not currently testing with those.

[nickdesaulniers]

strange bug I filed. I reported issues in mm/memcontrol.c, which needs CONFIG_MEMCG=y, which isn't set by x86's defconfig. I also titled the bug "arch/x86/kernel/kvm.c" which doesn't match the warning I reported.

Enabling CONFIG_MEMCG=y on top of defconfig does not produce a warning for mm/memcontrol.c related to stack frame size.

Ditto for KVM_GUEST=y (kvmconfig) and arch/x86/kernel/kvm.c.

Closing as nonsensical.

[nickdesaulniers]

probably duped the warning from #201 by accident.