linux-kernel - Re: [PATCH] x86: make sure we really have an hpet mapping before using it

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

Message-ID: <20081216210240.GJ14787@elte.hu>
Date:	Tue, 16 Dec 2008 22:02:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86: make sure we really have an hpet mapping before
	using it


* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Ingo Molnar wrote:
>> * Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>>
>>   
>>> When booting in Xen dom0, the hpet isn't really accessible, so make
>>> sure the mapping is non-NULL before use.
>>>
>>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
>>> ---
>>> arch/x86/kernel/hpet.c |    5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> ===================================================================
>>> --- a/arch/x86/kernel/hpet.c
>>> +++ b/arch/x86/kernel/hpet.c
>>> @@ -818,9 +818,10 @@
>>>
>>> 		hpet_address = force_hpet_address;
>>> 		hpet_enable();
>>> -		if (!hpet_virt_address)
>>> -			return -ENODEV;
>>> 	}
>>> +
>>> +	if (!hpet_virt_address)
>>> +		return -ENODEV;
>>>     
>>
>> hm, how can hpet_virt_address become non-NULL if hpet_address is zero?
>>   
>
> The mapping is normally created in (paravirt_ops.)time_init -> 
> hpet_time_init -> hpet_enable -> hpet_set_mapping.  However, under Xen, 
> time_init points to the Xen time init function, and so hpet_time_init is 
> never called.
>
> hpet_time_late_init is always called because its an initfunc.  In domU 
> it doesn't matter because hpet_address is NULL and so it does nothing.  
> In dom0, however, all the ACPI table parsing gets done as normal, so the 
> hpet is discovered and its address found.  But it is not available for 
> the dom0 kernel's use, and it is never mapped.

ok - applied it to tip/timers/hpet.

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