linux-toradex.git/kernel/user.c, branch imx-android-r10.4

sched: Remove a stale comment

2010-05-10T06:48:39+00:00

This comment should have been removed together with uids_mutex
when removing user sched.

Signed-off-by: Li Zefan 
Cc: Peter Zijlstra 
Cc: Dhaval Giani 
LKML-Reference: <4BE77C6B.5010402@cn.fujitsu.com>
Signed-off-by: Ingo Molnar

sched: Remove remaining USER_SCHED code

2010-04-02T18:12:00+00:00

This is left over from commit 7c9414385e ("sched: Remove USER_SCHED"")

Signed-off-by: Li Zefan 
Acked-by: Dhaval Giani 
Signed-off-by: Peter Zijlstra 
Cc: David Howells 
LKML-Reference: <4BA9A05F.7010407@cn.fujitsu.com>
Signed-off-by: Ingo Molnar

sched: Remove some dead code

2010-03-16T10:05:44+00:00

This was left over from "7c9414385e sched: Remove USER_SCHED"

Signed-off-by: Dan Carpenter 
Acked-by: Dhaval Giani 
Cc: Kay Sievers 
Cc: Greg Kroah-Hartman 
LKML-Reference: <20100315082148.GD18181@bicker>
Signed-off-by: Ingo Molnar

sched: Remove USER_SCHED

2010-01-21T12:40:18+00:00

Remove the USER_SCHED feature. It has been scheduled to be removed in
2.6.34 as per http://marc.info/?l=linux-kernel&m=125728479022976&w=2

Signed-off-by: Dhaval Giani 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1263990378.24844.3.camel@localhost>
Signed-off-by: Ingo Molnar

uids: Prevent tear down race

2009-11-02T15:02:39+00:00

Ingo triggered the following warning:

WARNING: at lib/debugobjects.c:255 debug_print_object+0x42/0x50()
Hardware name: System Product Name
ODEBUG: init active object type: timer_list
Modules linked in:
Pid: 2619, comm: dmesg Tainted: G        W  2.6.32-rc5-tip+ #5298
Call Trace:
 [<81035443>] warn_slowpath_common+0x6a/0x81
 [<8120e483>] ? debug_print_object+0x42/0x50
 [<81035498>] warn_slowpath_fmt+0x29/0x2c
 [<8120e483>] debug_print_object+0x42/0x50
 [<8120ec2a>] __debug_object_init+0x279/0x2d7
 [<8120ecb3>] debug_object_init+0x13/0x18
 [<810409d2>] init_timer_key+0x17/0x6f
 [<81041526>] free_uid+0x50/0x6c
 [<8104ed2d>] put_cred_rcu+0x61/0x72
 [<81067fac>] rcu_do_batch+0x70/0x121

debugobjects warns about an enqueued timer being initialized. If
CONFIG_USER_SCHED=y the user management code uses delayed work to
remove the user from the hash table and tear down the sysfs objects.

free_uid is called from RCU and initializes/schedules delayed work if
the usage count of the user_struct is 0. The init/schedule happens
outside of the uidhash_lock protected region which allows a concurrent
caller of find_user() to reference the about to be destroyed
user_struct w/o preventing the work from being scheduled. If the next
free_uid call happens before the work timer expired then the active
timer is initialized and the work scheduled again.

The race was introduced in commit 5cb350ba (sched: group scheduling,
sysfs tunables) and made more prominent by commit 3959214f (sched:
delayed cleanup of user_struct)

Move the init/schedule_delayed_work inside of the uidhash_lock
protected region to prevent the race.

Signed-off-by: Thomas Gleixner 
Acked-by: Dhaval Giani 
Cc: Paul E. McKenney 
Cc: Kay Sievers 
Cc: stable@kernel.org

sched: delayed cleanup of user_struct

2009-06-16T04:30:23+00:00

During bootup performance tracing we see repeated occurrences of
/sys/kernel/uid/* events for the same uid, leading to a,
in this case, rather pointless userspace processing for the
same uid over and over.

This is usually caused by tools which change their uid to "nobody",
to run without privileges to read data supplied by untrusted users.

This change delays the execution of the (already existing) scheduled
work, to cleanup the uid after one second, so the allocated and announced
uid can possibly be re-used by another process.

This is the current behavior, where almost every invocation of a
binary, which changes the uid, creates two events:
  $ read START < /sys/kernel/uevent_seqnum; \
  for i in `seq 100`; do su --shell=/bin/true bin; done; \
  read END < /sys/kernel/uevent_seqnum; \
  echo $(($END - $START))
  178

With the delayed cleanup, we get only two events, and userspace finishes
a bit faster too:
  $ read START < /sys/kernel/uevent_seqnum; \
  for i in `seq 100`; do su --shell=/bin/true bin; done; \
  read END < /sys/kernel/uevent_seqnum; \
  echo $(($END - $START))
  1

Acked-by: Dhaval Giani 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'master' into next

2009-03-23T23:52:46+00:00

kernel/user.c: fix a memory leak when freeing up non-init usernamespaces users

2009-03-10T22:55:11+00:00

We were returning early in the sysfs directory cleanup function if the
user belonged to a non init usernamespace.  Due to this a lot of the
cleanup was not done and we were left with a leak.  Fix the leak.

Reported-by: Serge Hallyn 
Signed-off-by: Dhaval Giani 
Acked-by: Serge Hallyn 
Tested-by: Serge Hallyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sched: don't allow setuid to succeed if the user does not have rt bandwidth

2009-02-27T10:11:53+00:00

Impact: fix hung task with certain (non-default) rt-limit settings

Corey Hickey reported that on using setuid to change the uid of a
rt process, the process would be unkillable and not be running.
This is because there was no rt runtime for that user group. Add
in a check to see if a user can attach an rt task to its task group.
On failure, return EINVAL, which is also returned in
CONFIG_CGROUP_SCHED.

Reported-by: Corey Hickey 
Signed-off-by: Dhaval Giani 
Acked-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar

keys: distinguish per-uid keys in different namespaces

2009-02-27T01:35:06+00:00

per-uid keys were looked by uid only.  Use the user namespace
to distinguish the same uid in different namespaces.

This does not address key_permission.  So a task can for instance
try to join a keyring owned by the same uid in another namespace.
That will be handled by a separate patch.

Signed-off-by: Serge E. Hallyn 
Acked-by: David Howells 
Signed-off-by: James Morris