linux-kernel - Re: [PATCH] Delete redundant IRQ_DISABLED check in 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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.00.0907181032210.11571@localhost.localdomain>
Date:	Sat, 18 Jul 2009 11:41:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Barry Song <21cnbao@...il.com>
cc:	mingo@...hat.com, dahlmann.thomas@...or.de,
	LKML <linux-kernel@...r.kernel.org>,
	uclinux-dist-devel@...ckfin.uclinux.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] Delete redundant IRQ_DISABLED check in irq_thread

On Sat, 18 Jul 2009, Barry Song wrote:
> I guess people call disable_irq to disable the whole execution,
> specially to disable the hardirq(then both top and bottom are
> blocked). It's really strange the disable operation only blocks the
> bottom-half.

The disable blocks both. After the disable no hardirq comes in
anymore. 

The disabled check in the thread is just to take care of the case when
the disable comes in between the hardirq and the thread handler.

That way we avoid doing the full tracking of the hardirq / thread
chain simply because it is complex and would produce significant
overhead in the fast path for no gain. It could be done, but it's not
worth the trouble.

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/