linux-kernel - Re: [PATCH] genirq: fix trigger flags check for shared irqs

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: <20160128111041.GB12884@e106950-lin.cambridge.arm.com>
Date:	Thu, 28 Jan 2016 11:10:42 +0000
From:	Brian Starkey <brian.starkey@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, marc.zyngier@....com
Subject: Re: [PATCH] genirq: fix trigger flags check for shared irqs

On Thu, Jan 28, 2016 at 11:29:21AM +0100, Thomas Gleixner wrote:
>Brian,
>
>On Thu, 28 Jan 2016, Brian Starkey wrote:
>> On Tue, Jan 26, 2016 at 09:45:32PM +0100, Thomas Gleixner wrote:
>> > On Tue, 26 Jan 2016, Brian Starkey wrote:
>> >
>> > > For shared interrupts, if one requester passes in any IRQF_TRIGGER_*
>> > > flags whilst another doesn't, __setup_irq() can erroneously fail.
>> > >
>> > > The no-flags case should be treated as "already configured", so change
>> > > __setup_irq() to only check that the flags match if any have been
>> > > provided.
>> >
>> > What happens if that "already configured", i.e. the default setting, is
>> > conflicting with the newly requested interrupt?
>> >
>> > I rather prefer the failure than the resulting silent wreckage.
>> >
>>
>> Yes, I agree that would be best avoided. It seems to me that this case
>> is actually handled a bit lower down:
>>
>> 	} else if (new->flags & IRQF_TRIGGER_MASK) {
>> 		unsigned int nmsk = new->flags & IRQF_TRIGGER_MASK;
>> 		unsigned int omsk = irq_settings_get_trigger_mask(desc);
>>
>> 		if (nmsk != omsk)
>> 			/* hope the handler works with current  trigger mode
>> */
>> 			pr_warning("irq %d uses trigger mode %u; requested
>> %u\n",
>> 				   irq, nmsk, omsk);
>> 	}
>>
>> Perhaps that should be louder/fatal?
>
>Perhaps. So what's the actual problem case you are trying to solve?

I've got a few devices on the same interrupt line. One driver does
something along these lines:

	res = platform_get_resource(dev, IORESOURCE_IRQ, 0);
	flags = (res->flags & IRQF_TRIGGER_MASK) | IRQF_SHARED;
	request_irq(res->start, handler, flags, "name", dev);

This seems pretty reasonable. The problem is since 4a43d686fe33:
    of/irq: Pass trigger type in IRQ resource flags[1]
the trigger type information from device-tree is in res->flags.

So when the other drivers don't pass in any flags, they fail the check
in __setup_irq().

Changing the former driver to remove the flags doesn't seem right, and
adding flags to the latter would imply adding flags to _every_ driver,
which is an awful lot to change - and I'm not sure it would be possible
and/or effective in all cases.

Cheers,

-Brian

[1]http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4a43d686fe336cc0e955c4400ba4d3fcff788786

>
>Thanks,
>
>	tglx
>