Re: [tip:x86/mm 14/35] kernel/trace/bpf_trace.c:179:16: error: implicit declaration of function 'nmi_uaccess_okay'; did you mean '__access_ok'?

[Nadav Amit <namit@vmware.com>]

> On Apr 30, 2019, at 5:13 PM, kbuild test robot <lkp@intel.com> wrote:
> 
> tree:   https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftip%2Ftip.git&amp;data=02%7C01%7Cnamit%40vmware.com%7C8a380b9453f249fd924a08d6cdc9e8cd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636922664483201432&amp;sdata=NWhVtiLZ4l7LvLKsNNDrR4A8PlpXIeH1tErfFz6EmcM%3D&amp;reserved=0 x86/mm
> head:   3950746d9d8ef981c1cb842384e0e86e8d1aad76
> commit: c7b6f29b6257532792fc722b68fcc0e00b5a856c [14/35] bpf: Fail bpf_probe_write_user() while mm is switched
> config: s390-defconfig (attached as .config)
> compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
>        wget https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&amp;data=02%7C01%7Cnamit%40vmware.com%7C8a380b9453f249fd924a08d6cdc9e8cd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636922664483201432&amp;sdata=Sm%2FfjL7UqETv7HEEr32M2v3XmGwdAD10Wyr8ZmoQX50%3D&amp;reserved=0 -O ~/bin/make.cross
>        chmod +x ~/bin/make.cross
>        git checkout c7b6f29b6257532792fc722b68fcc0e00b5a856c
>        # save the attached .config to linux build tree
>        GCC_VERSION=7.2.0 make.cross ARCH=s390 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
> 
> All errors (new ones prefixed by >>):
> 
>   In file included from include/linux/kernel.h:11:0,
>                    from kernel/trace/bpf_trace.c:5:
>   kernel/trace/bpf_trace.c: In function '____bpf_probe_write_user':
>>> kernel/trace/bpf_trace.c:179:16: error: implicit declaration of function 'nmi_uaccess_okay'; did you mean '__access_ok'? [-Werror=implicit-function-declaration]
>     if (unlikely(!nmi_uaccess_okay()))

So s390 does not use the generic TLB gather architecture, which triggered
the problem.

Unfortunately, reproducing the failed build caused (other) errors. But
worse, fixing this issue “cleanly” is hard due to the dependencies between
the header files.

The best I managed to do without over-complicating the solution is the
following, which might not be super clean. Let me know whether to submit a
separate patch (on top or instead of the current one).

-- >8 --

From bc60dfc415f9ecc01771b388dacd41adc976929c Mon Sep 17 00:00:00 2001
From: Nadav Amit <namit@vmware.com>
Date: Tue, 30 Apr 2019 13:48:48 -0700
Subject: [PATCH] mm/tlb: Fix "Provide default nmi_uaccess_okay()"

Signed-off-by: Nadav Amit <namit@vmware.com>
---
 arch/x86/include/asm/tlbflush.h |  4 +---
 arch/x86/include/asm/uaccess.h  |  2 ++
 include/asm-generic/tlb.h       |  9 ---------
 include/linux/uaccess.h         | 12 ++++++++++++
 4 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index dee375831962..765e6b01eefd 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -249,7 +249,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate);
  * interrupted some kernel code that was temporarily using a
  * different mm.
  */
-static inline bool nmi_uaccess_okay(void)
+static inline bool arch_nmi_uaccess_okay(void)
 {
 	struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
 	struct mm_struct *current_mm = current->mm;
@@ -274,8 +274,6 @@ static inline bool nmi_uaccess_okay(void)
 	return true;
 }
 
-#define nmi_uaccess_okay nmi_uaccess_okay
-
 /* Initialize cr4 shadow for this CPU. */
 static inline void cr4_init_shadow(void)
 {
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 22ba683afdc2..d4b487d2441c 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -698,6 +698,8 @@ extern struct movsl_mask {
  */
 #define __copy_from_user_nmi __copy_from_user_inatomic
 
+#define nmi_uaccess_okay() arch_nmi_uaccess_okay()
+
 /*
  * The "unsafe" user accesses aren't really "unsafe", but the naming
  * is a big fat warning: you have to not only do the access_ok()
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 480e5b2a5748..b9edc7608d90 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -21,15 +21,6 @@
 #include <asm/tlbflush.h>
 #include <asm/cacheflush.h>
 
-/*
- * Blindly accessing user memory from NMI context can be dangerous
- * if we're in the middle of switching the current user task or switching
- * the loaded mm.
- */
-#ifndef nmi_uaccess_okay
-# define nmi_uaccess_okay() true
-#endif
-
 #ifdef CONFIG_MMU
 
 /*
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 2b70130af585..e2e12945deab 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -280,4 +280,16 @@ void __noreturn usercopy_abort(const char *name, const char *detail,
 			       unsigned long len);
 #endif
 
+/*
+ * Blindly accessing user memory from NMI context can be dangerous if we're in
+ * the middle of switching the current user task or switching the loaded mm.
+ * Provide a default implementation for architectures that do not provide one.
+ */
+#ifndef nmi_uaccess_okay
+static inline bool nmi_uaccess_okay(void)
+{
+	return true;
+}
+#endif
+
 #endif		/* __LINUX_UACCESS_H__ */
-- 
2.17.1