linux-kernel - Re: CONFIG_DEBUG

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]

Date:	Thu, 27 Aug 2015 08:02:18 -0500
From:	Felipe Balbi <balbi@...com>
To:	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
CC:	Felipe Balbi <balbi@...com>, Ingo Molnar <mingo@...e.hu>,
	Tony Lindgren <tony@...mide.com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: CONFIG_DEBUG_SHIRQ and PM

On Wed, Aug 26, 2015 at 05:36:24PM -0300, Ezequiel Garcia wrote:
> On 26 August 2015 at 17:24, Felipe Balbi <balbi@...com> wrote:
> [..]
> >>
> >> static irqreturn_t tw68_irq(int irq, void *dev_id)
> >> {
> >>         struct tw68_dev *dev = dev_id;
> >>         u32 status, orig;
> >>         int loop;
> >>
> >>         status = orig = tw_readl(TW68_INTSTAT) & dev->pci_irqmask;
> >
> > Now try to read that register when your clock is gated. That's the
> > problem I'm talking about. Everything about the handler is functioning
> > correctly; however clocks are gated in ->remove() and free_irq() is
> > only called *AFTER* ->remove() has returned.
> >
> 
> Yeah, it's pretty clear you are talking about clocks here. That's
> why I said "read won't stall" in the next paragraph.
> 
> >>         [etc]
> >> }
> >>
> >> The IRQ handler accesses the device struct and then
> >> reads through PCI. So if you use devm_request_irq
> >> you need to make sure the device struct is still allocated
> >> after remove(), and the PCI read won't stall or crash.
> >
> > dude, that's not the problem I'm talking about. I still have my
> > private_data around, what I don't have is:
> >
> >               _            _
> >   __ _    ___| | ___   ___| | __
> >  / _` |  / __| |/ _ \ / __| |/ /
> > | (_| | | (__| | (_) | (__|   <
> >  \__,_|  \___|_|\___/ \___|_|\_\
> >
> >
> 
> Yes, *you* may have your private data around and have a clock gated,
> others (the tw68 for instance) may have its region released and unmapped.
> 
> And yet others may have $whatever resource released in the
> remove() and assume it's available in the IRQ handler.
> 
> I honestly can't think why using request_irq / free_irq to solve this
> is a workaround.

because it'll, eventually, boil down to not using devm_* at all and
that's pretty stupid.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)