linux-kernel - Re: [patch 1/2] genirq: Provide synchronize

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: <20140215095008.GG14089@laptop.programming.kicks-ass.net>
Date:	Sat, 15 Feb 2014 10:50:08 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Chris Ball <chris@...ntf.net>, linux-mmc@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 1/2] genirq: Provide synchronize_hardirq()

On Sat, Feb 15, 2014 at 12:55:18AM -0000, Thomas Gleixner wrote:
> synchronize_irq() waits for hard irq and threaded handlers to complete
> before returning. For some special cases we only need to make sure
> that the hard interrupt part of the irq line is not in progress when
> we disabled the - possibly shared - interrupt at the device level.
> 
> A proper use case for this was provided by Russell. The sdhci driver
> requires some irq triggered functions to be run in thread context. The
> current implementation of the thread context is a sdio private kthread
> construct, which has quite some shortcomings. These can be avoided
> when the thread is directly associated to the device interrupt via the
> generic threaded irq infrastructure.
> 
> Though there is a corner case related to run time power management
> where one side disables the device interrupts at the device level and
> needs to make sure, that an already running hard interrupt handler has
> completed before proceeding further. Though that hard interrupt
> handler might wake the associated thread, which in turn can request
> the runtime PM to reenable the device. Using synchronize_irq() leads
> to an immediate deadlock of the irq thread waiting for the PM lock and
> the synchronize_irq() waiting for the irq thread to complete.
> 
> Due to the fact that it is sufficient for this case to ensure that no
> hard irq handler is executing a new function which avoids the check
> for the thread is required.
> 
> Add a function, which just monitors the hard irq parts and ignores the
> threaded handlers.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

Acked-by: Peter Zijlstra <peterz@...radead.org>
--
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/