arch/tile: handle CLONE_SETTLS in copy_thread(), not user space
authorChris Metcalf <cmetcalf@tilera.com>
Tue, 14 Dec 2010 20:57:49 +0000 (15:57 -0500)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 7 Jan 2011 21:58:33 +0000 (13:58 -0800)
commit108d7726b7508b8aefce1f91ba97e56842f47f74
tree1ec9d855445b424e4b805af71b96feacff31c928
parent3ee6c4cf578834e96653b821054cc7fa7246affc
arch/tile: handle CLONE_SETTLS in copy_thread(), not user space

commit bc4cf2bb271b2d557fc510426755da786fc985be upstream.

Previously we were just setting up the "tp" register in the
new task as started by clone() in libc.  However, this is not
quite right, since in principle a signal might be delivered to
the new task before it had its TLS set up.  (Of course, this race
window still exists for resetting the libc getpid() cached value
in the new task, in principle.  But in any case, we are now doing
this exactly the way all other architectures do it.)

This change is important for 2.6.37 since the tile glibc we will
be submitting upstream will not set TLS in user space any more,
so it will only work on a kernel that has this fix.  It should
also be taken for 2.6.36.x in the stable tree if possible.

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
arch/tile/kernel/process.c