From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation
Date: Mon, 25 Apr 2016 11:15:27 +0100 [thread overview]
Message-ID: <20160425101527.GP2829@codeblueprint.co.uk> (raw)
In-Reply-To: <20160424212241.GO2829@codeblueprint.co.uk>
On Sun, 24 Apr, at 10:22:41PM, Matt Fleming wrote:
>
> I like this series a lot (well, ignoring the fact that the firmware is
> trying to eat itself). The runtime call code is much cleaner now, and
> this is a great precedent for any future multi-architecture quirks we
> may need.
>
> Queued for v4.7, thanks everyone!
Hmm... Booting this series with Qemu and OVMF results in lots of
warnings,
[ 0.102173] ------------[ cut here ]------------
[ 0.103000] WARNING: CPU: 0 PID: 0 at /dev/shm/mfleming/git/efi/drivers/firmware/efi/runtime-wrappers.c:30 efi_call_virt_check_flags+0x69/0x90
[ 0.103505] Modules linked in:
[ 0.104519] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4+ #1
[ 0.105000] 0000000000000000 ffffffff81e03e30 ffffffff8132206f 0000000000000000
[ 0.105000] 0000000000000000 ffffffff81e03e70 ffffffff8105a47c 0000001e0000000a
[ 0.105000] 0000000000000246 0000000000000286 ffffffff81bed975 ffffffff81e03f10
[ 0.105000] Call Trace:
[ 0.105000] [<ffffffff8132206f>] dump_stack+0x4d/0x6e
[ 0.105000] [<ffffffff8105a47c>] __warn+0xcc/0xf0
[ 0.105000] [<ffffffff8105a558>] warn_slowpath_null+0x18/0x20
[ 0.105000] [<ffffffff8164e5a9>] efi_call_virt_check_flags+0x69/0x90
[ 0.105000] [<ffffffff8164f9d2>] virt_efi_set_variable+0x82/0x190
[ 0.105000] [<ffffffff81054555>] efi_delete_dummy_variable+0x75/0x80
[ 0.105000] [<ffffffff81f599f6>] efi_enter_virtual_mode+0x463/0x472
[ 0.105000] [<ffffffff81f41f82>] start_kernel+0x38f/0x415
[ 0.105000] [<ffffffff81f419e1>] ? set_init_arg+0x55/0x55
[ 0.105000] [<ffffffff81f415ee>] x86_64_start_reservations+0x2a/0x2c
[ 0.105000] [<ffffffff81f416da>] x86_64_start_kernel+0xea/0xed
[ 0.107181] ---[ end trace 0081cc453369d969 ]---
[ 0.107499] Disabling lock debugging due to kernel taint
[ 0.108226] [Firmware Bug]: IRQ flags corrupted (0x00000246=>0x00000286) by EFI set_variable
Has anyone tested this series on x86 to ensure that this is a rare
case? I'll go and test some physical x86 machines now.
next prev parent reply other threads:[~2016-04-25 10:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 13:51 [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation Mark Rutland
2016-04-22 13:51 ` [PATCHv2 1/6] efi/runtime-wrappers: add {__,}efi_call_virt templates Mark Rutland
2016-04-24 21:12 ` Matt Fleming
2016-04-22 13:51 ` [PATCHv2 2/6] arm64/efi: move to generic {__,}efi_call_virt Mark Rutland
2016-04-22 13:51 ` [PATCHv2 3/6] arm/efi: " Mark Rutland
2016-04-22 13:51 ` [PATCHv2 4/6] x86/efi: " Mark Rutland
2016-04-22 13:51 ` [PATCHv2 5/6] efi/runtime-wrappers: remove redundant ifdefs Mark Rutland
2016-04-22 13:51 ` [PATCHv2 6/6] efi/runtime-wrappers: detect FW irq flag corruption Mark Rutland
2016-04-24 21:17 ` Matt Fleming
2016-04-22 14:12 ` [PATCHv2 0/6] efi: detect erroneous firmware IRQ manipulation Ard Biesheuvel
2016-04-24 21:22 ` Matt Fleming
2016-04-25 10:15 ` Matt Fleming [this message]
2016-04-25 10:21 ` Ard Biesheuvel
2016-04-25 10:28 ` Matt Fleming
2016-04-25 10:40 ` Mark Rutland
2016-04-25 10:51 ` Matt Fleming
2016-04-25 11:04 ` Mark Rutland
2016-04-25 11:19 ` Matt Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160425101527.GP2829@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).