linux-kernel - Re: [rfc patch] i386: don't save eflags on task switch

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:	Sun, 5 Nov 2006 19:52:55 +0100
From:	Andi Kleen <ak@...e.de>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Zachary Amsden <zach@...are.com>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Chuck Ebbert <76306.1226@...puserve.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [rfc patch] i386: don't save eflags on task switch

> 
> So you get a test, a unpredictable conditional jump, and the sti - and 
> you'll end up with the cost being pretty much the same as the popf: only 
> bigger and more complex.
> 
> That's a win, right?

Previously we had a popf which for the CPU unpredictable
restoring of most of its state. I would assume the unpredicted jump
is cheaper than that.

I might be wrong. Benchmarks will tell when I try it.

But I think it might be worth a try at least.

> 
> > 99.9999% of all restore_flags just need STI.
> 
> Hell no. If you know it statically, you can already just do the 
> "spin_lock_irq()"->"spin_unlock_irq()", and then you have the 
> _unconditional_ sti.

I meant they don't care about any other flags. Of course you need
a test + conditional jump first to handle the nested lock case.

> Andi, one single bug is usually worth _months_ of peoples time and effort. 
> How many CPU cycles is that? 

I bet near all cases where restore_flags() are used to restore something
else than IF are actually bugs or performance issues of some sort

This doesn't include the context switch of course, but that one 
doesn't use restore_flags().

(I think I have a few legitimate cases of save_flags though. They probably
should be using a different macro for clarity.) 

-Andi

-
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/