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: <9A1A7991592FAD49BCF9F28D9CF9FE3121AB7F0F@PGSMSX105.gar.corp.intel.com>
Date:   Wed, 13 Dec 2017 09:25:43 +0000
From:   "Chen, Augustine" <augustine.chen@...el.com>
To:     Takashi Iwai <tiwai@...e.de>
CC:     Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        "Anand, Jerome" <jerome.anand@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "Bossart, Pierre-louis" <pierre-louis.bossart@...el.com>,
        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" <linux-kernel@...r.kernel.org>
Subject: RE: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of
 HDMI LPE audio



> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@...e.de]
> Sent: Tuesday, December 12, 2017 5:45 PM
> To: Chen, Augustine <augustine.chen@...el.com>
> Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>; Anand, Jerome
> <jerome.anand@...el.com>; Thomas Gleixner <tglx@...utronix.de>; intel-
> gfx@...ts.freedesktop.org; alsa-devel@...a-project.org; Bossart, Pierre-louis
> <pierre-louis.bossart@...el.com>; 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 Tue, 12 Dec 2017 10:26:08 +0100,
> Chen, Augustine wrote:
> > > > > > > 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.
> > > > > >
> > > > >
> > > > > Ideally, I feel there needs to be an irq domain for mapping the
> > > > > irq numbers
> > > with hwirq.
> > > > > It is not created as part of the hdmi lpe audio bridge.
> > > > > Since the logic to mask/unmask lpe audio interrupts is removed,
> > > > > there is no need of the Chip data or creation of the domain now.
> > > >
> > > > There is no need right now. But there might be a need in the future.
> > > > LPE audio isn't even the only piece of hardware whose irq goes
> > > > through the i915 display engine (there's also the ISP and VED). So
> > > > I would much prefer a proper solution instead of sweeping the
> > > > problem under the rug.
> > >
> > > IMO, the primary question is whether the usage of irq chip without
> > > irq domain is valid or not.  If an irq domain is mandatory, that's
> > > the thing to be fixed in i915 side.
> > In terms of functionality, the interrupt and hdmi audio work fine
> > without irq domain according to the validation.
> 
> Sure, otherwise the patch never landed to mainline :)
> 
> > And besides, there
> > are other drivers with similar implementation which doesn't set chip
> > data at all.
> 
> Yes, dropping the chip data should be OK in the driver, but the only question is
> whether it is the right fix.
> 
> Did you check whether the issue happens with 4.15-rc, too?  This was never
> answered in bugzilla.  If I understand correctly, the code triggering Oops has
> been changed largely there and it should prune the non-legacy irqs.
> 
I tested it with 4.15-RC1 today and couldn't observed the same symptom. And yes, the code running into invalid pointer was modified dramatically.
Feels like it's available to keep this driver intact.


> 
> Takashi