lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 22 May 2016 11:16:19 +0200 From: Sedat Dilek <sedat.dilek@...il.com> To: Peter Zijlstra <peterz@...radead.org> Cc: Ingo Molnar <mingo@...nel.org>, David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "the arch/x86 maintainers" <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [v4.6-rc7-183-g1410b74e4061] On 5/16/16, Sedat Dilek <sedat.dilek@...il.com> wrote: > On 5/16/16, Peter Zijlstra <peterz@...radead.org> wrote: >> On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: >> >>> Unfortunately, I could not reproduce this again with none of my >>> 183-kernels. >>> When I first hit a "chain_key collision" issue, it was hard to >>> redproduce, >>> so. >>> Any idea, how I can "force" this? >> >> Nope; I wish I knew, that'd be so much easier to work with :/ >> >> I'm hoping someone will report a reproducer, even something that >> triggers once every 5-10 runs would be awesome. >> >> In any case, like I've explained before, nothing regressed as such, we >> only added this new warning under DEBUG_LOCKDEP because we want to >> better understand the condition that triggers it. >> >> If it bothers you, just turn off DEBUG_LOCKDEP and know that your kernel >> is as reliable as it was before. OTOH, if you do keep it on, please >> let me know if you can (semi) reliably trigger this, as I'd really like >> to have a better understanding. >> > > OK, I keep checking my logs. > > I refreshed your patch Ingo pointed me to. > > But it fails like this (on top of Linux v4.6 final)... > [...] > if [ "" = "-pg" ]; then if [ kernel/locking/mutex-debug.o != > "scripts/mod/empty.o" ]; then ./scripts/recordmcount > "kernel/locking/mutex-debug.o"; fi; fi; > mycompiler -Wp,-MD,kernel/locking/.lockdep.o.d -nostdinc -isystem > /usr/lib/gcc/x86_64-linux-gnu/4.9/include -nostdinc -isystem > /usr/lib/gcc/x86_64-linux-gnu/4.9/include -I./arch/x86/include > -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated > -Iinclude -I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi > -I./include/uapi -Iinclude/generated/uapi -include > ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef > -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common > -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 > -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 > -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 > -mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone > -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args > -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 > -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 > -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe > -Wno-sign-compare -fno-asynchronous-unwind-tables > -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 > -Wframe-larger-than=1024 -fno-stack-protector > -Wno-unused-but-set-variable -fno-omit-frame-pointer > -fno-optimize-sibling-calls -fno-var-tracking-assignments -mfentry > -DCC_USING_FENTRY -Wdeclaration-after-statement -Wno-pointer-sign > -fno-strict-overflow -fconserve-stack -Werror=implicit-int > -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO > -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(lockdep)" > -D"KBUILD_MODNAME=KBUILD_STR(lockdep)" -c -o > kernel/locking/.tmp_lockdep.o kernel/locking/lockdep.c > kernel/locking/lockdep.c: In function 'print_chain_keys_held_locks': > kernel/locking/lockdep.c:2034:2: error: too few arguments to function > 'print_chain_key_iteration' > print_chain_key_iteration(hlock_next->class_idx, chain_key); > ^ > kernel/locking/lockdep.c:2006:12: note: declared here > static u64 print_chain_key_iteration(int class_idx, u64 chain_key, > u64 prev_key) > ^ > make[4]: *** [kernel/locking/lockdep.o] Error 1 > make[3]: *** [kernel/locking] Error 2 > make[2]: *** [kernel] Error 2 > [...] > Is the attached fix correct? - Sedat - P.S.: Attached is a refreshed version of your original proposal patch which does not compile correctly. View attachment "lockdep-testing-peterz-20160516-fixes-4-6.diff" of type "text/plain" (485 bytes) Download attachment "0001-locking-lockdep-Some-more-additional-chain_key-colli.patch" of type "application/octet-stream" (4975 bytes)
Powered by blists - more mailing lists