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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 8 Dec 2017 23:51:35 +0100 (CET)
From:   Thomas Gleixner <>
To:     Ville Syrjälä <>
cc:     "Augustine.Chen" <>,,,,,, Ingo Molnar <>,
        "H. Peter Anvin" <>,
        Jiang Liu <>,
        Juergen Gross <>,
        Dou Liyang <>,
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of
 HDMI LPE audio

On Fri, 8 Dec 2017, Ville Syrjälä wrote:

> On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > The chip data of HDMI LPE audio is set to drm_i915_private which is not
> > consistent with the expectation by x86 APIC driver.
> Hmm. Why is the apic code looking at data for an irq chip it
> hasn't created?
> Do we need something like
> - dev_priv->lpe_audio.irq = irq_alloc_desc(0);
> + dev_priv->lpe_audio.irq = irq_alloc_desc(-1);

#define irq_alloc_desc(node)

So instead of handing in node 0 you hand in node -1 which is NUMA_NO_NODE

> That *looks* more correct to me based on a cursory glance at the x86
> code, but I didn't trawl very deeply.

The x86 core cares not at all about interrupt chips which are created in a
driver and not connected to an actual apic/ioapic/msi interrupt. This
interrupt chip is its own thing as we have others in GPIO etc.

> > In the case of not enabling CONFIG_CPUMASK_OFFSTACK, this would cause
> > kernel panic while doing CPU hotplug.

And why so? Surely not because you set irq_chip_data. That's really no
explanation at all.

Curing the symptom is never a good approach.



Powered by blists - more mailing lists