<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/futex_compat.c, branch v2.6.33.10</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/kernel/futex_compat.c?h=v2.6.33.10</id>
<link rel='self' href='https://git.amat.us/linux/atom/kernel/futex_compat.c?h=v2.6.33.10'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2009-08-10T13:41:12Z</updated>
<entry>
<title>futex: Fix compat_futex to be same as futex for REQUEUE_PI</title>
<updated>2009-08-10T13:41:12Z</updated>
<author>
<name>Dinakar Guniguntala</name>
<email>dino@in.ibm.com</email>
</author>
<published>2009-08-10T13:01:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4dc88029fd916b860ef063c40180aa604ce93494'/>
<id>urn:sha1:4dc88029fd916b860ef063c40180aa604ce93494</id>
<content type='text'>
Need to add the REQUEUE_PI checks to the compat_sys_futex API
as well to ensure 32 bit requeue's work fine on a 64 bit
system. Patch is against latest tip

Signed-off-by: Dinakar Guniguntala &lt;dino@in.ibm.com&gt;
Cc: Darren Hart &lt;dvhltc@us.ibm.com&gt;
LKML-Reference: &lt;20090810130142.GA23619@in.ibm.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>CRED: Use RCU to access another task's creds and to release a task's own creds</title>
<updated>2008-11-13T23:39:19Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2008-11-13T23:39:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c69e8d9c01db2adc503464993c358901c9af9de4'/>
<id>urn:sha1:c69e8d9c01db2adc503464993c358901c9af9de4</id>
<content type='text'>
Use RCU to access another task's creds and to release a task's own creds.
This means that it will be possible for the credentials of a task to be
replaced without another task (a) requiring a full lock to read them, and (b)
seeing deallocated memory.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
</content>
</entry>
<entry>
<title>CRED: Separate task security context from task_struct</title>
<updated>2008-11-13T23:39:16Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2008-11-13T23:39:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b6dff3ec5e116e3af6f537d4caedcad6b9e5082a'/>
<id>urn:sha1:b6dff3ec5e116e3af6f537d4caedcad6b9e5082a</id>
<content type='text'>
Separate the task security context from task_struct.  At this point, the
security data is temporarily embedded in the task_struct with two pointers
pointing to it.

Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
entry.S via asm-offsets.

With comment fixes Signed-off-by: Marc Dionne &lt;marc.c.dionne@gmail.com&gt;

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
</content>
</entry>
<entry>
<title>CRED: Wrap task credential accesses in the core kernel</title>
<updated>2008-11-13T23:39:12Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2008-11-13T23:39:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=76aac0e9a17742e60d408be1a706e9aaad370891'/>
<id>urn:sha1:76aac0e9a17742e60d408be1a706e9aaad370891</id>
<content type='text'>
Wrap access to task credentials so that they can be separated more easily from
the task_struct during the introduction of COW creds.

Change most current-&gt;(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

Change some task-&gt;e?[ug]id to task_e?[ug]id().  In some places it makes more
sense to use RCU directly rather than a convenient wrapper; these will be
addressed by later patches.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: linux-audit@redhat.com
Cc: containers@lists.linux-foundation.org
Cc: linux-mm@kvack.org
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
</content>
</entry>
<entry>
<title>futex_compat __user annotation</title>
<updated>2008-03-30T21:18:41Z</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2008-03-29T03:07:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8481664d373e7e2cea3ea0c2d7a06c9e939b19ee'/>
<id>urn:sha1:8481664d373e7e2cea3ea0c2d7a06c9e939b19ee</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>futex: runtime enable pi and robust functionality</title>
<updated>2008-02-24T01:12:15Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-02-23T23:23:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a0c1e9073ef7428a14309cba010633a6cd6719ea'/>
<id>urn:sha1:a0c1e9073ef7428a14309cba010633a6cd6719ea</id>
<content type='text'>
Not all architectures implement futex_atomic_cmpxchg_inatomic().  The default
implementation returns -ENOSYS, which is currently not handled inside of the
futex guts.

Futex PI calls and robust list exits with a held futex result in an endless
loop in the futex code on architectures which have no support.

Fixing up every place where futex_atomic_cmpxchg_inatomic() is called would
add a fair amount of extra if/else constructs to the already complex code.  It
is also not possible to disable the robust feature before user space tries to
register robust lists.

Compile time disabling is not a good idea either, as there are already
architectures with runtime detection of futex_atomic_cmpxchg_inatomic support.

Detect the functionality at runtime instead by calling
cmpxchg_futex_value_locked() with a NULL pointer from the futex initialization
code.  This is guaranteed to fail, but the call of
futex_atomic_cmpxchg_inatomic() happens with pagefaults disabled.

On architectures, which use the asm-generic implementation or have a runtime
CPU feature detection, a -ENOSYS return value disables the PI/robust features.

On architectures with a working implementation the call returns -EFAULT and
the PI/robust features are enabled.

The relevant syscalls return -ENOSYS and the robust list exit code is blocked,
when the detection fails.

Fixes http://lkml.org/lkml/2008/2/11/149
Originally reported by: Lennart Buytenhek

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Lennert Buytenhek &lt;buytenh@wantstofly.org&gt;
Cc: Riku Voipio &lt;riku.voipio@movial.fi&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>hrtimer: check relative timeouts for overflow</title>
<updated>2008-02-14T21:08:30Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-02-13T08:20:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5a7780e725d1bb4c3094fcc12f1c5c5faea1e988'/>
<id>urn:sha1:5a7780e725d1bb4c3094fcc12f1c5c5faea1e988</id>
<content type='text'>
Various user space callers ask for relative timeouts. While we fixed
that overflow issue in hrtimer_start(), the sites which convert
relative user space values to absolute timeouts themself were uncovered.

Instead of putting overflow checks into each place add a function
which does the sanity checking and convert all affected callers to use
it.

Thanks to Frans Pop, who reported the problem and tested the fixes.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Tested-by: Frans Pop &lt;elendil@planet.nl&gt;

</content>
</entry>
<entry>
<title>futex: Add bitset conditional wait/wakeup functionality</title>
<updated>2008-02-01T16:45:14Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-02-01T16:45:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=cd689985cf49f6ff5c8eddc48d98b9d581d9475d'/>
<id>urn:sha1:cd689985cf49f6ff5c8eddc48d98b9d581d9475d</id>
<content type='text'>
To allow the implementation of optimized rw-locks in user space, glibc
needs a possibility to select waiters for wakeup depending on a bitset
mask.

This requires two new futex OPs: FUTEX_WAIT_BITS and FUTEX_WAKE_BITS
These OPs are basically the same as FUTEX_WAIT and FUTEX_WAKE plus an
additional argument - a bitset. Further the FUTEX_WAIT_BITS OP is
expecting an absolute timeout value instead of the relative one, which
is used for the FUTEX_WAIT OP.

FUTEX_WAIT_BITS calls into the kernel with a bitset. The bitset is
stored in the futex_q structure, which is used to enqueue the waiter
into the hashed futex waitqueue.

FUTEX_WAKE_BITS also calls into the kernel with a bitset. The wakeup
function logically ANDs the bitset with the bitset stored in each
waiters futex_q structure. If the result is zero (i.e. none of the set
bits in the bitsets is matching), then the waiter is not woken up. If
the result is not zero (i.e. one of the set bits in the bitsets is
matching), then the waiter is woken.

The bitset provided by the caller must be non zero. In case the
provided bitset is zero the kernel returns EINVAL.

Internaly the new OPs are only extensions to the existing FUTEX_WAIT
and FUTEX_WAKE functions. The existing OPs hand a bitset with all bits
set into the futex_wait() and futex_wake() functions.

Signed-off-by: Thomas Gleixner &lt;tgxl@linutronix.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>[FUTEX] Fix address computation in compat code.</title>
<updated>2007-11-10T00:13:08Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2007-11-07T05:13:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1'/>
<id>urn:sha1:3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1</id>
<content type='text'>
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:

	(void __user *)entry + futex_offset

'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').

Things explode if the 32-bit sign bit is set in futex_offset.

Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.

This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().

Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.

Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.

Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():

1) load from address '0xfffffffff7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
   for address '0xf7f16bd8' which succeeds
3) goto #1

I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Uninline find_task_by_xxx set of functions</title>
<updated>2007-10-19T18:53:40Z</updated>
<author>
<name>Pavel Emelyanov</name>
<email>xemul@openvz.org</email>
</author>
<published>2007-10-19T06:40:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=228ebcbe634a30aec35132ea4375721bcc41bec0'/>
<id>urn:sha1:228ebcbe634a30aec35132ea4375721bcc41bec0</id>
<content type='text'>
The find_task_by_something is a set of macros are used to find task by pid
depending on what kind of pid is proposed - global or virtual one.  All of
them are wrappers above the most generic one - find_task_by_pid_type_ns() -
and just substitute some args for it.

It turned out, that dereferencing the current-&gt;nsproxy-&gt;pid_ns construction
and pushing one more argument on the stack inline cause kernel text size to
grow.

This patch moves all this stuff out-of-line into kernel/pid.c.  Together
with the next patch it saves a bit less than 400 bytes from the .text
section.

Signed-off-by: Pavel Emelyanov &lt;xemul@openvz.org&gt;
Cc: Sukadev Bhattiprolu &lt;sukadev@us.ibm.com&gt;
Cc: Oleg Nesterov &lt;oleg@tv-sign.ru&gt;
Cc: Paul Menage &lt;menage@google.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
