[PATCH] x86/hpet: fix cpumask allocation after 23990:1c8789852eaf

[PATCH] x86/hpet: fix cpumask allocation after 23990:1c8789852eaf

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

hpet_fsb_cap_lookup(), if it doesn't find any FSB capable timer, leaves
hpet_events allocated, while hpet_events->cpumask may not have been, As
we're pretty generous with these one-time allocations already (in that
hpet_events doesn't get freed when no usable counters were found, even
if in that case only the first array entry [or none at all] may get
used), simply make the cpumask allocation in the legacy case
independent of whether hpet_events was NULL before.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -512,15 +512,8 @@ void __init hpet_broadcast_init(void)
             return;
 
         if ( !hpet_events )
-        {
             hpet_events = xzalloc(struct hpet_event_channel);
-            if ( hpet_events && !zalloc_cpumask_var(&hpet_events->cpumask) )
-            {
-                xfree(hpet_events);
-                hpet_events = NULL;
-            }
-        }
-        if ( !hpet_events )
+        if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
         hpet_events->irq = -1;
 



[-- Attachment #2: x86-hpet-fix-23990.patch --]
[-- Type: text/plain, Size: 1195 bytes --]

x86/hpet: fix cpumask allocation after 23990:1c8789852eaf

hpet_fsb_cap_lookup(), if it doesn't find any FSB capable timer, leaves
hpet_events allocated, while hpet_events->cpumask may not have been, As
we're pretty generous with these one-time allocations already (in that
hpet_events doesn't get freed when no usable counters were found, even
if in that case only the first array entry [or none at all] may get
used), simply make the cpumask allocation in the legacy case
independent of whether hpet_events was NULL before.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -512,15 +512,8 @@ void __init hpet_broadcast_init(void)
             return;
 
         if ( !hpet_events )
-        {
             hpet_events = xzalloc(struct hpet_event_channel);
-            if ( hpet_events && !zalloc_cpumask_var(&hpet_events->cpumask) )
-            {
-                xfree(hpet_events);
-                hpet_events = NULL;
-            }
-        }
-        if ( !hpet_events )
+        if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
         hpet_events->irq = -1;
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] x86/hpet: fix cpumask allocation after 23990:1c8789852eaf

[Christoph Egger]

On 10/21/11 16:00, Jan Beulich wrote:
> hpet_fsb_cap_lookup(), if it doesn't find any FSB capable timer, leaves
> hpet_events allocated, while hpet_events->cpumask may not have been, As
> we're pretty generous with these one-time allocations already (in that
> hpet_events doesn't get freed when no usable counters were found, even
> if in that case only the first array entry [or none at all] may get
> used), simply make the cpumask allocation in the legacy case
> independent of whether hpet_events was NULL before.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Tested-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -512,15 +512,8 @@ void __init hpet_broadcast_init(void)
>               return;
>
>           if ( !hpet_events )
> -        {
>               hpet_events = xzalloc(struct hpet_event_channel);
> -            if ( hpet_events&&  !zalloc_cpumask_var(&hpet_events->cpumask) )
> -            {
> -                xfree(hpet_events);
> -                hpet_events = NULL;
> -            }
> -        }
> -        if ( !hpet_events )
> +        if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
>               return;
>           hpet_events->irq = -1;
>
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632