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.11.1601281116310.3886@nanos>
Date:	Thu, 28 Jan 2016 11:29:21 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Brian Starkey <brian.starkey@....com>
cc:	linux-kernel@...r.kernel.org, marc.zyngier@....com
Subject: Re: [PATCH] genirq: fix trigger flags check for shared irqs

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?

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ