linux-kernel - ticket spin locks vs. interrupt re-enabling during spin loops

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>] [day] [month] [year] [list]

Message-Id: <4F106A4A020000780006C90E@nat28.tlf.novell.com>
Date:	Fri, 13 Jan 2012 16:30:50 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	<npiggin@...nel.dk>
Cc:	<linux-kernel@...r.kernel.org>
Subject: ticket spin locks vs. interrupt re-enabling during spin loops

Hi Nick,

prior to your introduction of ticket locks on x86 interrupts would get
re-enabled in what was then called __raw_spin_lock_flags(). While I
realize that this is tricky with ticket locks, have you ever thought
through what it would take to implement this correctly?

We had this working well in our Xen kernels up to 2.6.39, but the
changes to try_to_wake_up() in 3.0 uncovered a problem with the
original implementation, and so I'm now struggling with finding a
solution that can cover both this problem as well as to another
possible scenario I meanwhile thought of that would break with
the original code (an open coded spinning loop over spin_trylock()
continuing until success in a scenario similar to that in the new
try_to_wake_up()). A draft implementation that I had put
together today isn't working quite right yet (and hence I can't
quantify its performance impact at all).

One fundamental question of course is whether this really is worth
it at all, since re-enabling interrupts here inherently implies that
tickets may need to be dropped, and hence the fairness they are
intended to guarantee is being undermined. But keeping interrupts
frequently disabled for virtually indefinite periods of time (as can
happen in a CPU over-committed virtualized environment) is
certainly a problem that's worth considering solutions for.

Jan

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