Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement
On 08/01/2018 07:46 PM, J. Bruce Fields wrote:
On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote:
On 07/16, Ye Xiaolong wrote:
On 07/04, Huang, Ying wrote:
"J. Bruce Fields" writes:
Thanks!
On Wed, Jun 20, 2018 at 02:52:43PM +0800, kernel test robot wrote:
FYI, we noticed a 32.4% improvement of fsmark.files_per_sec due to commit:
commit: 517dc52baa2a508c82f68bbc7219b48169e6b29f ("nfsd4: shortern default lease
period")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
That doesn't make any sense
OK, I think I see the problem:
in testcase: fsmark
on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G
memory
with following parameters:
iterations: 1x
nr_threads: 1t
disk: 1BRD_48G
fs: f2fs
fs2: nfsv4
filesize: 4M
test_size: 40G
sync_method: fsyncBeforeClose
cpufreq_governor: performance
test-description: The fsmark is a file system benchmark to test synchronous
write workloads, for example, mail servers workload.
test-url: https://sourceforge.net/projects/fsmark/
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/filesize/fs2/fs/iterations/kconfig/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
gcc-7/performance/1BRD_48G/4M/nfsv4/f2fs/1x/x86_64-rhel-7.2/1t/debian-x86_64-2016-08-31.cgz/fsyncBeforeClose/ivb44/40G/fsmark
commit:
c2993a1d7d ("nfsd4: extend reclaim period for reclaiming clients")
517dc52baa ("nfsd4: shortern default lease period")
c2993a1d7d6687fd 517dc52baa2a508c82f68bbc72
--
%stddev %change %stddev
\ |\
53.60 +32.4% 70.95fsmark.files_per_sec
191.89 -24.4% 145.16fsmark.time.elapsed_time
191.89 -24.4% 145.16fsmark.time.elapsed_time.max
So what happened is the test took about 45 seconds less.
I suspect you're starting the nfs server and then immediately running
this test.
Yes.
The problem is that if there's a grace period on startup, any open will
just hang until the grace period ends.
This patch changed the default grace period from 90 seconds to 45, so
that would explain the change.
In my testing I usually
start the nfs server
on the client:
mount the server
touch a file
When the touch returns, I know any grace period has completed, and then
I can run any tests normally.
I've modified our test to touch a file before running the actual workload, then
requeue tests for both commit 517dc52baa and its parent c2993a1d7d, but the
result seems persistent which shows a ~30% improvement of fsmark.files_per_sec.
Any suggestions?
You're sure you only start timing after the "touch" returns?
The result is normal after retesting, thank you for helping us improve
the test.
Best Regards,
Rong, Chen
--b.
Re: [lkp-robot] [mm] 15d36fecd0: WARNING:at_kernel/memremap.c:#devm_memremap_pages
On 08/24/2018 12:55 AM, Dave Jiang wrote:
I am not able to reproduce when I booted my test system with "mem=8G
memmap=4G!8G". I ended up with a single pmem:
The issue seems to be related to specific machines,
If you need any other debug log, please tell me.
Best Regards,
Rong Chen
[ 57.750556] nd_pmem namespace0.0: unable to guarantee persistence of
writes
[ 57.881573] pmem0: detected capacity change from 0 to 4294967296
However in the reported kmsg, it appears that memmap is splitting into 2
namespaces rather than providing a single one, and the first region
ended up ending in the same section as start of the second region and
thus triggered the warning and having the second namespace rejected.
kern :warn : [ 76.646531] nd_pmem namespace0.0: unable to guarantee
persistence of writes
kern :info : [ 76.661660] pmem0: detected capacity change from 0 to
534773760
kern :warn : [ 76.670129] nd_pmem namespace1.0: unable to guarantee
persistence of writes
kern :warn : [ 76.670290] [ cut here ]
kern :warn : [ 76.670372] nd_pmem namespace1.0: Conflicting mapping
in same section
On 08/22/2018 08:05 PM, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 15d36fecd0bdc7510b70a0e5ec6671140b3fce0c ("mm: disallow mappings that
conflict for devm_memremap_pages()")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: ndctl
with following parameters:
on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G
memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|| 03758dbbe2 | 15d36fecd0 |
++++
| boot_successes | 4 | 4 |
++++
kern :warn : [ 76.670496] WARNING: CPU: 2 PID: 213 at kernel/memremap.c:188
devm_memremap_pages+0x9f/0x470
kern :warn : [ 76.670665] Modules linked in: nd_pmem(O+) dax_pmem(O)
device_dax(O) nd_btt(O) x86_pkg_temp_thermal intel_powerclamp coretemp
snd_hda_codec_idt kvm_intel snd_hda_codec_generic kvm irqbypass
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd
nd_e820(O) pcspkr libnvdimm(O) ahci libahci nfit_test_iomap(O) libata
snd_hda_intel i915 snd_hda_codec snd_hda_core snd_hwdep snd_pcm drm_kms_helper
snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops snd soundcore drm video
pcc_cpufreq ip_tables
kern :warn : [ 76.671408] CPU: 2 PID: 213 Comm: systemd-udevd Tainted: G
O 4.18.0-rc6-00155-g15d36fe #1
kern :warn : [ 76.671564] Hardware name: Hewlett-Packard p6-1451cx/2ADA,
BIOS 8.15 02/05/2013
kern :warn : [ 76.671690] RIP: 0010:devm_memremap_pages+0x9f/0x470
kern :warn : [ 76.671774] Code: c6 74 78 49 8b 5f 50 48 85 db 75 04 49 8b 5f 10
4c 89 ff e8 13 77 42 00 48 89 da 48 89 c6 48 c7 c7 a8 62 0e 82 e8 51 8c eb ff
<0f> 0b 49 8b be 80 00 00 00 65 ff 05 f1 59 e4 7e 48 8b 47 08 a8 03
kern :warn : [ 76.672107] RSP: 0018:c9000125fad8 EFLAGS: 00010282
kern :warn : [ 76.672197] RAX: RBX: 8801a969e310 RCX:
0006
kern :warn : [ 76.672316] RDX: 0007 RSI: 0086 RDI:
8801ffd16950
kern :warn : [ 76.672434] RBP: 8801a98030a0 R08: 036e R09:
000a
kern :warn : [ 76.672555] R10: R11: 82d6434d R12:
0002
kern :warn : [ 76.672673] R13: R14: 8801a98024a0 R15:
8801aae09808
kern :warn : [ 76.672793] FS: 7fae9129e8c0()
GS:8801ffd0() knlGS:
kern :warn : [ 76.672929] CS: 0010 DS: ES: CR0: 80050033
kern :warn : [ 76.673026] CR2: 7fae9127ec28 CR3: 0001aafe8003 CR4:
001606e0
kern :warn : [ 76.673145] Call Trace:
kern :warn : [ 76.673199] ? devres_add+0x2f/0x40
kern :warn : [ 76.673266] pmem_attach_disk+0x542/0x6a0 [nd_pmem]
kern :warn : [ 76.673354] ? kobject_release+0x69/0x1a0
kern :warn : [ 76.673431] ? nd_dax_probe+0xfc/0x120 [libnvdimm]
kern :warn : [ 76.673520] nvdimm_bus_probe+0x69/0x150 [libnvdimm]
kern :warn : [ 76.673608] driver_probe_device+0x2fa/0x470
kern :warn : [ 76.673685] __driver_attach+0xdc/0x100
kern :warn : [ 76.673753] ? driver_probe_device+0x470/0x470
kern :warn : [ 76.673831] bus_for_each_dev+0x76/0xc0
kern :warn : [ 76.673900] ? klist_add_tail+0x3b/0x70
kern :warn : [ 76.673968] bus_add_driver+0x161/0x260
kern :warn : [ 76.674035] ? 0xa0504000
kern :warn : [ 76.674096] driver_register+0x5b/0xe0
kern :warn : [ 76.674162] ? 0xa0504000
kern :warn : [ 76.674223] do_one_initcall+0x46/0x1e4
kern :warn : [ 76.674293] ? preempt_schedule_common+0x15/0x30
kern :warn : [ 76.674373] ? _cond_res
Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d
/0x2c4 [9.087338] ? lock_is_held_type+0x7e/0x8a [9.087338] ? maybe_link+0x110/0x1b0 [9.087338] ? __slab_alloc+0x4b/0x7e [9.087338] __slab_alloc+0x4b/0x7e [9.087338] ? maybe_link+0x110/0x1b0 [9.087338] kmem_cache_alloc+0x59/0xf6 [9.087338] maybe_link+0x110/0x1b0 [9.087338] ? write_buffer+0x3e/0x3e [9.087338] do_name+0xae/0x32b [9.087338] write_buffer+0x2d/0x3e [9.087338] flush_buffer+0x2e/0x96 [9.087338] ? md_run_setup+0x85/0x85 [9.087338] __gunzip+0x399/0x470 [9.087338] ? bunzip2+0x560/0x560 [9.087338] ? __gunzip+0x470/0x470 [9.087338] gunzip+0xe/0x11 [9.087338] ? md_run_setup+0x85/0x85 [9.087338] unpack_to_rootfs+0x1fe/0x393 [9.087338] ? md_run_setup+0x85/0x85 [9.087338] ? do_symlink+0xaf/0xaf [9.087338] ? populate_rootfs+0x10/0x1b2 [9.087338] ? populate_rootfs+0x4b/0x1b2 [9.087338] ? parse_header+0x1c9/0x1c9 [9.087338] populate_rootfs+0x96/0x1b2 [9.087338] ? parse_header+0x1c9/0x1c9 [9.087338] do_one_initcall+0xc4/0x1ce [9.087338] ? initcall_blacklisted+0x12f/0x12f [9.087338] ? lock_downgrade+0x298/0x298 [9.087338] kernel_init_freeable+0x282/0x317 [9.087338] ? rest_init+0xc6/0xc6 [9.087338] kernel_init+0x7/0xfe [9.087338] ? rest_init+0xc6/0xc6 [9.087338] ret_from_fork+0x24/0x30 [9.087338] Modules linked in: [9.087338] CR2: 09b0 [9.087338] ---[ end trace 17f361a4b4e30da1 ]--- To reproduce: 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 # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.18.0-rc5 Kernel Configuration # # # Compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010 # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_FILTER_PGPROT=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_KASAN_SHADOW_OFFSET=0xdc00 CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DYNAMIC_PHYSICAL_MASK=y CONFIG_PGTABLE_LEVELS=4 CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=50401 CONFIG_CLANG_VERSION=0 CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y 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_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=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 CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=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 # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_IRQ_TIME_ACC
Re: [LKP] [bpf] fd978bf7fd: will-it-scale.per_process_ops -4.0% regression
On 11/02/2018 04:36 PM, Daniel Borkmann wrote:
Hi Rong,
On 11/02/2018 03:14 AM, kernel test robot wrote:
Greeting,
FYI, we noticed a -4.0% regression of will-it-scale.per_process_ops due to
commit:
commit: fd978bf7fd312581a7ca454a991f0ffb34c4204b ("bpf: Add reference tracking to
verifier")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: will-it-scale
on test machine: 80 threads Skylake with 64G memory
with following parameters:
nr_task: 100%
mode: process
test: mmap1
cpufreq_governor: performance
Hmm, so the test cases you are running are these ones:
https://github.com/antonblanchard/will-it-scale/blob/master/tests/mmap1.c
https://github.com/antonblanchard/will-it-scale/blob/master/tests/mmap2.c
The commit from Joe referenced above only adds a feature to the (eBPF)
verifier. Looking
through will-it-scale test suite, looks like there's neither cBPF nor eBPF in
use and if
it would have been the former (e.g. via seccomp BPF), then also this has no
effect on it
since this doesn't load through bpf(2); meaning if so then something must use
eBPF here,
but then it's also unclear right now how this would even remotely affect mmap()
test
performance by -4%. Hm, are you certain it's not a false bisection? If so, what
else is
loading eBPF on your machine in parallel when you run the tests?
Please accept my apologies for taking your time, It's a false bisection.
Something strange happened, we're trying to figure out the root cause.
Best Regards,
Rong Chen
Thanks,
Daniel
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
In addition to that, the commit also has significant impact on the following
tests:
+--+---+
| testcase: change | will-it-scale: will-it-scale.per_process_ops -3.8%
regression |
| test machine | 80 threads Skylake with 64G memory
|
| test parameters | cpufreq_governor=performance
|
| | mode=process
|
| | nr_task=100%
|
| | test=mmap2
|
+--+---+
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/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
gcc-7/performance/x86_64-rhel-7.2/process/100%/debian-x86_64-2018-04-03.cgz/lkp-skl-2sp2/mmap1/will-it-scale
commit:
84dbf35073 ("bpf: Macrofy stack state copy")
fd978bf7fd ("bpf: Add reference tracking to verifier")
84dbf3507349696b fd978bf7fd312581a7ca454a99
--
%stddev %change %stddev
\ |\
16811-4.0% 16140will-it-scale.per_process_ops
1344946-4.0%1291230will-it-scale.workload
107.75 ± 38%+252.4% 379.75 ± 93% cpuidle.POLL.usage
121.70 ± 18% +18.9% 144.70 ± 4%
sched_debug.cfs_rq:/.exec_clock.stddev
4933+2.0% 5031proc-vmstat.nr_inactive_anon
4933+2.0% 5031proc-vmstat.nr_zone_inactive_anon
9874+9.0% 10765 ± 7%
slabinfo.proc_inode_cache.active_objs
9874+9.0% 10765 ± 7%
slabinfo.proc_inode_cache.num_objs
12248 ± 50% +52.2% 18640 ± 2% numa-meminfo.node0.Inactive
33943 ± 8% +16.2% 39453 ± 6% numa-meminfo.node0.SReclaimable
91549 ± 9% -9.9% 82530 ± 7% numa-meminfo.node1.Slab
18091 ± 15% +29.2% 23382 ± 17% numa-vmstat.node0
3027 ± 52% +52.6% 4620 ± 3%
numa-vmstat.node0.nr_inactive_anon
8485 ± 8% +16.2% 9862 ± 6%
numa-vmstat.node0.nr_slab_reclaimable
3027 ± 52% +52.6% 4620 ± 3%
numa-vmstat.node0.nr_zone_inactive_anon
1.4e+12-2.5% 1.364e+12perf-stat.branch-instructions
41.42+0.7 42.15perf-stat.cache-miss-rate%
2.166e+10-2.1% 2.12e+10per
Re: [LKP] a13c600e15 ("x86/mm/pti: Move user W+X check into .."): WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:283 note_page
On 08/10/2018 04:35 PM, Joerg Roedel wrote: On Fri, Aug 10, 2018 at 06:33:42AM +0800, kernel test robot wrote: commit a13c600e15de44ccf03df28d3311ef3cb754ed9b Author: Joerg Roedel AuthorDate: Wed Aug 8 13:16:40 2018 +0200 Commit: Thomas Gleixner CommitDate: Thu Aug 9 20:42:07 2018 +0200 x86/mm/pti: Move user W+X check into pti_finalize() Okay, I found the problem and the diff below fixes it. The patch works well. Tested-by: kernel test robot Ingo, Thomas, can you fold that diff into above commit or do you prefer a separate patch? Thanks and sorry for the hassle, Joerg diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c index 026a89aa16d7..d1435c78ae4f 100644 --- a/arch/x86/mm/pti.c +++ b/arch/x86/mm/pti.c @@ -629,5 +629,6 @@ void pti_finalize(void) pti_clone_entry_text(); pti_clone_kernel_text(); - debug_checkwx_user(); + if (__supported_pte_mask & _PAGE_NX) + debug_checkwx_user(); } ___ LKP mailing list l...@lists.01.org https://lists.01.org/mailman/listinfo/lkp
Re: [kbuild-all] [PATCH v3] ARM: smp: add support for per-task stack canaries
On 12/09/2018 06:37 PM, Russell King - ARM Linux wrote:
On Sun, Dec 09, 2018 at 06:28:11PM +0800, kbuild test robot wrote:
Hi Ard,
I love your patch! Perhaps something to improve:
Hi,
This looks to me like a false warning - how can a patch touching arch
code affect the result of lib/test_ubsan.c? Please can you double-
check this result?
Hi,
I'm sorry for the trouble, It's a false warning, we will look into it.
Best Regards,
Rong Chen
Thanks.
[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.20-rc5]
[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/Ard-Biesheuvel/ARM-smp-add-support-for-per-task-stack-canaries/20181209-033321
base: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.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.2.0 make.cross ARCH=arm
All warnings (new ones prefixed by >>):
lib/test_ubsan.c: In function 'test_ubsan_vla_bound_not_positive':
lib/test_ubsan.c:48:2: warning: ISO C90 forbids variable length array 'buf'
[-Wvla]
char buf[size];
^~~~
lib/test_ubsan.c: In function 'test_ubsan_out_of_bounds':
lib/test_ubsan.c:64:2: warning: ISO C90 forbids variable length array 'arr'
[-Wvla]
volatile int arr[i];
^~~~
vim +/buf +48 lib/test_ubsan.c
854686f4 Jinbum Park 2018-04-10 44
854686f4 Jinbum Park 2018-04-10 45 static void
test_ubsan_vla_bound_not_positive(void)
854686f4 Jinbum Park 2018-04-10 46 {
854686f4 Jinbum Park 2018-04-10 47 volatile int size = -1;
854686f4 Jinbum Park 2018-04-10 @48 char buf[size];
854686f4 Jinbum Park 2018-04-10 49
854686f4 Jinbum Park 2018-04-10 50 (void)buf;
854686f4 Jinbum Park 2018-04-10 51 }
854686f4 Jinbum Park 2018-04-10 52
854686f4 Jinbum Park 2018-04-10 53 static void
test_ubsan_shift_out_of_bounds(void)
854686f4 Jinbum Park 2018-04-10 54 {
854686f4 Jinbum Park 2018-04-10 55 volatile int val = -1;
854686f4 Jinbum Park 2018-04-10 56 int val2 = 10;
854686f4 Jinbum Park 2018-04-10 57
854686f4 Jinbum Park 2018-04-10 58 val2 <<= val;
854686f4 Jinbum Park 2018-04-10 59 }
854686f4 Jinbum Park 2018-04-10 60
854686f4 Jinbum Park 2018-04-10 61 static void test_ubsan_out_of_bounds(void)
854686f4 Jinbum Park 2018-04-10 62 {
854686f4 Jinbum Park 2018-04-10 63 volatile int i = 4, j = 5;
854686f4 Jinbum Park 2018-04-10 @64 volatile int arr[i];
854686f4 Jinbum Park 2018-04-10 65
854686f4 Jinbum Park 2018-04-10 66 arr[j] = i;
854686f4 Jinbum Park 2018-04-10 67 }
854686f4 Jinbum Park 2018-04-10 68
:: The code at line 48 was first introduced by commit
:: 854686f4edf483db1e0d26d972bdb8fb65c8bfaa lib: add testing module for
UBSAN
:: TO: Jinbum Park
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [LKP] [xarray] 4e99d4e957: BUG:soft_lockup-CPU##stuck_for#s
On 12/11/2018 10:29 PM, Matthew Wilcox wrote:
On Tue, Dec 11, 2018 at 05:54:41PM +0800, kernel test robot wrote:
# To reproduce,
# 1) save job-script and this script (both are attached in 0day report email)
# 2) run this script with your compiled kernel and optional env
$INSTALL_MOD_PATH
kernel=$1
initrds=(
/osimage/yocto/yocto-tiny-i386-2016-04-22.cgz
/lkp/lkp/lkp-i386.cgz
/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig.i386_2016-09-03.cgz
)
HTTP_PREFIX=https://download.01.org/0day-ci/lkp-qemu
wget --timestamping "${initrds[@]/#/$HTTP_PREFIX}"
{
cat "${initrds[@]//*\//}"
[[ $INSTALL_MOD_PATH ]] && (
cd "$INSTALL_MOD_PATH"
To reproduce:
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
When I do this, the only output I get is:
make: Entering directory '/home/willy/kernel/lkp-tests/bin/event'
gcc-c -o wakeup.o wakeup.c
gcc -static -o wakeup wakeup.o
rm -f wakeup.o
strip wakeup
make: Leaving directory '/home/willy/kernel/lkp-tests/bin/event'
Running under sh -x, I get as far as:
+ exec /home/willy/kernel/lkp-tests/lkp-exec/qemu -k
../idrext/.build-yocto/arch/x86/boot/bzImage job-script
Editing that script to set -x, I get to:
+ /home/willy/kernel/lkp-tests/sbin/pack -f -a x86_64 lkp-src
make: Entering directory '/home/willy/kernel/lkp-tests/bin/event'
gcc-c -o wakeup.o wakeup.c
gcc -static -o wakeup wakeup.o
rm -f wakeup.o
strip wakeup
make: Leaving directory '/home/willy/kernel/lkp-tests/bin/event'
+ exit
which would seem to indicate your 'pack' command failed with a non-zero
exit code? Adding set -x to _that_ script gives me:
+ find . -type d -exec chmod g+rwx '{}' ';'
+ chmod -R g+rw etc lib root usr
+ '[' -d /osimage/addon-x86_64 ']'
+ gzip -n -9 /home/willy/.lkp/cache/lkp-x86_64.cpio
+ mv -f /home/willy/.lkp/cache/lkp-x86_64.cpio.gz
/home/willy/.lkp/cache/lkp-x86_64.cgz
+ [[ -n '' ]]
+ [[ -n '' ]]
+ exit
I'm using your top-of-tree lkp-tests, commit
e28c726dfe85e3e595ba4776a4eb92f2559d3ac0
By the way, I took this kernel config and ran it under one of your other
test cases (the one which runs Trinity) and didn't see a boot problem,
so either it's something specific to this setup, or the problem got
fixed between this commit and current top-of-tree.
Please accept my apologies for taking your time, the reproduce tool was broken
for a long time, and it's fixed now.
if it can't be reproduced, here is the original
bzImage(https://download.01.org/0day-ci/lkp-qemu/fbc/4e99d4e9579d3b950bf4b38d0d64eb1b9be78761/).
Best Regards,
Rong Chen
Re: [LKP] 5404a7f1c2 [ 90.902541] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
On 12/18/2018 08:17 PM, Matthew Wilcox wrote: On Tue, Dec 18, 2018 at 08:20:28AM +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 5404a7f1c21cfda061712bedf2d06cc0f6c755e9 I feel like you're wasting my time. This is the fourth time in a row you've reported something I can't reproduce. At least this time the instructions work, but I've tried it a dozen times and it doesn't produce the error you're showing. $ git branch * (HEAD detached at 5404a7f1c21c) ... [0.00] Linux version 4.20.0-rc1-00012-g5404a7f1c21c (willy@bobo) (gcc version 8.2.0 (Debian 8.2.0-9)) #4 Mon Dec 17 23:28:21 EST 2018 ... [9.848471] test_uuid: all 18 tests passed [ 11.019267] XArray: 19496249 of 19496249 tests passed Your logs show it failing every time. I can't help but wonder if it's something else in your setup that's causing it to fail -- maybe the machines doing the testing are overloaded? Please accept my apologies for taking your time, it might be a false positive, we have uploaded the original bzImage(https://download.01.org/0day-ci/lkp-qemu/fbc/5404a7f1c21cfda061712bedf2d06cc0f6c755e9/) for your reference. Best Regards, Rong Chen
Re: [LKP] [xarray] 4e99d4e957: BUG:soft_lockup-CPU##stuck_for#s
On 12/19/2018 05:54 PM, Rong Chen wrote:
On 12/11/2018 10:29 PM, Matthew Wilcox wrote:
On Tue, Dec 11, 2018 at 05:54:41PM +0800, kernel test robot wrote:
# To reproduce,
# 1) save job-script and this script (both are attached in 0day
report email)
# 2) run this script with your compiled kernel and optional env
$INSTALL_MOD_PATH
kernel=$1
initrds=(
/osimage/yocto/yocto-tiny-i386-2016-04-22.cgz
/lkp/lkp/lkp-i386.cgz
/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig.i386_2016-09-03.cgz
)
HTTP_PREFIX=https://download.01.org/0day-ci/lkp-qemu
wget --timestamping "${initrds[@]/#/$HTTP_PREFIX}"
{
cat "${initrds[@]//*\//}"
[[ $INSTALL_MOD_PATH ]] && (
cd "$INSTALL_MOD_PATH"
To reproduce:
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
When I do this, the only output I get is:
make: Entering directory '/home/willy/kernel/lkp-tests/bin/event'
gcc -c -o wakeup.o wakeup.c
gcc -static -o wakeup wakeup.o
rm -f wakeup.o
strip wakeup
make: Leaving directory '/home/willy/kernel/lkp-tests/bin/event'
Running under sh -x, I get as far as:
+ exec /home/willy/kernel/lkp-tests/lkp-exec/qemu -k
../idrext/.build-yocto/arch/x86/boot/bzImage job-script
Editing that script to set -x, I get to:
+ /home/willy/kernel/lkp-tests/sbin/pack -f -a x86_64 lkp-src
make: Entering directory '/home/willy/kernel/lkp-tests/bin/event'
gcc -c -o wakeup.o wakeup.c
gcc -static -o wakeup wakeup.o
rm -f wakeup.o
strip wakeup
make: Leaving directory '/home/willy/kernel/lkp-tests/bin/event'
+ exit
which would seem to indicate your 'pack' command failed with a non-zero
exit code? Adding set -x to _that_ script gives me:
+ find . -type d -exec chmod g+rwx '{}' ';'
+ chmod -R g+rw etc lib root usr
+ '[' -d /osimage/addon-x86_64 ']'
+ gzip -n -9 /home/willy/.lkp/cache/lkp-x86_64.cpio
+ mv -f /home/willy/.lkp/cache/lkp-x86_64.cpio.gz
/home/willy/.lkp/cache/lkp-x86_64.cgz
+ [[ -n '' ]]
+ [[ -n '' ]]
+ exit
I'm using your top-of-tree lkp-tests, commit
e28c726dfe85e3e595ba4776a4eb92f2559d3ac0
By the way, I took this kernel config and ran it under one of your other
test cases (the one which runs Trinity) and didn't see a boot problem,
so either it's something specific to this setup, or the problem got
fixed between this commit and current top-of-tree.
Please accept my apologies for taking your time, the reproduce tool
was broken for a long time, and it's fixed now.
if it can't be reproduced, here is the original
bzImage(https://download.01.org/0day-ci/lkp-qemu/fbc/4e99d4e9579d3b950bf4b38d0d64eb1b9be78761/).
Hi,
It should be a false positive too, The test VM are usually overloaded
much to improve test density, we will pay attention to the issue.
Best Regards,
Rong Chen
Re: [LKP] bea5b158ff BUG: kernel reboot-without-warning in boot-around-mounting-root stage
On 01/02/2019 05:58 PM, Greg Kroah-Hartman wrote: On Wed, Jan 02, 2019 at 09:15:12AM +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 bea5b158ff0da9c7246ff391f754f5f38e34577a Author: Rob Herring AuthorDate: Thu Aug 11 10:20:58 2016 -0500 Commit: Greg Kroah-Hartman CommitDate: Wed Aug 31 15:13:55 2016 +0200 driver core: add test of driver remove calls during probe In recent discussions on ksummit-discuss[1], it was suggested to do a sequence of probe, remove, probe for testing driver remove paths. This adds a kconfig option for said test. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html Suggested-by: Arnd Bergmann Cc: Greg Kroah-Hartman Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman cebf8fd169 driver core: fix race between creating/querying glue dir and its cleanup bea5b158ff driver core: add test of driver remove calls during probe e1ef035d27 Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 6a1d293238 Add linux-next specific files for 20181224 +--++++---+ | | cebf8fd169 | bea5b158ff | e1ef035d27 | next-20181224 | +--++++---+ | boot_successes | 31 | 0 | 0 | 0 | | boot_failures| 0 | 11 | 11 | 7 | | BUG:kernel_reboot-without-warning_in_boot-around-mounting-root_stage | 0 | 11 | 11 | 7 | +--++++---+ [ 14.073515] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 14.095297] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 14.177113] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 14.256672] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A [ 14.278578] console [ttyS0] disabled BUG: kernel reboot-without-warning in boot-around-mounting-root stage # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start v4.9 v4.8 -- You are testing the 4.9 kernel release here? A commit from 2016 is a "problem"? Are you sure this is still an issue? I'm very sorry for the old commit report, we're testing latest code, and the robot shouldn't track old commits. we'll fix it. Best Regards, Rong Chen thanks, greg k-h
Re: [kbuild-all] sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of function 'pci_iomap'; did you mean 'pcim_iomap'?
On 11/01/2018 09:09 AM, Randy Dunlap wrote:
On 10/31/18 5:48 PM, kbuild test robot wrote:
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
date: 9 weeks ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 6bae5ea9498926440ffc883f3dbceb0adc65e492
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
Hi lkp robot,
I have a (process) question:
Does the above mean that this build failed on 4.19-rc1 9 weeks ago and that
it still fails on 4.19-rc1? Has this .config been tested on v4.19, e.g.?
the date was from "git log -n1 --format=format:"%cr"
6bae5ea9498926440ffc883f3dbceb0adc65e492"
I have tested this .config on v4.19 and don't see the build error that is
listed here (below). This error happens because CONFIG_PCI is not enabled,
so pci_iomap() is not available. The drivers in sound/pci/hda/ should not
be enabled since CONFIG_PCI is not enabled and indeed, in v4.19, after running
"make oldconfig", those drivers are not enabled, so the build error does not
happen.
None of these Kconfig symbols (from the attached .config file) is enabled
after running "make oldconfig":
we used "make olddefconfig" to correct possible problems.
Best Regards,
Rong Chen
CONFIG_SND_HDA=y
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=1
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
CONFIG_SND_HDA_CODEC_CA0132_DSP=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
I conclude that someone has "fixed" the faulty Kconfig file(s) that caused this
problem and that it is no longer a problem.
Or I could be all mussed up. :)
Thanks.
All errors (new ones prefixed by >>):
sound/pci/hda/patch_ca0132.c: In function 'patch_ca0132':
sound/pci/hda/patch_ca0132.c:7650:20: error: implicit declaration of function
'pci_iomap'; did you mean 'pcim_iomap'? [-Werror=implicit-function-declaration]
spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
^
pcim_iomap
sound/pci/hda/patch_ca0132.c:7650:18: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
spec->mem_base = pci_iomap(codec->bus->pci, 2, 0xC20);
^
cc1: some warnings being treated as errors
vim +7650 sound/pci/hda/patch_ca0132.c
d5c016b56 Gabriele Martino 2015-05-18 7581
95c6e9cb7 Ian Minett 2011-06-15 7582 static int patch_ca0132(struct
hda_codec *codec)
95c6e9cb7 Ian Minett 2011-06-15 7583 {
95c6e9cb7 Ian Minett 2011-06-15 7584 struct ca0132_spec *spec;
a73d511c4 Ian Minett 2012-12-20 7585 int err;
d5c016b56 Gabriele Martino 2015-05-18 7586 const struct snd_pci_quirk
*quirk;
95c6e9cb7 Ian Minett 2011-06-15 7587
4e76a8833 Takashi Iwai 2014-02-25 7588 codec_dbg(codec,
"patch_ca0132\n");
95c6e9cb7 Ian Minett 2011-06-15 7589
95c6e9cb7 Ian Minett 2011-06-15 7590 spec = kzalloc(sizeof(*spec),
GFP_KERNEL);
95c6e9cb7 Ian Minett 2011-06-15 7591 if (!spec)
95c6e9cb7 Ian Minett 2011-06-15 7592 return -ENOMEM;
95c6e9cb7 Ian Minett 2011-06-15 7593 codec->spec = spec;
993884f6a Chih-Chung Chang 2013-03-25 7594 spec->codec = codec;
95c6e9cb7 Ian Minett 2011-06-15 7595
225068ab2 Takashi Iwai 2015-05-29 7596 codec->patch_ops =
ca0132_patch_ops;
225068ab2 Takashi Iwai 2015-05-29 7597 codec->pcm_format_first = 1;
225068ab2 Takashi Iwai 2015-05-29 7598 codec->no_sticky_stream = 1;
225068ab2 Takashi Iwai 2015-05-29 7599
d5c016b56 Gabriele Martino 2015-05-18 7600 /* Detect codec quirk */
d5c016b56 Gabriele Martino 2015-05-18 7601 quirk =
snd_pci_quirk_lookup(codec->bus->pci, ca0132_quirks);
d5c016b56 Gabriele Martino 2015-05-18 7602 if (quirk)
d5c016b56 Gabriele Martino 2015-05-18 7603 spec->quirk =
quirk->value;
d5c016b56 Gabriele Martino 2015-05-18 7604 else
d5c016b56 Gabriele Martino 2015-05
Re: [kbuild-all] [PATCH RT] rt: convert mm/kasan/quarantine_lock to raw_spinlock
On 10/06/2018 12:37 AM, Sebastian Andrzej Siewior wrote: On 2018-09-19 04:34:50 [+0800], kbuild test robot wrote: Hi Clark, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linux-rt-devel/for-kbuild-bot/current-stable] url: https://github.com/0day-ci/linux/commits/Clark-Williams/rt-convert-mm-kasan-quarantine_lock-to-raw_spinlock/20180919-021343 base: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git for-kbuild-bot/current-stable config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): how is this related? Could someone please explain this. It Iooks like a kbuild issue, we will looking into it. Best Regards, Rong Chen
Re: [LKP] [mm/memory.c] 6558038e45: general_protection_fault:#[##]
On 10/18/2018 06:26 AM, Andrew Morton wrote:
On Wed, 17 Oct 2018 09:36:00 +0800 kernel test robot
wrote:
FYI, we noticed the following commit (built with gcc-6):
commit: 6558038e4540a22ee4f99a5def74791189102bc0 ("mm/memory.c: recheck page table
entry with page table lock held")
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 qemu64,+ssse3 -smp 4 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
mm-recheck-page-table-entry-with-page-table-lock-held-fix.patch ("mm:
fix the crash observed with syzkaller run") will most likely fix this.
Was it applied during this testing?
It wasn't applied during this testing.
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: [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(&kfd_processes_srcu);
+ WARN_ON(ret);
si_meminfo(&si);
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(&kfd_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 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(&kfd_processes_srcu);
> > >+ WARN_ON(ret);
> > > si_meminfo(&si);
> > > 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(&kfd_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: [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
[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: 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: [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' ___
[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: [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: 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
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: [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: [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: 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: 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/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(&m->pg_init_in_progress);
541 activate_or_offline_path(pgpath);
542 return DM_MAPIO_DELAY_REQUEUE;
543 }
544
545
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 i
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_defc
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 (&ids->rwsem){}-{3:3}, at:
semctl_down+0x6d/0x686
[ 235.557684] #1: 888128ccc868 (&mm->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: 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/lin
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 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: 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: [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: [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_
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: 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 '__compil
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
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: [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: 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(&cdev->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: 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/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/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: [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] 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
[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 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: [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
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))
2385
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: 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: [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-patch&data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cy3huYNzWiJ57OKmzmaleCT14gcFr8RyYDnqTfZWNG4%3D&reserved=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-205353&data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=x5XoDUUskeGteTFaPjgS24Hrbb712XqMqaIkqwXWu14%3D&reserved=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.cross&data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jAavg0T3itnjkbHXADvePHHgtYeqiVTBt%2BoatHT0VHU%3D&reserved=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%2F315bfcf1e0604de6ecfc1856cf5820876390f16c&data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SQ75IXxfld6HMRIFkZ%2F8Z4YqxnFP%2F%2BZ%2BsYZIycNeO%2FA%3D&reserved=0 git remote add linux-review https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux&data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZVS4723WbEO03hbsLXJ%2B%2FmB5EZElulY7lAsMEMatiko%3D&reserved=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, &cdns->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, &cdns->otg_irq_regs->ien); | ^~ drivers/usb/cdns3/drd.c: In function 'cdns_drd_init': drivers/usb/cdns3/drd.c:409:22: error:
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: [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&id=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: [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,
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: [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, &val)) {
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
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
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);
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
Re: [kbuild-all] proc.c:undefined reference to `strcmp'
On 1/22/19 7:44 PM, Geert Uytterhoeven wrote:
On Tue, Jan 22, 2019 at 11:11 AM kbuild test robot wrote:
It's probably a bug fix that unveils the link errors.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 47bfa6d9dc8c060bf56554a465c9031e286d2f80
commit: 35004f2e55807a1a1491db24ab512dd2f770a130 lib/genalloc.c: include
vmalloc.h
date: 2 weeks ago
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 35004f2e55807a1a1491db24ab512dd2f770a130
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=m68k
All errors (new ones prefixed by >>):
m68k-linux-gnu-ld: block/partitions/ldm.o: in function `ldm_partition':
ldm.c:(.text+0x1900): undefined reference to `strcmp'
m68k-linux-gnu-ld: ldm.c:(.text+0x1964): undefined reference to `strcmp'
m68k-linux-gnu-ld: drivers/rtc/proc.o: in function `is_rtc_hctosys':
proc.c:(.text+0x18c): undefined reference to `strcmp'
m68k-linux-gnu-ld: drivers/watchdog/watchdog_pretimeout.o: in function
`watchdog_register_governor':
watchdog_pretimeout.c:(.text+0x142): undefined reference to `strcmp'
m68k-linux-gnu-ld: drivers/devfreq/devfreq.o: in function
`try_then_request_governor':
devfreq.c:(.text+0x9c6): undefined reference to `strcmp'
I guess this bisection is a false positive. Have you just upgraded to gcc 8?
yes, we upgraded to gcc 8 recently.
Gcc 8 replaces the strncmp() in is_rtc_hctosys() to strcmp().
Will be fixed in v5.1 by
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/commit/?h=for-v5.1&id=28713169d879b67be2ef2f84dcf54905de238294
Thanks for your explanation. we'll blacklist it.
Best Regards,
Rong Chen
Gr{oetje,eeting}s,
Geert
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
[iommu/dma] b1d2dc009d: can't load the disk
OM sr0 [ 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: [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: [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: [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: [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] [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] [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: 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 ||
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: [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: [kbuild-all] [PATCH 2/2] memcg: do not report racy no-eligible OOM tasks
On 01/08/2019 05:39 PM, Michal Hocko wrote: On Tue 08-01-19 16:35:42, kbuild test robot wrote: [...] All warnings (new ones prefixed by >>): include/linux/rcupdate.h:659:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit include/linux/sched/mm.h:141:37: warning: dereference of noderef expression mm/oom_kill.c:225:28: warning: context imbalance in 'oom_badness' - unexpected unlock mm/oom_kill.c:406:9: warning: context imbalance in 'dump_tasks' - different lock contexts for basic block mm/oom_kill.c:918:17: warning: context imbalance in '__oom_kill_process' - unexpected unlock What exactly does this warning say? I do not see anything wrong about the code. find_lock_task_mm returns a locked task when t != NULL and mark_oom_victim doesn't do anything about the locking. Am I missing something or the warning is just confused? Thanks for your reply. It looks like a false positive. We'll look into it. Best Regards, Rong Chen [...] 00508538 Michal Hocko 2019-01-07 915 t = find_lock_task_mm(p); 00508538 Michal Hocko 2019-01-07 916 if (!t) 00508538 Michal Hocko 2019-01-07 917 continue; 00508538 Michal Hocko 2019-01-07 @918 mark_oom_victim(t); 00508538 Michal Hocko 2019-01-07 919 task_unlock(t); 647f2bdf David Rientjes2012-03-21 920 }
Re: [LKP] [vfs] fd0002870b: BUG:KASAN:null-ptr-deref_in_n
On 09/12/2018 04:29 AM, David Howells wrote: kernel test robot wrote: [ 18.568403] nfs_fs_mount+0x901/0x1220 I don't suppose you can tell me what file and line number this corresponds to? $ faddr2line vmlinux nfs_fs_mount+0x901 nfs_fs_mount+0x901/0x1218: nfs_parse_devname at fs/nfs/super.c:1911 (inlined by) nfs_validate_text_mount_data at fs/nfs/super.c:2187 (inlined by) nfs_fs_mount at fs/nfs/super.c:2684 Also, can you tell me what the mount parameters were? I'm not sure how to extract them from the information provided. qemu command (you could get from 'bin/lkp qemu -k job-script'): qemu-system-x86_64 -enable-kvm -fsdev local,id=test_dev,path=/home/nfs/.lkp//result/boot/1/vm-kbuild-1G/debian-x86_64-2018-04-03.cgz/x86_64-randconfig-r0-09070102/gcc-6/fd0002870b453c58d0d8c195954f5049bc6675fb/0,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=9p/virtfs_mount -kernel vmlinuz-4.19.0-rc1-00104-gfd00028 -append root=/dev/ram0 user=lkp job=/lkp/jobs/scheduled/vm-kbuild-1G-11/boot-1-debian-x86_64-2018-04-03.cgz-fd0002870b453c58d0d8c195954f5049bc6675fb-20180910-6016-1hqt4et-1.yaml ARCH=x86_64 kconfig=x86_64-randconfig-r0-09070102 branch=linux-devel/devel-hourly-2018090623 commit=fd0002870b453c58d0d8c195954f5049bc6675fb BOOT_IMAGE=/pkg/linux/x86_64-randconfig-r0-09070102/gcc-6/fd0002870b453c58d0d8c195954f5049bc6675fb/vmlinuz-4.19.0-rc1-00104-gfd00028 max_uptime=600 RESULT_ROOT=/result/boot/1/vm-kbuild-1G/debian-x86_64-2018-04-03.cgz/x86_64-randconfig-r0-09070102/gcc-6/fd0002870b453c58d0d8c195954f5049bc6675fb/3 LKP_LOCAL_RUN=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 ip=dhcp result_service=9p/virtfs_mount -initrd /home/nfs/.lkp/cache/final_initrd -smp 2 -m 1024M -no-reboot -watchdog i6300esb -rtc base=localtime -device e1000,netdev=net0 -netdev user,id=net0 -display none -monitor null -serial stdio -device virtio-scsi-pci,id=scsi0 -drive file=/tmp/vdisk-nfs/disk-vm-kbuild-1G-11-0,if=none,id=hd0,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd0,scsi-id=1,lun=0 -drive file=/tmp/vdisk-nfs/disk-vm-kbuild-1G-11-1,if=none,id=hd1,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd1,scsi-id=1,lun=1 -drive file=/tmp/vdisk-nfs/disk-vm-kbuild-1G-11-2,if=none,id=hd2,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd2,scsi-id=1,lun=2 -drive file=/tmp/vdisk-nfs/disk-vm-kbuild-1G-11-3,if=none,id=hd3,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd3,scsi-id=1,lun=3 -drive file=/tmp/vdisk-nfs/disk-vm-kbuild-1G-11-4,if=none,id=hd4,media=disk,aio=native,cache=none -device scsi-hd,bus=scsi0.0,drive=hd4,scsi-id=1,lun=4 Best Regards, Rong Chen Thanks, David ___ LKP mailing list l...@lists.01.org https://lists.01.org/mailman/listinfo/lkp
Re: [LKP] 0a3856392c [ 10.513760] INFO: trying to register non-static key.
On 09/07/2018 10:19 AM, Matthew Wilcox wrote:
On Fri, Sep 07, 2018 at 09:05:39AM +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 0a3856392cff1542170b5bc37211c9a21fd0c3f6
Author: Matthew Wilcox
AuthorDate: Mon Jun 18 17:23:37 2018 -0400
Commit: Matthew Wilcox
CommitDate: Tue Aug 21 23:54:20 2018 -0400
test_ida: Move ida_check_leaf
Convert to new API and move to kernel space. Take the opportunity to
test the situation a little more thoroughly (ie at different offsets).
Signed-off-by: Matthew Wilcox
Thank you test-bot. Can you check if this patch fixes the problem?
Thanks, It works.
Best Regards,
Rong Chen
diff --git a/lib/test_ida.c b/lib/test_ida.c
index 2d1637d8136b..b06880625961 100644
--- a/lib/test_ida.c
+++ b/lib/test_ida.c
@@ -150,10 +150,10 @@ static void ida_check_conv(struct ida *ida)
IDA_BUG_ON(ida, !ida_is_empty(ida));
}
+static DEFINE_IDA(ida);
+
static int ida_checks(void)
{
- DEFINE_IDA(ida);
-
IDA_BUG_ON(&ida, !ida_is_empty(&ida));
ida_check_alloc(&ida);
ida_check_destroy(&ida);
Re: [LKP] [ipc] 61224adcd2: general_protection_fault:#[##]
On 09/13/2018 07:28 PM, David Howells wrote: kernel test robot wrote: To reproduce: 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 Tried that. That seems to work for me. Or, at least, it comes to a prompt at which I can log in. I'm not sure whether anything else is meant to happen. It's a 0day problem, we will fix it as soon as possible. Best Regards, Rong Chen
Re: [LKP] [mm, oom] 6209f6fc62: general_protection_fault:#[##]
On 09/25/2018 02:06 PM, Michal Hocko wrote:
On Tue 25-09-18 13:48:20, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 6209f6fc62835d84c2a92d237588a114e39436ce ("mm, oom: rework mmap_exit vs.
oom_reaper synchronization")
https://github.com/0day-ci/linux
UPDATE-20180911-024633/Tetsuo-Handa/mm-oom-Fix-unnecessary-killing-of-additional-processes/20180910-163452
Do you have a msg-id to the patch that has been tested?
message_id: 20180910125513.311-2-mho...@kernel.org
Best Regards,
Rong Chen
Re: [LKP] [mm, oom] 6209f6fc62: general_protection_fault:#[##]
On 09/25/2018 03:31 PM, Michal Hocko wrote:
On Tue 25-09-18 15:00:15, Rong Chen wrote:
On 09/25/2018 02:06 PM, Michal Hocko wrote:
On Tue 25-09-18 13:48:20, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 6209f6fc62835d84c2a92d237588a114e39436ce ("mm, oom: rework mmap_exit vs.
oom_reaper synchronization")
https://github.com/0day-ci/linux
UPDATE-20180911-024633/Tetsuo-Handa/mm-oom-Fix-unnecessary-killing-of-additional-processes/20180910-163452
Do you have a msg-id to the patch that has been tested?
message_id: 20180910125513.311-2-mho...@kernel.org
Thanks! It woudl be really great if this was a part of the report when
testing patches which are not mainline yet.
This patch resulting in a crash is quite surprising. The patch is RFC
and not tested yet but I will definitely have a look. Could you help me
some more and give faddr2line __oom_reap_task_mm+0x40 please?
$ faddr2line ./vmlinux __oom_reap_task_mm+0x40
__oom_reap_task_mm+0x40/0x175:
can_madv_dontneed_vma at mm/internal.h:48
(inlined by) __oom_reap_task_mm at mm/oom_kill.c:505
Best Regards,
Rong Chen
Re: [LKP] 3f906ba236 [ 71.192813] WARNING: possible circular locking dependency detected
On 09/05/2018 09:02 PM, Thomas Gleixner wrote:
On Wed, 5 Sep 2018, 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 3f906ba23689a3f824424c50f3ae937c2c70f676
Author: Thomas Gleixner
AuthorDate: Mon Jul 10 15:50:09 2017 -0700
Commit: Linus Torvalds
CommitDate: Mon Jul 10 16:32:33 2017 -0700
So it identified a more than one year old commit. Great.
vm86 returned ENOSYS, marking as inactive. 20044 iterations. [F:14867 S:5032
HI:3700] [ 57.651003] synth uevent: /module/pcmcia_core: unknown uevent action
string [ 71.189062] [ 71.191953]
== [ 71.192813] WARNING:
possible circular locking dependency detected [ 71.193664]
4.12.0-10480-g3f906ba #1 Not tainted [ 71.194355]
-- [ 71.195211]
trinity-c0/1666 is trying to acquire lock: [ 71.195958]
(mem_hotplug_lock.rw_sem){.+.+.+}, at: show_slab_objects+0x14b/0x440 [
71.197284] [ 71.197284] but task is already holding lock:
along with completely unparseable information. What am I supposed to do
with this mail?
Hi,
Attached please find the dmesg/reproduce files in previous mail.
please ignore the report if it's a false positive.
Best Regards,
Rong Chen
Thanks,
tglx
___
LKP mailing list
l...@lists.01.org
https://lists.01.org/mailman/listinfo/lkp
Re: [LKP] [x86/pci] 7ffb31888c: PANIC:early_exception
On 09/19/2018 09:53 PM, Pu Wen wrote: On 2018/9/19 11:19, kernel test robot wrote: [0.800215] AGP: No AGP bridge found PANIC: early exception 0xe3 IP 10:8294623f error 0 cr2 0x0 [0.815262] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc2-00018-g7ffb318 #1 [0.826860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [0.839894] RIP: 0010:early_is_amd_nb+0x30/0x4b [0.846986] Code: 15 07 3e c8 ff 0f b7 cf 48 c7 c0 c0 6a 01 82 80 fa 02 74 13 80 fa 09 48 c7 c0 20 69 01 82 ba 00 00 00 00 48 0f 45 c2 c1 ef 10 <8b> 10 85 d2 74 0f 39 ca 75 05 39 78 04 74 09 48 83 c0 20 eb eb 31 [0.876321] RSP: :82403e38 EFLAGS: 00010017 ORIG_RAX: [0.888131] RAX: RBX: RCX: [0.899187] RDX: RSI: c000 RDI: [0.910233] RBP: 0018 R08: 0002 R09: [0.921388] R10: 829ecc40 R11: 82aeed87 R12: [0.932476] R13: R14: R15: [0.943658] FS: () GS:82909000() knlGS: [0.956271] CS: 0010 DS: ES: CR0: 80050033 [0.965216] CR2: CR3: 029a2000 CR4: 06a0 [0.976358] Call Trace: [0.980238] ? early_gart_iommu_check+0xef/0x2c5 [0.987493] ? setup_arch+0x4fa/0xc67 [0.993231] ? printk+0x52/0x6e [0.998157] ? start_kernel+0x6e/0x4dc [1.004044] ? load_ucode_bsp+0x42/0x12e [1.010145] ? secondary_startup_64+0xa4/0xb0 BUG: kernel hang in boot stage Elapsed time: 700 #!/bin/bash To reproduce: 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 I cannot reproduce this panic on Hygon Dhyana platform. I tired lkp-tests both in Ubuntu 16.04 (with gcc-5) and Ubuntu 18.04 (with gcc-7). What kind of host do you use to run the qemu? A Intel one or AMD one? It's a Intel one, model: Nehalem-EX memory: 224G nr_node: 4 nr_cpu: 64 nr_socket: 4 brand: Intel(R) Xeon(R) CPU X7560 @ 2.27GHz 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: [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] 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: [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] 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 *) &datalen_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
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.
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: [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: 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, &rval); 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: [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: [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: [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: [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: [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
