Re: [kbuild-all] Re: arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE"
On 4/11/21 1:42 PM, Randy Dunlap wrote: On 4/10/21 9:43 PM, kernel test robot wrote: Hi Julian, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 52e44129fba5cfc4e351fdb5e45849afc74d9a53 commit: 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS date: 31 hours ago config: csky-randconfig-c003-20210411 (attached as .config) compiler: csky-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7d37cb2c912dc5c25ffac784a4f9b98c06c6bd08 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=csky If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arch/csky/mm/tcm.c:9:2: error: #error "You should define ITCM_RAM_BASE" 9 | #error "You should define ITCM_RAM_BASE" | ^ arch/csky/mm/tcm.c:109:7: warning: no previous prototype for 'tcm_alloc' [-Wmissing-prototypes] 109 | void *tcm_alloc(size_t len) | ^ arch/csky/mm/tcm.c:124:6: warning: no previous prototype for 'tcm_free' [-Wmissing-prototypes] 124 | void tcm_free(void *addr, size_t len) | ^~~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for LOCKDEP Depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && (FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) Selected by - LOCK_STAT && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT - DEBUG_LOCK_ALLOC && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT vim +9 arch/csky/mm/tcm.c f525bb2c9e7cf1 Guo Ren 2019-11-27 7 f525bb2c9e7cf1 Guo Ren 2019-11-27 8 #if (CONFIG_ITCM_RAM_BASE == 0x) f525bb2c9e7cf1 Guo Ren 2019-11-27 @9 #error "You should define ITCM_RAM_BASE" f525bb2c9e7cf1 Guo Ren 2019-11-27 10 #endif f525bb2c9e7cf1 Guo Ren 2019-11-27 11 :: The code at line 9 was first introduced by commit :: f525bb2c9e7cf1e3c43ab57704c9e1c836d30b34 csky: Tightly-Coupled Memory or Sram support :: TO: Guo Ren :: CC: Guo Ren Hi ktr/lkp, Do you have the ability to modify a (rand)config file before doing a build? To fix this kconfig problem, you can use: ./scripts/config --set-val ITCM_RAM_BASE 0xe000 or ./scripts/config --file csky-randconfig-c003-20210411 --set-val ITCM_RAM_BASE 0xe000 if you want to modify some file other than ".config". (0xe00 is an arbitrary value here -- just cannot be 0x.) Then run "make oldconfig" and "make all" or however you normally build a kernel. It looks like the Kconfig file's ITCM_RAM_BASE parameter is expected to be set/modified by the user. The default value of 0x is invalid. Hi Randy, Thanks for the advice, we'll modify the config files for arch csky. Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH] mm: gup: remove FOLL_SPLIT
Hi John,
On 3/30/21 3:08 PM, John Hubbard wrote:
On 3/29/21 11:24 PM, kernel test robot wrote:
Hi Yang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hnaz-linux-mm/master]
url:
https://github.com/0day-ci/linux/commits/Yang-Shi/mm-gup-remove-FOLL_SPLIT/20210330-034042
base: https://github.com/hnaz/linux-mm master
config: s390-randconfig-r032-20210330 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/c8563a636718f98af86a3965d94e25b8f2cf2354
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Yang-Shi/mm-gup-remove-FOLL_SPLIT/20210330-034042
git checkout c8563a636718f98af86a3965d94e25b8f2cf2354
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
make.cross ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/s390/mm/gmap.c: In function 'thp_split_mm':
arch/s390/mm/gmap.c:2498:27: error: 'FOLL_SPLIT' undeclared (first
use in this function); did you mean 'FOLL_PIN'?
2498 | follow_page(vma, addr, FOLL_SPLIT);
| ^~
| FOLL_PIN
arch/s390/mm/gmap.c:2498:27: note: each undeclared identifier is
reported only once for each function it appears in
vim +2498 arch/s390/mm/gmap.c
There appears to be an imperfection in this 0day testing system,
because (just as the patch
says), commit ba925fa35057a062ac98c3e8138b013ce4ce351c ("s390/gmap:
improve THP splitting"),
July 29, 2020, removes the above use of FOLL_SPLIT.
And "git grep", just to be sure, shows it is not there in today's
linux.git. So I guess the
https://github.com/0day-ci/linux repo needs a better way to stay in sync?
Sorry for the delay, indeed, it's a issue from 0day-CI, we'll update
linux-mm in the system.
Best Regards,
Rong Chen
Re: [kbuild-all] Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO
Hi Nathan, On 3/27/21 7:58 AM, Nathan Chancellor wrote: On Sat, Mar 27, 2021 at 12:05:34AM +0800, kernel test robot wrote: Hi Nathan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc4 next-20210326] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 002322402dafd846c424ffa9240a937f49b48c42 config: riscv-randconfig-r032-20210326 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f490a5969bd52c8a48586f134ff8f02ccbb295b3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install riscv cross compiling tool for clang build # apt-get install binutils-riscv64-linux-gnu # https://github.com/0day-ci/linux/commit/dfdcaf93f40f0d15ffc3f25128442c1688e612d6 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421 git checkout dfdcaf93f40f0d15ffc3f25128442c1688e612d6 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv For the record, I tried to use this script to reproduce but it has a couple of bugs: 1. It does not download the right version of clang. This report says that it is clang-13 but the one that the script downloaded is clang-12. 2. It does not download it to the right location. The script expects ~/0day/clang-latest but it is downloaded to ~/0day/clang it seems. I symlinked it to get around it. Sorry for the inconvenience, we'll fix both asap. Best Regards, Rong Chen If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): riscv64-linux-gnu-objcopy: 'arch/riscv/kernel/vdso/vdso.so.dbg': No such file This error only occurs because of errors before it that are not shown due to a denylist: ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax My patch only adds another occurrence of this error because we move from $(CC)'s default linker (in clang's case, ld.bfd) to $(LD), which in the case of 0day appears to be ld.lld. ld.lld should not be used with RISC-V in its current form due to errors of this nature, which happen without my patch as well: https://github.com/ClangBuiltLinux/linux/issues/1020 Linker relaxation in ld.lld for RISC-V is an ongoing debate/process. Please give RISC-V the current treatment as s390 with ld.lld for the time being to get meaningful reports. We will reach out once that issue has been resolved. TL;DR: Patch exposes existing issue with LD=ld.lld that would have happened without it in different areas, the report can be ignored. Cheers! Nathan ___ kbuild-all mailing list -- kbuild-...@lists.01.org To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
On 3/23/21 7:47 PM, Greg KH wrote: On Wed, Mar 17, 2021 at 05:50:22PM +0800, kernel test robot wrote: Hi Manish, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on usb/usb-testing] [also build test WARNING on robh/for-next v5.12-rc3 next-20210316] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Manish-Narani/Add-a-separate-DWC3-OF-driver-for-Xilinx-platforms/20210317-145425 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/def409fdf931cd77f4a88812570ea6f38f4053d8 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Manish-Narani/Add-a-separate-DWC3-OF-driver-for-Xilinx-platforms/20210317-145425 git checkout def409fdf931cd77f4a88812570ea6f38f4053d8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/usb/dwc3/dwc3-xilinx.c:27: warning: expecting prototype for dwc3(). Prototype was for XLNX_USB_PHY_RST_EN() instead vim +27 drivers/usb/dwc3/dwc3-xilinx.c 25 26 /* USB phy reset mask register */ > 27 #define XLNX_USB_PHY_RST_EN 0x001C 28 #define XLNX_PHY_RST_MASK 0x1 29 I do not understand this warning message. What is it trying to say? Hi Greg, It's a kernel-doc warning: $ ./scripts/kernel-doc -none drivers/usb/dwc3/dwc3-xilinx.c drivers/usb/dwc3/dwc3-xilinx.c:27: warning: expecting prototype for dwc3(). Prototype was for XLNX_USB_PHY_RST_EN() instead the root cause is that there's a redundant symbol ( * ) at the beginning: diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c index a59e1494b1a0..f42f4cbffab0 100644 --- a/drivers/usb/dwc3/dwc3-xilinx.c +++ b/drivers/usb/dwc3/dwc3-xilinx.c @@ -1,5 +1,5 @@ // SPDX-License-Identifier: GPL-2.0 -/** +/* * dwc3-xilinx.c - Xilinx DWC3 controller specific glue driver * * Authors: Manish Narani Best Regards, Rong Chen confused, greg k-h
Re: drivers/opp/of.c:959:12: warning: stack frame size of 1056 bytes in function '_of_add_table_indexed'
On 3/23/21 3:25 PM, Viresh Kumar wrote: On 23-03-21, 15:23, kernel test robot wrote: Hi Viresh, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 84196390620ac0e5070ae36af84c137c6216a7dc commit: 406e47652161d4f0d9bc4cd6237b36c51497ec75 opp: Create _of_add_table_indexed() to reduce code duplication date: 7 weeks ago config: powerpc64-randconfig-r023-20210323 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 14696baaf4c43fe53f738bc292bbe169eed93d5d) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=406e47652161d4f0d9bc4cd6237b36c51497ec75 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 406e47652161d4f0d9bc4cd6237b36c51497ec75 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/opp/of.c:959:12: warning: stack frame size of 1056 bytes in function '_of_add_table_indexed' [-Wframe-larger-than=] static int _of_add_table_indexed(struct device *dev, int index) ^ 1 warning generated. I have reported this on 1st march as well. Looks to be false positive. Hi Viresh, Thanks for the feedback, we'll stop the bot sending such report again. Best Regards, Rong Chen
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 3/23/21 4:54 PM, Marc Kleine-Budde wrote: On 23.03.2021 09:32:10, Oliver Hartkopp wrote: I wonder if the compiler configurations (gcc -v) or the options used at kernel build time are identical. I tested several compilers and with my .config never triggered a problem, but with Rong Chen it does. I'm trying to figure out which option it is, stay tuned. Marc Hi Marc, Oliver, We use the below cross compiler: https://download.01.org/0day-ci/cross-package/gcc-9.3.0-nolibc/x86_64-gcc-9.3.0-nolibc_arm-linux-gnueabi.tar.xz and here is the detail: $ /home/nfs/0day/gcc-9.3.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/home/nfs/0day/gcc-9.3.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/nfs/0day/gcc-9.3.0-nolibc/arm-linux-gnueabi/bin/../libexec/gcc/arm-linux-gnueabi/9.3.0/lto-wrapper Target: arm-linux-gnueabi Configured with: /tmp/build-crosstools-xh/gcc/gcc-9.3.0/configure --target=arm-linux-gnueabi --enable-targets=all --prefix=/tmp/build-crosstools-xh/cross --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release Thread model: single gcc version 9.3.0 (GCC) Best Regards, Rong Chen
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
Hi Vincent,
On 3/23/21 1:46 PM, Vincent MAILHOL wrote:
Hi Oliver and Rong,
This is an interesting and quite surprising issue!
On Tue. 23 mars 2021 at 11:54, Rong Chen wrote:
On 3/23/21 12:24 AM, Oliver Hartkopp wrote:
Hi Rong,
On 22.03.21 09:52, Rong Chen wrote:
On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
Two reminders in two days? ;-)
Did you check my answer here?
https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
And did you try the partly revert?
Hi Oliver,
Sorry for the delay, we tried the revert patch and the problem still
exists,
we also found that commit c7b74967 changed the error message which
triggered
the report.
The problem is that offsetof(struct can_frame, data) !=
offsetof(struct canfd_frame, data)
the following struct layout shows that the offset has been changed by
union:
struct can_frame {
canid_tcan_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
Just a random idea but maybe the added padding is due to some
kind of odd intrication with the __attribute__((__aligned__(8)))
just below? Does this reproduce if we remove the
__attribute__((__aligned__(8)))?
Here is the layout without __attribute__((__aligned__(8))),
the union is still extended to 4 bytes:
struct can_frame {
canid_t can_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
__u8 __pad; /* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
__u8 data[8]; /* 11 8 */
/* size: 20, cachelines: 1, members: 6 */
/* padding: 1 */
/* last cacheline: 20 bytes */
};
Best Regards,
Rong Chen
(I am not saying that we should permanently remove it, this is
only a suggestion for troubleshooting).
__u8 __pad;/* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
/* XXX 5 bytes hole, try to pack */
__u8 data[8]
__attribute__((__aligned__(8))); /*16 8 */
/* size: 24, cachelines: 1, members: 6 */
/* sum members: 19, holes: 1, sum holes: 5 */
/* forced alignments: 1, forced holes: 1, sum forced holes:
5 */
/* last cacheline: 24 bytes */
} __attribute__((__aligned__(8)));
struct canfd_frame {
canid_tcan_id; /* 0 4 */
__u8 len; /* 4 1 */
__u8 flags;/* 5 1 */
__u8 __res0; /* 6 1 */
__u8 __res1; /* 7 1 */
__u8 data[64]
__attribute__((__aligned__(8))); /* 864 */
/* size: 72, cachelines: 2, members: 6 */
/* forced alignments: 1 */
/* last cacheline: 8 bytes */
} __attribute__((__aligned__(8)))
and I tried to add "__attribute__((packed))" to the union, the issue
is gone:
diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
index f75238ac6dce..9842bb55ffd9 100644
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -113,7 +113,7 @@ struct can_frame {
*/
__u8 len;
__u8 can_dlc; /* deprecated */
- };
+ } __attribute__((packed));
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9
.. 15) */
This is pretty strange!
pahole on my x86_64 machine shows the correct data structure layout:
struct can_frame {
canid_tcan_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 1 */
__u8 __pad;/* 5 1 */
__u8 __res0; /* 6 1 */
__u8 len8_dlc; /* 7 1 */
__u8 data[8]
__attribute__((__aligned__(8))); /*
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 3/23/21 12:24 AM, Oliver Hartkopp wrote:
Hi Rong,
On 22.03.21 09:52, Rong Chen wrote:
On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
Two reminders in two days? ;-)
Did you check my answer here?
https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
And did you try the partly revert?
Hi Oliver,
Sorry for the delay, we tried the revert patch and the problem still
exists,
we also found that commit c7b74967 changed the error message which
triggered
the report.
The problem is that offsetof(struct can_frame, data) !=
offsetof(struct canfd_frame, data)
the following struct layout shows that the offset has been changed by
union:
struct can_frame {
canid_t can_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
__u8 __pad; /* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
/* XXX 5 bytes hole, try to pack */
__u8 data[8]
__attribute__((__aligned__(8))); /* 16 8 */
/* size: 24, cachelines: 1, members: 6 */
/* sum members: 19, holes: 1, sum holes: 5 */
/* forced alignments: 1, forced holes: 1, sum forced holes:
5 */
/* last cacheline: 24 bytes */
} __attribute__((__aligned__(8)));
struct canfd_frame {
canid_t can_id; /* 0 4 */
__u8 len; /* 4 1 */
__u8 flags; /* 5 1 */
__u8 __res0; /* 6 1 */
__u8 __res1; /* 7 1 */
__u8 data[64]
__attribute__((__aligned__(8))); /* 8 64 */
/* size: 72, cachelines: 2, members: 6 */
/* forced alignments: 1 */
/* last cacheline: 8 bytes */
} __attribute__((__aligned__(8)))
and I tried to add "__attribute__((packed))" to the union, the issue
is gone:
diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
index f75238ac6dce..9842bb55ffd9 100644
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -113,7 +113,7 @@ struct can_frame {
*/
__u8 len;
__u8 can_dlc; /* deprecated */
- };
+ } __attribute__((packed));
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9
.. 15) */
This is pretty strange!
pahole on my x86_64 machine shows the correct data structure layout:
struct can_frame {
canid_t can_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 1 */
__u8 __pad; /* 5 1 */
__u8 __res0; /* 6 1 */
__u8 len8_dlc; /* 7 1 */
__u8 data[8]
__attribute__((__aligned__(8))); /* 8 8 */
/* size: 16, cachelines: 1, members: 6 */
/* forced alignments: 1 */
/* last cacheline: 16 bytes */
} __attribute__((__aligned__(8)));
Target: x86_64-linux-gnu
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Linux 5.12.0-rc3-00070-g8b12a62a4e3e x86_64 GNU/Linux
So it looks like your compiler does not behave correctly - and I
wonder if it would be the correct approach to add the __packed()
attribute or better fix/change the (ARM) compiler.
Hi Oliver,
I tried arm-linux-gnueabi (gcc version 10.2.0) and the problem still exists,
btw we prefer to not use the latest gcc compiler to avoid false positives.
Best Regards,
Rong Chen
At least I'm very happy that the BUILD_BUG_ON() triggered correctly -
so it was worth to have it ;-)
Best regards,
Oliver
Maybe there's a mismatch in include files - or BUILD_BUG_ON()
generally does not work with unions on ARM as assumed here:
https://lore.kernel.org/lkml/6e57d5d2-9b88-aee6-fb7a-82e24144d...@hartkopp.net/
In both cases I can not really fix the issue.
When the partly revert (suggested above) works, this would be a hack
too.
Best,
Oliver
On 20.03.21 21:43, kernel test robot wrote:
Hi Oliver,
FYI, the error/warning still remains.
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
ma
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
Two reminders in two days? ;-)
Did you check my answer here?
https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
And did you try the partly revert?
Hi Oliver,
Sorry for the delay, we tried the revert patch and the problem still
exists,
we also found that commit c7b74967 changed the error message which
triggered
the report.
The problem is that offsetof(struct can_frame, data) != offsetof(struct
canfd_frame, data)
the following struct layout shows that the offset has been changed by union:
struct can_frame {
canid_t can_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
__u8 __pad; /* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
/* XXX 5 bytes hole, try to pack */
__u8 data[8]
__attribute__((__aligned__(8))); /* 16 8 */
/* size: 24, cachelines: 1, members: 6 */
/* sum members: 19, holes: 1, sum holes: 5 */
/* forced alignments: 1, forced holes: 1, sum forced holes: 5 */
/* last cacheline: 24 bytes */
} __attribute__((__aligned__(8)));
struct canfd_frame {
canid_t can_id; /* 0 4 */
__u8 len; /* 4 1 */
__u8 flags; /* 5 1 */
__u8 __res0; /* 6 1 */
__u8 __res1; /* 7 1 */
__u8 data[64]
__attribute__((__aligned__(8))); /* 8 64 */
/* size: 72, cachelines: 2, members: 6 */
/* forced alignments: 1 */
/* last cacheline: 8 bytes */
} __attribute__((__aligned__(8)))
and I tried to add "__attribute__((packed))" to the union, the issue is
gone:
diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
index f75238ac6dce..9842bb55ffd9 100644
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -113,7 +113,7 @@ struct can_frame {
*/
__u8 len;
__u8 can_dlc; /* deprecated */
- };
+ } __attribute__((packed));
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9 ..
15) */
Best Regards,
Rong Chen
Maybe there's a mismatch in include files - or BUILD_BUG_ON()
generally does not work with unions on ARM as assumed here:
https://lore.kernel.org/lkml/6e57d5d2-9b88-aee6-fb7a-82e24144d...@hartkopp.net/
In both cases I can not really fix the issue.
When the partly revert (suggested above) works, this would be a hack too.
Best,
Oliver
On 20.03.21 21:43, kernel test robot wrote:
Hi Oliver,
FYI, the error/warning still remains.
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 812da4d39463a060738008a46cfc9f775e4bfcf6
commit: c7b74967799b1af52b3045d69d4c26836b2d41de can: replace can_dlc
as variable/element for payload length
date: 4 months ago
config: arm-randconfig-r016-20210321 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7b74967799b1af52b3045d69d4c26836b2d41de
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c7b74967799b1af52b3045d69d4c26836b2d41de
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from :
net/can/af_can.c: In function 'can_init':
include/linux/compiler_types.h:315:38: error: call to
'__compiletime_assert_536' declared with attribute error:
BUILD_BUG_ON failed: offsetof(struct can_frame, len) !=
offsetof(struct canfd_frame, len) || offsetof(struct can_frame,
data) != offsetof(struct canfd_frame, data)
315 | _compiletime_assert(condition, msg,
__compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:296:4: note: in definition of
macro '__compiletime_assert'
296 |
Re: [kbuild-all] Re: [tip:x86/cpu 2/3] arch/x86/kernel/alternative.c:96:10: warning: Undefined behaviour, pointer arithmetic 'x86nops+10' is out of bounds.
On 3/16/21 4:27 PM, Borislav Petkov wrote: Yet another useless report! On Tue, Mar 16, 2021 at 07:50:10AM +0800, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu head: 301cddc21a157a3072d789a3097857202e550a24 commit: a89dfde3dc3c2dbf56910af75e2d8b11ec5308f6 [2/3] x86: Remove dynamic NOP selection compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot cppcheck possible warnings: (new ones prefixed by >>, may not real problems) What's cppcheck? That? Description-en: tool for static C/C++ code analysis (CLI) Cppcheck is a command-line tool that tries to detect bugs that your arch/x86/kernel/alternative.c:96:10: warning: Undefined behaviour, pointer arithmetic 'x86nops+10' is out of bounds. [pointerOutOfBounds] x86nops + 1 + 2 + 3 + 4, ^ arch/x86/kernel/alternative.c:97:10: warning: Undefined behaviour, pointer arithmetic 'x86nops+15' is out of bounds. [pointerOutOfBounds] x86nops + 1 + 2 + 3 + 4 + 5, ^ arch/x86/kernel/alternative.c:98:10: warning: Undefined behaviour, pointer arithmetic 'x86nops+21' is out of bounds. [pointerOutOfBounds] x86nops + 1 + 2 + 3 + 4 + 5 + 6, ^ arch/x86/kernel/alternative.c:99:10: warning: Undefined behaviour, pointer arithmetic 'x86nops+28' is out of bounds. [pointerOutOfBounds] x86nops + 1 + 2 + 3 + 4 + 5 + 6 + 7, ^ arch/x86/kernel/ftrace.c:304:7: warning: union member 'ftrace_op_code_union::code' is never used. [unusedStructMember] char code[OP_REF_SIZE]; ^ How do you trigger this? /me ignores it until there's some info on how those things can be reproduced. Hi Borislav, Sorry for the inconvenience, there's a bug in our system which sent internal reports to outside. please ignore the warnings. Best Regards, Rong Chen
[PATCH] selftests/vm: fix out-of-tree build
When building out-of-tree, attempting to make target from $(OUTPUT) directory: make[1]: *** No rule to make target '$(OUTPUT)/protection_keys.c', needed by '$(OUTPUT)/protection_keys_32'. Reported-by: kernel test robot Signed-off-by: Rong Chen --- tools/testing/selftests/vm/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile index 4cbc91d6869f..73e1cc96d7c2 100644 --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -102,7 +102,7 @@ endef ifeq ($(CAN_BUILD_I386),1) $(BINARIES_32): CFLAGS += -m32 $(BINARIES_32): LDLIBS += -lrt -ldl -lm -$(BINARIES_32): %_32: %.c +$(BINARIES_32): $(OUTPUT)/%_32: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-32,$(t endif @@ -110,7 +110,7 @@ endif ifeq ($(CAN_BUILD_X86_64),1) $(BINARIES_64): CFLAGS += -m64 $(BINARIES_64): LDLIBS += -lrt -ldl -$(BINARIES_64): %_64: %.c +$(BINARIES_64): $(OUTPUT)/%_64: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-64,$(t endif -- 2.20.1
Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch
On 3/13/21 1:52 AM, Linus Torvalds wrote: On Thu, Mar 11, 2021 at 7:50 PM Rong Chen wrote: The issue is from a=!, and [ "$a $b" = ".size .LPBX0," ] can avoid the error. + [ ! = .size -a ABI = .LPBX0, ] ./kernel/gcov/geninfosize.sh: 13: [: =: unexpected operator But that's not what the patch did. The patch used quotes around $a, so "$a" should still be fine. See: [torvalds@ryzen ~]$ a="!" [ "$a" = ".size" ] is fine, but [torvalds@ryzen ~]$ a="!" [ $a = ".size" ] -bash: [: =: unary operator expected and the patch I saw, and that the test robot replied to, had that correct quoting, afaik. So I still don't see what the test robot is complaining about. Was there an earlier version of the patch without the quotes that I didn't see? Or is the shell on the test robot doing something really really odd, and it's somehow nds32-specific? Linus Hi Linus, It can be reproduced with '-a' option in dash: $ a="!" $ [ "$a" = ".size" ] $ [ "$a" = ".size" -a "$b" = ".LPBX0," ] sh: 2: [: =: unexpected operator and there is a advice for the option at https://wiki.ubuntu.com/DashAsBinSh, I'm not sure it's the best practice or not. While dash supports most uses of the -a and -o options, they have very confusing semantics even in bash and are best avoided. Commands like the following: [ \( "$foo" = "$bar" -a -f /bin/baz \) -o ! -x /bin/quux ] should be replaced with: (([ "$foo" = "$bar" ] && [ -f /bin/baz ]) || [ ! -x /bin/quux ]) Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH] gcov: fail build on gcov_info size mismatch
On 3/12/21 4:02 AM, Linus Torvalds wrote: On Thu, Mar 11, 2021 at 11:34 AM kernel test robot wrote: kernel/gcov/geninfosize.sh: 13: [: =: unexpected operator Wth? I'm not seeing how this can fail on nds32 - doesn't look like a bashism, everything is properly quoted, etc etc. Plus it's a cross-compile anyway, so the shell in question should be the same as on all the other architectures. Presumably the nds32 assembly contains something odd and unexpected, but with the quoting, I can't see how even that could matter. Yeah, the test itself could probably be simplified to testing both conditions at the same time: [ "$a $b" = ".size .LPBX0," ] but that's a separate issue. Funky. What am I missing? Presumably something really stupid. Linus Hi Linus, The issue is from a=!, and [ "$a $b" = ".size .LPBX0," ] can avoid the error. + [ ! = .size -a ABI = .LPBX0, ] ./kernel/gcov/geninfosize.sh: 13: [: =: unexpected operator Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH v2] mm: page_alloc: dump migrate-failed pages
On 3/9/21 6:29 AM, Minchan Kim wrote: On Tue, Mar 09, 2021 at 05:29:30AM +0800, kernel test robot wrote: Hi Minchan, I love your patch! Perhaps something to improve: [auto build test WARNING on hnaz-linux-mm/master] url: https://github.com/0day-ci/linux/commits/Minchan-Kim/mm-page_alloc-dump-migrate-failed-pages/20210309-042205 base: https://github.com/hnaz/linux-mm master config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/3c635af37b862e9c601ee8d5818f7da9cd3e2e57 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Minchan-Kim/mm-page_alloc-dump-migrate-failed-pages/20210309-042205 git checkout 3c635af37b862e9c601ee8d5818f7da9cd3e2e57 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of pointer with null pointer [-Wextra] 169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory) | ^~ include/linux/compiler.h:78:42: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON' 143 | BUG_ON(!virt_addr_valid(buf)); | ^~ include/linux/scatterlist.h:143:10: note: in expansion of macro 'virt_addr_valid' 143 | BUG_ON(!virt_addr_valid(buf)); | ^~~ In file included from arch/m68k/include/asm/page.h:60, from arch/m68k/include/asm/thread_info.h:6, from include/linux/thread_info.h:38, from include/asm-generic/preempt.h:5, from ./arch/m68k/include/generated/asm/preempt.h:1, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/mm.h:10, from mm/page_alloc.c:19: I am not sure this is triggered by the patch since I could see the warn with reverting the patch. Hi Minchan, Only the lines prefixed by ">>" are related with the patch: mm/page_alloc.c:8348:5: warning: no previous prototype for 'alloc_contig_ratelimit' [-Wmissing-prototypes] 8348 | int alloc_contig_ratelimit(void) | ^~ mm/page_alloc.c:8353:6: warning: no previous prototype for 'dump_migrate_failure_pages' [-Wmissing-prototypes] 8353 | void dump_migrate_failure_pages(struct list_head *page_list) Best Regards, Rong Chen
Re: [kbuild-all] Re: COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc kernel lib mm net samples scripts security so
On 3/4/21 4:07 AM, Arnd Bergmann wrote: On Wed, Mar 3, 2021 at 8:44 PM kernel test robot wrote: Hi Arnd, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f69d02e37a85645aa90d18cacfff36dba370f797 commit: a579fcfa8e49cc77ad59211bb18bc5004133e6a0 c6x: remove architecture date: 6 weeks ago config: c6x-randconfig-r026-20210303 (attached as .config) compiler: c6x-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a579fcfa8e49cc77ad59211bb18bc5004133e6a0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout a579fcfa8e49cc77ad59211bb18bc5004133e6a0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=c6x If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): Makefile:681: arch/c6x/Makefile: No such file or directory Yes, arch/c6x is gone and unlikely to return. Please fix the 0day scripts to no longer build it on v5.12-rc1 or higher. Hi Arnd, Thanks for the warning, we have removed the related tests. Best Regards, Rong Chen Arnd ___ kbuild-all mailing list -- kbuild-...@lists.01.org To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [kbuild-all] Re: net/ceph/messenger_v1.c:1204:5: warning: stack frame size of 2944 bytes in function 'ceph_con_v1_try_read'
On 3/1/21 7:42 PM, Ilya Dryomov wrote: On Mon, Mar 1, 2021 at 9:36 AM kernel test robot wrote: Hi Ilya, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8 commit: 2f713615ddd9d805b6c5e79c52e0e11af99d2bf1 libceph: move msgr1 protocol implementation to its own file date: 3 months ago It's fine. This commit just moved the code which has been this way for years and never caused any real issues. Please add it to the allowlist if possible. Hi llya, Thanks for the suggestion, we have added to the allowlist. Best Regards, Rong Chen config: powerpc64-randconfig-r001-20210301 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 5de09ef02e24d234d9fc0cd1c6dfe18a1bb784b0) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2f713615ddd9d805b6c5e79c52e0e11af99d2bf1 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 2f713615ddd9d805b6c5e79c52e0e11af99d2bf1 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from net/ceph/messenger_v1.c:8: In file included from include/net/sock.h:38: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :32:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from net/ceph/messenger_v1.c:8: In file included from include/net/sock.h:38: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :36:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from net/ceph/messenger_v1.c:8: In file included from include/net/sock.h:38: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned
Re: [kbuild-all] Re: WARNING: modpost: vmlinux.o(.text+0x1a8edb8): Section mismatch in reference from the function stop_machine() to the function .init.text:intel_rng_hw_init()
On 2/24/21 10:26 PM, Jürgen Groß wrote: On 24.02.21 15:20, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c03c21ba6f4e95e406a1a7b4c34ef334b977c194 commit: ab234a260b1f625b26cbefa93ca365b0ae66df33 x86/pv: Rework arch_local_irq_restore() to not use popf date: 2 weeks ago config: x86_64-randconfig-a005-20210223 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f14a14dd2564703db02f80c00db8ae492b594f77) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab234a260b1f625b26cbefa93ca365b0ae66df33 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ab234a260b1f625b26cbefa93ca365b0ae66df33 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: vmlinux.o(.text+0x1a8edb8): Section mismatch in reference from the function stop_machine() to the function .init.text:intel_rng_hw_init() The function stop_machine() references the function __init intel_rng_hw_init(). This is often because stop_machine lacks a __init annotation or the annotation of intel_rng_hw_init is wrong. I'd be very interested to know how the identified patch would be able to have this effect. Hi Clang Team, The problem is found by the latest clang, and I can't reproduce it with clang-11, could you take a look? Best Regards, Rong Chen
[PATCH] scripts/recordmcount.pl: support big endian for ARCH sh
The kernel test robot reported the following issue:
CC [M] drivers/soc/litex/litex_soc_ctrl.o
sh4-linux-objcopy: Unable to change endianness of input file(s)
sh4-linux-ld: cannot find drivers/soc/litex/.tmp_gl_litex_soc_ctrl.o: No such
file or directory
sh4-linux-objcopy: 'drivers/soc/litex/.tmp_mx_litex_soc_ctrl.o': No such file
The problem is that the format of input file is elf32-shbig-linux,
but sh4-linux-objcopy wants to output a file which format is elf32-sh-linux:
$ sh4-linux-objdump -d drivers/soc/litex/litex_soc_ctrl.o | grep format
drivers/soc/litex/litex_soc_ctrl.o: file format elf32-shbig-linux
Reported-by: kernel test robot
Link: https://lore.kernel.org/linux-mm/202101261118.gbbyslhu-...@intel.com
Signed-off-by: Rong Chen
---
scripts/recordmcount.pl | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 56c801502b9a..867860ea57da 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -265,7 +265,11 @@ if ($arch eq "x86_64") {
# force flags for this arch
$ld .= " -m shlelf_linux";
-$objcopy .= " -O elf32-sh-linux";
+if ($endian eq "big") {
+$objcopy .= " -O elf32-shbig-linux";
+} else {
+$objcopy .= " -O elf32-sh-linux";
+}
} elsif ($arch eq "powerpc") {
my $ldemulation;
--
2.20.1
Re: [kbuild-all] Re: [PATCH v12 7/7] kasan: don't run tests in async mode
On 2/9/21 7:33 PM, Vincenzo Frascino wrote: On 2/9/21 6:32 AM, kernel test robot wrote: Hi Vincenzo, I love your patch! Yet something to improve: [auto build test ERROR on next-20210125] [cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc6 v5.11-rc5 v5.11-rc4 v5.11-rc6] The patches are based on linux-next/akpm and since they depend on some patches present on that tree, can be applied only on linux-next/akpm and linux-next/master. The dependency is reported in the cover letter. Hi Vincenzo, Thanks for the feedback, we'll take a look. Best Regards, Rong Chen Thanks, Vincenzo [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 base:59fa6a163ffabc1bf25c5e0e33899e268a96d3cc config: powerpc64-randconfig-r033-20210209 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/53907a0b15724b414ddd9201356f92e09571ef90 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 git checkout 53907a0b15724b414ddd9201356f92e09571ef90 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc-linux-ld: lib/test_kasan.o: in function `kasan_test_init': test_kasan.c:(.text+0x849a): undefined reference to `kasan_flag_async' powerpc-linux-ld: test_kasan.c:(.text+0x84a2): undefined reference to `kasan_flag_async' powerpc-linux-ld: test_kasan.c:(.text+0x84e2): undefined reference to `kasan_flag_async' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [kbuild-all] Re: [patch 06/12] x86/entry: Convert system vectors to irq stack macro
On 2/8/21 10:19 PM, Borislav Petkov wrote: On Sun, Feb 07, 2021 at 04:15:11PM +0800, Rong Chen wrote: Thanks for the advice, we'll add the check to our cluster, and sorry for the inconvenience. When it comes to the tip tree, I'd say you guys are much better off not scraping any patches from the mailing list but simply testing the tip branches. That would be more than enough and you already do that anyway. Thx. Hi Borislav, Thanks for the help, how can we identify the patches for tip tree, could you please guide us? Best Regards, Rong Chen
Re: [kbuild-all] Re: [patch 06/12] x86/entry: Convert system vectors to irq stack macro
On 2/5/21 10:13 PM, Peter Zijlstra wrote: On Fri, Feb 05, 2021 at 11:52:40AM +0800, kernel test robot wrote: Hi Thomas, I love your patch! Perhaps something to improve: [auto build test WARNING on tip/x86/asm] [also build test WARNING on tip/master linus/master tip/x86/core v5.11-rc6 next-20210125] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-irq-64-Inline-irq-stack-switching/20210205-091059 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 5c99720b28381bb400d4f546734c34ddaf608761 config: x86_64-randconfig-r026-20210204 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/d91ff58e804175dd59e483c7cf236e1fe66c2187 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Thomas-Gleixner/x86-irq-64-Inline-irq-stack-switching/20210205-091059 git checkout d91ff58e804175dd59e483c7cf236e1fe66c2187 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/x86/hyperv/hv_init.o: warning: objtool: sysvec_hyperv_reenlightenment()+0x7f: undefined stack state -- arch/x86/kernel/cpu/mshyperv.o: warning: objtool: sysvec_hyperv_callback()+0x7f: undefined stack state arch/x86/kernel/cpu/mshyperv.o: warning: objtool: sysvec_hyperv_stimer0()+0x7f: undefined stack state It would help if you'd actually applied the patches to a tree that had the required objtool patches as described in 0/n. Or better yet, don't scrape emails if the 0/n includes a git link which you'll run on anyway. Hi Peter, Thanks for the advice, we'll add the check to our cluster, and sorry for the inconvenience. Best Regards, Rong Chen
[PATCH] selftests/vm: rename file run_vmtests to run_vmtests.sh
Commit c2aa8afc36fa has renamed run_vmtests in Makefile,
but the file still uses the old name.
The kernel test robot reported the following issue:
# selftests: vm: run_vmtests.sh
# Warning: file run_vmtests.sh is missing!
not ok 1 selftests: vm: run_vmtests.sh
Reported-by: kernel test robot
Fixes: c2aa8afc36fa (selftests/vm: rename run_vmtests --> run_vmtests.sh)
Signed-off-by: Rong Chen
---
tools/testing/selftests/vm/{run_vmtests => run_vmtests.sh} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename tools/testing/selftests/vm/{run_vmtests => run_vmtests.sh} (100%)
diff --git a/tools/testing/selftests/vm/run_vmtests
b/tools/testing/selftests/vm/run_vmtests.sh
similarity index 100%
rename from tools/testing/selftests/vm/run_vmtests
rename to tools/testing/selftests/vm/run_vmtests.sh
--
2.20.1
Re: [kbuild-all] Re: s390-linux-ld: ll_temac_main.c:undefined reference to `devm_platform_ioremap_resource_byname'
On 2/2/21 1:22 PM, Randy Dunlap wrote: On 2/1/21 9:09 PM, Rong Chen wrote: On 2/2/21 6:38 AM, Randy Dunlap wrote: On 1/31/21 4:06 PM, kernel test robot wrote: Hi Wang, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1048ba83fb1c00cd24172e23e8263972f6b5d9ac commit: bd69058f50d5ffa659423bcfa6fe6280ce9c760a net: ll_temac: Use devm_platform_ioremap_resource_byname() date: 6 months ago config: s390-randconfig-r034-20210201 (attached as .config) Hi robot, Instead of hit & miss with s390 randconfigs, you could do what I did: (all for arch/s390/): Hi Randy, Thanks for the advice, do you mean we don't need to test randconfig for arch s390? You should still do randconfig testing for s390 (for other problems), but the robot has been sending out a lot of build errors similar to this one, using different randconfig files. I am just saying that you can find all of the ioremap/iounmap/devm_io* type build errors in one kernel config file as described above. Hi Randy, Thanks for the detailed explanation, will do it. Best Regards, Rong Chen Best Regards, Rong Chen $ make allmodconfig $ scripts/config -d PCI ## this also disables HAS_IOMEM $ make oldconfig $ make all The latter gives a full list of drivers etc. that use iomemp/ioremap etc. as well as dev_io* variants instead of just a few random ones. All errors (new ones prefixed by >>): s390-linux-ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe': ll_temac_main.c:(.text+0x39b6): undefined reference to `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x3a4c): undefined reference to `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x3bce): undefined reference to `devm_ioremap' s390-linux-ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in function `axienet_probe': xilinx_axienet_main.c:(.text+0x844): undefined reference to `devm_ioremap_resource' ___
Re: [kbuild-all] Re: s390-linux-ld: ll_temac_main.c:undefined reference to `devm_platform_ioremap_resource_byname'
On 2/2/21 6:38 AM, Randy Dunlap wrote: On 1/31/21 4:06 PM, kernel test robot wrote: Hi Wang, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1048ba83fb1c00cd24172e23e8263972f6b5d9ac commit: bd69058f50d5ffa659423bcfa6fe6280ce9c760a net: ll_temac: Use devm_platform_ioremap_resource_byname() date: 6 months ago config: s390-randconfig-r034-20210201 (attached as .config) Hi robot, Instead of hit & miss with s390 randconfigs, you could do what I did: (all for arch/s390/): Hi Randy, Thanks for the advice, do you mean we don't need to test randconfig for arch s390? Best Regards, Rong Chen $ make allmodconfig $ scripts/config -d PCI ## this also disables HAS_IOMEM $ make oldconfig $ make all The latter gives a full list of drivers etc. that use iomemp/ioremap etc. as well as dev_io* variants instead of just a few random ones. All errors (new ones prefixed by >>): s390-linux-ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe': ll_temac_main.c:(.text+0x39b6): undefined reference to `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x3a4c): undefined reference to `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x3bce): undefined reference to `devm_ioremap' s390-linux-ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in function `axienet_probe': xilinx_axienet_main.c:(.text+0x844): undefined reference to `devm_ioremap_resource' ___ kbuild-all mailing list -- kbuild-...@lists.01.org To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [rcu:rcu/next] BUILD SUCCESS WITH WARNING f81f6edb74f27c5c8917d20a2bc128aca39aae11
On 1/13/21 11:14 PM, Paul E. McKenney wrote: On Wed, Jan 13, 2021 at 08:24:24PM +0800, kernel test robot wrote: tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next branch HEAD: f81f6edb74f27c5c8917d20a2bc128aca39aae11 rcu: Remove spurious instrumentation_end() in rcu_nmi_enter() Warning ids grouped by kconfigs: gcc_recent_errors |-- h8300-randconfig-c003-20210112 | `-- kernel-rcu-rcutorture.c:WARNING-kmalloc-is-used-to-allocate-this-memory-at-line |-- i386-randconfig-c001-20210112 | `-- kernel-rcu-rcutorture.c:WARNING-kmalloc-is-used-to-allocate-this-memory-at-line `-- powerpc-randconfig-c004-20210112 `-- kernel-rcu-rcutorture.c:WARNING-kmalloc-is-used-to-allocate-this-memory-at-line OK, I will bite... At which line? Thanx, Paul Hi Paul, It's a coccinelle warning, it seems Julia Lawall didn't forward it to you, it maybe not a real problem. https://lists.01.org/hyperkitty/list/kbu...@lists.01.org/message/ZN45D2QHCG5W4KMOGVBLUCUOKH32LFHE/ Best Regards, Rong Chen elapsed time: 722m configs tested: 164 configs skipped: 2 gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm shannon_defconfig powerpc maple_defconfig arm zx_defconfig mipse55_defconfig arm spear13xx_defconfig arm colibri_pxa300_defconfig sh se7206_defconfig arc nsimosci_hs_smp_defconfig powerpc lite5200b_defconfig sh sh7785lcr_32bit_defconfig mips lemote2f_defconfig sh rts7751r2d1_defconfig m68km5272c3_defconfig shmigor_defconfig powerpcicon_defconfig sh alldefconfig mips cu1000-neo_defconfig arm cns3420vb_defconfig mips decstation_r4k_defconfig arm corgi_defconfig arm eseries_pxa_defconfig ia64 tiger_defconfig powerpc pasemi_defconfig mips bigsur_defconfig mips rbtx49xx_defconfig c6x alldefconfig mips decstation_defconfig sh sh7770_generic_defconfig armhisi_defconfig c6xevmc6472_defconfig microblaze defconfig xtensa cadence_csp_defconfig powerpcmvme5100_defconfig m68k amcore_defconfig mipsbcm47xx_defconfig mipsworkpad_defconfig h8300 edosk2674_defconfig powerpc mpc8313_rdb_defconfig mips xway_defconfig arc tb10x_defconfig sh se7721_defconfig arm axm55xx_defconfig m68kq40_defconfig armmini2440_defconfig powerpc tqm8560_defconfig sh ecovec24_defconfig c6xevmc6457_defconfig armmvebu_v7_defconfig mips pistachio_defconfig m68k multi_defconfig s390 zfcpdump_defconfig xtensasmp_lx200_defconfig h8300h8300h-sim_defconfig arm multi_v4t_defconfig arm davinci_all_defconfig sh r7780mp_defconfig armkeystone_defconfig ia64zx1_defconfig mips maltaaprp_defconfig sh se7724_defconfig sh urquell_defconfig sparcalldefconfig armmulti_v5_defconfig powerpc pmac32_defconfig powerpc ksi8560_defconfig powerpcamigaone_defconfig arc haps_hs_smp_defconfig cskydefconfig umkunit_defconfig powerpc mpc832x_rdb_defconfig powerpc mgcoge_defconfig ia64generic_defconfig powerpc bamboo_defconfig arm pxa255-idp_defconfig sh se7705_defconfig parisc defconfig m68km5407c3_defconfig m68k
Re: [kbuild-all] Re: fs/f2fs/gc.c:622:12: warning: stack frame size of 3056 bytes in function 'get_victim_by_default'
On 1/11/21 4:23 PM, Chao Yu wrote: Hello, Thanks for the report. I replied for your previous report [1], could you please check that? [1] https://lore.kernel.org/lkml/8a8ef6b8-84c2-abfe-e758-2fa52a989...@huawei.com/ That says, in my environment, get_victim_by_default()'s frame size is less than 512 bytes, and also after going through related code, I don't see any obvious large stack size usage. Is that issue a powerpc specified issue? Hi Chao, The issue can be found on arch mips too: fs/f2fs/gc.c:622:12: warning: stack frame size of 1672 bytes in function 'get_victim_by_default' [-Wframe-larger-than=] static int get_victim_by_default(struct f2fs_sb_info *sbi, ^ 1 warning generated. Could you help to verify powerpc compiling with -Wframe-larger-than=512 after reverting that atgc patch? I mean whether get_victim_by_default() already have large frame size before applying atgc patch (commit 093749e296e2)? After reverting commit 093749e29 and set -Wframe-larger-than=512, the warning is fs/f2fs/gc.c:325:12: warning: stack frame size of 912 bytes in function 'get_victim_by_default' [-Wframe-larger-than=] static int get_victim_by_default(struct f2fs_sb_info *sbi, Best Regards, Rong Chen On 2021/1/9 21:18, kernel test robot wrote: Hi Chao, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 996e435fd401de35df62ac943ab9402cfe85c430 commit: 093749e296e29a4b0162eb925a6701a01e8c9a98 f2fs: support age threshold based garbage collection date: 4 months ago config: powerpc-randconfig-r033-20210109 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bc556e5685c0f97e79fb7b3c6f15cc5062db8e36) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=093749e296e29a4b0162eb925a6701a01e8c9a98 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 093749e296e29a4b0162eb925a6701a01e8c9a98 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :182:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :184:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from include/linux/har
Re: [LKP] Re: [kasan] 97593cad00: RIP:kasan_record_aux_stack
On 12/31/20 4:49 AM, Linus Torvalds wrote:
On Tue, Dec 29, 2020 at 6:59 PM kernel test robot wrote:
[ 235.553325] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1351
[ 235.554684] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 7515,
name: trinity-c1
[ 235.555890] 2 locks held by trinity-c1/7515:
[ 235.556506] #0: 8323dd38 (>rwsem){}-{3:3}, at:
semctl_down+0x6d/0x686
[ 235.557684] #1: 888128ccc868 (>mmap_lock#2){}-{3:3}, at:
do_user_addr_fault+0x196/0x59e
[ 235.559020] CPU: 1 PID: 7515 Comm: trinity-c1 Not tainted
5.10.0-g97593cad003c #2
[ 235.560317] Call Trace:
[ 235.560767] dump_stack+0x7d/0xa3
[ 235.561371] ___might_sleep+0x2c4/0x2df
[ 235.562063] ? do_user_addr_fault+0x196/0x59e
[ 235.562834] do_user_addr_fault+0x234/0x59e
[ 235.563519] exc_page_fault+0x70/0x8b
[ 235.564112] asm_exc_page_fault+0x1b/0x20
Btw, I wonder if the kernel test robot dumps could be please run through the
scripts/decode_stacktrace.sh
script to give line numbers and inlining information?
That does require CONFIG_DEBUG_INFO to work, but it would help things
like this when you don't have to try to guess where the exact access
happens.
Now, in this case, it seems to be a recursive issue with the original
fault happening in:
[ 235.564754] RIP: 0010:kasan_record_aux_stack+0x64/0x74
And yeah, that explains why it then bisects to 97593cad003c ("kasan:
sanitize objects when metadata doesn't fit")
The faulting instruction sequence decodes to
10: 48 39 f3cmp%rsi,%rbx
13: 48 0f 46 f3 cmovbe %rbx,%rsi
17: e8 6f e5 ff ff callq .. something ..
1c: bf 00 08 00 00 mov$0x800,%edi
21: 48 89 c3mov%rax,%rbx
24:* 8b 40 08mov0x8(%rax),%eax <--
trapping instruction
27: 89 43 0cmov%eax,0xc(%rbx)
and I *think* that "call something" is the call to
kasan_get_alloc_meta. And there is no check for a NULL return.
So I think this was already fixed by commit 13384f6125ad ("kasan: fix
null pointer dereference in kasan_record_aux_stack").
But see about that "decode_stacktrace,sh" script request. I thought I
had already asked for this, but I now realize that I think that was
just for syzbot.
Can we do that for these kernel test robot reports too? Please?
Linus
Hi Linus,
Sorry for the inconvenience and we're working on it right now.
Happy New Year!
Best Regards,
Rong Chen
Re: [kbuild-all] Re: ERROR: "snd_soc_new_ac97_component" undefined!
On 12/11/20 8:16 AM, Randy Dunlap wrote: On 12/6/20 10:11 AM, kernel test robot wrote: Hi Geert, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7059c2c00a2196865c2139083cbef47cd18109b6 commit: ea00d95200d02ece71f5814d41b14f2eb16d598b ASoC: Use imply for SND_SOC_ALL_CODECS date: 10 months ago config: powerpc-randconfig-r012-20201207 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea00d95200d02ece71f5814d41b14f2eb16d598b git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ea00d95200d02ece71f5814d41b14f2eb16d598b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): ERROR: "mpc5200_audio_dma_create" [sound/soc/fsl/mpc5200_psc_ac97.ko] undefined! ERROR: "mpc5200_audio_dma_destroy" [sound/soc/fsl/mpc5200_psc_ac97.ko] undefined! ERROR: "snd_soc_new_ac97_component" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: "snd_soc_free_ac97_component" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: "snd_soc_new_ac97_component" [sound/soc/codecs/snd-soc-ad1980.ko] undefined! ERROR: "snd_soc_free_ac97_component" [sound/soc/codecs/snd-soc-ad1980.ko] undefined! I also see these: ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: modpost: "regmap_ac97_default_volatile" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! and the (usual) missing Kconfig warnings::( WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97 Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_MPC52xx [=y] && PPC_BESTCOMM [=n] Selected by [m]: - SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y] WARNING: unmet direct dependencies detected for SND_SOC_STAC9766 Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_AC97_BUS [=n] Selected by [m]: - SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y] WARNING: unmet direct dependencies detected for HOTPLUG_CPU Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n] || PPC_POWERNV [=n] || FSL_SOC_BOOKE [=n]) Selected by [y]: - PM_SLEEP_SMP [=y] && SMP [=y] && (ARCH_SUSPEND_POSSIBLE [=y] || ARCH_HIBERNATION_POSSIBLE [=y]) && PM_SLEEP [=y] Please begin including Kconfig warnings. I have asked previously but... thanks. Hi Randy, We have added Kconfig warnings in reports now. please see another report: https://lore.kernel.org/linux-block/202012170150.y7ycoei9-...@intel.com/ Best Regards, Rong Chen
Re: [kbuild-all] Re: drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn
On 12/15/20 11:40 PM, Willy Tarreau wrote:
Hi,
On Tue, Dec 15, 2020 at 11:05:28PM +0800, kernel test robot wrote:
Hi Willy,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 148842c98a24e508aecb929718818fbf4c2a6ff3
commit: 3744741adab6d9195551ce30e65e726c7a408421 random32: add noise from
network and scheduling activity
(...)
not sure why I'm assigned this, but the root cause is a compiler bug:
drivers/mtd/tests/subpagetest.c: In function 'mtd_subpagetest_init':
drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn
426 | }
| ^
(insn:TI 453 2652 455 (set (reg/v:SI 3 a3 [orig:304 a ] [304])
(xor:SI (reg:SI 1 a1 [orig:717 net_rand_noise ] [717])
(const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(const_int 12 [0xc]) "include/linux/prandom.h":66:4
152 {cskyv2_xorsi3}
(expr_list:REG_DEAD (reg:SI 1 a1 [orig:717 net_rand_noise ] [717])
(nil)))
during RTL pass: final
drivers/mtd/tests/subpagetest.c:426:1: internal compiler error: in
final_scan_insn_1, at final.c:3074
^^^
0x510da0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/rtl-error.c:108
0x503d22 final_scan_insn_1
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:3074
0x73f8bf final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:3153
0x73fbac final_1
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:2021
0x740618 rest_of_handle_final
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:4659
0x740618 execute
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
^
That's totally out of my scope. I suspect it might have broken a bisect
operation.
Hi Willy,
Thanks for the feedback, I have created a issue in GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98310
Best Regards,
Rong Chen
Regards,
Willy
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [kbuild-all] Re: [PATCH 1/3] Add TX sending hardware timestamp.
On 12/12/20 4:47 PM, Philip Li wrote:
On Thu, Dec 10, 2020 at 12:41:32PM +, Geva, Erez wrote:
On 10/12/2020 04:11, kernel test robot wrote:
Hi Erez,
Thank you for the patch! Yet something to improve:
Thanks for the robot,
as we rarely use clang for kernel. It is very helpful.
[auto build test ERROR on b65054597872ce3aefbc6a666385eabdf9e288da]
url:
https://github.com/0day-ci/linux/commits/Erez-Geva/Add-sending-TX-hardware-timestamp-for-TC-ETF-Qdisc/20201210-000521
I can not find this commit
Hi Erez,
The url has been recovered now.
Best Regards,
Rong Chen
base:b65054597872ce3aefbc6a666385eabdf9e288da
config: mips-randconfig-r026-20201209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
1968804ac726e7674d5de22bc2204b45857da344)
However the clang in
https://download.01.org/0day-ci/cross-package/clang-latest/clang.tar.xz is
version 11
Sorry that these are issues at our side, including the branch/commit missing.
The push to download.01.org failed and did not really work, we will look for
recovering them.
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
Your make cross script tries to download the clang every time.
Please separate the download (which is ~400 MB and 2 GB after open) from the
compilation.
Hi Erez, thanks for your feedback, we will improve the reproduction
side per these suggestions.
Please use "wget" follow your own instructions in this email.
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://github.com/0day-ci/linux/commit/8a8f634bc74db16dc551cfcf3b63c1183f98eaac
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Erez-Geva/Add-sending-TX-hardware-timestamp-for-TC-ETF-Qdisc/20201210-000521
This branch is absent
git checkout 8a8f634bc74db16dc551cfcf3b63c1183f98eaac
This commit as well
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
I use Debian 10.7.
I usually compile with GCC. I have not see any errors.
When I use clang 11 from download.01.org I get a crash right away.
Please add a proper instructions how to use clang on Debian or provide
a Docker container with updated clang for testing.
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
net/core/sock.c:2383:7: error: use of undeclared identifier 'SCM_HW_TXTIME';
did you mean 'SOCK_HW_TXTIME'?
case SCM_HW_TXTIME:
^
SOCK_HW_TXTIME
include/net/sock.h:862:2: note: 'SOCK_HW_TXTIME' declared here
SOCK_HW_TXTIME,
^
1 error generated.
vim +2383 net/core/sock.c
2351
2352int __sock_cmsg_send(struct sock *sk, struct msghdr *msg,
struct cmsghdr *cmsg,
2353 struct sockcm_cookie *sockc)
2354{
2355u32 tsflags;
2356
2357switch (cmsg->cmsg_type) {
2358case SO_MARK:
2359if (!ns_capable(sock_net(sk)->user_ns,
CAP_NET_ADMIN))
2360return -EPERM;
2361if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
2362return -EINVAL;
2363sockc->mark = *(u32 *)CMSG_DATA(cmsg);
2364break;
2365case SO_TIMESTAMPING_OLD:
2366if (cmsg->cmsg_len != CMSG_LEN(sizeof(u32)))
2367return -EINVAL;
2368
2369tsflags = *(u32 *)CMSG_DATA(cmsg);
2370if (tsflags & ~SOF_TIMESTAMPING_TX_RECORD_MASK)
2371return -EINVAL;
2372
2373sockc->tsflags &=
~SOF_TIMESTAMPING_TX_RECORD_MASK;
2374sockc->tsflags |= tsflags;
2375break;
2376case SCM_TXTIME:
2377if (!sock_flag(sk, SOCK_TXTIME))
2378return -EINVAL;
2379if (cmsg->cmsg_len != CMSG_LEN(sizeof(u64)))
2380return -EINVAL;
2381sockc->transmit_time = get_unaligned((u64
*)CMSG_DATA(cmsg));
2382break;
2383case SCM_HW_TXTIME:
2384if (!sock_flag(sk, SOCK_HW_TXTIME))
2385return -EINVAL;
Re: [kbuild-all] Re: [PATCH] usb: cdns3: Adds missing __iomem markers
On 12/15/20 1:58 PM, Peter Chen wrote: On 20-12-14 23:35:56, kernel test robot wrote: Hi Pawel, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20201211] [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 v5.10] Sorry, I changed the branch name to reflect the branch does not only queue chipidea USB patches. next branch: for-usb-next fixes branch: for-usb-fixes Peter Hi Peter, Thanks for the feedback, we'll update it on the CI system. Best Regards, Rong Chen [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit-scm.com%2Fdocs%2Fgit-format-patchdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Cy3huYNzWiJ57OKmzmaleCT14gcFr8RyYDnqTfZWNG4%3Dreserved=0] url: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommits%2FPawel-Laszczak%2Fusb-cdns3-Adds-missing-__iomem-markers%2F20201214-205353data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=x5XoDUUskeGteTFaPjgS24Hrbb712XqMqaIkqwXWu14%3Dreserved=0 base:3cc2bd440f2171f093b3a8480a4b54d8c270ed38 config: riscv-allmodconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.crossdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jAavg0T3itnjkbHXADvePHHgtYeqiVTBt%2BoatHT0VHU%3Dreserved=0 -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommit%2F315bfcf1e0604de6ecfc1856cf5820876390f16cdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SQ75IXxfld6HMRIFkZ%2F8Z4YqxnFP%2F%2BZ%2BsYZIycNeO%2FA%3Dreserved=0 git remote add linux-review https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinuxdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZVS4723WbEO03hbsLXJ%2B%2FmB5EZElulY7lAsMEMatiko%3Dreserved=0 git fetch --no-tags linux-review Pawel-Laszczak/usb-cdns3-Adds-missing-__iomem-markers/20201214-205353 git checkout 315bfcf1e0604de6ecfc1856cf5820876390f16c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from arch/riscv/include/asm/io.h:23, from include/linux/io.h:13, from include/linux/irq.h:20, from include/asm-generic/hardirq.h:17, from ./arch/riscv/include/generated/asm/hardirq.h:1, from include/linux/hardirq.h:10, from include/linux/interrupt.h:11, from drivers/usb/cdns3/drd.c:13: drivers/usb/cdns3/drd.c: In function 'cdns_otg_disable_irq': drivers/usb/cdns3/drd.c:159:31: error: dereferencing pointer to incomplete type 'struct cdns_otg_irq_reg' 159 | writel(0, >otg_irq_regs->ien); | ^~ arch/riscv/include/asm/mmio.h:93:76: note: in definition of macro 'writel_cpu' 93 | #define writel_cpu(v, c) ((void)__raw_writel((__force u32)cpu_to_le32(v), (c))) | ^ drivers/usb/cdns3/drd.c:159:2: note: in expansion of macro 'writel' 159 | writel(0, >otg_irq_regs->ien); | ^~ drivers/usb/cdns3/drd.c: In function 'cdns_drd_init': drivers/usb/cdns3/drd.c:409:22: error: assignment to 'struct cdns_otg_irq_reg *' from incompatible pointer type 'struct cdns_otg_irq_regs *' [-Werror=incompatible-pointer-types] 409 |
Re: [kbuild-all] Re: drivers/net/wan/slic_ds26522.c:205:12: warning: stack frame size of 12288 bytes in function 'slic_ds26522_probe'
On 11/24/20 7:51 PM, Andrey Konovalov wrote: On Tue, Nov 24, 2020 at 9:02 AM Rong Chen wrote: On 11/23/20 10:15 PM, Andrey Konovalov wrote: On Thu, Nov 19, 2020 at 11:16 PM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3494d58865ad4a47611dbb427b214cc5227fa5eb commit: cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 kasan: allow enabling stack tagging for tag-based mode date: 3 months ago config: arm64-randconfig-r002-20201119 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project b2613fb2f0f53691dd0211895afbb9413457fca7) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/net/wan/slic_ds26522.c:205:12: warning: stack frame size of 12288 bytes in function 'slic_ds26522_probe' [-Wframe-larger-than=] static int slic_ds26522_probe(struct spi_device *spi) ^ 1 warning generated. -- drivers/gpu/drm/panel/panel-sitronix-st7789v.c:194:12: warning: stack frame size of 18352 bytes in function 'st7789v_prepare' [-Wframe-larger-than=] static int st7789v_prepare(struct drm_panel *panel) ^ 1 warning generated. Same issue as reported previously. Copying my response from the other email just in case: This is the same issue in LLVM that was reported by Arnd for generic KASAN (also see KASAN_STACK_ENABLE option description). By default KASAN shouldn't have stack instrumentation enabled unless KASAN_STACK_ENABLE is specified. Perhaps it makes sense to disable it for KASAN_SW_TAGS config on the kernel test robot. [1] https://bugs.llvm.org/show_bug.cgi?id=38809 Hi Andrey, Thanks for the explanation, we'll disable CONFIG_KASAN_SW_TAGS. Hi Rong, No, no, if you have a CONFIG_KASAN_SW_TAGS-based config - keep it enabled, just disable CONFIG_KASAN_STACK_ENABLE to avoid these stack overflows. Thanks! Ah.. my fault, will disable CONFIG_KASAN_STACK_ENABLE for this case. Best Regards, Rong Chen
Re: [kbuild-all] Re: sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: consider using resource_size() here
On 11/24/20 5:13 PM, Andy Shevchenko wrote: On Tue, Nov 24, 2020 at 10:06 AM Rong Chen wrote: On 11/23/20 7:41 PM, Rojewski, Cezary wrote: On 2020-11-23 11:53 AM, Andy Shevchenko wrote: On Sun, Nov 22, 2020 at 03:52:27AM +0800, kernel test robot wrote: ... This sounds like false positive. From where it gets the idea of resource_size() for the *start* offset?! Indeed it is false positive. I've already explained this in: RE: [bug report] ASoC: Intel: catpt: Firmware loading and context restore https://www.spinics.net/lists/alsa-devel/msg117145.html Thanks a lot, we'll ignore the warning next time. I think the proper solution here is to notify smatch upstream to fix the tool. +Dan Carpenter Hi Dan, Could you take a look at this? the original report is at https://lore.kernel.org/lkml/202011220325.ob7oeteq-...@intel.com/ Best Regards, Rong Chen
Re: [kbuild-all] Re: drivers/net/wan/slic_ds26522.c:205:12: warning: stack frame size of 12288 bytes in function 'slic_ds26522_probe'
On 11/23/20 10:15 PM, Andrey Konovalov wrote: On Thu, Nov 19, 2020 at 11:16 PM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3494d58865ad4a47611dbb427b214cc5227fa5eb commit: cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 kasan: allow enabling stack tagging for tag-based mode date: 3 months ago config: arm64-randconfig-r002-20201119 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project b2613fb2f0f53691dd0211895afbb9413457fca7) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout cae9dc35ed9ff82a99754e51d57ff6c332e1f7e4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/net/wan/slic_ds26522.c:205:12: warning: stack frame size of 12288 bytes in function 'slic_ds26522_probe' [-Wframe-larger-than=] static int slic_ds26522_probe(struct spi_device *spi) ^ 1 warning generated. -- drivers/gpu/drm/panel/panel-sitronix-st7789v.c:194:12: warning: stack frame size of 18352 bytes in function 'st7789v_prepare' [-Wframe-larger-than=] static int st7789v_prepare(struct drm_panel *panel) ^ 1 warning generated. Same issue as reported previously. Copying my response from the other email just in case: This is the same issue in LLVM that was reported by Arnd for generic KASAN (also see KASAN_STACK_ENABLE option description). By default KASAN shouldn't have stack instrumentation enabled unless KASAN_STACK_ENABLE is specified. Perhaps it makes sense to disable it for KASAN_SW_TAGS config on the kernel test robot. [1] https://bugs.llvm.org/show_bug.cgi?id=38809 Hi Andrey, Thanks for the explanation, we'll disable CONFIG_KASAN_SW_TAGS. Best Regards, Rong Chen
Re: [kbuild-all] Re: sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: consider using resource_size() here
On 11/23/20 7:41 PM, Rojewski, Cezary wrote: On 2020-11-23 11:53 AM, Andy Shevchenko wrote: On Sun, Nov 22, 2020 at 03:52:27AM +0800, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 27bba9c532a8d21050b94224ffd310ad0058c353 commit: 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 ASoC: Intel: Select catpt and deprecate haswell date: 7 weeks ago config: x86_64-randconfig-m001-20201122 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot smatch warnings: sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: consider using resource_size() here ... a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 652 for (res = cdev->dram.child; res->sibling; res = res->sibling) a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 653 ; a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 @654 __request_region(>dram, res->end + 1, This sounds like false positive. From where it gets the idea of resource_size() for the *start* offset?! Indeed it is false positive. I've already explained this in: RE: [bug report] ASoC: Intel: catpt: Firmware loading and context restore https://www.spinics.net/lists/alsa-devel/msg117145.html Hi all, Thanks a lot, we'll ignore the warning next time. Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH v6] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces
On 11/15/20 7:41 PM, Vincent MAILHOL wrote:
The report from Intel's test robot is a false positive.
On Sun. 15 Nov. 2020 at 03:12, kernel test robot wrote:
Hi Vincent,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on bff6f1db91e330d7fba56f815cdbc412c75fe163 v5.10-rc3
next-20201113]
[If your patch is applied to the wrong git tree, kindly drop us a note.
Patch is applied to the wrong git tree. It is based on the testing
branch of linux-can-next:
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=testing
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
I did so (c.f. the base-commit and prerequisite-patch-id tags at the
bottom of the patch). While the base-commit was taken into account,
the prerequisite-patch-id tags seem to have been ignored.
FYI, I used the below command to generate the patch.
git format-patch --base=bff6f1db91e330d7fba56f815cdbc412c75fe163 -v6
-o patch/v6 HEAD~1
Hi Vincent,
Thanks for the feedback, we'll fix the problem asap.
Best Regards,
Rong Chen
Yours sincerely,
Vincent Mailhol
url:
https://github.com/0day-ci/linux/commits/Vincent-Mailhol/can-usb-etas_es58X-add-support-for-ETAS-ES58X-CAN-USB-interfaces/20201114-232854
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
config: x86_64-randconfig-a005-20201115 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
9a85643cd357e412cff69067bb5c4840e228c2ab)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/80a9b72580bad04e879752fa5c54d278b486e2bb
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Vincent-Mailhol/can-usb-etas_es58X-add-support-for-ETAS-ES58X-CAN-USB-interfaces/20201114-232854
git checkout 80a9b72580bad04e879752fa5c54d278b486e2bb
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/net/can/usb/etas_es58x/es58x_core.c:745:12: error: use of undeclared
identifier 'CAN_MAX_RAW_DLC'
if (dlc > CAN_MAX_RAW_DLC) {
^
drivers/net/can/usb/etas_es58x/es58x_core.c:748:22: error: use of
undeclared identifier 'CAN_MAX_RAW_DLC'
__func__, dlc, CAN_MAX_RAW_DLC);
^
drivers/net/can/usb/etas_es58x/es58x_core.c:753:9: error: implicit declaration
of function 'can_fd_dlc2len' [-Werror,-Wimplicit-function-declaration]
len = can_fd_dlc2len(dlc);
^
drivers/net/can/usb/etas_es58x/es58x_core.c:753:9: note: did you mean
'can_dlc2len'?
include/linux/can/dev.h:190:4: note: 'can_dlc2len' declared here
u8 can_dlc2len(u8 can_dlc);
^
drivers/net/can/usb/etas_es58x/es58x_core.c:756:9: error: implicit declaration
of function 'can_cc_dlc2len' [-Werror,-Wimplicit-function-declaration]
len = can_cc_dlc2len(dlc);
^
drivers/net/can/usb/etas_es58x/es58x_core.c:756:9: note: did you mean
'can_dlc2len'?
include/linux/can/dev.h:190:4: note: 'can_dlc2len' declared here
u8 can_dlc2len(u8 can_dlc);
^
drivers/net/can/usb/etas_es58x/es58x_core.c:775:3: error: implicit declaration
of function 'can_frame_set_cc_len' [-Werror,-Wimplicit-function-declaration]
can_frame_set_cc_len(ccf, dlc,
es58x_priv(netdev)->can.ctrlmode);
^
5 errors generated.
--
drivers/net/can/usb/etas_es58x/es581_4.c:385:20: error: implicit declaration of
function 'can_get_cc_dlc' [-Werror,-Wimplicit-function-declaration]
tx_can_msg->dlc = can_get_cc_dlc(cf, priv->can.ctrlmode);
^
drivers/net/can/usb/etas_es58x/es581_4.c:387:41: error: no member named 'len'
in 'struct can_frame'
memcpy(tx_can_msg->data, cf->data, cf->len);
~~ ^
drivers/net/can/usb/etas_es58x/es581_4.c:391:13: error: implicit declaration of
function 'can_cc_dlc2len' [-Werror,-Wimplicit-function-declaration]
msg_len += es581_4_sizeof_rx_tx_msg(*tx_can_msg);
^
drivers/net/can/usb/etas_es58x/es581_4.c:30:29: note: expanded from macro
'es581_4_sizeof_rx_tx_msg'
offsetof(typeof(msg), da
Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression
On 11/2/20 5:27 PM, Michal Hocko wrote:
On Mon 02-11-20 17:15:43, kernel test robot wrote:
Greeting,
FYI, we noticed a -22.7% regression of will-it-scale.per_process_ops due to
commit:
commit: bd0b230fe14554bfffbae54e19038716f96f5a41 ("mm/memcg: unify swap and memsw
page counters")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
I really fail to see how this can be anything else than a data structure
layout change. There is one counter less.
btw. are cgroups configured at all? What would be the configuration?
Hi Michal,
We used the default configure of cgroups, not sure what configuration
you want,
could you give me more details? and here is the cgroup info of
will-it-scale process:
$ cat /proc/3042/cgroup
12:hugetlb:/
11:memory:/system.slice/lkp-bootstrap.service
10:devices:/system.slice/lkp-bootstrap.service
9:cpuset:/
8:perf_event:/
7:rdma:/
6:freezer:/
5:pids:/system.slice/lkp-bootstrap.service
4:net_cls,net_prio:/
3:blkio:/
2:cpu,cpuacct:/
1:name=systemd:/system.slice/lkp-bootstrap.service
Best Regards,
Rong Chen
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On 10/30/20 10:58 PM, Matthew Wilcox wrote: On Fri, Oct 30, 2020 at 10:02:45PM +0800, Chen, Rong A wrote: On 10/30/2020 9:17 PM, Matthew Wilcox wrote: On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: Details are as below: --> To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Do you actually test these instructions before you send them out? hdd_partitions: "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part 1" ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" rootfs_partition: "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" That's _very_ specific to a given machine. I'm not familiar with this test, so I don't know what I need to change. Hi Matthew, Sorry about that, I copied the job.yaml file from the server, the right way to do is to set your disk partitions in the yaml, please see https://github.com/intel/lkp-tests#run-your-own-disk-partitions. there is another reproduce script attached in the original mail for your reference. Can you reproduce this? Here's my results: # stress-ng "--timeout" "100" "--times" "--verify" "--metrics-brief" "--sequential" "96" "--class" "memory" "--minimize" "--exclude" "spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib" stress-ng: info: [7670] disabled 'oom-pipe' as it may hang or reboot the machine (enable it with the --pathological option) stress-ng: info: [7670] dispatching hogs: 96 tmpfs stress-ng: info: [7670] successful run completed in 100.23s (1 min, 40.23 secs) stress-ng: info: [7670] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [7670] (secs)(secs)(secs) (real time) (usr+sys time) stress-ng: info: [7670] tmpfs 8216100.10368.02230.89 82.0813.72 stress-ng: info: [7670] for a 100.23s run time: stress-ng: info: [7670] 601.38s available CPU time stress-ng: info: [7670] 368.71s user time ( 61.31%) stress-ng: info: [7670] 231.55s system time ( 38.50%) stress-ng: info: [7670] 600.26s total time ( 99.81%) stress-ng: info: [7670] load average: 78.32 27.87 10.10 Hi Matthew, IIUC, yes, we can reproduce it, here is the result from the server: $ stress-ng --timeout 100 --times --verify --metrics-brief --sequential 96 --class memory --minimize --exclude spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib stress-ng: info: [2765] disabled 'oom-pipe' as it may hang or reboot the machine (enable it with the --pathological option) stress-ng: info: [2765] dispatching hogs: 96 tmpfs stress-ng: info: [2765] successful run completed in 104.67s (1 min, 44.67 secs) stress-ng: info: [2765] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [2765] (secs) (secs) (secs) (real time) (usr+sys time) stress-ng: info: [2765] tmpfs 363 103.02 622.07 7289.85 3.52 0.05 stress-ng: info: [2765] for a 104.67s run time: stress-ng: info: [2765] 10047.98s available CPU time stress-ng: info: [2765] 622.46s user time ( 6.19%) stress-ng: info: [2765] 7290.66s system time ( 72.56%) stress-ng: info: [2765] 7913.12s total time ( 78.75%) stress-ng: info: [2765] load average: 79.62 28.89 10.45 we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and parent commit. Best Regards, Rong Chen
Re: [kbuild-all] Re: drivers/pinctrl/renesas/pinctrl-rzn1.c:183:52: sparse: sparse: dubious: x | !y
On 10/20/20 3:49 PM, Geert Uytterhoeven wrote: Hi Kernel Test Robot, On Tue, Oct 20, 2020 at 9:42 AM kernel test robot wrote: First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 270315b8235e3d10c2e360cff56c2f9e0915a252 commit: 077365a941166f3a7f5894017f9d26d17cdec00e pinctrl: Rename sh-pfc to renesas date: 5 weeks ago config: x86_64-randconfig-s032-20201020 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=077365a941166f3a7f5894017f9d26d17cdec00e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 077365a941166f3a7f5894017f9d26d17cdec00e # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/pinctrl/renesas/pinctrl-rzn1.c:183:52: sparse: sparse: dubious: x | !y drivers/pinctrl/renesas/pinctrl-rzn1.c:189:52: sparse: sparse: dubious: x | !y This is a false positive, cfr. https://lore.kernel.org/linux-renesas-soc/CAMuHMdV=awj9epl9gaa-vsmlluzky4ip2337am8a7ktxg7y...@mail.gmail.com/ Hi Geert, Thanks for the information, we'll double check such warning in the future. Best Regards, Rong Chen
Re: [tip:x86/pti] BUILD SUCCESS WITH WARNING 767d46ab566dd489733666efe48732d523c8c332
Hi Boris,
On 9/17/20 9:37 PM, Philip Li wrote:
On Thu, Sep 17, 2020 at 10:00:44AM +0200, Borislav Petkov wrote:
On Thu, Sep 17, 2020 at 03:36:20PM +0800, Philip Li wrote:
The 2nd type is this one, which is a summarized report of head
to provide an overview. Most of time, repo owner can receive the
bisected mail. For this time, the issue is reported against peterz-queue
repo which has this 767d46ab56 head firstly. Since the head later appears
in tip, we just gather all issues and send the summary to tip related
recipients. But no more bisected mail.
Yeah, but that second report is not very helpful because nowhere it says
it is a summary and nowhere it has that link you pasted above so that
some other maintainer can go look.
Always put yourself in the recipient's shoes and ask yourself: "what can
the recipient do with this report and does it have everything in there
required to be able to reproduce the issue?"
If not, then it needs changing.
thanks for the advice. We will provide update in 1-2 weeks for the progress
to make the report more informative and useful.
We have added the reported links in the report, you can find it in the
latest tip report:
[tip:master] BUILD REGRESSION 820e6f502f021417140bc8ee11f9c7be148ea844
tree/branch:https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
branch HEAD: 820e6f502f021417140bc8ee11f9c7be148ea844 Merge branch 'efi/core'
Error/Warning reports:
https://lore.kernel.org/lkml/202010112007.jdl1bsci-...@intel.com
Error/Warning in current branch:
tools/include/linux/types.h:30:18: error: typedef redefinition with different
types ('uint64_t' (aka 'unsigned long') vs '__u64' (aka 'unsigned long long'))
tools/include/linux/types.h:31:17: error: typedef redefinition with different
types ('int64_t' (aka 'long') vs '__s64' (aka 'long long'))
Error/Warning ids grouped by kconfigs:
clang_recent_errors
`-- x86_64-randconfig-a016-20201011
|--
tools-include-linux-types.h:error:typedef-redefinition-with-different-types-(-int64_t-(aka-long-)-vs-__s64-(aka-long-long-))
`--
tools-include-linux-types.h:error:typedef-redefinition-with-different-types-(-uint64_t-(aka-unsigned-long-)-vs-__u64-(aka-unsigned-long-long-))
Best Regards,
Rong Chen
We will consider how to show useful produce info in summary report as
the feedback here, which is quite useful, such like pointing to the
bisected mail. This would take some time, and we will add to our TODO
as high priority.
Yes, that would be much appreciated. You can also tag your reports with
a unique hash which is then in an URL so that one can go and download the
.config and what else is needed. For example...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Re: [kbuild-all] Re: drivers/power/supply/mp2629_charger.c:522:9: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
On 10/9/20 10:27 PM, Andy Shevchenko wrote: On Fri, Oct 9, 2020 at 4:23 PM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 549738f15da0e5a00275977623be199fbbf7df50 commit: 3bc6d790c39dfc4539c36525e6bcb617abbae467 power: supply: Add support for mps mp2629 battery charger date: 4 months ago :: branch date: 12 hours ago :: commit date: 4 months ago compiler: sh4-linux-gcc (GCC) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot ... 3bc6d790c39dfc Saravanan Sekar 2020-05-26 514 unsigned int rval; 3bc6d790c39dfc Saravanan Sekar 2020-05-26 515 int ret; 3bc6d790c39dfc Saravanan Sekar 2020-05-26 516 3bc6d790c39dfc Saravanan Sekar 2020-05-26 517 ret = regmap_read(charger->regmap, MP2629_REG_IMPEDANCE_COMP, ); 3bc6d790c39dfc Saravanan Sekar 2020-05-26 518 if (ret) 3bc6d790c39dfc Saravanan Sekar 2020-05-26 519 return ret; 3bc6d790c39dfc Saravanan Sekar 2020-05-26 520 3bc6d790c39dfc Saravanan Sekar 2020-05-26 521 rval = (rval >> 4) * 10; 3bc6d790c39dfc Saravanan Sekar 2020-05-26 @522 return sprintf(buf, "%d mohm\n", rval); 3bc6d790c39dfc Saravanan Sekar 2020-05-26 523 } Right, should be %u. Can LKP generate this type of patches? Hi Andy, Thanks for the advice, is there a auto correct tool to do such thing? I afraid we can't cover all the circumstances. Best Regards, Rong Chen
Re: [kbuild-all] Re: arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'
On 10/10/20 11:49 AM, Randy Dunlap wrote: On 10/9/20 8:19 PM, Rong Chen wrote: On 10/8/20 3:15 PM, Pavel Machek wrote: Hi! tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c85fb28b6f999db9928b841f63f1beeb3074eeca commit: 92a81562e695628086acb92f95090ab09d9b9ec0 leds: lp55xx: Add multicolor framework support to lp55xx date: 3 months ago config: arc-randconfig-r035-20201008 (attached as .config) compiler: arceb-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92a81562e695628086acb92f95090ab09d9b9ec0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 92a81562e695628086acb92f95090ab09d9b9ec0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Hi robot. Do you have human around to talk to? All errors (new ones prefixed by >>): arceb-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.o: in function `in_irqentry_text': lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to What is going on here? Did you just start testing arc? The commit is... really old. Hi Pavel, Only this error "arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'" was found in this commit, other errors are for reference only, and the test config is a rand config, so it's discovered by chance. Hi, Just for the record, I could not reproduce the build error with the config file that was provided. Hi Randy, I can reproduce it with the above reproduce steps: ➜ linux git:(92a81562e695) ✗ make CROSS_COMPILE=/home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf- ARCH=arc CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh CHK include/generated/compile.h GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': /home/nfs/linux/lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: lib/stackdepot.o: in function `in_irqentry_text': /home/nfs/linux/lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: drivers/leds/leds-lp55xx-common.o: in function `devm_led_classdev_register': /home/nfs/linux/./include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext' /home/nfs/0day/gcc-9.3.0-nolibc/arceb-elf/bin/arceb-elf-ld: /home/nfs/linux/./include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext' make: *** [Makefile:1139: vmlinux] Error 1 Best Regards, Rong Chen
Re: [kbuild-all] Re: arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'
On 10/8/20 3:15 PM, Pavel Machek wrote: Hi! tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c85fb28b6f999db9928b841f63f1beeb3074eeca commit: 92a81562e695628086acb92f95090ab09d9b9ec0 leds: lp55xx: Add multicolor framework support to lp55xx date: 3 months ago config: arc-randconfig-r035-20201008 (attached as .config) compiler: arceb-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92a81562e695628086acb92f95090ab09d9b9ec0 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 92a81562e695628086acb92f95090ab09d9b9ec0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Hi robot. Do you have human around to talk to? All errors (new ones prefixed by >>): arceb-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.c:331: undefined reference to `__irqentry_text_start' arceb-elf-ld: lib/stackdepot.o: in function `in_irqentry_text': lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:323: undefined reference to `__irqentry_text_end' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:324: undefined reference to `__softirqentry_text_start' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to `__softirqentry_text_end' arceb-elf-ld: lib/stackdepot.c:325: undefined reference to What is going on here? Did you just start testing arc? The commit is... really old. Hi Pavel, Only this error "arceb-elf-ld: include/linux/leds.h:193: undefined reference to `devm_led_classdev_register_ext'" was found in this commit, other errors are for reference only, and the test config is a rand config, so it's discovered by chance. Best Regards, Rong Chen
Re: [PATCH v3 3/9] lib: zstd: Upgrade to latest upstream zstd version 1.4.6
Hi Nick, Thanks for the feedback, we'll take a look at these errors that maybe false positives. Best Regards, Rong Chen On 9/24/20 11:05 AM, Nick Terrell wrote: On Wed, Sep 23, 2020 at 7:28 PM kernel test robot wrote: Hi Nick, Thank you for the patch! Yet something to improve: [auto build test ERROR on kdave/for-next] [also build test ERROR on f2fs/dev-test linus/master v5.9-rc6 next-20200923] [cannot apply to cryptodev/master crypto/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nick-Terrell/Update-to-zstd-1-4-6/20200924-064102 base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next config: h8300-randconfig-p002-20200923 (attached as .config) compiler: h8300-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): h8300-linux-ld: lib/zstd/common/entropy_common.o: in function `MEM_swap32': lib/zstd/common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/common/fse_decompress.o: in function `MEM_swap32': lib/zstd/common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/common/fse_decompress.o:lib/zstd/common/mem.h:179: more undefined references to `__bswapsi2' follow h8300-linux-ld: lib/zstd/compress/zstd_compress.o: in function `MEM_swap64': lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/zstd_compress.o: in function `MEM_swap32': lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/zstd_compress.o:lib/zstd/compress/../common/mem.h:179: more undefined references to `__bswapsi2' follow h8300-linux-ld: lib/zstd/compress/zstd_double_fast.o: in function `MEM_swap64': lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/zstd_double_fast.o:lib/zstd/compress/../common/mem.h:192: more undefined references to `__bswapdi2' follow h8300-linux-ld: lib/zstd/compress/zstd_opt.o: in function `MEM_swap32': lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/compress/zstd_opt.o: in function `MEM_swap64': lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/../common/mem.h:192: undefined reference to `__bswapdi2' h8300-linux-ld: lib/zstd/compress/zstd_opt.o:lib/zstd/compress/../common/mem.h:192: more undefined references to `__bswapdi2' follow h8300-linux-ld: lib/zstd/decompress/huf_decompress.o: in function `MEM_swap32': lib/zstd/decompress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/decompress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/decompress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/decompress/../common/mem.h:179: undefined reference to `__bswapsi2' h8300-linux-ld: lib/zstd/decompress/../common/mem.h:179: undefined ref
Re: drivers/gpu/drm/ingenic/ingenic-drm-drv.c:undefined reference to `clk_get_parent'
On 9/15/20 9:20 PM, Paul Cercueil wrote: Hi, Le mer. 9 sept. 2020 à 10:28, kernel test robot a écrit : Hi Paul, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8 commit: 54fe894219903e32f5154265f46ed1eb5cdc2f5f drm/ingenic: Rename ingenic-drm.c to ingenic-drm-drv.c date: 8 weeks ago config: mips-randconfig-r022-20200909 (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 54fe894219903e32f5154265f46ed1eb5cdc2f5f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mips-linux-ld: drivers/gpu/drm/ingenic/ingenic-drm-drv.o: in function `ingenic_drm_probe': drivers/gpu/drm/ingenic/ingenic-drm-drv.c:(.text+0xc90): undefined reference to `clk_get_parent' mips-linux-ld: drivers/mmc/host/mtk-sd.o: in function `msdc_set_mclk': drivers/mmc/host/mtk-sd.c:(.text+0x26fc): undefined reference to `clk_get_parent' mips-linux-ld: drivers/mmc/host/mtk-sd.c:(.text+0x27c0): undefined reference to `clk_get_parent' clk_get_parent() is either provided if CONFIG_HAVE_CLK, or it's a inline dummy in clk.h otherwise. Given it chokes on other drivers too, I would say this is a false positive. -Paul Hi Paul, Sorry for the inconvenience, the bot can't distinguish the errors yet if only file name changed. we'll continue to improve it. Best Regards, Rong Chen
Re: [kbuild-all] Re: include/linux/spinlock.h:346:2: error: invalid type argument of unary (have 'spinlock_t' {aka 'struct spinlock'})
On 9/16/20 3:27 PM, Sebastian Andrzej Siewior wrote:
On 2020-09-16 15:18:56 [+0800], kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fc4f28bb3daf3265d6bc5f73b497306985bb23ab
commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type
checks
date: 6 months ago
config: mips-randconfig-r011-20200916 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout de8f5e4f2dc1f032b46afda0a78cab5456974f89
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/pcmcia/vrc4173_cardu.c:41:
This driver does not compile even before this commit.
Yes, it is still broken and yes it has nothing to do with this commit.
Hi Sebastian,
Only the errors prefixed by '>>' are from this commit, other errors are
for reference only.
include/linux/spinlock.h:346:2: error: invalid type argument of unary '*' (have
'spinlock_t' {aka 'struct spinlock'})
346 | *(_lock) = __SPIN_LOCK_UNLOCKED(_lock); \
Best Regards,
Rong Chen
Re: [tip:x86/seves] BUILD SUCCESS WITH WARNING e6eb15c9ba3165698488ae5c34920eea20eaa38e
On Tue, Sep 15, 2020 at 03:55:19PM +0200, Borislav Petkov wrote: > On Tue, Sep 15, 2020 at 09:42:56PM +0800, kernel test robot wrote: > > tree/branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/seves > > branch HEAD: e6eb15c9ba3165698488ae5c34920eea20eaa38e KVM: nSVM: Avoid > > freeing uninitialized pointers in svm_set_nested_state() > > > > Warning in current branch: > > > > arch/x86/kernel/sev-es.o: warning: objtool: > > ist_exc_vmm_communication()+0x12: unreachable instruction > > > > Warning ids grouped by kconfigs: > > > > clang_recent_errors > > `-- x86_64-randconfig-r001-20200913 > > `-- > > arch-x86-kernel-sev-es.o:warning:objtool:ist_exc_vmm_communication():unreachable-instruction > > Guys, can you get me that config pls? > Hi Boris, I attached the config for your reference. Best Regards, Rong Chen # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.9.0-rc4 Kernel Configuration # CONFIG_CC_VERSION_TEXT="clang version 12.0.0 (git://gitmirror/llvm_project d6fadc49e3d7eb0977bca3ff92bf156bd059fcd4)" CONFIG_GCC_VERSION=0 CONFIG_LD_VERSION=0 CONFIG_CC_IS_CLANG=y CONFIG_LD_IS_LLD=y CONFIG_CLANG_VERSION=12 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_HAVE_KERNEL_ZSTD=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set # CONFIG_KERNEL_ZSTD is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_WATCH_QUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set CONFIG_CONTEXT_TRACKING=y CONFIG_CONTEXT_TRACKING_FORCE=y # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # end of Timers subsystem # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_VIRT_CPU_ACCOUNTING_GEN=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set CONFIG_PSI=y CONFIG_PSI_DEFAULT_DISABLED=y # end of CPU/Task time and stats accounting # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_RCU=y CONFIG_TASKS_RUDE_RCU=y CONFIG_TASKS_TRACE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKHEADERS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y # CONFIG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set CONFIG_CGROUP_PIDS=y # CONFIG_CGROUP_RDMA is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CGROUP_CPUACCT is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_DEBUG=y CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_TIME_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y # CONFIG_NET_NS is not set CONFI
Re: [LKP] Re: [rcuperf] 4e88ec4a9e: UBSAN:division-overflow_in_arch/x86/include/asm/div64.h
On 8/31/20 11:50 PM, Paul E. McKenney wrote:
On Mon, Aug 31, 2020 at 08:01:22PM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 4e88ec4a9eb17527e640b063f79e5b875733eb53 ("rcuperf: Change rcuperf to
rcuscale")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+++
| | 65bd77f554 |
4e88ec4a9e |
+-+++
| boot_successes | 13 | 0
|
| boot_failures | 0 | 14
|
| UBSAN:division-overflow_in_arch/x86/include/asm/div64.h | 0 | 14
|
| error:#[##] | 0 | 14
|
| EIP:main_func.cold | 0 | 14
|
| Kernel_panic-not_syncing:Fatal_exception| 0 | 14
|
+-+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Does the patch below fix this for you?
Yes, this patch can fix the issue, and nreaders was adjusted to 1:
[ 5.953645] The force parameter has not been set to 1. The Iris
poweroff handler will not be installed.
[ 12.546587] rcu-ref-scale: --- Start of test: verbose=0 shutdown=1
holdoff=10 loops=1 nreaders=-1 nruns=30 readdelay=0
[ 12.561495] [ cut here ]
[ 12.562016] ref_scale_init: nreaders = 0, adjusted to 1
[ 12.562601] WARNING: CPU: 0 PID: 1 at kernel/rcu/refscale.c:684
ref_scale_init+0x653/0x80
Best Regards,
Rong Chen
Thanx, Paul
commit d301e320e952e2e604d83d9540e52510b0eb3d94
Author: Paul E. McKenney
Date: Thu Aug 27 09:58:19 2020 -0700
refscale: Bounds-check module parameters
The default value for refscale.nreaders is -1, which results in the code
setting the value to three-quarters of the number of CPUs. On single-CPU
systems, this results in three-quarters of the value one, which the C
language's integer arithmetic rounds to zero. This in turn results in
a divide-by-zero error.
This commit therefore adds bounds checking to the refscale module
parameters, so that if they are less than one, they are set to the
value one.
Reported-by: kernel test robot
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c
index 952595c..fb5f20d 100644
--- a/kernel/rcu/refscale.c
+++ b/kernel/rcu/refscale.c
@@ -681,6 +681,12 @@ ref_scale_init(void)
// Reader tasks (default to ~75% of online CPUs).
if (nreaders < 0)
nreaders = (num_online_cpus() >> 1) + (num_online_cpus() >> 2);
+ if (WARN_ONCE(loops <= 0, "%s: loops = %ld, adjusted to 1\n", __func__,
loops))
+ loops = 1;
+ if (WARN_ONCE(nreaders <= 0, "%s: nreaders = %d, adjusted to 1\n",
__func__, nreaders))
+ nreaders = 1;
+ if (WARN_ONCE(nruns <= 0, "%s: nruns = %d, adjusted to 1\n", __func__,
nruns))
+ nruns = 1;
reader_tasks = kcalloc(nreaders, sizeof(reader_tasks[0]),
GFP_KERNEL);
if (!reader_tasks) {
___
LKP mailing list -- l...@lists.01.org
To unsubscribe send an email to lkp-le...@lists.01.org
Re: [mm] c566586818: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
On 8/27/20 1:30 AM, Catalin Marinas wrote: On Tue, Aug 25, 2020 at 11:02:40PM -0400, Qian Cai wrote: On Aug 25, 2020, at 8:44 PM, Rong Chen wrote: I rebuilt the kernel on commit c566586818 but the error changed to "RIP: 0010:clear_page_orig+0x12/0x40", and the error can be reproduced on parent commit: Catalin, any thought? Sounds like those early kmemleak allocations cause some sort of memory corruption? I can't immediately see how but Rong implies that the error also happens on the parent commit. Does it mean the bisection isn't entirely right? Hi Catalin, The original bisection is for "BUG:kernel_hang_in_early-boot_stage" which locate to commit c566586818, and the boot will go on and meet the error "RIP: 0010:clear_page_orig+0x12/0x40" if we set CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=400, but the error shouldn't cause by commit c566586818 because we can reproduce the error on parent commit. Best Regards, Rong Chen
Re: [mm] c566586818: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
On 8/21/20 9:01 AM, Qian Cai wrote:
On Tue, Aug 18, 2020 at 08:23:51AM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: c5665868183fec689dbab9fb8505188b2c4f0757 ("mm: kmemleak: use the memory pool
for early allocations")
I might see one of those early boot failure before. In my case, the bare-metal
system was reset. Can you try to narrow down to a smaller
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE (assume 0 works if your bisecting was
correct) that works?
Hi Qian,
Adding CONFIG_EARLY_PRINTK=y to the kconfig file, and the boot hangs in
the below position:
[ 0.715834] Kernel command line: root=/dev/ram0 hung_task_panic=1
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0 watchdog_thresh=60
[ 0.719688] sysrq: sysrq always enabled.
[ 0.801005] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes, linear)
[ 0.805588] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes, linear)
[ 0.806464] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 1.080978] Memory: 12319196K/12680692K available (10243K kernel
code, 2414K rwdata, 8184K rodata, 856K init, 20772K bss, 361496K
reserved, 0K cma-reserved)
qemu-system-x86_64: terminating on signal 2
The problem disappeared if CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=400:
[ 1.064575] Kernel command line: root=/dev/ram0 hung_task_panic=1
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0 watchdog_thresh=60
[ 1.068883] sysrq: sysrq always enabled.
[ 1.108720] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes, linear)
[ 1.148852] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes, linear)
[ 1.150271] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 1.835309] Memory: 12325340K/12680692K available (10243K kernel
code, 2414K rwdata, 8192K rodata, 856K init, 14628K bss, 355352K
reserved, 0K cma-reserved)
[ 3.487078] general protection fault: [#1] DEBUG_PAGEALLOC PTI
[ 3.488185] CPU: 0 PID: 0 Comm: swapper Not tainted
5.3.0-11792-gc5665868183fe #1
[ 3.489581] RIP: 0010:lookup_address_in_pgd+0xd1/0x158
[ 3.490566] Code: 80 e0 01 0f 84 a7 00 00 00 49 89 f0 b8 11 ff ff 01
48 21 f9 49 c1 e8 12 48 c1 e0 27 41 81 e0 f8 0f 00 00 49 01 c0 49 8d 04
08 <48> f7 00 9f ff ff ff 0f 84 34 ff ff ff c7 02 02 00 00 00 48 8b 38
[ 3.494020] RSP: :8239e700 EFLAGS: 00010086
[ 3.494959] RAX: 110302110d90 RBX: 0001 RCX:
88830211
[ 3.496222] RDX: 8239e72c RSI: 88833653b000 RDI:
88833653a000
[ 3.497363] RBP: 8239e808 R08: 88800d90 R09:
00346000
[ 3.498467] R10: 0001 R11: R12:
0001
[ 3.499554] R13: R14: 88833653b000 R15:
[ 3.500638] FS: () GS:8243d000()
knlGS:
[ 3.501863] CS: 0010 DS: ES: CR0: 80050033
[ 3.503036] CR2: 8883447ff000 CR3: 0242 CR4:
06b0
[ 3.504116] DR0: DR1: DR2:
[ 3.505156] DR3: DR6: fffe0ff0 DR7:
0400
[ 3.506225] Call Trace:
[ 3.506597] Modules linked in:
[ 3.507255] random: get_random_bytes called from
init_oops_id+0x1d/0x2c with crng_init=0
[ 3.508734] ---[ end trace ]---
Best Regards,
Rong Chen
Re: [clk] a2499eff4b: BUG:kernel_NULL_pointer_dereference,address
On 8/19/20 11:13 AM, Stephen Boyd wrote:
Quoting kernel test robot (2020-08-11 01:49:44)
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: a2499eff4b30a85d56e4466e6ca4746c72a347c6 ("[PATCH v2] clk: samsung: Keep top
BPLL mux on Exynos542x enabled")
url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/clk-samsung-Keep-top-BPLL-mux-on-Exynos542x-enabled/20200807-213239
base: https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git clk-next
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
Cool robot. But this doesn't look related to the patch at all?
Hi Stephen,
Sorry for the inconvenience, you are right, we run more times
on the parent commit and can reproduce the error too.
Best Regards,
Rong Chen
Re: [kbuild-all] Re: arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
On 8/12/20 11:09 AM, Gao Xiang wrote:
Hi,
On Wed, Aug 12, 2020 at 09:49:38AM +0800, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
staging
date: 12 months ago
config: sparc64-randconfig-s032-20200812 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
fs/erofs/utils.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
--
fs/erofs/zdata.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
bits from constant value (5f0edead becomes ad)
vim +161 arch/sparc/include/asm/cmpxchg_64.h
d550bbd40c0e10 David Howells 2012-03-28 155
d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
unsigned long old, unsigned long new, int size)
d550bbd40c0e10 David Howells 2012-03-28 158 {
d550bbd40c0e10 David Howells 2012-03-28 159switch (size) {
a12ee2349312d7 Babu Moger2017-05-24 160case 1:
a12ee2349312d7 Babu Moger2017-05-24 @161return
__cmpxchg_u8(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 162case 4:
d550bbd40c0e10 David Howells 2012-03-28 163return
__cmpxchg_u32(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 164case 8:
d550bbd40c0e10 David Howells 2012-03-28 165return
__cmpxchg_u64(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 166}
d550bbd40c0e10 David Howells 2012-03-28 167
__cmpxchg_called_with_bad_pointer();
d550bbd40c0e10 David Howells 2012-03-28 168return old;
d550bbd40c0e10 David Howells 2012-03-28 169 }
d550bbd40c0e10 David Howells 2012-03-28 170
Again, I have no idea how to deal with that in my current
gatekeeping code.
I got these reports, but I cannot help to resolve that.
Even I don't know if that's another sparse issue (since I
only got such reports on sparc and alpha arch, but no x86
or arm64.)
https://lore.kernel.org/r/202007251532.y5a10zoo%25...@intel.com
https://lore.kernel.org/r/202007272132.1agbbo3u%25...@intel.com
https://lore.kernel.org/r/202008100408.wc6wgrac%25...@intel.com
https://lore.kernel.org/r/202008120933.yrvhhyoa%25...@intel.com
If no one can help that, could you please silence such reports.
It really makes me confusing.
Hi Gao Xiang,
Sorry for the inconvenience, we'll silence the reports on this commit.
Best Regards,
Rong Chen
Thanks,
Gao Xiang
:: The code at line 161 was first introduced by commit
:: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
cmpxchg_u8 SPARC
:: TO: Babu Moger
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [kbuild-all] Re: drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked 'm->lock' (orig line 516)
On 8/8/20 10:35 PM, Mike Snitzer wrote:
On Sat, Aug 08 2020 at 8:10am -0400,
kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 374117ad4736c5a4f8012cfe59fc07d9d58191d5 dm mpath: use double checked
locking in fast path
date: 4 weeks ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All 3 recent reports about smatch showing "double unlocked 'm->lock'"
appear to be bogus. Think smatch is generating false positives (and
given "Old smatch warnings" it seems it has been doing so for some
time).
In addition, does l...@intel.com no longer test linux-next? The dm-mpath
locking changes that were just merged into mainline have been in
linux-next since July 13. Why were these tests only done against
mainline?
Hi Mike,
kernel test robot still test linux-next, but the bisection worked on
linus/master and didn't check the fix in linux-next,
we'll optimize the bisection to avoid reporting this kind of problem.
Best Regards,
Rong Chen
Mike
New smatch warnings:
drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked
'm->lock' (orig line 516)
Old smatch warnings:
drivers/md/dm-mpath.c:446 choose_pgpath() error: double unlocked 'm->lock'
(orig line 416)
drivers/md/dm-mpath.c:457 choose_pgpath() error: double unlocked 'm->lock'
(orig line 403)
drivers/md/dm-mpath.c:525 multipath_clone_and_map() error: double unlocked
'm->lock' (orig line 516)
drivers/md/dm-mpath.c:526 multipath_clone_and_map() error: double unlocked
'm->lock' (orig line 524)
drivers/md/dm-mpath.c:626 __map_bio() error: double unlocked 'm->lock' (orig
line 615)
drivers/md/dm-mpath.c:627 __map_bio() error: double unlocked 'm->lock' (orig
line 615)
drivers/md/dm-mpath.c:628 __map_bio() error: double unlocked 'm->lock' (orig
line 626)
drivers/md/dm-mpath.c:629 __map_bio() error: double unlocked 'm->lock' (orig
line 628)
drivers/md/dm-mpath.c:1607 pg_init_done() error: double unlocked 'm->lock'
(orig line 1560)
drivers/md/dm-mpath.c:1707 multipath_end_io_bio() error: double unlocked
'm->lock' (orig line 1704)
drivers/md/dm-mpath.c:1988 multipath_prepare_ioctl() error: double unlocked
'm->lock' (orig line 1984)
drivers/md/dm-mpath.c:2012 multipath_prepare_ioctl() error: double unlocked
'm->lock' (orig line 2001)
vim +524 drivers/md/dm-mpath.c
498
499 /*
500 * Map cloned requests (request-based multipath)
501 */
502 static int multipath_clone_and_map(struct dm_target *ti, struct request
*rq,
503union map_info *map_context,
504struct request **__clone)
505 {
506 struct multipath *m = ti->private;
507 size_t nr_bytes = blk_rq_bytes(rq);
508 struct pgpath *pgpath;
509 struct block_device *bdev;
510 struct dm_mpath_io *mpio = get_mpio(map_context);
511 struct request_queue *q;
512 struct request *clone;
513
514 /* Do we need to select a new pgpath? */
515 pgpath = READ_ONCE(m->current_pgpath);
> 516 if (!pgpath ||
!mpath_double_check_test_bit(MPATHF_QUEUE_IO, m))
517 pgpath = choose_pgpath(m, nr_bytes);
518
519 if (!pgpath) {
520 if (must_push_back_rq(m))
521 return DM_MAPIO_DELAY_REQUEUE;
522 dm_report_EIO(m); /* Failed */
523 return DM_MAPIO_KILL;
> 524 } else if (mpath_double_check_test_bit(MPATHF_QUEUE_IO, m)
||
525mpath_double_check_test_bit(MPATHF_PG_INIT_REQUIRED,
m)) {
526 pg_init_all_paths(m);
527 return DM_MAPIO_DELAY_REQUEUE;
528 }
529
530 mpio->pgpath = pgpath;
531 mpio->nr_bytes = nr_bytes;
532
533 bdev = pgpath->path.dev->bdev;
534 q = bdev_get_queue(bdev);
535 clone = blk_get_request(q, rq->cmd_flags | REQ_NOMERGE,
536 BLK_MQ_REQ_NOWAIT);
537 if (IS_ERR(clone)) {
538 /* EBUSY, ENODEV or EWOULDBLOCK: requeue */
539 if (blk_queue_dying(q)) {
540 atomic_inc(>pg_init_in_progress);
541 activate_or_offline_path(pgpath);
542 return DM_MAPIO_DELAY_REQUEUE;
543 }
544
545 /*
546 * blk-mq's SCHED_RESTART can cover this requeue, so we
547 * needn't deal with it by DELAY_REQUEUE. Mor
Re: [kbuild-all] Re: drivers/video/fbdev/pxafb.c:916:24: sparse: sparse: incorrect type in assignment (different address spaces)
On 8/7/20 7:53 PM, Luc Van Oostenryck wrote: On Fri, Aug 07, 2020 at 06:37:36PM +0800, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 86cfccb66937dd6cbf26ed619958b9e587e6a115 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: arm-randconfig-s031-20200807 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-118-ge1578773-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/video/fbdev/pxafb.c:916:24: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void [noderef] __iomem *video_mem @@ got void * @@ drivers/video/fbdev/pxafb.c:916:24: sparse: expected void [noderef] __iomem *video_mem Hi, since late June I receive several mails per day about this commit but they are all false-positive. Commit 670d0a4b10704667765f7d18f7592993d02783aa can't introduce *new* warnings, it only change how address-spaces are displayed in sparse's warnings (for example, the address space for __user pointers were displayd as '', now it's nicely displayed as '__user', same for '__iomem', '__percpu' and '__rcu'). Isn't it possible to ignore some commits like this one? Hi Luc, Sorry for the inconvenience, we'll ignore this commit firstly. Or, even better, should it be possible to only report when a new warning is effectively added, not when its content is simply modified? If not it would be nice to be able to see the difference in a diff-like format. Thanks for your advice, we'll seriously consider it. Best Regards, Rong Chen
Re: [kbuild-all] Re: drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error: uninitialized symbol 'rc'.
On 8/8/20 8:44 PM, David Hildenbrand wrote:
Am 08.08.2020 um 13:39 schrieb kernel test robot :
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 5f1f79bbc9e26fa9412fa9522f957bb8f030c442 virtio-mem: Paravirtualized
memory hotplug
date: 9 weeks ago
config: x86_64-randconfig-m001-20200808 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Was there a delay in sending these out? The fix by Dan is long upstream:
1c3d69ab5348
Hi David,
Sorry for the inconvenience, the bot will check head commit before
reporting usually, we'll take a look.
Best Regards,
Rong Chen
New smatch warnings:
drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error:
uninitialized symbol 'rc'.
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1607
calculate_bandwidth() warn: Function too hairy. No more merges.
Old smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3387 bw_calcs()
warn: inconsistent indenting
vim +/rc +1031 drivers/virtio/virtio_mem.c
978
979/*
980 * Try to plug the desired number of subblocks of a memory block that
981 * is already added to Linux.
982 *
983 * Will modify the state of the memory block.
984 *
985 * Note: Can fail after some subblocks were successfully plugged.
986 */
987static int virtio_mem_mb_plug_any_sb(struct virtio_mem *vm, unsigned
long mb_id,
988 uint64_t *nb_sb, bool online)
989{
990unsigned long pfn, nr_pages;
991int sb_id, count;
992int rc;
993
994if (WARN_ON_ONCE(!*nb_sb))
995return -EINVAL;
996
997while (*nb_sb) {
998sb_id = virtio_mem_mb_first_unplugged_sb(vm, mb_id);
999if (sb_id >= vm->nb_sb_per_mb)
1000break;
1001count = 1;
1002while (count < *nb_sb &&
1003 sb_id + count < vm->nb_sb_per_mb &&
1004 !virtio_mem_mb_test_sb_plugged(vm, mb_id, sb_id +
count,
1005 1))
1006count++;
1007
1008rc = virtio_mem_mb_plug_sb(vm, mb_id, sb_id, count);
1009if (rc)
1010return rc;
1011*nb_sb -= count;
1012if (!online)
1013continue;
1014
1015/* fake-online the pages if the memory block is online */
1016pfn = PFN_DOWN(virtio_mem_mb_id_to_phys(mb_id) +
1017 sb_id * vm->subblock_size);
1018nr_pages = PFN_DOWN(count * vm->subblock_size);
1019virtio_mem_fake_online(pfn, nr_pages);
1020}
1021
1022if (virtio_mem_mb_test_sb_plugged(vm, mb_id, 0,
vm->nb_sb_per_mb)) {
1023if (online)
1024virtio_mem_mb_set_state(vm, mb_id,
1025VIRTIO_MEM_MB_STATE_ONLINE);
1026else
1027virtio_mem_mb_set_state(vm, mb_id,
1028VIRTIO_MEM_MB_STATE_OFFLINE);
1029}
1030
1031return rc;
1032}
1033
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
<.config.gz>
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [kbuild-all] Re: [RFC PATCH linux-next] platform/x86: thinkpad_acpi: dev_attr_charge_start_threshold can be static
On 8/1/20 7:45 PM, Andy Shevchenko wrote:
On Sat, Aug 1, 2020 at 11:38 AM kernel test robot wrote:
Thanks and sorry folks, Hulk robot was faster, and TBH their patch
looks much better (proper commit message applied). Perhaps something
LKP should work on?
Hi Andy,
Thanks for the advice, we'll improve the commit message.
Best Regards,
Rong Chen
Fixes: e33929537b76 ("platform/x86: thinkpad_acpi: use standard charge control
attribute names")
Signed-off-by: kernel test robot
Re: [fsnotify] c738fbabb0: will-it-scale.per_process_ops -9.5% regression
On 7/21/20 11:59 PM, Amir Goldstein wrote:
On Tue, Jul 21, 2020 at 3:15 AM kernel test robot wrote:
Greeting,
FYI, we noticed a -9.5% regression of will-it-scale.per_process_ops due to
commit:
commit: c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold fsnotify() call
into fsnotify_parent()")
Strange, that's a pretty dumb patch moving some inlined code from one
function to
another (assuming there are no fsnotify marks in this test).
Unless I am missing something the only thing that changes slightly is
an extra d_inode(file->f_path.dentry) deference.
I can get rid of it.
Is it possible to ask for a re-test with fix patch (attached)?
Hi Amir,
We failed to apply this patch, could you tell us the base commit or the
base branch?
Best Regards,
Rong Chen
Re: [LKP] Re: db57e98d87 ("mm/sparse.c: fix ALIGN() without power of 2 in .."): BUG: kernel reboot-without-warning in early-boot stage, last printk: early console in setup code
On 7/17/20 6:06 AM, Andrew Morton wrote: On Thu, 16 Jul 2020 16:32:00 +0800 kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit db57e98d87908b8837352abe08515e42752270c1 Author: Lecopzer Chen AuthorDate: Mon Sep 23 15:36:24 2019 -0700 Commit: Linus Torvalds CommitDate: Tue Sep 24 15:54:09 2019 -0700 mm/sparse.c: fix ALIGN() without power of 2 in sparse_buffer_alloc() Are we sure about this? That patch is a year old - has something in the test setup changed to make it visible at this late stage? Hi Andrew, The issue can be reproduced if CONFIG_SPARSEMEM_VMEMMAP is not set $ grep CONFIG_SPARSEMEM .config CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y # CONFIG_SPARSEMEM_VMEMMAP is not set $ ./reproduce-yocto-vm-yocto-23:20200619042212:x86_64-randconfig-r025-20200618:5.3.0-11836-gdb57e98d87908:1 vmlinuz-5.3.0-11836-gdb57e98d87908 early console in setup code and kernel can boot if enable CONFIG_SPARSEMEM_VMEMMAP $ grep CONFIG_SPARSEMEM .config CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y $ ./reproduce-yocto-vm-yocto-23:20200619042212:x86_64-randconfig-r025-20200618:5.3.0-11836-gdb57e98d87908:1 vmlinuz-5.3.0-11836-gdb57e98d87908.CONFIG_SPARSEMEM_VMEMMAP | head early console in setup code [ 0.00] Linux version 5.3.0-11836-gdb57e98d87908 (kbuild@6c2adaf8a115) (clang version 12.0.0 (git://gitmirror/llvm_project ed6b578040a85977026c93bf4188f996148f3218)) #1 SMP Fri Jul 17 15:41:47 CST 2020 [ 0.00] Command line: root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw rcuperf.shutdown=0 watchdog_thresh=60 [ 0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009fbff] usable qemu-system-x86_64: terminating on signal 2 Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH v5 06/11] remoteproc: stm32: Properly set co-processor state when attaching
On 7/16/20 6:19 AM, Mathieu Poirier wrote:
Hi Robot,
On Tue, 14 Jul 2020 at 14:31, kernel test robot wrote:
Hi Mathieu,
I love your patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on linus/master v5.8-rc5 next-20200714]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Mathieu-Poirier/remoteproc-stm32-Add-support-for-attaching-to-M4/20200708-053515
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
config: arm-randconfig-r011-20200714 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
02946de3802d3bc65bc9f2eb9b8d4969b5a7add8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/remoteproc/stm32_rproc.c:697:18: error: use of undeclared identifier
'RPROC_DETACHED'
rproc->state = RPROC_DETACHED;
^
1 error generated.
This patchset depends on this one [1], something that is clearly
stated in the cover letter. Compiling this set on top of [1]
generates no error.
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=318275
Hi Mathieu,
Thanks for the feedback, the bot can't parse the base which links to another
patchset,
and we can get the base commit if using 'git format-patch --base' to submit
patch.
Best Regards,
Rong Chen
vim +/RPROC_DETACHED +697 drivers/remoteproc/stm32_rproc.c
661
662
663 static int stm32_rproc_probe(struct platform_device *pdev)
664 {
665 struct device *dev = >dev;
666 struct stm32_rproc *ddata;
667 struct device_node *np = dev->of_node;
668 struct rproc *rproc;
669 unsigned int state;
670 int ret;
671
672 ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
673 if (ret)
674 return ret;
675
676 rproc = rproc_alloc(dev, np->name, _rproc_ops, NULL,
sizeof(*ddata));
677 if (!rproc)
678 return -ENOMEM;
679
680 ddata = rproc->priv;
681
682 rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE);
683
684 ret = stm32_rproc_parse_dt(pdev, ddata, >auto_boot);
685 if (ret)
686 goto free_rproc;
687
688 ret = stm32_rproc_of_memory_translations(pdev, ddata);
689 if (ret)
690 goto free_rproc;
691
692 ret = stm32_rproc_get_m4_status(ddata, );
693 if (ret)
694 goto free_rproc;
695
696 if (state == M4_STATE_CRUN)
> 697 rproc->state = RPROC_DETACHED;
698
699 rproc->has_iommu = false;
700 ddata->workqueue = create_workqueue(dev_name(dev));
701 if (!ddata->workqueue) {
702 dev_err(dev, "cannot create workqueue\n");
703 ret = -ENOMEM;
704 goto free_rproc;
705 }
706
707 platform_set_drvdata(pdev, rproc);
708
709 ret = stm32_rproc_request_mbox(rproc);
710 if (ret)
711 goto free_wkq;
712
713 ret = rproc_add(rproc);
714 if (ret)
715 goto free_mb;
716
717 return 0;
718
719 free_mb:
720 stm32_rproc_free_mbox(rproc);
721 free_wkq:
722 destroy_workqueue(ddata->workqueue);
723 free_rproc:
724 if (device_may_wakeup(dev)) {
725 dev_pm_clear_wake_irq(dev);
726 device_init_wakeup(dev, false);
727 }
728 rproc_free(rproc);
729 return ret;
730 }
731
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [LKP] Re: [refperf] 8e4ec3d02b: error:#[##]
On 7/7/20 6:50 AM, Paul E. McKenney wrote:
On Sun, Jul 05, 2020 at 04:00:05PM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 8e4ec3d02b549a731c94b4bcddff212bb92cdbaf ("refperf: Rename RCU_REF_PERF_TEST
to RCU_REF_SCALE_TEST")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
You lost me on this one. All that this commit does is to change the
name of a Kconfig option. I don't see how it changes execution.
What am I missing here?
Hi Paul,
It's the bot problem, CONFIG_RCU_REF_SCALE_TEST is set to 'y' in kconfig
file,
but CONFIG_RCU_REF_SCALE_TEST doesn't exist in parent commit c7dcf8106f75,
bot used 'make olddefconfig' to update the kconfig to build the parent
commit
which causes CONFIG_RCU_REF_PERF_TEST not set too.
We will check more carefully to avoid false positive.
Best Regards,
Rong Chen
Thanx, Paul
on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+++
| | c7dcf8106f |
8e4ec3d02b |
+-+++
| boot_successes | 14 | 0
|
| boot_failures | 23 | 38
|
| invoked_oom-killer:gfp_mask=0x | 5 | 4
|
| Mem-Info| 5 | 4
|
| Out_of_memory_and_no_killable_processes | 4 | 4
|
| Kernel_panic-not_syncing:System_is_deadlocked_on_memory | 4 | 4
|
| WARNING:at_kernel/trace/trace.c:#trace_find_next_entry | 18 |
|
| EIP:trace_find_next_entry | 18 |
|
| error:#[##] | 0 | 34
|
| EIP:main_func | 0 | 34
|
| Kernel_panic-not_syncing:Fatal_exception| 0 | 34
|
+-+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[ 14.325320]
[ 14.337793] [main] Added 18 filenames from /dev
[ 14.337808]
[ 15.232694] rcu-ref-perf: Experiment #0 (Format: :)
[ 15.232694]
[ 15.238007] divide_error: [#1] PTI
[ 15.239505] CPU: 0 PID: 86 Comm: main_func Tainted: G S
5.8.0-rc3-00028-g8e4ec3d02b549 #1
[ 15.242735] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[ 15.249804] EIP: main_func+0x2af/0x393
[ 15.251276] Code: af f0 e8 86 f8 ff ff bf e8 03 00 00 69 ca e8 03 00 00 f7 e7 89
55 8c 89 45 88 8b 45 8c 31 ff 8d 14 01 39 d6 77 08 89 d0 31 d2 f6 89 c7 8b
4d 94 8b 45 88 f7 f6 89 7c d9 04 89 04 d9 43 e9 09
[ 15.256851] EAX: EBX: ECX: EDX:
[ 15.258817] ESI: EDI: EBP: dc6cdf80 ESP: dc6cdf08
[ 15.260738] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00010246
[ 15.262810] CR0: 80050033 CR2: 08bb CR3: 33bbe000 CR4: 000406f0
[ 15.264757] Call Trace:
[ 15.265997] ? __kthread_parkme+0x3a/0x71
[ 15.267516] ? _raw_spin_unlock_irqrestore+0x34/0x40
[ 15.269216] ? tracer_hardirqs_on+0x11/0x25
[ 15.270767] ? trace_hardirqs_on+0x34/0x41
[ 15.272295] kthread+0xee/0xf3
[ 15.273636] ? srcu_ref_perf_read_section+0x69/0x69
[ 15.275325] ? kthread_create_worker_on_cpu+0x1c/0x1c
[ 15.277009] ret_from_fork+0x19/0x30
[ 15.278462] Modules linked in: psmouse parport_pc ide_pci_generic
qemu_fw_cfg ide_core processor
[ 15.281552] ---[ end trace 891088ef0ed36b53 ]---
[ 15.283184] EIP: main_func+0x2af/0x393
[ 15.284632] Code: af f0 e8 86 f8 ff ff bf e8 03 00 00 69 ca e8 03 00 00 f7 e7 89
55 8c 89 45 88 8b 45 8c 31 ff 8d 14 01 39 d6 77 08 89 d0 31 d2 f6 89 c7 8b
4d 94 8b 45 88 f7 f6 89 7c d9 04 89 04 d9 43 e9 09
[ 15.290313] EAX: EBX: ECX: EDX:
[ 15.292272] ESI: EDI: EBP: dc6cdf80 ESP: dc6cdf08
[ 15.294261] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00010246
[ 15.296304] CR0: 80050033 CR2: 08bb CR3: 33bbe000 CR4: 000406f0
[ 15.298264] Kernel panic - not syncing: Fatal exception
[ 15.31] Kernel Offset: disabled
Elapsed time: 60
qemu-img create -f qcow2 disk-vm-snb-i386-61-0 256G
To reproduce:
# build kernel
Re: [bpf] af7ec13833: will-it-scale.per_process_ops -2.5% regression
On 6/29/20 11:10 PM, Yonghong Song wrote:
On 6/28/20 1:50 AM, kernel test robot wrote:
Greeting,
FYI, we noticed a -2.5% regression of will-it-scale.per_process_ops
due to commit:
commit: af7ec13833619e17f03aa73a785a2f871da6d66b ("bpf: Add
bpf_skc_to_tcp6_sock() helper")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
One of previous emails claims that
commit: 492e639f0c222784e2e0f121966375f641c61b15 ("bpf: Add
bpf_seq_printf and bpf_seq_write helpers")
is reponsible for 2.5% improvement for will-it-scale.per_process_ops,
which I believe is false.
This commit should not cause regression.
Probably the variation of performance is caused by test environment
which you may want to investigate further to reduce false alarming.
Thanks!
Hi Yonghong,
It's a function align issue, the commit effects the align of functions
which causes a little regression,
we force to set -falign-functions=32 in KBUILD_CFLAGS and the regression
is gone:
diff --git a/Makefile b/Makefile
index 70def4907036c..9746afa4edc21 100644
--- a/Makefile
+++ b/Makefile
@@ -476,7 +476,7 @@ LINUXINCLUDE := \
$(USERINCLUDE)
KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE
-KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
+KBUILD_CFLAGS := -Wall -Wundef -falign-functions=32
-Werror=strict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common -fshort-wchar
-fno-PIE \
-Werror=implicit-function-declaration
-Werror=implicit-int \
-Wno-format-security \
Best Regards,
Rong Chen
in testcase: will-it-scale
on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @
2.30GHz with 192G memory
with following parameters:
nr_task: 16
mode: process
test: mmap1
cpufreq_governor: performance
ucode: 0x5002f01
test-description: Will It Scale takes a testcase and runs it from 1
through to n parallel copies to see if the testcase will scale. It
builds both a process and threads based test in order to see any
differences between the two.
test-url: https://github.com/antonblanchard/will-it-scale
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Details are as below:
[...]
Re: [kbuild-all] Re: [PATCH] sparse: use static inline for __chk_{user,io}_ptr()
On 6/30/20 2:37 AM, Luc Van Oostenryck wrote: On Tue, Jun 30, 2020 at 02:08:36AM +0800, kernel test robot wrote: Hi Luc, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20200626] [cannot apply to linux/master linus/master v5.8-rc2 v5.8-rc1 v5.7 v5.8-rc3] [If your patch is applied to the wrong git tree, kindly drop us a note. This patch should be applied on top of akpm's tree or on top of next. I'm not sure hwo I should have specified this, 'git send-mail --base=...' is less useful for these trees. Hi Luc, Thanks for the feedback, we'll fix the wrong base. Best Regards, Rong Chen
Re: [kbuild-all] Re: [PATCH] ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2
On 6/30/20 2:12 AM, Tony Lindgren wrote: * kernel test robot [200617 17:28]: Hi Adam, Thank you for the patch! Yet something to improve: [auto build test ERROR on omap/for-next] [cannot apply to balbi-usb/testing/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] This applies to v5.8-rc1, so the error above can be ignored now. Applying patch into omap-for-v5.9/ti-sysc-drop-pdata. Hi Tony, Thanks for the feedback, we'll fix the wrong base. Best Regards, Rong Chen
Re: [kbuild-all] Re: ld.lld: warning: drivers/built-in.a(misc/ds1682.o):(.data..compoundliteral) is being placed in '.data..compoundliteral'
On 6/20/20 12:32 AM, Nick Desaulniers wrote: On Fri, Jun 19, 2020 at 6:24 AM Christophe Leroy wrote: Le 18/06/2020 à 03:12, kernel test robot a écrit : tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1b5044021070efa3259f3e9548dc35d1eb6aa844 commit: 74016701fe5f873ae23bf02835407227138d874d powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG I'm really having hard time understanding the link between this commit and the issue reported below. Can Clang people help understand what the problem might be ? For randconfigs, it might be the case that we're not clean in the first place. + Philip to provide more info on how the bisection pinpoints commits? (Is the same randconfig used repeatedly as part of a bisection?) Hi, The commit is not the root cause, bisection stopped at a wrong commit because parent commit failed earlier before the ld.lld error, we're going to optimize the bisect logic to avoid false positive. Best Regards, Rong Chen + Kees, idk if this is the warning from the orphan section placement, if any of those patches have landed? + Fangrui, who might know more about this warning from LLD. Christophe date: 2 weeks ago config: powerpc-randconfig-r032-20200617 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 487ca07fcc75d52755c9fe2ee05bcb3b6c44) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu git checkout 74016701fe5f873ae23bf02835407227138d874d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): ld.lld: warning: drivers/built-in.a(misc/ds1682.o):(.data..compoundliteral) is being placed in '.data..compoundliteral' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral) is being placed in '.data..compoundliteral' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.29) is being placed in '.data..compoundliteral.29' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.31) is being placed in '.data..compoundliteral.31' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.33) is being placed in '.data..compoundliteral.33' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.bss..compoundliteral.35) is being placed in '.bss..compoundliteral.35' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.37) is being placed in '.data..compoundliteral.37' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.39) is being placed in '.data..compoundliteral.39' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.41) is being placed in '.data..compoundliteral.41' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.43) is being placed in '.data..compoundliteral.43' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.45) is being placed in '.data..compoundliteral.45' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.47) is being placed in '.data..compoundliteral.47' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.49) is being placed in '.data..compoundliteral.49' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.51) is being placed in '.data..compoundliteral.51' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.53) is being placed in '.data..compoundliteral.53' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.55) is being placed in '.data..compoundliteral.55' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.57) is being placed in '.data..compoundliteral.57' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.59) is being placed in '.data..compoundliteral.59' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.61) is being placed in '.data..compoundliteral.61' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.63) is being placed in '.data..compoundliteral.63' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.65) is being placed in '.data..compoundliteral.65' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.67) is being placed in '.data..compoundliteral.67' ld.
Re: [kbuild-all] security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of 1152 bytes in function 'ima_calc_field_array_hash_tfm'
Hi Herbert,
Could you take a look at this warning? Roberto mentioned you in previous
report:
https://lore.kernel.org/linux-integrity/9dbec9465bda4f8995a42593eb0db...@huawei.com/
Best Regards,
Rong Chen
On 6/17/20 9:35 PM, kernel test robot wrote:
Hi Roberto,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 69119673bd50b176ded34032fadd41530fb5af21
commit: 1ea973df6e2166d1a576cabe5d08925d3261ff9d ima: Calculate and extend PCR
with digests in ima_template_entry
date: 8 weeks ago
config: mips-randconfig-r014-20200617 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
487ca07fcc75d52755c9fe2ee05bcb3b6c44)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
git checkout 1ea973df6e2166d1a576cabe5d08925d3261ff9d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of 1152
bytes in function 'ima_calc_field_array_hash_tfm' [-Wframe-larger-than=]
static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
^
1 warning generated.
vim +/ima_calc_field_array_hash_tfm +575 security/integrity/ima/ima_crypto.c
3bcced39ea7d1b Dmitry Kasatkin 2014-02-26 571
3323eec921efd8 Mimi Zohar 2009-02-04 572 /*
a71dc65d30a472 Roberto Sassu 2013-06-07 573 * Calculate the hash of
template data
3323eec921efd8 Mimi Zohar 2009-02-04 574 */
a71dc65d30a472 Roberto Sassu 2013-06-07 @575 static int
ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
7ca79645a1f883 Roberto Sassu 2020-03-25 576
struct ima_template_entry *entry,
6d94809af6b083 Roberto Sassu 2020-03-25 577
int tfm_idx)
3323eec921efd8 Mimi Zohar 2009-02-04 578 {
6d94809af6b083 Roberto Sassu 2020-03-25 579
SHASH_DESC_ON_STACK(shash, ima_algo_array[tfm_idx].tfm);
7ca79645a1f883 Roberto Sassu 2020-03-25 580 struct ima_template_desc
*td = entry->template_desc;
7ca79645a1f883 Roberto Sassu 2020-03-25 581 int num_fields =
entry->template_desc->num_fields;
a71dc65d30a472 Roberto Sassu 2013-06-07 582 int rc, i;
3323eec921efd8 Mimi Zohar 2009-02-04 583
6d94809af6b083 Roberto Sassu 2020-03-25 584 shash->tfm =
ima_algo_array[tfm_idx].tfm;
3323eec921efd8 Mimi Zohar 2009-02-04 585
357aabed626fe3 Behan Webster 2014-04-04 586 rc =
crypto_shash_init(shash);
a71dc65d30a472 Roberto Sassu 2013-06-07 587 if (rc != 0)
a71dc65d30a472 Roberto Sassu 2013-06-07 588 return rc;
a71dc65d30a472 Roberto Sassu 2013-06-07 589
a71dc65d30a472 Roberto Sassu 2013-06-07 590 for (i = 0; i <
num_fields; i++) {
e3b64c268b485f Roberto Sassu 2014-02-03 591 u8
buffer[IMA_EVENT_NAME_LEN_MAX + 1] = { 0 };
e3b64c268b485f Roberto Sassu 2014-02-03 592 u8
*data_to_hash = field_data[i].data;
e3b64c268b485f Roberto Sassu 2014-02-03 593 u32 datalen =
field_data[i].len;
98e1d55d033eed Andreas Steffen 2016-12-19 594 u32
datalen_to_hash =
98e1d55d033eed Andreas Steffen 2016-12-19 595
!ima_canonical_fmt ? datalen : cpu_to_le32(datalen);
e3b64c268b485f Roberto Sassu 2014-02-03 596
b6f8f16f41d928 Roberto Sassu 2013-11-08 597 if
(strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
357aabed626fe3 Behan Webster 2014-04-04 598 rc =
crypto_shash_update(shash,
98e1d55d033eed Andreas Steffen 2016-12-19 599
(const u8 *) _to_hash,
98e1d55d033eed Andreas Steffen 2016-12-19 600
sizeof(datalen_to_hash));
b6f8f16f41d928 Roberto Sassu 2013-11-08 601 if (rc)
b6f8f16f41d928 Roberto Sassu 2013-11-08 602
break;
e3b64c268b485f Roberto Sassu 2014-02-03 603 } else if
(strcmp(td->fields[i]->field_id, "n") == 0) {
e3b64c268b485f Roberto Sassu 2014-02-03 604
memcpy(buffer, data_to_hash, datalen);
e3b64c268b485f Roberto Sassu 2014-02-03 605
data_to_hash = buffer;
e3b64c268b485f Roberto Sassu 2014-02-03 606 datalen
= IMA_
Re: [kbuild-all] Re: [PATCH] compiler_attributes.h: Support no_sanitize_undefined check with GCC 4
On Tue, Jun 16, 2020 at 03:19:21PM +0200, Peter Zijlstra wrote: > On Tue, Jun 16, 2020 at 01:15:29AM +0200, Marco Elver wrote: > > UBSAN is supported since GCC 4.9, which unfortunately did not yet have > > __has_attribute(). To work around, the __GCC4_has_attribute workaround > > requires defining which compiler version supports the given attribute. > > > > In the case of no_sanitize_undefined, it is the first version that > > supports UBSAN, which is GCC 4.9. > > > > Reported-by: kernel test robot > > Signed-off-by: Marco Elver > > --- > > > > Doing a 'make W=1' with GCC 4.9 and the provided config fixes the build > > robot's report. > > > > Peter: Feel free to either squash this patch into the one adding > > __no_sanitize_undefined or apply on top. > > Yeah, argh! So I only saw this thread now, even though I'd already > pushed out x86/entry to tip last night due to getting: > > 301805 N + Jun 16 kernel test rob (5.8K) [peterz-queue:x86/entry] BUILD > SUCCESS 8e8bb06d199a5aa7a534aa3b3fc0abbbc11ca438 > > Why that thing is claiming SUCCESS when it introduces a build error I > don't know. > Hi Peter, Sorry for the misunderstanding, some folks complained that it's too noisy when there're only new warnings in a "BUILD REGRESSION" report, so we changed to use "BUILD SUCCESS" if there's no new build error. To avoid misunderstanding, we'll change build complete report title to "BUILD SUCCESS WITH WARNING" for new warnings. Best Regards, Rong Chen
Re: [LKP] Re: [x86/entry] 2bbc68f837: ltp.ptrace08.fail
On Tue, Jun 16, 2020 at 10:44:00AM +0200, Thomas Gleixner wrote:
> kernel test robot writes:
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 2bbc68f8373c0631ebf137f376fbea00e8086be7 ("x86/entry: Convert Debug
> > exception to IDTENTRY_DB")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> Is the head of linux.git exposing the same problem or is this an
> intermittent failure, which only affects bisectability?
>
Hi Thomas,
The problem still exists in v5.8-rc1:
9f58fdde95c9509a 2bbc68f8373c0631ebf137f376v5.8-rc1
testcase/testparams/testbox
-- --
---
fail:runs %reproductionfail:runs %reproductionfail:runs
| | | | |
:12 92% 11:12 100% 13:13
ltp/1HDD-xfs-syscalls_part4/vm-snb
:12 92% 11:12 100% 13:13TOTAL
ltp.ptrace08.fail
Best Regards,
Rong Chen
Re: [btrfs] e678934cbe: reaim.jobs_per_min -30.7% regression
On 6/12/20 7:50 PM, Filipe Manana wrote:
On 11/06/20 10:02, kernel test robot wrote:
Greeting,
FYI, we noticed a -30.7% regression of reaim.jobs_per_min due to commit:
Hello,
In the future, can you please always CC linux-bt...@vger.kernel.org for
btrfs related reports?
Thanks for the advice, we'll cc the mailing list next time.
Best Regards,
Rong Chen
Thanks.
commit: e678934cbe5f026c2765a1da651e61daa5724fb3 ("btrfs: Remove unnecessary check
from join_running_log_trans")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: reaim
on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 256G
memory
with following parameters:
runtime: 300s
nr_task: 100
disk: 1HDD
fs: btrfs
test: disk
cpufreq_governor: performance
ucode: 0x52c
test-description: REAIM is an updated and improved version of AIM 7 benchmark.
test-url: https://sourceforge.net/projects/re-aim-7/
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=
compiler/cpufreq_governor/disk/fs/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase/ucode:
gcc-9/performance/1HDD/btrfs/x86_64-rhel-7.6/100/debian-x86_64-20191114.cgz/300s/lkp-csl-2sp6/disk/reaim/0x52c
commit:
32e534402a ("Btrfs: wake up inode cache waiters sooner to reduce waiting
time")
e678934cbe ("btrfs: Remove unnecessary check from join_running_log_trans")
32e534402ad52e9f e678934cbe5f026c2765a1da651
---
fail:runs %reproductionfail:runs
| | |
:4 25% 1:4
dmesg.WARNING:at#for_ip_swapgs_restore_regs_and_return_to_usermode/0x
%stddev %change %stddev
\ |\
5.39+6.4% 5.73 ± 6% reaim.child_utime
6882 ± 2% -30.7% 4771 ± 2% reaim.jobs_per_min
68.82 ± 2% -30.7% 47.72 ± 2% reaim.jobs_per_min_child
98.56-3.4% 95.25reaim.jti
6978 ± 2% -29.5% 4917 ± 2% reaim.max_jobs_per_min
87.24 ± 2% +44.3% 125.92 ± 2% reaim.parent_time
0.97 ± 5%+337.7% 4.26 ± 9% reaim.std_dev_percent
0.84 ± 5%+504.3% 5.05 ± 7% reaim.std_dev_time
357.77 ± 2% +7.4% 384.27 ± 2% reaim.time.elapsed_time
357.77 ± 2% +7.4% 384.27 ± 2% reaim.time.elapsed_time.max
276434 -25.6% 205672reaim.time.file_system_inputs
10740316 -20.1%8583748 ± 2% reaim.time.file_system_outputs
63443 -13.8% 54688
reaim.time.involuntary_context_switches
6205791 -24.9%4661554reaim.time.minor_page_faults
84.25 ± 2% -34.4% 55.25 ± 11%
reaim.time.percent_of_cpu_this_job_got
281.73 -30.3% 196.49 ± 11% reaim.time.system_time
21.59 -20.2% 17.23 ± 6% reaim.time.user_time
2253123 -10.4%2017718
reaim.time.voluntary_context_switches
4 -25.0% 3reaim.workload
92.59+2.6% 95.01iostat.cpu.idle
6.37 -32.9% 4.27iostat.cpu.iowait
0.97 ± 4% -32.4% 0.65 ± 13% iostat.cpu.system
6.41-2.14.29mpstat.cpu.all.iowait%
0.02 ± 6% -0.00.01 ± 4% mpstat.cpu.all.soft%
0.95 ± 4% -0.30.64 ± 13% mpstat.cpu.all.sys%
0.07 ± 2% -0.00.06 ± 3% mpstat.cpu.all.usr%
3177396 ± 4% -17.2%2630192 ± 2% numa-numastat.node0.local_node
3208408 ± 3% -17.3%2653430 ± 3% numa-numastat.node0.numa_hit
3183435 ± 4% -21.0%2515397 ± 2% numa-numastat.node1.local_node
3183678 ± 4% -20.7%2523398 ± 2% numa-numastat.node1.numa_hit
92.00+2.4% 94.25vmstat.cpu.id
382.00 -30.6% 265.25vmstat.io.bi
26136 -29.9% 18312vmstat.io.bo
6.00 -37.5% 3.75 ± 11% vmstat.procs.b
20123 ± 2% -19.6% 16189vmstat.system.cs
1044628 -21.1% 824233 ± 4% meminfo.Active
758190 -28.5% 542058 ± 7% meminfo.Active(file)
163791 +76.7% 289387 ± 6% meminfo.Inactive
145927 +86.1% 271504 ± 6% m
Re: [kmemleak] b751c52bb5: BUG:kernel_hang_in_boot_stage
On 6/10/20 6:56 PM, Catalin Marinas wrote:
On Wed, Jun 10, 2020 at 03:51:56PM +0800, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: b751c52bb587ae66f773b15204ef7a147467f4c7 ("kmemleak: increase
DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
[...]
BUG: kernel hang in boot stage
To reproduce:
# build kernel
cd linux
cp config-5.3.0-11789-gb751c52bb587a .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=i386 olddefconfig prepare
modules_prepare bzImage
I've never tried kmemleak on i386.
Anyway, I'm not sure what caused the hang (or whether it's a hang at
all) but I suspect prior to the above commit, kmemleak probably just
disabled itself (early log buffer exceeded). So the bug may have been
there already, only that kmemleak started working and tripped over it
when the log buffer increased.
Hi,
Sorry for the late, I can reproduce the problem with command "bin/lkp
qemu -k job-script",
and the kernel hangs:
[ 0.333897] -
[ 0.334561] |block | try |context|
[ 0.335170] -
[ 0.335760] context: ok | ok | ok |
[ 0.337995] try: ok | ok | ok |
[ 0.340089] block: ok | ok | ok |
[ 0.342175] spinlock: ok | ok | ok |
[ 0.344481] ---
[ 0.345068] Good, all 261 testcases passed! |
[ 0.345514] -
KVM internal error. Suberror: 3
extra data[0]: 8b0e
extra data[1]: 31
extra data[2]: 182
extra data[3]: bfff0
EAX= EBX=00200297 ECX= EDX=
ESI=d2e997c0 EDI=d2e997f0 EBP=d2bbb038 ESP=c00bfff4
EIP=f4dccd57 EFL=00210046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b 00c0f300 DPL=3 DS [-WA]
CS =0060 00c09b00 DPL=0 CS32 [-RA]
SS =0068 00c09300 DPL=0 DS [-WA]
DS =007b 00c0f300 DPL=3 DS [-WA]
FS =00d8 23331000 00809300 DPL=0 DS16 [-WA]
GS =00e0 f6422900 0018 00409100 DPL=0 DS [--A]
LDT= 00c0
TR =0080 ff403000 206b 8b00 DPL=0 TSS32-busy
GDT= ff401000 00ff
IDT= ff40 07ff
CR0=80050033 CR2= CR3=130fc000 CR4=0690
DR0= DR1= DR2=
DR3=
DR6=fffe0ff0 DR7=0400
EFER=
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Is there a chance that the kernel got much slower with kmemleak enabled
and the test scripts timed out?
no, the parent commit log is:
[ 0.313845] -
[ 0.314608] |block | try |context|
[ 0.315314] -
[ 0.315974] context: ok | ok | ok |
[ 0.318261] try: ok | ok | ok |
[ 0.320478] block: ok | ok | ok |
[ 0.322562] spinlock: ok | ok | ok |
[ 0.324825] ---
[ 0.325403] Good, all 261 testcases passed! |
[ 0.325809] -
[ 0.326221] kmemleak: Early log buffer exceeded (401), please
increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
[ 0.327065] ACPI: Core revision 20190816
[ 0.327585] clocksource: hpet: mask: 0x max_cycles:
0x, max_idle_ns: 19112604467 ns
[ 0.328545] APIC: Switch to symmetric I/O mode setup
[ 0.329009] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.329572] masked ExtINT on CPU#0
[ 0.330686] ENABLING IO-APIC IRQs
[ 0.331001] init IO_APIC IRQs
[ 0.331274] apic 0 pin 0 not connected
Does this problem still exist with the latest mainline?
yes, still in v5.7.
Best Regards,
Rong Chen
Re: [PATCH v7 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases
On 6/7/20 7:15 AM, Syed Nayyar Waris wrote:
On Fri, Jun 5, 2020 at 5:54 PM Andy Shevchenko
wrote:
On Fri, Jun 05, 2020 at 02:12:54AM +0530, Syed Nayyar Waris wrote:
On Sun, May 31, 2020 at 12:50 AM kbuild test robot wrote:
WARNING: modpost: lib/test_bitmap.o(.data+0xe80): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp1
The variable clump_test_data references
the variable __initconst clump_exp1
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xec8): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp2
The variable clump_test_data references
the variable __initconst clump_exp2
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xf10): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp3
The variable clump_test_data references
the variable __initconst clump_exp3
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
--
WARNING: modpost: lib/test_bitmap.o(.data+0xf58): Section mismatch in reference
from the variable clump_test_data to the variable .init.rodata:clump_exp4
The variable clump_test_data references
the variable __initconst clump_exp4
If the reference is valid then annotate the
variable with or __refdata (see linux/init.h) or name the variable:
I am unable to reproduce the compilation warning.
You have to enable section mismatch checker.
I ran the command:
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' lib/
But the compilation warning didn't show up. Can anyone please point to me
what I am doing wrong here? How shall I reproduce the warning? Thanks !
You put some data into init section of the object, while you are trying to
access it from non-init one. It's easy-to-fix issue.
--
With Best Regards,
Andy Shevchenko
Thanks! I have made code changes for the above warning. Actually I am
still unable to reproduce the compilation warning. But I believe the
following code fix will fix the compilation warning:
In file lib/test_bitmap.c
@@ -692,7 +692,7 @@ struct clump_test_data_params {
unsigned long const *exp;
};
-struct clump_test_data_params clump_test_data[] =
+static struct clump_test_data_params clump_test_data[] __initdata =
{ {{0}, 2, 0, 64, 8, clump_exp1},
{{0}, 8, 2, 240, 24, clump_exp2},
{{0}, 8, 10, 240, 30, clump_exp3},
Let me know if I should submit a new patchset (v8) for
'for_each_set_clump' including above code fix.
Just to share how I attempted to reproduce the warning (but unsuccessful):
Step 1: Use the config file in attachment. Download, extract, rename
file to .config at the root of the tree.
Step 2: '$ make lib/'
No warning reproduced after above step 2.
Step 3: '$ make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix
-D__CHECK_ENDIAN__' lib/'
After step 3 I got error in build:
scripts/kconfig/conf --syncconfig Kconfig
CHECK scripts/mod/empty.c
No such file: asan-globals=1
scripts/Makefile.build:266: recipe for target 'scripts/mod/empty.o' failed
make[1]: *** [scripts/mod/empty.o] Error 1
Makefile:1147: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
The command in above step 3 was mentioned in the bot mail.
Regards
Syed Nayyar Waris
Hi Syed Nayyar Waris,
We can reproduce the warning with the steps in original report,
you may need to build the whole kernel instead of the 'lib'.
Best Regards,
Rong Chen
Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this configuration
On 6/10/20 8:58 AM, Fangrui Song wrote: On 2020-06-10, Rong Chen wrote: On 6/10/20 1:49 AM, Fangrui Song wrote: On 2020-06-09, Nick Desaulniers wrote: On Tue, Jun 9, 2020 at 6:12 AM kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: abfbb29297c27e3f101f348dc9e467b0fe70f919 commit: 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace Makefile: support compressed debug info date: 12 days ago config: x86_64-randconfig-r032-20200609 (attached as .config) compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 reproduce (this is a W=1 build): git checkout 10e68b02c861ccf2b3adb59d3f0c10dc6b5e3ace # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): gcc-5: error: -gz is not supported in this configuration Hmm...I wonder if the feature detection is incomplete? I suspect it's possible to not depend on zlib. make[2]: *** [scripts/Makefile.build:277: scripts/mod/empty.o] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [Makefile:1169: prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:185: __sub-make] Error 2 The output of gcc-5 -v --version on that machine may help. The convoluted gcc_cv_ld_compress_de logic in gcc/configure.ac may be related, but I can't find any mistake that our CONFIG_DEBUG_INFO_COMPRESSED conditions may make. Hi Fangrui, Here is the output: $gcc-5 -v --version Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.5.0-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1) COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccqnZumV.s GNU C11 (Ubuntu 5.5.0-12ubuntu1) version 5.5.0 20171010 (x86_64-linux-gnu) compiled by GNU C version 5.5.0 20171010, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0 warning: MPFR header version 4.0.1 differs from library version 4.0.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' as -v --64 --version -o /tmp/ccRPgs9J.o /tmp/ccqnZumV.s GNU assembler version 2.34 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.34 GNU assembler (GNU Binutils for Ubuntu) 2.34 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccJLhs3y.res -plugin-opt=-pass-through=-lgcc -plug
Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this configuration
ugh=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro --version /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. /tmp/ccRPgs9J.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o collect2 version 5.5.0 20171010 /usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccJLhs3y.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro --version /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. /tmp/ccRPgs9J.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o GNU ld (GNU Binutils for Ubuntu) 2.34 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Best Regards, Rong Chen
Re: [LKP] Re: b614345f52 ("x86/entry: Clarify irq_{enter,exit}_rcu()"): WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3680 lockdep_hardirqs_on_prepare
On 6/3/20 6:23 PM, Thomas Gleixner wrote: kernel test robot writes: 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/l...@lists.01.org #!/bin/bash kernel=$1 initrd=yocto-x86_64-trinity.cgz wget --no-clobber https://download.01.org/0day-ci/lkp-qemu/osimage/yocto/$initrd That results in a 404. Still the same problem as months ago. Hi Thomas, Sorry about that, we'll fix it soon. Best Regards, Rong Chen initrd=yocto-trinity-x86_64.cgz works ___ LKP mailing list -- l...@lists.01.org To unsubscribe send an email to lkp-le...@lists.01.org
Re: Default enable RCU list lockdep debugging with PROVE_RCU
On 5/18/20 5:47 AM, Paul E. McKenney wrote: On Fri, May 15, 2020 at 02:36:26PM -0400, Qian Cai wrote: On May 14, 2020, at 2:13 PM, Paul E. McKenney wrote: Fair enough! And yes, the Linux kernel is quite large, so I certainly am not asking you to test the whole thing yourself. Ok, I saw 0day bot also started to report those which is good. For example, lkml.org/lkml/2020/5/12/1358 which so far is nit blocking 0day on linux-next since it does not use panic_on_warn yet (while syzbot does). Thus, I am more convinced that we should not revert the commit just for syzbot until someone could also convince 0day to select RCU_EXPERT and then DEBUG_RCU_LIST? Let's ask the 0day people, now CCed, if they would be willing to build with CONFIG_RCU_EXPERT=y and CONFIG_DEBUG_RCU_LIST=y on some fraction of their testing. ;-) Thanx, Paul Hi, Thanks for your advice, we'll support it in the near future. Best Regards, Rong Chen
Re: [Jfs-discussion] [fs] 05c5a0273b: netperf.Throughput_total_tps -71.8% regression
On 5/14/20 12:27 PM, Christian Kujau wrote: On Tue, 12 May 2020, kernel test robot wrote: FYI, we noticed a -71.8% regression of netperf.Throughput_total_tps due to commit: As noted in this report, netperf is used to "measure various aspect of networking performance". Are we sure the bisect is correct? JFS is a filesystem and is not touching net/ in any way. So, having not attempted to reproduce this, maybe the JFS commit is a red herring? C. Hi, The commit also causes -74.6% regression of will-it-scale.per_thread_ops: in testcase: will-it-scale on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G memory with following parameters: nr_task: 100% mode: thread test: unlink2 cpufreq_governor: performance ucode: 0x21 I'll send another report for this regression. Best Regards, Rong Chen
Re: [pipe] f2af7d90e2: xfstests.btrfs.052.fail
On 5/11/20 9:16 AM, Matthew Wilcox wrote: On Mon, May 11, 2020 at 09:09:57AM +0800, kernel test robot wrote: --- tests/btrfs/095.out2020-04-09 10:45:28.0 +0800 +++ /lkp/benchmarks/xfstests/results//btrfs/095.out.bad2020-05-06 21:13:51.276485703 +0800 @@ -1,35 +1,9 @@ QA output created by 095 -Blocks modified: [135 - 164] -Blocks modified: [768 - 792] +awk: line 19: function strtonum never defined +awk: line 19: function strtonum never defined +awk: line 19: function strtonum never defined +awk: line 19: function strtonum never defined This looks like a problem with the test setup. Hi Matthew, Thanks for the response, we'll double check it. Best Regards, Rong Chen
Re: [kbuild-all] [PATCH] net: stmmac: socfpga: re-use the `interface` parameter from platform data
On 9/9/19 4:53 PM, Ardelean, Alexandru wrote:
On Sat, 2019-09-07 at 20:54 +0800, kbuild test robot wrote:
[External]
Hi Alexandru,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
Hmm, this error should be expectable I guess: I applied this on net-next/master.
Sorry for the inconvenience, we'll take a look. btw, 0day-CI introduced
'--base' option to record base tree info in format-patch.
please see https://stackoverflow.com/a/37406982
Best Regards,
Rong Chen
Alex
[cannot apply to v5.3-rc7 next-20190904]
[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/Alexandru-Ardelean/net-stmmac-socfpga-re-use-the-interface-parameter-from-platform-data/20190907-190627
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from include/linux/dma-mapping.h:7:0,
from include/linux/skbuff.h:30,
from include/linux/if_ether.h:19,
from include/uapi/linux/ethtool.h:19,
from include/linux/ethtool.h:18,
from include/linux/phy.h:16,
from
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c:11:
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c: In function
'socfpga_gen5_set_phy_mode':
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: error: 'phymode'
undeclared (first use in this
function); did you mean 'phy_modes'?
dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
^
include/linux/device.h:1499:32: note: in definition of macro 'dev_err'
_dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: note: each
undeclared identifier is reported only once
for each function it appears in
dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
^
include/linux/device.h:1499:32: note: in definition of macro 'dev_err'
_dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c: In function
'socfpga_gen10_set_phy_mode':
drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c:340:6: error:
'phymode' undeclared (first use in this
function); did you mean 'phy_modes'?
phymode == PHY_INTERFACE_MODE_MII ||
^~~
phy_modes
vim +264 drivers/net//ethernet/stmicro/stmmac/dwmac-socfpga.c
40ae25505fe834 Dinh Nguyen2019-06-05 255
40ae25505fe834 Dinh Nguyen2019-06-05 256 static int
socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
40ae25505fe834 Dinh Nguyen2019-06-05 257 {
40ae25505fe834 Dinh Nguyen2019-06-05 258 struct regmap
*sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
40ae25505fe834 Dinh Nguyen2019-06-05 259 u32 reg_offset =
dwmac->reg_offset;
40ae25505fe834 Dinh Nguyen2019-06-05 260 u32 reg_shift =
dwmac->reg_shift;
40ae25505fe834 Dinh Nguyen2019-06-05 261 u32 ctrl, val, module;
40ae25505fe834 Dinh Nguyen2019-06-05 262
6169afbe4a340b Alexandru Ardelean 2019-09-06 263 if
(socfpga_set_phy_mode_common(dwmac, )) {
801d233b7302ee Dinh Nguyen2014-03-26 @264 dev_err(dwmac->dev,
"bad phy mode %d\n", phymode);
801d233b7302ee Dinh Nguyen2014-03-26 265 return -EINVAL;
801d233b7302ee Dinh Nguyen2014-03-26 266 }
801d233b7302ee Dinh Nguyen2014-03-26 267
b4834c86e11baf Ley Foon Tan 2014-08-20 268 /* Overwrite val to
GMII if splitter core is enabled. The
phymode here
b4834c86e11baf Ley Foon Tan 2014-08-20 269* is the actual phy
mode on phy hardware, but phy interface
from
b4834c86e11baf Ley Foon Tan 2014-08-20 270* EMAC core is GMII.
b4834c86e11baf Ley Foon Tan 2014-08-20 271*/
b4834c86e11baf Ley Foon Tan 2014-08-20 272 if
(dwmac->splitter_base)
b4834c86e11baf Ley Foon Tan 2014-08-20 273 val =
SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
b4834c86e11baf Ley Foon Tan 2014-08-20 274
70cb136f773083 Joachim Eastwood 2016-05-01 275 /* Assert reset to the
enet controller before changing the phy
mode */
bc8a2d9bcbf1ca Dinh Nguyen2018-06-
Re: [kbuild-all] Re: [PATCH] lis3lv02d: switch to using input device polling mode
Hi, On 10/3/19 8:03 AM, Dmitry Torokhov wrote: On Wed, Oct 02, 2019 at 04:59:43PM -0700, Dmitry Torokhov wrote: On Thu, Oct 03, 2019 at 07:30:23AM +0800, kbuild test robot wrote: Hi Dmitry, I love your patch! Yet something to improve: [auto build test ERROR on char-misc/char-misc-testing] [cannot apply to v5.4-rc1 next-20191002] This is weird, I just tried applying it to both next-20191002 and Greg's char-misc/char-misc-testing and it applied cleanly and compiled (on x86). You seem to have tried applying it to this commit: Merge tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here is the big char/misc driver pull request for 5.4-rc1... so of it failed because at that time Linus' tree did not have the necessary input changes. I am not sure why you decided to apply the patch to this particular commit. Thanks. Thanks for your comment, robot applied the patch to the head of char-misc/char-misc-testing, It seems the branch was still old at that moment. We'll fix it asap. Best Regards, Rong Chen
Re: [xfs] 610125ab1e: fsmark.app_overhead -71.2% improvement
Hi Dave, On 9/9/19 1:32 PM, Dave Chinner wrote: On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote: Greeting, FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit: A negative improvement? That's somewhat ambiguous... Sorry for causing the misunderstanding, it's a improvement not a regression. 0e822255f95db400 610125ab1e4b1b48dcffe74d9d8 --- %stddev %change %stddev \ |\ 1.095e+08 -71.2% 31557568fsmark.app_overhead 6157 +95.5% 12034fsmark.files_per_sec So, the files/s rate doubled, and the amount of time spent in userspace by the fsmark app dropped by 70%. 167.31 -47.3% 88.25fsmark.time.elapsed_time 167.31 -47.3% 88.25fsmark.time.elapsed_time.max Wall time went down by 50%. 91.00-8.8% 83.00 fsmark.time.percent_of_cpu_this_job_got 148.15 -53.2% 69.38fsmark.time.system_time As did system CPU. IOWs, this change has changed create performance by a factor of 4 - the file create is 2x faster for half the CPU spent. I don't think this is a negative improvement - it's a large positive improvement. I suspect that you need to change the metric classifications for this workload... To avoid misunderstanding, we'll use fsmark.files_per_sec instead of fsmark.app_overhead in the subject. Best Regards, Rong Chen
Re: [btrfs] 3ae92b3782: xfstests.generic.269.fail
On 9/3/19 9:25 PM, Josef Bacik wrote:
On Tue, Sep 03, 2019 at 04:06:33PM +0800, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 3ae92b3782182d282a92573abe95c96d34ca6e73 ("btrfs: change the minimum global
reserve size")
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
master
in testcase: xfstests
with following parameters:
disk: 4HDD
fs: btrfs
test: generic-group13
test-description: xfstests is a regression test suite for xfs and other files
ystems.
test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
It would help if you could capture generic/269.full, but this is likely a
problem with fsck that I fixed a few weeks ago where we're seeing nbytes of an
inode is wrong, but there's an orphan item so it doesn't matter. This patch
just made it more likely for us to have a still being iput'ed inode after a
transaction commit. Thanks,
Josef
Hi Josef,
I enclose the generic/269.full file for your reference.
Best Regards,
Rong Chen
btrfs-progs v4.7.3
See http://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID:
Node size: 16384
Sector size:4096
Filesystem size:512.00MiB
Block group profiles:
Data: single8.00MiB
Metadata: DUP 32.00MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Number of devices: 1
Devices:
IDSIZE PATH
1 512.00MiB /dev/vdb
fsstress -p128 -n9 -f setattr=1 -ffsync=0 -fsync=0 -ffdatasync=0 -d
/fs/scratch/fsstress.2854
dd: error writing '/fs/scratch/SPACE_CONSUMER': No space left on device
34+0 records in
33+0 records out
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
dd: failed to open '/fs/scratch/SPACE_CONSUMER': No space left on device
Killing fsstress process...
_check_btrfs_filesystem: filesystem on /dev/vdb is inconsistent
*** fsck.btrfs output ***
checking extents
checking free space cache
checking fs roots
root 5 inode 1551 errors 400, nbytes wrong
Checking filesystem on /dev/vdb
UUID: f5ee8129-b434-4217-a8fb-bae2bf4c0062
found 461627392 bytes used err is 1
total csum bytes: 267348
total tree bytes: 9715712
total fs tree bytes: 7602176
total extent tree bytes: 1540096
btree space waste bytes: 1712570
file data blocks allocated: 1012891648
referenced 399106048
*** end fsck.btrfs output
*** mount output ***
rootfs on / type rootfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=1729372k,nr_inodes=432343,mode=755)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/hugetlb type cgroup
(rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,
Re: [PATCH 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
Hi, On 8/19/19 2:59 AM, Jernej Škrabec wrote: Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a): Hi Jernej, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc4 next-20190816] [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/Jernej-Skrabec/dt-bindings-arm-sun xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config: arm64-defconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label or path r_ir not found FATAL ERROR: Syntax error parsing input tree Strange, Allwinner tree has commit, which introduces r_ir node: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/? h=sunxi/dt-for-5.4=9267811aad3524c857cf2e16bbadd8c569e15ab9 Maybe kbuild test robot tree doesn't have it? The tree is in our list. https://github.com/intel/lkp-tests/blob/master/repo/linux/sunxi Robot also tries to apply patches to a git tree to test. Maybe your patch was applied to a wrong git tree. Best Regards, Rong Chen
Re: [kbuild-all] [PATCH] fix odd_ptr_err.cocci warnings
Hi Peter, We have updated to only send the reports to you, please see https://github.com/intel/lkp-tests/blob/master/repo/linux/omap-audio Best Regards, Rong Chen On 8/9/19 9:21 PM, Julia Lawall wrote: On Fri, 9 Aug 2019, Peter Ujfalusi wrote: On 09/08/2019 15.31, Mark Brown wrote: On Fri, Aug 09, 2019 at 12:30:46PM +0200, Julia Lawall wrote: tree: https://github.com/omap-audio/linux-audio peter/ti-linux-4.19.y/wip head: 62c9c1442c8f61ca93e62e1a9d8318be0abd9d9a commit: 62c9c1442c8f61ca93e62e1a9d8318be0abd9d9a [34/34] j721e new machine driver wip :: branch date: 20 hours ago :: commit date: 20 hours ago j721e-evm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/soc/ti/j721e-evm.c +++ b/sound/soc/ti/j721e-evm.c @@ -283,7 +283,7 @@ static int j721e_get_clocks(struct platf This file isn't upstream, it's only in the TI BSP. Yes, it is not upstream, but the fix is valid. Julia: is it possible to direct these notifications only to me from https://github.com/omap-audio/linux-audio.git ? It mostly carries TI BSP stuff and my various for upstream branches nowdays. Please discuss it with the kbuild people. They should be able to set it up as you want. You can try l...@intel.com julia ___ kbuild-all mailing list kbuild-...@lists.01.org https://lists.01.org/mailman/listinfo/kbuild-all
[iommu/dma] b1d2dc009d: can't load the disk
41.046795] mpt2sas_cm0: diag reset: SUCCESS [ 41.052527] mgag200 :08:00.0: fb0: mgag200drmfb frame buffer device Starting Load CPU micro [ 41.358171] [drm] Initialized mgag200 1.0.0 20110418 for :08:00.0 on minor 0 code update... Starting System Logging Service... 0m] Started Syst [ 41.399695] mpt2sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10522/_scsih_probe()! em Logging Service. Starting LSB: Load kernel image with kexec... [ 44.527222] Kernel tests: Boot OK! [ 44.527225] [ 48.521365] install debs round one: dpkg -i --force-confdef --force-depends /opt/deb/ntpdate_1%3a4.2.8p10+dfsg-3+deb9u2_amd64.deb [ 48.521368] [ 48.538114] /opt/deb/python2.7_2.7.13-2+deb9u3_amd64.deb [ 48.538116] [ 48.547544] /opt/deb/libpython2.7-stdlib_2.7.13-2+deb9u3_amd64.deb [ 48.547548] [ 48.557987] /opt/deb/python2.7-minimal_2.7.13-2+deb9u3_amd64.deb [ 48.557990] [ 48.568234] /opt/deb/libpython2.7-minimal_2.7.13-2+deb9u3_amd64.deb [ 48.568235] [ 48.578670] /opt/deb/libpython2.7_2.7.13-2+deb9u3_amd64.deb [ 48.578673] [ 48.588134] /opt/deb/sysstat_11.4.3-2_amd64.deb [ 48.588135] [ 48.596519] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb [ 48.596521] [ 48.605583] Selecting previously unselected package ntpdate. [ 48.605586] [ 48.615955] (Reading database ... 16195 files and directories currently installed.) [ 48.615958] [ 48.628562] Preparing to unpack .../ntpdate_1%3a4.2.8p10+dfsg-3+deb9u2_amd64.deb ... [ 48.628565] [ 48.640842] Unpacking ntpdate (1:4.2.8p10+dfsg-3+deb9u2) ... [ 48.640845] [ 48.651117] Preparing to unpack .../python2.7_2.7.13-2+deb9u3_amd64.deb ... [ 48.651119] [ 48.662900] Unpacking python2.7 (2.7.13-2+deb9u3) over (2.7.13-2+deb9u2) ... [ 48.662905] [ 48.674907] Preparing to unpack .../libpython2.7-stdlib_2.7.13-2+deb9u3_amd64.deb ... [ 48.674912] [ 48.685559] random: crng init done [ 48.688065] Unpacking libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) over (2.7.13-2+deb9u2) ... [ 48.688070] [ 48.691528] random: 7 urandom warning(s) missed due to ratelimiting [ 48.712690] Preparing to unpack .../python2.7-minimal_2.7.13-2+deb9u3_amd64.deb ... [ 48.712693] [ 48.725540] Unpacking python2.7-minimal (2.7.13-2+deb9u3) over (2.7.13-2+deb9u2) ... [ 48.725546] [ 48.738565] Preparing to unpack .../libpython2.7-minimal_2.7.13-2+deb9u3_amd64.deb ... [ 48.738569] [ 48.751939] Unpacking libpython2.7-minimal:amd64 (2.7.13-2+deb9u3) over (2.7.13-2+deb9u2) ... [ 48.751941] [ 48.765516] Selecting previously unselected package libpython2.7:amd64. [ 48.765517] [ 48.777059] Preparing to unpack .../libpython2.7_2.7.13-2+deb9u3_amd64.deb ... [ 48.777060] [ 48.788991] Unpacking libpython2.7:amd64 (2.7.13-2+deb9u3) ... [ 48.788997] [ 48.799292] Selecting previously unselected package sysstat. [ 48.799293] [ 48.809615] Preparing to unpack .../deb/sysstat_11.4.3-2_amd64.deb ... [ 48.809618] [ 48.820387] Unpacking sysstat (11.4.3-2) ... [ 48.820389] [ 48.828886] Selecting previously unselected package gawk. [ 48.828892] [ 48.838913] Preparing to unpack .../gawk_1%3a4.1.4+dfsg-1_amd64.deb ... [ 48.838918] [ 48.849806] Unpacking gawk (1:4.1.4+dfsg-1) ... [ 48.849807] [ 48.858691] Setting up ntpdate (1:4.2.8p10+dfsg-3+deb9u2) ... [ 48.858694] [ 48.869081] Setting up libpython2.7-minimal:amd64 (2.7.13-2+deb9u3) ... [ 48.869084] [ 48.879966] Setting up sysstat (11.4.3-2) ... [ 48.879967] [ 48.888376] Setting up gawk (1:4.1.4+dfsg-1) ... [ 48.888380] [ 48.897503] Setting up libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ... [ 48.897505] [ 48.908595] Setting up python2.7-minimal (2.7.13-2+deb9u3) ... [ 48.908598] [ 48.918941] Setting up libpython2.7:amd64 (2.7.13-2+deb9u3) ... [ 48.918945] [ 48.929200] Setting up python2.7 (2.7.13-2+deb9u3) ... [ 48.929202] [ 48.938602] Processing triggers for mime-support (3.60) ... [ 48.938605] [ 48.948663] Processing triggers for libc-bin (2.24-11+deb9u3) ... [ 48.948664] [ 48.959229] Processing triggers for systemd (232-25+deb9u2) ... [ 48.959231] [ 49.729064] 25 Jul 16:02:52 ntpdate[1803]: step time server 192.168.1.1 offset 28724.486990 sec [ 49.729069] [ 81.657115] can't load the disk LABEL=LKP-ROOTFS, skip testing... Thanks, Rong Chen dmesg.xz Description: application/xz job.sh Description: application/shellscript
Re: buildbot status?
On 6/30/19 9:49 PM, Philip Li wrote: On Sun, Jun 30, 2019 at 12:51:54PM +0300, Kalle Valo wrote: Christoph Hellwig writes: Hi buildbot maintainers, lately I usually get no, in some case a few very delayed build bot results for my repos. Is this as known issue? I have the same problem, I did receive few reports on Wednesday but nothing after that. I rely a lot for buildbot doing build checks on wireless-drivers patches so I hope it comes back soon. hi Kalle and Christoph, sorry for inconvenience. We will check this as early as possible which may be due to certain issue in our side. +Rong to help check the exact problem. Hi all, There's a problem with the network in our side, we're trying to solve it. Sorry for the inconvenience that may have caused to you. Best Regards, Rong Chen -- Kalle Valo
Re: [LKP] fcc784be83 [ 150.952780] WARNING: held lock freed!
On 6/27/19 10:32 PM, Steven Rostedt wrote: On Wed, 19 Jun 2019 10:41:14 +0800 kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit fcc784be837714a9173b372ff9fb9b514590dad9 Author: Steven Rostedt (VMware) AuthorDate: Wed Apr 4 14:06:30 2018 -0400 Commit: Ingo Molnar CommitDate: Thu Jun 21 18:19:01 2018 +0200 locking/lockdep: Do not record IRQ state within lockdep code While debugging where things were going wrong with mapping enabling/disabling interrupts with the lockdep state and actual real enabling and disabling interrupts, I had to silent the IRQ disabling/enabling in debug_check_no_locks_freed() because it was always showing up as it was called before the splat was. Use raw_local_irq_save/restore() for not only debug_check_no_locks_freed() but for all internal lockdep functions, as they hide useful information about where interrupts were used incorrectly last. Signed-off-by: Steven Rostedt (VMware) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/lkml/20180404140630.3f4f4...@gandalf.local.home Signed-off-by: Ingo Molnar I can crash with this config with and without this commit. Are you sure the bug is with this commit? Can you consistently reproduce the problem with the commit applied, and consistently not see the problem with the commit removed? If not, then you should definitely add that procedure before sending these reports, otherwise they will start to be ignored. Hi Steve, Sorry for the inconvenience, the robot noticed that the error "WARNING: held lock freed!" first appears with commit fcc784be83 and didn't find the error in parent commit. then it sent it out automatically. We'll improve the robot to sent reports more carefully. Best Regards, Rong Chen -- Steve 03eeafdd9a locking/rwsem: Fix up_read_non_owner() warning with DEBUG_RWSEMS fcc784be83 locking/lockdep: Do not record IRQ state within lockdep code bed3c0d84e Merge tag 'for-5.2-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux 1c6b40509d Add linux-next specific files for 20190618 +--++++---+ | | 03eeafdd9a | fcc784be83 | bed3c0d84e | next-20190618 | +--++++---+ | boot_successes | 874| 277| 276| 21| | boot_failures | 14 | 19 | 64 | 7 | | BUG:soft_lockup-CPU##stuck_for#s | 11 | 2 | 4 | | | EIP:smp_call_function_single | 1 | 1 || | | Kernel_panic-not_syncing:softlockup:hung_tasks | 11 | 2 | 4 | | | EIP:_raw_spin_unlock_irqrestore | 3 | 0 | 1 | | | EIP:__copy_user_ll | 2 | 0 | 1 | | | invoked_oom-killer:gfp_mask=0x | 1 | 2 | 1 | | | Mem-Info | 1 | 2 | 2 | | | EIP:wp_page_copy | 3 ||| | | BUG:kernel_hang_in_early-boot_stage | 1 ||| | | EIP:shmem_getpage_gfp | 2 | 0 | 1 | | | BUG:workqueue_lockup-pool | 1 | 0 | 1 | | | BUG:kernel_hang_in_boot-around-mounting-root_stage | 0 | 1 || | | Out_of_memory:Kill_process | 0 | 1 || | | WARNING:held_
Re: [LKP] [btrfs] c8eaeac7b7: aim7.jobs-per-min -11.7% regression
On 6/26/19 11:17 AM, Josef Bacik wrote:
On Wed, Jun 26, 2019 at 10:39:36AM +0800, Rong Chen wrote:
On 6/25/19 10:22 PM, Josef Bacik wrote:
On Fri, Jun 21, 2019 at 08:48:03AM +0800, Huang, Ying wrote:
"Huang, Ying" writes:
"Huang, Ying" writes:
Hi, Josef,
kernel test robot writes:
Greeting,
FYI, we noticed a -11.7% regression of aim7.jobs-per-min due to commit:
commit: c8eaeac7b734347c3afba7008b7af62f37b9c140 ("btrfs: reserve
delalloc metadata differently")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: aim7
on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with 384G
memory
with following parameters:
disk: 4BRD_12G
md: RAID0
fs: btrfs
test: disk_rr
load: 1500
cpufreq_governor: performance
test-description: AIM7 is a traditional UNIX system level benchmark
suite which is used to test and measure the performance of multiuser
system.
test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
Here's another regression, do you have time to take a look at this?
Ping
Ping again ...
Finally got time to look at this but I can't get the reproducer to work
root@destiny ~/lkp-tests# bin/lkp run ~/job-aim.yaml
Traceback (most recent call last):
11: from /root/lkp-tests/bin/run-local:18:in `'
10: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
9: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
8: from /root/lkp-tests/lib/yaml.rb:5:in `'
7: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
6: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
5: from /root/lkp-tests/lib/common.rb:9:in `'
4: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
3: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
2: from /root/lkp-tests/lib/array_ext.rb:3:in `'
1: from
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require': cannot
load such file -- active_support/core_ext/enumerable (LoadError)
Hi Josef,
I tried the latest lkp-tests, and didn't have the problem. Could you please
update the lkp-tests repo and run "lkp install" again?
I updated it this morning, and I just updated it now, my tree is on
2c5b1a95b08dbe81bba64419c482a877a3b424ac
lkp install says everything is installed except
No match for argument: libipc-run-perl
I've just fixed it. could you add "libipc-run-perl: perl-IPC-Run" to the
end of distro/adaptation/fedora?
Thanks,
Rong Chen
and it still doesn't run properly. Thanks,
Josef
Re: [LKP] [btrfs] c8eaeac7b7: aim7.jobs-per-min -11.7% regression
On 6/25/19 10:22 PM, Josef Bacik wrote:
On Fri, Jun 21, 2019 at 08:48:03AM +0800, Huang, Ying wrote:
"Huang, Ying" writes:
"Huang, Ying" writes:
Hi, Josef,
kernel test robot writes:
Greeting,
FYI, we noticed a -11.7% regression of aim7.jobs-per-min due to commit:
commit: c8eaeac7b734347c3afba7008b7af62f37b9c140 ("btrfs: reserve
delalloc metadata differently")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: aim7
on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz with 384G
memory
with following parameters:
disk: 4BRD_12G
md: RAID0
fs: btrfs
test: disk_rr
load: 1500
cpufreq_governor: performance
test-description: AIM7 is a traditional UNIX system level benchmark
suite which is used to test and measure the performance of multiuser
system.
test-url: https://sourceforge.net/projects/aimbench/files/aim-suite7/
Here's another regression, do you have time to take a look at this?
Ping
Ping again ...
Finally got time to look at this but I can't get the reproducer to work
root@destiny ~/lkp-tests# bin/lkp run ~/job-aim.yaml
Traceback (most recent call last):
11: from /root/lkp-tests/bin/run-local:18:in `'
10: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
9: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
8: from /root/lkp-tests/lib/yaml.rb:5:in `'
7: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
6: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
5: from /root/lkp-tests/lib/common.rb:9:in `'
4: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
3: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
2: from /root/lkp-tests/lib/array_ext.rb:3:in `'
1: from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in
`require'
/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require': cannot
load such file -- active_support/core_ext/enumerable (LoadError)
Hi Josef,
I tried the latest lkp-tests, and didn't have the problem. Could you
please update the lkp-tests repo and run "lkp install" again?
Thanks,
Rong Chen
I can't even figure out from the job file or anything how I'm supposed to run
AIM7 itself. This is on a Fedora 30 box, so it's relatively recent. Thanks,
Josef
Re: [LKP] [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
On 6/25/19 7:32 PM, Thomas Gleixner wrote:
Rong,
On Tue, 25 Jun 2019, Rong Chen wrote:
On 6/25/19 2:24 PM, Thomas Gleixner wrote:
On 6/22/19 3:08 AM, Thomas Gleixner wrote:
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp
2 -m
2G
I cannot reproduce that issue. What's the underlying hardware machine?
brand: Genuine Intel(R) CPU 000 @ 2.27GHz
model: Westmere-EX
memory: 256G
nr_node: 4
nr_cpu: 80
Ok. I'll try to find something similar. Can please you rerun that test on
that particular configuration with the updated branch?
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi
I have tested commit e0b179bc1a ("x86/apic/x2apic: Add conditional IPI
shorthands support"), the problem is still exist.
the head of that branch is:
4f3f6d6a7f8e ("x86/apic/x2apic: Add conditional IPI shorthands support")
This is WIP and force pushed. There are no incremental changes. Could you
please check again?
The problem is still exist.
Best Regards,
Rong Chen
Thanks,
tglx
___
LKP mailing list
l...@lists.01.org
https://lists.01.org/mailman/listinfo/lkp
dmesg.xz
Description: application/xz
Re: [LKP] [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
On 6/25/19 2:24 PM, Thomas Gleixner wrote:
Rong,
On Tue, 25 Jun 2019, Rong Chen wrote:
On 6/22/19 3:08 AM, Thomas Gleixner wrote:
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m
2G
I cannot reproduce that issue. What's the underlying hardware machine?
brand: Genuine Intel(R) CPU 000 @ 2.27GHz
model: Westmere-EX
memory: 256G
nr_node: 4
nr_cpu: 80
Ok. I'll try to find something similar. Can please you rerun that test on
that particular configuration with the updated branch?
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi
Hi tglx,
I have tested commit e0b179bc1a ("x86/apic/x2apic: Add conditional IPI
shorthands support"), the problem is still exist.
Best Regards,
Rong Chen
dmesg.xz
Description: application/xz
Re: [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
On 6/22/19 3:08 AM, Thomas Gleixner wrote:
On Thu, 20 Jun 2019, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: e1056a25daa6460c95e92d7d6853d05ad62458f7 ("x86/hotplug: Silence APIC and NMI
when CPU is dead")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.x86/ipi
in testcase: locktorture
with following parameters:
runtime: 300s
test: cpuhotplug
test-description: This torture test consists of creating a number of kernel
threads which acquire the lock and hold it for specific amount of time, thus
simulating different critical region behaviors.
test-url: https://www.kernel.org/doc/Documentation/locking/locktorture.txt
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 2G
I cannot reproduce that issue. What's the underlying hardware machine?
brand: Genuine Intel(R) CPU 000 @ 2.27GHz
model: Westmere-EX
memory: 256G
nr_node: 4
nr_cpu: 80
Best Regards,
Rong Chen
Thanks,
tglx
Re: [selftests/bpf] 69d96519db: kernel_selftests.bpf.test_socket_cookie.fail
On 6/22/19 6:27 AM, Stanislav Fomichev wrote:
On 06/21, Andrii Nakryiko wrote:
)
On Fri, Jun 21, 2019 at 9:11 AM Stanislav Fomichev wrote:
On 06/21, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 69d96519dbf0bfa1868dc8597d4b9b2cdeb009d7 ("selftests/bpf: convert
socket_cookie test to sk storage")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: kernel_selftests
with following parameters:
group: kselftests-00
test-description: The kernel contains a set of "self tests" under the
tools/testing/selftests/ directory. These are intended to be small unit tests to exercise
individual code paths in the kernel.
test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
# selftests: bpf: test_socket_cookie
# libbpf: failed to create map (name: 'socket_cookies'): Invalid
# argument
Another case of old clang trying to create a map that depends on BTF?
Should we maybe switch those BTF checks in the kernel to return
EOPNOTSUPP to make it easy to diagnose?
For older compilers that don't generate DATASEC/VAR, you'll see a clear message:
libbpf: DATASEC '.maps' not found.
So this must be something else. I just confirmed with clang version
7.0.20180201 that for ./test_socket_cookie that's the first line
that's emitted on failure.
Thanks for checking, I also took a look at the attached kernel_selftests.xz,
here is what it has:
2019-06-21 11:58:35 ln -sf /usr/bin/clang-6.0 /usr/bin/clang
2019-06-21 11:58:35 ln -sf /usr/bin/llc-6.0 /usr/bin/llc
...
# BTF libbpf test[1] (test_btf_haskv.o): SKIP. No ELF .BTF found
# BTF libbpf test[2] (test_btf_nokv.o): SKIP. No ELF .BTF found
...
# Test case #0 (btf_dump_test_case_syntax): test_btf_dump_case:71:FAIL
# failed to load test BTF: -2
# Test case #1 (btf_dump_test_case_ordering): test_btf_dump_case:71:FAIL
# failed to load test BTF: -2
...
And so on. So there is clearly an old clang that doesn't emit any
BTF. And I also don't see your recent abd29c931459 before 69d96519dbf0 in
linux-next, that's why it doesn't complain about missing/corrupt BTF.
We need to convince lkp people to upgrade clang, otherwise, I suppose,
we'll get more of these reportings after your recent df0b77925982 :-(
Thanks for the clarification, we'll upgrade clang asap.
Best Regards,
Rong Chen
# libbpf: failed to load object './socket_cookie_prog.o'
# (test_socket_cookie.c:149: errno: Invalid argument) Failed to load
# ./socket_cookie_prog.o
# FAILED
not ok 15 selftests: bpf: test_socket_cookie
To reproduce:
# build kernel
cd linux
cp config-5.2.0-rc2-00598-g69d9651 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
Re: eb9d1bf079 [ 88.881528] EIP: _random_read
On 5/23/19 12:24 AM, Theodore Ts'o wrote: Can you check and see if this addresses the issue? I'm not able to easily repro the softlockup. Hi, The patch could fix the issue in our testing environment. Best Regards, Rong Chen Thanks! - Ted commit f93d3e94983bf8b4697ceb121c79afd941862860 Author: Theodore Ts'o Date: Wed May 22 12:02:16 2019 -0400 random: fix soft lockup when trying to read from an uninitialized blocking pool Fixes: eb9d1bf079bb: "random: only read from /dev/random after its pool has received 128 bits" Reported-by: kernel test robot Signed-off-by: Theodore Ts'o diff --git a/drivers/char/random.c b/drivers/char/random.c index a42b3d764da8..9cea93d0bfb3 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1936,8 +1936,8 @@ _random_read(int nonblock, char __user *buf, size_t nbytes) return -EAGAIN; wait_event_interruptible(random_read_wait, - ENTROPY_BITS(_pool) >= - random_read_wakeup_bits); + blocking_pool.initialized && + (ENTROPY_BITS(_pool) >= random_read_wakeup_bits)); if (signal_pending(current)) return -ERESTARTSYS; }
Re: [ext4] 345c0dbf3a: xfstests.ext4.303.fail
On 4/27/19 12:28 AM, Theodore Ts'o wrote:
On Fri, Apr 26, 2019 at 05:47:09PM +0800, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 345c0dbf3a30872d9b204db96b5857cd00808cae ("ext4: protect journal inode's
blocks using block_validity")
https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git dev
in testcase: xfstests
with following parameters:
disk: 4HDD
fs: ext4
test: ext4-run
Hi, I'm not able to reproduce this.
Thanks for your input, we found the test result of ext4/303 is not
stable on this commit, but it's no problem on v5.1-rc7.
TESTRUNID: tytso-20190426093752
KERNEL:kernel 5.1.0-rc3-xfstests-7-g345c0dbf3a30 #921 SMP Fri Apr 26
09:36:55 EDT 2019 x86_64
CMDLINE: -c 4k -g auto
CPUS: 2
MEM: 7680
ext4/4k: 462 tests, 43 skipped, 4271 seconds
Totals: 419 tests, 43 skipped, 0 failures, 0 errors, 4249s
Ran: ext4/001 ext4/002 ext4/003 ext4/004 ext4/005 ext4/020 ext4/021 ext4/022
ext4/023 ext4/024 ext4/025 ext4/026 ext4/027 ext4/028 ext4/029 ext4/030
ext4/031 ext4/032 ext4/033 ext4/034 ext4/271 ext4/301 ext4/302 ext4/303
ext4/305 ext4/306 ext4/307 ext4/308 generic/001 generic/002 generic/003
Given some of the failures, especially this one:
Yes, it's our fault, we have fixed it.
Best Regards,
Rong Chen
ext4/307- output mismatch (see
/lkp/benchmarks/xfstests/results//ext4/307.out.bad)
--- tests/ext4/307.out 2019-04-25 09:04:55.0 +0800
+++ /lkp/benchmarks/xfstests/results//ext4/307.out.bad 2019-04-26
13:15:02.522490198 +0800
@@ -1,6 +1,7 @@
QA output created by 307
Run fsstress
+./tests/ext4/307: line 34: gawk: command not found
Allocate donor file
Perform compacting
Check data
...
(Run 'diff -u /lkp/benchmarks/xfstests/tests/ext4/307.out
/lkp/benchmarks/xfstests/results//ext4/307.out.bad' to see the entire diff)
I'm very much wondering whether your VM has gotten corrupted or hasn't
been correctly set up?
- Ted
Re: [rcu:dev.2019.03.20b 54/83] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type defaults to 'int' in declaration of 'DEFINE_SRCU'
On Tue, Apr 02, 2019 at 06:04:24AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 02, 2019 at 08:32:45AM +0800, Rong Chen wrote:
> >
> > On 3/28/19 3:57 AM, Paul E. McKenney wrote:
> > >On Mon, Mar 25, 2019 at 02:34:27AM +0800, kbuild test robot wrote:
> > >>tree:
> > >>https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > >>dev.2019.03.20b
> > >>head: 6d4434b4b4df791620743178e1419de882b44c7b
> > >>commit: eb89abcb30733e3a2343dda23cb6d81cc17c60b3 [54/83] rcu: Forbid
> > >>DEFINE{,_STATIC}_SRCU() from modules
> > >>config: x86_64-randconfig-b0-03250021 (attached as .config)
> > >>compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> > >>reproduce:
> > >> git checkout eb89abcb30733e3a2343dda23cb6d81cc17c60b3
> > >> # save the attached .config to linux build tree
> > >> make ARCH=x86_64
> > >>
> > >>All errors (new ones prefixed by >>):
> > >>
> > >>drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning:
> > >> data definition has no type or storage class
> > >> DEFINE_SRCU(kfd_processes_srcu);
> > >> ^~~
> > >>>>drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type
> > >>>>defaults to 'int' in declaration of 'DEFINE_SRCU' [-Werror=implicit-int]
> > >>drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning:
> > >> parameter names (without types) in function declaration
> > >>cc1: some warnings being treated as errors
> > >I don't have that hardware, but does the following help? (It at least
> > >builds for me, but your mileage may vary.)
> >
> > Yes, the patch works for kbuild robot.
>
> Thank you very much! May I add your Tested-by?
Sure, please feel free to add it.
Thanks,
Rong Chen
>
> Thanx, Paul
>
> > Thanks,
> > Rong Chen
> >
> >
> > >
> > >
> > >
> > >commit b30be5a76070402912437fa23b43de11cb1973f4
> > >Author: Paul E. McKenney
> > >Date: Wed Mar 27 12:53:36 2019 -0700
> > >
> > > drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu
> > > Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
> > > requires that the size of the reserved region be increased, which is
> > > not something we really want to be doing. This commit therefore
> > > removes
> > > the DEFINE_STATIC_SRCU() from
> > > drivers/gpu/drm/amd/amdkfd/kfd_process.c in
> > > favor of defining kfd_processes_srcu as a simple srcu_struct,
> > > initializing
> > > it in amdgpu_amdkfd_init(), and cleaning it up in
> > > amdgpu_amdkfd_fini().
> > > Reported-by: kbuild test robot
> > > Signed-off-by: Paul E. McKenney
> > > Cc: Oded Gabbay
> > > Cc: Alex Deucher
> > > Cc: "Christian König" > > Cc: "David (ChunMing) Zhou"
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > >
> > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > >b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > >index fe1d7368c1e6..eadb20dee867 100644
> > >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
> > >@@ -28,6 +28,8 @@
> > > #include
> > > #include
> > >+extern struct srcu_struct kfd_processes_srcu;
> > >+
> > > static const unsigned int compute_vmid_bitmap = 0xFF00;
> > > /* Total memory size in system memory and all GPU VRAM. Used to
> > >@@ -40,6 +42,8 @@ int amdgpu_amdkfd_init(void)
> > > struct sysinfo si;
> > > int ret;
> > >+ ret = init_srcu_struct(_processes_srcu);
> > >+ WARN_ON(ret);
> > > si_meminfo();
> > > amdgpu_amdkfd_total_mem_size = si.totalram - si.totalhigh;
> > > amdgpu_amdkfd_total_mem_size *= si.mem_unit;
> > >@@ -57,6 +61,7 @@ int amdgpu_amdkfd_init(void)
> > > void amdgpu_amdkfd_fini(void)
> > > {
> > > kgd2kfd_exit();
> > >+ cleanup_srcu_struct(_processes_srcu);
> > > }
> > > void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev)
> > >diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > >b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > >index 4bdae78bab8e..98b694068b8a 100644
> > >--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > >+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > >@@ -47,7 +47,7 @@ struct mm_struct;
> > > DEFINE_HASHTABLE(kfd_processes_table, KFD_PROCESS_TABLE_SIZE);
> > > static DEFINE_MUTEX(kfd_processes_mutex);
> > >-DEFINE_SRCU(kfd_processes_srcu);
> > >+struct srcu_struct kfd_processes_srcu;
> > > /* For process termination handling */
> > > static struct workqueue_struct *kfd_process_wq;
> > >
> >
>
Re: [LKP] [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage, last_printk:Probing_EDD(edd=off_to_disable)...ok
On 4/1/19 11:40 PM, David Sterba wrote:
On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
On 4/1/2019 10:29 PM, Qu Wenruo wrote:
On 2019/4/1 下午10:02, Chen, Rong A wrote:
On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
On 1.04.19 г. 16:24 ч., kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
tree-checker: Verify dev item")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp
2 -m 2G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|
| 36b9d2bc69 | 70d28b0e4f |
++++
|
boot_successes
| 14 | 0 |
|
boot_failures
| 2 | 14 |
|
IP-Config:Auto-configuration_of_network_failed
| 2 | |
|
BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
| 0 | 14 |
++++
early console in setup code
Probing EDD (edd=off to disable)... ok
BUG: kernel reboot-without-warning in early-boot stage, last printk:
Probing EDD (edd=off to disable)... ok
Linux version 5.0.0-rc8-00196-g70d28b0 #1
Command line: ip=vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
user=lkp
job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
branch=linux-devel/devel-hourly-2019032317
commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
max_uptime=1500
RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
LKP_SERVER=inn debug apic=debug sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0
Can this report be made useful by actually including output from serial
console? For example possible bug-ons or whatnot? dmesg.xz just contains
qemu's command line + some metadata about the test and :
"BUG: kernel reboot-without-warning in early-boot stage, last printk:
Probing EDD (edd=off to disable)... ok"
At least a stack trace would have been useful.
Hi,
We usually use the tool ("bin/lkp qemu -k job-script") to
reproduce it. It seems no stack trace in the result:
So there is no regression at that commit right?
Just some false alert?
Hi,
I think there's a regression, it stopped in the early-boot stage .
Can you please provide any logs that would point at btrfs? If the module
is loaded or built-in started, there's a line about that. Besides that
it's preceded by messages from other subsystems' initialization.
Hi,
CONFIG_BTRFS_FS and CONFIG_BTRFS_FS_REF_VERIFY is enabled in the kconfig.
I disabled them for the experiment, and the new kernel is bootable. I
don't have more logs to prove it.
$ grep BTRFS config-5.0.0-rc8-00196-g70d28b0
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
CONFIG_BTRFS_FS_REF_VERIFY=y
Best Regards,
Rong Chen
___
LKP mailing list
l...@lists.01.org
https://lists.01.org/mailman/listinfo/lkp
Re: [rcu:dev.2019.03.20b 54/83] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type defaults to 'int' in declaration of 'DEFINE_SRCU'
On 3/28/19 3:57 AM, Paul E. McKenney wrote:
On Mon, Mar 25, 2019 at 02:34:27AM +0800, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.03.20b
head: 6d4434b4b4df791620743178e1419de882b44c7b
commit: eb89abcb30733e3a2343dda23cb6d81cc17c60b3 [54/83] rcu: Forbid
DEFINE{,_STATIC}_SRCU() from modules
config: x86_64-randconfig-b0-03250021 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout eb89abcb30733e3a2343dda23cb6d81cc17c60b3
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning: data
definition has no type or storage class
DEFINE_SRCU(kfd_processes_srcu);
^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: error: type defaults
to 'int' in declaration of 'DEFINE_SRCU' [-Werror=implicit-int]
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:50:1: warning: parameter
names (without types) in function declaration
cc1: some warnings being treated as errors
I don't have that hardware, but does the following help? (It at least
builds for me, but your mileage may vary.)
Thanx, Paul
Yes, the patch works for kbuild robot.
Thanks,
Rong Chen
commit b30be5a76070402912437fa23b43de11cb1973f4
Author: Paul E. McKenney
Date: Wed Mar 27 12:53:36 2019 -0700
drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu
Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
requires that the size of the reserved region be increased, which is
not something we really want to be doing. This commit therefore removes
the DEFINE_STATIC_SRCU() from drivers/gpu/drm/amd/amdkfd/kfd_process.c in
favor of defining kfd_processes_srcu as a simple srcu_struct, initializing
it in amdgpu_amdkfd_init(), and cleaning it up in amdgpu_amdkfd_fini().
Reported-by: kbuild test robot
Signed-off-by: Paul E. McKenney
Cc: Oded Gabbay
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index fe1d7368c1e6..eadb20dee867 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -28,6 +28,8 @@
#include
#include
+extern struct srcu_struct kfd_processes_srcu;
+
static const unsigned int compute_vmid_bitmap = 0xFF00;
/* Total memory size in system memory and all GPU VRAM. Used to
@@ -40,6 +42,8 @@ int amdgpu_amdkfd_init(void)
struct sysinfo si;
int ret;
+ ret = init_srcu_struct(_processes_srcu);
+ WARN_ON(ret);
si_meminfo();
amdgpu_amdkfd_total_mem_size = si.totalram - si.totalhigh;
amdgpu_amdkfd_total_mem_size *= si.mem_unit;
@@ -57,6 +61,7 @@ int amdgpu_amdkfd_init(void)
void amdgpu_amdkfd_fini(void)
{
kgd2kfd_exit();
+ cleanup_srcu_struct(_processes_srcu);
}
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 4bdae78bab8e..98b694068b8a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -47,7 +47,7 @@ struct mm_struct;
DEFINE_HASHTABLE(kfd_processes_table, KFD_PROCESS_TABLE_SIZE);
static DEFINE_MUTEX(kfd_processes_mutex);
-DEFINE_SRCU(kfd_processes_srcu);
+struct srcu_struct kfd_processes_srcu;
/* For process termination handling */
static struct workqueue_struct *kfd_process_wq;
Re: [LKP] [uaccess] 780464aed0: WARNING:at_arch/x86/include/asm/uaccess.h:#strnlen_user/0x
On 3/4/19 3:53 AM, Linus Torvalds wrote:
On Sun, Mar 3, 2019 at 9:40 AM kernel test robot wrote:
commit: 780464aed08ad00aa6d5f81ac8bef2e714dc8b06 ("[PATCH v5 2/6] uaccess: Use
user_access_ok() in user_access_begin()")
Hmm. Not an upstream commit ID, so this is presumably a backport.
Ok, let's see what it is using the web link:
url:
https://github.com/0day-ci/linux/commits/Masami-Hiramatsu/tracing-probes-uaccess-Add-support-user-space-access/20190303-203749
Yeah, that just gives a github 404 error.
Sorry for the broken link, It's ok now.
Best Regards,
Rong Chen
I'm _assuming_ it's the WARN_ON_IN_IRQ() in the access_ok().
Which doesn't much make sense either (why wouldn't it happen in
mainline)? But without a useful web link to see what is actually being
tested, I guess it's not something I can even look at...
Linus
___
LKP mailing list
l...@lists.01.org
https://lists.01.org/mailman/listinfo/lkp
Re: [LKP] [RFC PATCH] mm, memory_hotplug: fix off-by-one in is_pageblock_removable
Hi,
The patch can fix the issue for me.
Best Regards,
Rong Chen
On 2/20/19 8:57 PM, Michal Hocko wrote:
Rong Chen,
coudl you double check this indeed fixes the issue for you please?
On Mon 18-02-19 19:15:44, Michal Hocko wrote:
From: Michal Hocko
Rong Chen has reported the following boot crash
[ 40.305212] PGD 0 P4D 0
[ 40.308255] Oops: [#1] PREEMPT SMP PTI
[ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted 5.0.0-rc4-00149-gefad4e4
#1
[ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 40.330813] RIP: 0010:page_mapping+0x12/0x80
[ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d c3 0f 1f
44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da <48> 8b 53 08 48
8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48
[ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202
[ 40.362714] RAX: RBX: fffe RCX: 000a
[ 40.370798] RDX: fffe RSI: 820b9a20 RDI: 88801e5c
[ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: 01b64d13
[ 40.386902] R10: 88801fa87cf8 R11: 0001 R12: 88801e64
[ 40.395033] R13: 820b9a20 R14: 88801f145258 R15: 0001
[ 40.403138] FS: 7fb2079817c0() GS:88801dd0()
knlGS:
[ 40.412243] CS: 0010 DS: ES: CR0: 80050033
[ 40.418846] CR2: 0006 CR3: 1fa82000 CR4: 06a0
[ 40.426951] Call Trace:
[ 40.429843] __dump_page+0x14/0x2c0
[ 40.433947] is_mem_section_removable+0x24c/0x2c0
[ 40.439327] removable_show+0x87/0xa0
[ 40.443613] dev_attr_show+0x25/0x60
[ 40.447763] sysfs_kf_seq_show+0xba/0x110
[ 40.452363] seq_read+0x196/0x3f0
[ 40.456282] __vfs_read+0x34/0x180
[ 40.460233] ? lock_acquire+0xb6/0x1e0
[ 40.464610] vfs_read+0xa0/0x150
[ 40.468372] ksys_read+0x44/0xb0
[ 40.472129] ? do_syscall_64+0x1f/0x4a0
[ 40.476593] do_syscall_64+0x5e/0x4a0
[ 40.480809] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 40.486195] entry_SYSCALL_64_after_hwframe+0x49/0xbe
and bisected it down to efad4e475c31 ("mm, memory_hotplug:
is_mem_section_removable do not pass the end of a zone"). The reason for
the crash is that the mapping is garbage for poisoned (uninitialized) page.
This shouldn't happen as all pages in the zone's boundary should be
initialized. Later debugging revealed that the actual problem is an
off-by-one when evaluating the end_page. start_pfn + nr_pages resp.
zone_end_pfn refers to a pfn after the range and as such it might belong
to a differen memory section. This along with CONFIG_SPARSEMEM then
makes the loop condition completely bogus because a pointer arithmetic
doesn't work for pages from two different sections in that memory model.
Fix the issue by reworking is_pageblock_removable to be pfn based and
only use struct page where necessary. This makes the code slightly
easier to follow and we will remove the problematic pointer arithmetic
completely.
Fixes: efad4e475c31 ("mm, memory_hotplug: is_mem_section_removable do not pass the
end of a zone")
Reported-by:
Signed-off-by: Michal Hocko
---
mm/memory_hotplug.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 124e794867c5..1ad28323fb9f 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1188,11 +1188,13 @@ static inline int pageblock_free(struct page *page)
return PageBuddy(page) && page_order(page) >= pageblock_order;
}
-/* Return the start of the next active pageblock after a given page */
-static struct page *next_active_pageblock(struct page *page)
+/* Return the pfn of the start of the next active pageblock after a given pfn
*/
+static unsigned long next_active_pageblock(unsigned long pfn)
{
+ struct page *page = pfn_to_page(pfn);
+
/* Ensure the starting page is pageblock-aligned */
- BUG_ON(page_to_pfn(page) & (pageblock_nr_pages - 1));
+ BUG_ON(pfn & (pageblock_nr_pages - 1));
/* If the entire pageblock is free, move to the end of free page */
if (pageblock_free(page)) {
@@ -1200,16 +1202,16 @@ static struct page *next_active_pageblock(struct page
*page)
/* be careful. we don't have locks, page_order can be changed.*/
order = page_order(page);
if ((order < MAX_ORDER) && (order >= pageblock_order))
- return page + (1 << order);
+ return pfn + (1 << order);
}
- return page + pageblock_nr_pages;
+ return pfn + pageblock_nr_pages;
}
-static bool is_pageblock_removable_nolock(struct page *page)
+static bool is_pageblock_removable_nolock(unsigned long pfn)
{
+ struct page *page = pfn_to_page(pfn);
struct zone *zone
Re: [LKP] efad4e475c [ 40.308255] Oops: 0000 [#1] PREEMPT SMP PTI
On 2/18/19 5:03 PM, Michal Hocko wrote: On Mon 18-02-19 16:47:26, Rong Chen wrote: On 2/18/19 3:08 PM, Michal Hocko wrote: On Mon 18-02-19 13:28:23, kernel test robot wrote: [...] [ 40.305212] PGD 0 P4D 0 [ 40.308255] Oops: [#1] PREEMPT SMP PTI [ 40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted 5.0.0-rc4-00149-gefad4e4 #1 [ 40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 40.330813] RIP: 0010:page_mapping+0x12/0x80 [ 40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d c3 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da <48> 8b 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48 [ 40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202 [ 40.362714] RAX: RBX: fffe RCX: 000a [ 40.370798] RDX: fffe RSI: 820b9a20 RDI: 88801e5c [ 40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: 01b64d13 [ 40.386902] R10: 88801fa87cf8 R11: 0001 R12: 88801e64 [ 40.395033] R13: 820b9a20 R14: 88801f145258 R15: 0001 [ 40.403138] FS: 7fb2079817c0() GS:88801dd0() knlGS: [ 40.412243] CS: 0010 DS: ES: CR0: 80050033 [ 40.418846] CR2: 0006 CR3: 1fa82000 CR4: 06a0 [ 40.426951] Call Trace: [ 40.429843] __dump_page+0x14/0x2c0 [ 40.433947] is_mem_section_removable+0x24c/0x2c0 This looks like we are stumbling over an unitialized struct page again. Something this patch should prevent from. Could you try to apply [1] which will make __dump_page more robust so that we do not blow up there and give some more details in return. Hi Hocko, I have applied [1] and attached the dmesg file. Thanks so the log confirms that this is really an unitialized struct page [ 12.228622] raw: [ 12.231474] page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) [ 12.232135] [ cut here ] [ 12.232649] kernel BUG at include/linux/mm.h:1020! So now, we have to find out what has been left behind. Please see my other email. Also could you give me faddr2line of the is_mem_section_removable offset please? I assume it is is_pageblock_removable_nolock: if (!node_online(page_to_nid(page))) return false; faddr2line result: is_mem_section_removable+0x24c/0x2c0: page_to_nid at include/linux/mm.h:1020 (inlined by) is_pageblock_removable_nolock at mm/memory_hotplug.c:1221 (inlined by) is_mem_section_removable at mm/memory_hotplug.c:1241 Best Regards, Rong Chen
Re: [kbuild-all] arch/x86/include/asm/cmpxchg.h:245:2: error: 'asm' operand has impossible constraints
On 1/22/19 7:55 PM, Borislav Petkov wrote: On Tue, Jan 22, 2019 at 07:13:59PM +0800, Philip Li wrote: thanks for the feedback, we will blacklist this. So may i understand based on the thread at https://lists.01.org/pipermail/kbuild-all/2018-December/056225.html, this is gcc-4.9 problem? AFAICT, this triggers only on gcc-4.9, 32-bit build. Or do you have other configurations which trigger it? Hi Boris, we have added it to the blacklist, and there's no other configuration found in the past reports. Best Regards, Rong Chen
