linux-kernel - Re: _proxy_pda still makes linking modules fail

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:	Tue, 13 Mar 2007 20:04:46 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Marcin 'Qrczak' Kowalczyk <qrczak@....org.pl>,
	linux-kernel@...r.kernel.org
Subject: Re: _proxy_pda still makes linking modules fail

Rusty Russell writes:

> The ideal solution has always been to use __thread, but no architecture
> has yet managed it (I tried for i386, and it quickly caused unbearable
> pain).  On x86-64 that uses "%fs" on x86-64, not "%gs" as the kernel
> does, but I might try that if I feel particularly masochistic soon...

There is a fundamental problem with using __thread, which is that gcc
assumes that the addresses of __thread variables are constant within
one thread, and that therefore it can cache the result of address
calculations.  However, with preempt, threads in the kernel can't rely
on staying on one cpu, and therefore the addresses of per-cpu
variables can change.  There appears to be no way to tell gcc to drop
all cached __thread variable address calculations at a given point
(e.g. when enabling or disabling preemption).  That is basically why I
gave up on using __thread for per-cpu variables on powerpc.

We could use __thread for per-task variables quite naturally.  There
doesn't seem to be much point, though, since we already have a way to
do per-task variables - it's called struct task_struct. :-/

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