linux-kernel - Re: [tip:x86/urgent] x86, apic: Fix apic=debug boot crash

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C743E00.1040601@kernel.org>
Date:	Tue, 24 Aug 2010 14:47:44 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Daniel Kiper <dkiper@...-space.pl>
CC:	"H. Peter Anvin" <hpa@...or.com>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, apic: Fix apic=debug boot crash

On 08/24/2010 02:39 PM, Daniel Kiper wrote:
> Hello,
> 
> On 08/23/2010 07:54 AM, H. Peter Anvin wrote:
>> It's already applied.
> 
> Thx.
> 
> On Mon, Aug 23, 2010 at 10:59:19AM -0700, Yinghai Lu wrote:
> [...]
>>>>>> x86, apic: Fix apic=debug boot crash
>>>>>>
>>>>>> Fix a boot crash when apic=debug is used and the APIC is
>>>>>> not properly initialized.
>>>>>>
>>>>>> This issue appears during Xen Dom0 kernel boot but the
>>>>>> fix is generic and the crash could occur on real hardware
>>>>>> as well.
>>>>>
>>>>> Do you have any report on real hardware?
>>>>> that could not happen on real hardware.
>>>>
>>>> Till now no, however I think it is good idea
>>>> to apply this patch now. It is not worth to wait
>>>> for another null pointer dereference.
>>
>> no, we should add BUG_ON() etc debug info there to see why that null cfg could happen.
>> because according to code, we should have null there.
> 
> I think that BUG_ON() is too strong here because
> it is "debug" function and it should work also
> with let's say "invalid" data (in Xen case it is
> normal because APIC state is managed directly
> by hypervisor).
> 
> Additionally, with this patch it is easy to
> differentiate between cfg != NULL and
> cfg == NULL. Please look below:
> 
> cfg != NULL:
> IRQ to pin mappings:
> IRQ0 -> 0:2
> IRQ1 -> 0:1
> IRQ3 -> 0:3
> IRQ4 -> 0:4
> IRQ5 -> 0:5
> IRQ6 -> 0:6
> IRQ7 -> 0:7
> IRQ8 -> 0:8
> IRQ9 -> 0:9
> IRQ10 -> 0:10
> IRQ11 -> 0:11
> IRQ12 -> 0:12
> IRQ13 -> 0:13
> IRQ14 -> 0:14
> IRQ15 -> 0:15
> .................................... done.
> 
> cfg == NULL:
> IRQ to pin mappings:
> .................................... done.
> 
> If I missed something or if you have any
> questions please drop me a line.

I mean you should figure out why xen ops could have null cfg.

Yinghai
--
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/