Hi Sai, On Sun, Sep 3, 2017 at 1:16 PM, Prakhya, Sai Praneeth <sai.praneeth.prakhya@xxxxxxxxx> wrote: >> > >> > Thanks for this v2. >> > Introducing the 'efi_switch_mm() ' helper instead of manually >> > twiddling with %cr3 seems more cleaner. >> > >> > I have tested this patchset on a x86_64 machine with the following >> > configurations: >> > >> > 1. Primary kernel boot with efi=old_map 2. Primary kernel boot with >> > new efi map >> > >> > While it seems that efi=old_map passes, the new efi map boot fails for >> > me on both the two x86 machine (Dell 3050MT and a SGI - UV300 machine. >> > >> > It seems we are hitting a NULL pointer deference in >> > 'efi_call_phys_prolog' while accessing '&efi_mm'. >> > >> > Please see the log below for details: >> > >> > [ 0.020006] BUG: unable to handle kernel NULL pointer dereference >> > at (null) >> > [ 0.021000] IP: switch_mm_irqs_off+0x44/0x270 >> > [ 0.021000] Call Trace: >> > [ 0.021000] switch_mm+0x20/0x30 >> > [ 0.021000] efi_switch_mm+0x49/0x60 >> > [ 0.021000] efi_call_phys_prolog+0x56/0x1b3 >> > [ 0.021000] efi_enter_virtual_mode+0x3a9/0x520 >> > [ 0.021000] start_kernel+0x424/0x4c8 >> > [ 0.021000] ? set_init_arg+0x5a/0x5a >> > [ 0.021000] ? early_idt_handler_array+0x120/0x120 >> > [ 0.021000] x86_64_start_reservations+0x29/0x2b >> > [ 0.021000] x86_64_start_kernel+0x151/0x174 >> > [ 0.021000] secondary_startup_64+0x9f/0x9f >> > [ 0.021000] Code: 2d 82 51 d9 4f 65 c7 05 0f 65 da 4f 01 00 00 00 >> > 48 39 f7 0f 84 14 01 00 00 65 48 89 35 f6 64 da 4f 48 8b 86 e8 02 00 >> > 00 45 89 ed <f0> 4c 0f ab 28 bf 00 00 00 80 48 03 7e 50 48 8b 05 27 b0 >> > b9 00 >> > [ 0.021000] RIP: switch_mm_irqs_off+0x44/0x270 RSP: ffffffffb0e035d0 >> > [ 0.021000] CR2: 0000000000000000 >> > [ 0.021000] ---[ end trace fb94349305e1cb8b ]--- >> > [ 0.021000] Kernel panic - not syncing: Fatal exception >> > [ 0.021000] ---[ end Kernel panic - not syncing: Fatal exception >> > >> >> And I forgot to mention that I tried the patchset both with the efi/next and >> linus's trees and saw the same result. >> >> I would be happy to help in case you need further details of the test environment >> or need help in testing this crash further. >> >> Regards, >> Bhupesh > > Hi Bhupesh, > > Thanks for trying the patches and raising the concern. > Could you also please also give a try on qemu? (if reproducible, we will be having a common platform to start debugging) > I have tested this patch set on qemu and real machines (different from one's you tried) in our lab and didn’t notice this issue. > I get a similar crash on Qemu with linus's master branch and the V2 applied on top of it. Here are the details of my test environment: 1. I use the OVMF (EDK2) EFI firmware to launch the kernel: edk2.git/ovmf-x64 2. I used linus's master branch (HEAD - commit: b1b6f83ac938d176742c85757960dec2cf10e468) and applied your v2 on top of the same. 3. I use the following qemu command line to launch the test: # /usr/local/bin/qemu-system-x86_64 --version QEMU emulator version 2.9.50 (v2.9.0-526-g76d20ea) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers # /usr/local/bin/qemu-system-x86_64 -enable-kvm -net nic -net tap -m $MEMSIZE -nographic -drive file=$DISK_IMAGE,if=virtio,format=qcow2 -vga std -boot c -cpu host -kernel $KERNEL -append "crashkernel=$CRASH_MEMSIZE console=ttyS0,115200n81" -initrd $INITRAMFS -bios $OVMF_FW_PATH And here is the crash log: [ 0.006054] general protection fault: 0000 [#1] SMP [ 0.006459] Modules linked in: [ 0.006711] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.0+ #3 [ 0.007000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 0.007000] task: ffffffff81e0f480 task.stack: ffffffff81e00000 [ 0.007000] RIP: 0010:switch_mm_irqs_off+0x1bc/0x440 [ 0.007000] RSP: 0000:ffffffff81e03d80 EFLAGS: 00010086 [ 0.007000] RAX: 800000007d084000 RBX: 0000000000000000 RCX: 000077ff80000000 [ 0.007000] RDX: 000000007d084000 RSI: 8000000000000000 RDI: 0000000000019a00 [ 0.007000] RBP: ffffffff81e03dc0 R08: 0000000000000000 R09: ffff88007d085000 [ 0.007000] R10: ffffffff81e03dd8 R11: 000000007d095063 R12: ffffffff81e5c6a0 [ 0.007000] R13: ffffffff81ed4f40 R14: 0000000000000030 R15: 0000000000000001 [ 0.007000] FS: 0000000000000000(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000 [ 0.007000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.007000] CR2: ffff88007d754000 CR3: 000000000220a000 CR4: 00000000000406b0 [ 0.007000] Call Trace: [ 0.007000] switch_mm+0xd/0x20 [ 0.007000] ? switch_mm+0xd/0x20 [ 0.007000] efi_switch_mm+0x3e/0x4a [ 0.007000] efi_call_phys_prolog+0x28/0x1ac [ 0.007000] efi_enter_virtual_mode+0x35a/0x48f [ 0.007000] start_kernel+0x332/0x3b8 [ 0.007000] x86_64_start_reservations+0x2a/0x2c [ 0.007000] x86_64_start_kernel+0x178/0x18b [ 0.007000] secondary_startup_64+0xa5/0xa5 [ 0.007000] ? secondary_startup_64+0xa5/0xa5 [ 0.007000] Code: 00 00 00 80 49 03 55 50 0f 82 7f 02 00 00 48 b9 00 00 00 80 ff 77 00 00 48 be 00 00 00 00 00 00 00 80 48 01 ca 48 09 f0 48 09 d0 <0f> 22 d8 0f 1f 44 00 00 e9 47 ff ff ff 65 8b 05 b8 87 fb 7e 89 [ 0.007000] RIP: switch_mm_irqs_off+0x1bc/0x440 RSP: ffffffff81e03d80 [ 0.007000] ---[ end trace bfa55bf4e4765255 ]--- [ 0.007000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.007000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! 4. Note though that if I use the EFI_MIXED mode (i.e. 32-bit ovmf firmware and 64-bit x86 kernel) with your patches, the primary kernel boots fine on Qemu: ovmf firmware used in this case - edk2.git/ovmf-ia32 5. Also, if I append 'efi=old_map' to the bootargs (for the failing case in point 3 above), I see the primary kernel boots fine on Qemu as well. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
