linux-kernel - Re: [PATCH 1/2] irq_flags_t: intro and core annotations

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: <20071022.172123.78710569.davem@davemloft.net>
Date:	Mon, 22 Oct 2007 17:21:23 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jeff@...zik.org
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	matthew@....cx, arnd@...db.de, ralf@...ux-mips.org,
	adobriyan@...il.com, viro@....linux.org.uk,
	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/2] irq_flags_t: intro and core annotations

From: Jeff Garzik <jeff@...zik.org>
Date: Mon, 22 Oct 2007 16:47:16 -0400

> Let me add to the chorus of voices:  I continually see two cases where 
> real bugs crop up:
> 
> 1) hacker uses spin_lock_irq() in incorrect context (where it is not 
> safe to do a blind enable/disable)
> 
> 2) hacker uses spin_lock_irq() correctly, but the surrounding code 
> changes, thus invalidating prior assumptions.
> 
> I would even go so far as to support the drastic measure of deleting 
> spin_lock_irq().
> 
> spin_lock_irqsave() generates fewer bugs, is more future-proof, and by 
> virtue of 'flags' permits architectures a bit more flexibility.

Whilst I agree with you fully on the error-prone'ness argument,
reading the processor interrupt level to fill in the 'flags'
can have non-trivial cost.  I think it's about 9 cycles and
a full pipeline flush on most sparc64 chips for example.

The write to turn off interrupts costs about the same, so you'd
essentially be doubling the execution cost in every case that
you convert as you propose.

I seem to recall that on modern x86 chips the cost of dorking
around with eflags like this is even higher.

What's the relative cost of pushfl/popl/pushl/popfl vs.  cli/sti on
like a core2 duo or a k8?

For 64-bit powerpc's software interrupt disabling scheme it seems
to cost is about equal for both cases.
-
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/