linux-kernel - Re: [RFC PATCH] genirq: implement read_irq

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]

Date:	Fri, 15 Apr 2011 15:02:26 -0700
From:	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC:	tglx@...utronix.de, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, dwalker@...o99.com,
	linux-arm-msm-owner@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [RFC PATCH] genirq: implement read_irq_line for interrupt lines

Mathieu Desnoyers wrote:
> * Abhijeet Dharmapurikar (adharmap@...eaurora.org) wrote:
>> Drivers need to be aware whether the interrupt controller is a slow bus
>> and call read_irq_line in proper context.
> 
> Hrm, this strikes me as odd. Is there any way this generic API could
> handle the corner-cases without needed the caller to know this ?

Usually, a slow bus irq controller marks its irq as nested and has its 
irq handler running in thread context. In that case it will be safe to 
call irq_read_line from thread context. For the usual (non slow bus) irq 
controller we can always call irq_read_line within irq context.

This function is intended to be called from within the handler, to know 
if a rising edge or a falling edge caused the interrupt. It can be used 
in other places too, but then the driver needs to be careful about the 
interrupt controller slowbus nature.

The problem happens when this function is called from interrupt context 
when irq controller is slowbus. For example one has taken a spin_lock 
with interrupts disabled and now it wants to know the real time status 
on a pin that is controlled by a slow bus controller. The slowbus 
controller could end up sleeping and things go bad.

I should explain this more in the commit text. Will do so in the next 
revision of this patch.

>> + *	This function may be called from IRQ context only when
>> + *	desc->chip->bus_lock and desc->chip->bus_sync_unlock are NULL !
> 
> The comment here seems to imply "be careful when using this extremely
> fragile interface", which does not give me the warm safety feeling I
> would come to expect from a generic kernel API.
> 
> Any ideas on how to improve that ?

Well, even the enable_irq() and disable_irq_nosync() have the same 
calling restrictions. I picked this line from the comment block in 
enable_irq() function. You think I should explain it more in the 
upcoming patch?

--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm 
Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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/