linux-kernel - Re: [PATCH 0/5] ARM: at91: fix irq_pm_install

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2662748.NJbkr6jW7r@vostro.rjw.lan>
Date:	Mon, 15 Dec 2014 23:20:17 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>, linux-serial@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com, Mike Turquette <mturquette@...aro.org>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Andrew Victor <linux@...im.org.za>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] ARM: at91: fix irq_pm_install_action WARNING

On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote:
> Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON
> test which triggers a WARNING backtrace on at91 platforms.

Pretty much as intended.

> While this WARN_ON is absolutely necessary to warn users that they should
> not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs,
> there is no easy way to solve this issue on at91 platforms.
> 
> The main reason is that the init timer is often using a shared irq line
> and thus request this irq with IRQF_NO_SUSPEND flag set, while other
> peripherals request the same irq line without this flag.
> 
> We could deal with that by identifying whether a given peripheral is
> connected to the init timer shared irq line and add the IRQF_NO_SUSPEND
> in this case, but this implies adding the logic in all peripheral drivers
> that could be connected to this shared irq.
> 
> This series takes the reverse approach: force IRQ users to specify that
> they take care of disabling peripheral interrupts and that IRQ core can
> safely leave the handler in a suspended state without having to bother
> about spurious interrupts.
> This is done by mean of a new IRQF_SUSPEND_NOACTION flag which tells the
> core to move the action handler to a suspended list, thus preventing its
> execution when we are in suspend mode.
> Of course, specifying the IRQF_SUSPEND_NOACTION flag implies taking care
> of masking/unmasking the peripheral interrupts in the suspend/resume
> implementation.

Well, I'm not sure how much value is in all that to be honest.  The only
thing it helps with is to make the WARN_ON go away in some cases, while
the drivers in question need to make sure that they disable their interrupts
properly anyway, so what exactly is the purpose of the new irqaction
shuffling?

It might just be simpler to add a flag to suppress the WARN_ON that would be
set by the user of IRQF_NO_SUSPEND that is broken enough to have to share the
interrupt with others ...


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/