This trivial patch causes the TLS to be cleared on execve (code is in flush_thread).
This is necessary to avoid ESRCH errors when set_thread_area is asked
to choose a free TLS entry after several nested execve's.
The LDT also has a similar problem, but it is less serious because the
LDT code doesn't scan for free entries. I'll probably send a patch to
fix this too, unless there is something important relying on this behavior.
diff --exclude-from=/home/ldb/src/linux-exclude -urNdp linux-2.5.45/arch/i386/kernel/process.c linux-2.5.45_ldb/arch/i386/kernel/process.c
--- linux-2.5.45/arch/i386/kernel/process.c 2002-10-12 06:21:02.000000000 +0200
+++ linux-2.5.45_ldb/arch/i386/kernel/process.c 2002-10-31 14:23:18.000000000 +0100
@@ -247,6 +247,7 @@ void flush_thread(void)
struct task_struct *tsk = current;
memset(tsk->thread.debugreg, 0, sizeof(unsigned long)*8);
+ memset(tsk->thread.tls_array, 0, sizeof(tsk->thread.tls_array));
/*
* Forget coprocessor state..
*/
Luca Barbieri wrote:
> This trivial patch causes the TLS to be cleared on execve (code is
> in flush_thread). This is necessary to avoid ESRCH errors when
> set_thread_area is asked to choose a free TLS entry after several
> nested execve's.
Ouch!
> The LDT also has a similar problem, but it is less serious because the
> LDT code doesn't scan for free entries. I'll probably send a patch to
> fix this too, unless there is something important relying on this behavior.
Ouch again! Does the LDT really not get released on execve? I am
using threading code which _does_ scan for free entries in the LDT -
using the lar instruction. I'd never stumbled across this, though.
I'll be glad of your patch.
-- Jamie