linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

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

Message-ID: <alpine.DEB.2.20.1712082340400.2301@nanos>
Date:   Fri, 8 Dec 2017 23:51:35 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>
cc:     "Augustine.Chen" <augustine.chen@...el.com>,
        intel-gfx@...ts.freedesktop.org, alsa-devel@...a-project.org,
        jerome.anand@...el.com, pierre-louis.bossart@...el.com,
        tiwai@...e.de, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Jiang Liu <jiang.liu@...ux.intel.com>,
        Juergen Gross <jgross@...e.com>,
        Dou Liyang <douly.fnst@...fujitsu.com>,
        linux-kernel@...r.kernel.org
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.

Thanks,

	tglx