linux-kernel - Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86

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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 4 Feb 2017 12:05:42 -0800
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Mark Brown <broonie@...nel.org>
Cc:     Fengguang Wu <fengguang.wu@...el.com>,
        Guenter Roeck <linux@...ck-us.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...capital.net>,
        Borislav Petkov <bp@...en8.de>
Subject: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64

I could not boot next-20170203 on my x86_64 qemu instance. It stalls at:

[    0.015549] CPU: Physical Processor ID: 0
[    0.015842] mce: CPU supports 10 MCE banks
[    0.016032] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[    0.016393] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[    0.016871] Freeing SMP alternatives memory: 24K
[    0.017710] ftrace: allocating 25888 entries in 102 pages
[    0.024102] smpboot: Max logical packages: 4
[    0.024524] x2apic enabled
[    0.024851] Switched APIC routing to physical x2apic.
[    0.025755] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1

This is no different than a functional boot, it just stalls. I see it
next-20170203 booted and worked on other qemu instances elsewhere
though so it seems something with my configuration and boot. I
bisected next-20170203 between its latest commit and v4.10-rc6 and
ended up with this bad commit:

104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62

$ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62
commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62
Merge: 7c3b1edeee66 3f87493930a0
Author: Stephen Rothwell <sfr@...b.auug.org.au>
Date:   Fri Feb 3 12:30:38 2017 +1100

    Merge remote-tracking branch 'spi/for-next'

I have checked Next/SHA1s and it shows:

mcgrof@...gy ~/linux-next (git::original)$ grep spi Next/SHA1s
spi-nor        dc12bcccadafb5441170e6b7c8a438c91d4f385b
spi        3f87493930a0f934549b04e100ecc2110e4f1efd
hwspinlock    bd5717a4632cdecafe82d03de7dcb3b1876e2828

The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be
what I need to test. I have cloned Mark's spi tree and just tried to
boot the for-next branch (on v4.10-rc1) on
3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully.
This would lead me to believe this issue might be related to the merge
conflict resolution done by Stephen, but wanted to check and ask.
Perhaps there might be some specific tests I can run.

The qemu instance I am using:

/usr/local/bin/qemu-system-x86_64 -cpu kvm64 -enable-kvm -m 4096 -smp
4 -netdev vde,sock=/var/run/qemu-vde.ctl,group=kvm,mode=0660,id=vde0
-device e1000,netdev=vde0,mac=52:54:00:12:34:84 -hda
/opt/qemu/debian-x86_64.qcow2 -hdb /opt/qemu/linux-next.qcow2 -monitor
pty -serial stdio -chardev pty,id=ttyS1 -device
isa-serial,chardev=ttyS1 -chardev pty,id=ttyS2 -device
isa-serial,chardev=ttyS2 -nographic -boot order=d

  Luis