linux-kernel - current_thread_info() vs task_thread

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

Message-ID: <1310988183.13765.56.camel@twins>
Date:	Mon, 18 Jul 2011 13:23:03 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	linux-arch@...r.kernel.org
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>
Subject: current_thread_info() vs task_thread_info(current)

Thomas just spend a lovely morning trying to make sense of a trace where
TIF_NEED_RESCHED wasn't set after resched_task() and magically appeared
after local_bh_enable().

What happened is that on that particular platform softirqs ran on a
separate stack, and current_thread_info() is relative to the stack
pointer.

The result is that current_thread_info() isn't the same as
task_thread_info(current), *surprise*!!

The immediate problem is of course that we can loose TIF flags when set
through current_thread_info() from IRQ/SoftIRQ context.

Now I was going to add a WARN() in x86_64's current_thread_info() to
catch all these, sadly x86_64's implementation isn't prone to this
particular issue, which means most people (kernel devs) will not be
affected (i386 is affected, but nobody sane uses that anymore).

Just to give an example, RCU uses set_need_resched(), set_need_resched()
uses current_thread_info(). The use in force_quiescent_state() is from
softirq afaict, the one in __rcu_pending() is from hardirq.

On such platforms as Thomas was playing on, the TIF bit will be lost,
since it will be set on the thread_info associated with some interrupt
stack, not the current process.

So how are we going to solve this? Naively I'd think that
current_thread_info() is short for task_thread_info(current), and thus
the platforms for where this isn't true are broken.

I mean, what use is the thread_info not of a thread?

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