Bug 9779

It appears that this bug only happens when setting cpu_share=1 for _another_ user.

Here's a way to reproduce it also in a virtual machine (at least for me):
1. Create another user (I'm using "foo") or just use another one probably (e.g. "boinc")
2. sudo -u foo python -c 'while 1: i = 1' &
3. echo 1 | sudo tee /sys/kernel/uids/`id -u foo`/cpu_share

The gdb backtrace on the VirtualBox process then looks like the following. (I don't know if it's really useful)
(gdb) bt
#0  0xb7f86410 in __kernel_vsyscall ()
#1  0xb58f7311 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0xb79b2d23 in QEventLoop::processEvents (this=0x8312120, flags=4)
    at kernel/qeventloop_x11.cpp:291
#3  0xb7a286a8 in QEventLoop::enterLoop (this=0x8312120) at kernel/qeventloop.cpp:198
#4  0xb7a283a6 in QEventLoop::exec (this=0x8312120) at kernel/qeventloop.cpp:145
#5  0xb7a0eef7 in QApplication::exec (this=0xbf84bf90) at kernel/qapplication.cpp:2758
#6  0x08127e3f in ?? ()
#7  0xbf84bf90 in ?? ()
#8  0xbf84c074 in ?? ()
#9  0x00000000 in ?? ()

Can you send your kernel stacktrace? It should come out when the system crashes on the console.

I'm downloading and setting up virtual box now to try to reproduce it here. I do not see it happening on my test system.

Can you please send your .config as well?

* bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> wrote:

> The following command locks up my system:
> echo 1 | sudo tee /sys/kernel/uids/`id -u`/cpu_share
> 
> While I have not reproduced it for this command, it locked up my 
> system twice when trying it with the uid of my system user "boinc".

does the patch below fix it?

	Ingo

Subject: x86: patches/sched-user-share-fix.patch
From: Ingo Molnar <mingo@elte.hu>


Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/sched.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -268,7 +268,7 @@ struct task_group init_task_group = {
 # define INIT_TASK_GROUP_LOAD	NICE_0_LOAD
 #endif
 
-#define MIN_GROUP_SHARES	1
+#define MIN_GROUP_SHARES	2
 
 static int init_task_group_load = INIT_TASK_GROUP_LOAD;
 

please try the fix below instead.

-------------->
Subject: sched: group scheduler, set uid share fix
From: Ingo Molnar <mingo@elte.hu>

setting cpu share to 1 causes hangs, as reported in:

    http://bugzilla.kernel.org/show_bug.cgi?id=9779

as the default share is 1024, the values of 0 and 1 can indeed
cause problems. Limit it to 2 or higher values.

These values can only be set by the root user - but still it
makes sense to protect against nonsensical values.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/sched.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -7136,6 +7136,14 @@ static void set_se_shares(struct sched_e
 
 	spin_lock_irq(&rq->lock);
 
+	/*
+	 * A weight of 0 or 1 can cause arithmetics problems.
+	 * (The default weight is 1024 - so there's no practical
+	 *  limitation from this.)
+	 */
+	if (shares < 2)
+		shares = 2;
+
 	on_rq = se->on_rq;
 	if (on_rq)
 		dequeue_entity(cfs_rq, se, 0);

Created attachment 14531 [details]
fix for root-triggered /sys/kernel/uids hang

please try this attached patch instead.

ok, i will agree with that fix :-).

Do you want to try the other fix for sched-devel? (Using the macro?)

Ingo, this fix will work as it has been reported that setting the shares as 2 does not cause a hang.

> Ingo, this fix will work as it has been reported that setting the 
> shares as 2 does not cause a hang.

nitpick: testing the patch is still required, to make sure it's really 
fixed. I too see that that patch sets it to 2, but it's only fixed if 
testers confirm that the patch works :)

Fix got included in Linus' tree as commit c61935fd0e7f087a643827b4bf5ef646963c10fa.