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:	Tue, 15 Jan 2013 00:54:06 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] genirq: Give warning when setup an already-setup
 non-shared irq



> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@...utronix.de]
> Sent: Monday, January 14, 2013 7:16 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] genirq: Give warning when setup an already-setup
> non-shared irq
> 
> On Thu, 10 Jan 2013, Chuansheng Liu wrote:
> >
> > Meet the case when the request_threaded_irq() with the same irq
> > is called twice continually, get the below mismatch info:
> > "IRQ handler type mismatch for IRQ 323"
> 
> I have no idea where you get that from. The mismatch is printed with:
> 
>         if (!(new->flags & IRQF_PROBE_SHARED)) {
> 	   pr_err("Flags mismatch irq %d. %08x (%s) vs. %08x (%s)\n",
>                        irq, new->flags, new->name, old->flags,
> old->name);
	if (!(new->flags & IRQF_PROBE_SHARED)) {
		printk(KERN_ERR "IRQ handler type mismatch for IRQ %d\n", irq);
		if (old_name)
			printk(KERN_ERR "current handler: %s\n", old_name);
		dump_stack();
	}
The "IRQ handler type mismatch for IRQ 323" message is coming from the above code,
which is something older than you pasted, but it is the same place.

> 
> And its only printed when IRQF_PROBE_SHARED is not set. Your change
> would cause printouts where no printouts are due and it'd change the
> return value from EBUSY to EINVAL.
My test case is below:
request_irq(323, func1,
				IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING,
				name, dev);
After succeeded, then called it again:
request_irq(323, func1,
				IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING,
				name, dev);

After the test case, I will get the "mismatch" info.
But in this case, it should not be the "mismatch" case, so I want to give another warning
in case of duplicated setup the same irq with non-shared.
Not sure if it is right. Thanks your pointing out.
> 
> Thanks,
> 
> 	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ