linux-kernel - Re: [x86] BUG: unable to handle kernel paging request at 00740060

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131007092744.GA28686@localhost>
Date:	Mon, 7 Oct 2013 17:27:44 +0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>, hpa@...or.com
Subject: Re: [x86] BUG: unable to handle kernel paging request at 00740060

On Mon, Oct 07, 2013 at 10:55:33AM +0200, Peter Zijlstra wrote:
> On Sun, Oct 06, 2013 at 07:44:30AM +0800, Fengguang Wu wrote:
> > Greetings,
> > 
> > I got the below dmesg and the first bad commit is
> > 
> > commit 0c44c2d0f459cd7e275242b72f500137c4fa834d
> > Author: Peter Zijlstra <peterz@...radead.org>
> > Date:   Wed Sep 11 15:19:24 2013 +0200
> > 
> >     x86: Use asm goto to implement better modify_and_test() functions
> >     
> >     Linus suggested using asm goto to get rid of the typical SETcc + TEST
> >     instruction pair -- which also clobbers an extra register -- for our
> >     typical modify_and_test() functions.
> >     
> >     Because asm goto doesn't allow output fields it has to include an
> >     unconditinal memory clobber when it changes a memory variable to force
> >     a reload.
> >     
> >     Luckily all atomic ops already imply a compiler barrier to go along
> >     with their memory barrier semantics.
> >     
> >     Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
> >     Signed-off-by: Peter Zijlstra <peterz@...radead.org>
> >     Link: http://lkml.kernel.org/n/tip-0mtn9siwbeo1d33bap1422se@git.kernel.org
> >     Signed-off-by: Ingo Molnar <mingo@...nel.org>
> 
> 
> Well that blows,.. Anybody got any clue as to where to start looking?
> I've not actually seen anything like this on my own machines.

Perhaps it's related to one of

- the randconfig
- kvm
- gcc

In the end of dmesg file, there is the qemu command line to run the kernel:

qemu-system-x86_64 -cpu kvm64 -enable-kvm -kernel
/kernel/i386-randconfig-j1-10052106/a0cf1abc25ac197dd97b857c0f6341066a8cb1cf/vmlinuz-3.12.0-rc2-next-20130927-03100-ga0cf1ab -append 'hung_task_panic=1
rcutree.rcu_cpu_stall_timeout=100 log_buf_len=8M ignore_loglevel debug sched_debug apic=debug dynamic_printk sysrq_always_enabled panic=10
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal  root=/dev/ram0 rw
link=/kernel-tests/run-queue/kvm/i386-randconfig-j1-10052106/next:master/.vmlinuz-a0cf1abc25ac197dd97b857c0f6341066a8cb1cf-20131005211923-7-athens
branch=next/master
BOOT_IMAGE=/kernel/i386-randconfig-j1-10052106/a0cf1abc25ac197dd97b857c0f6341066a8cb1cf/vmlinuz-3.12.0-rc2-next-20130927-03100-ga0cf1ab'  -initrd
/kernel-tests/initrd/quantal-core-i386.cgz -m 256M -smp 2 -net nic,vlan=0,macaddr=00:00:00:00:00:00,model=virtio -net user,vlan=0,hostfwd=tcp::10661-:22
-net nic,vlan=1,model=e1000 -net user,vlan=1 -boot order=nc -no-reboot -watchdog i6300esb -drive
file=/fs/LABEL=KVM/disk0-quantal-athens-6,media=disk,if=virtio -drive file=/fs/LABEL=KVM/disk1-quantal-athens-6,media=disk,if=virtio -drive
file=/fs/LABEL=KVM/disk2-quantal-athens-6,media=disk,if=virtio -drive file=/fs/LABEL=KVM/disk3-quantal-athens-6,media=disk,if=virtio -drive
file=/fs/LABEL=KVM/disk4-quantal-athens-6,media=disk,if=virtio -drive file=/fs/LABEL=KVM/disk5-quantal-athens-6,media=disk,if=virtio -pidfile
/dev/shm/kboot/pid-quantal-athens-6 -serial file:/dev/shm/kboot/serial-quantal-athens-6 -daemonize -display none -monitor null    

> Wu, do you use the same compiler version for all the builds that crash
> like this (I'm assuming the other email was this same commit)? Does a
> different compiler make things work again?

Good point. I'll try a different compiler.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/