linux-kernel - Re: [RFC] Fix shared irq trigger-flags conflict when old irqaction uses IRQF_TRIGGER

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

Date:   Fri, 14 Apr 2017 11:34:27 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Hans de Goede <hdegoede@...hat.com>
cc:     Marc Zyngier <marc.zyngier@....com>, linux-acpi@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Fix shared irq trigger-flags conflict when old irqaction
 uses IRQF_TRIGGER_NONE

On Mon, 10 Apr 2017, Hans de Goede wrote:
> Where the new_action trigger_mask gets filled with the triger_mask
> from the irq_data, which is a further hint that looking at
> irqd_get_trigger_type(&desc->irq_data) rather then at
> (old->flags IRQF_TRIGGER_MASK) is probably the right fix.
> 
> Note btw that 4b357daed698 is (part of) what is breaking things for
> my use-case, I request the irq with IRQF_TRIGGER_NONE but
> 4b357daed698 modifies that before comparing the new trigger flags
> to the old.

The issue here is, that at the time of the first setup_irq() the trigger
type in irq_data is NONE. As a consequence the following is a NOOP:

     if (!new->trigger)
	new->flags |= get_type(irqdata);

Now the irq is started up for the first time and then the actual trigger
type gets established, but that's to late to fix up new->flags.

So yes, we should change the logic for the shared case to:

   if (old) {
      	    oldtype = get_type(irqdata);

	    if (oldtype != newtype)
	       	    goto mismatch;

That should cover all cases.

Thanks,

	tglx