Message-ID: <9fafba22-bd84-dc33-8c95-8856791b9d2d@intel.com>
Date:   Sun, 24 Jun 2018 02:09:40 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     kbuild test robot <lkp@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     kbuild-all@...org, "x86@...nel.org" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V7 35/41] x86/intel_rdt: Create debugfs files for
 pseudo-locking testing

On 6/23/2018 6:07 AM, kbuild test robot wrote:
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on v4.18-rc1]
> [cannot apply to tip/x86/core tip/auto-latest next-20180622]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Reinette-Chatre/Intel-R-Resource-Director-Technology-Cache-Pseudo-Locking-enabling/20180623-065548
> config: x86_64-randconfig-r0-06231921 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
>         # save the attached .config to linux build tree
>         make ARCH=x86_64 
> 
> Note: the linux-review/Reinette-Chatre/Intel-R-Resource-Director-Technology-Cache-Pseudo-Locking-enabling/20180623-065548 HEAD c7e9cf1c60a66a41df4d37856b51360dde846b60 builds fine.
>       It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
>    arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c: In function 'pseudo_lock_measure_trigger':
>>> arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c:831:6: error: implicit declaration of function 'copy_from_user' [-Werror=implicit-function-declaration]
>      if (copy_from_user(buf, user_buf, buf_size))
>          ^~~~~~~~~~~~~~

Thank you very much for catching this.

Clearly an issue but I was concerned that my testing did not pick this
up since I do run the ktest.pl patchcheck tests to ensure that each
patch from the series compiled cleanly without introducing a new warning.

Thanks to another test from ktest.pl, config_bisect, I was able to learn
that I did not see this issue because I always have CONFIG_FTRACE=y and
the config used in this test did not set it. This error can be
reproduced when the config contains "# CONFIG_FTRACE is not set".

I assume this is why it took us a while to learn about this problem (a
few versions of the patch series was sent to mailing list with this
content) - since it needed a particular config to be encountered.

Thomas, I am sorry for breaking bisect on x86/cache. To fix this the
appropriate header file needs to be added like a snippet below. I am not
submitting a patch since I assume that this fix needs to be folded into
the culprit ("x86/intel_rdt: Create character device exposing
pseudo-locked region") to restore bisect.

The snippet was created against the culprit patch in an attempt for ease
of merging. Three of the patches that follows it in the series also
modifies that area but in my test it did not cause conflicts when
rebased on top of this change. Please let me know what I can do from my
side to help fix this.

8<-----------------
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 5851f3e20742..4ce0fe05fd82 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -17,6 +17,7 @@
 #include <linux/debugfs.h>
 #include <linux/kthread.h>
 #include <linux/slab.h>
+#include <linux/uaccess.h>
 #include <asm/cacheflush.h>
 #include <asm/intel-family.h>
 #include <asm/intel_rdt_sched.h>


Reinette

Powered by blists - more mailing lists