linux-kernel - FW: sched_setaffinity not working with kernel 2.6.32.15

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <COL124-W1850C30E9FF3BFB06DF5BFD6C20@phx.gbl>
Date:	Sun, 20 Jun 2010 22:10:18 +0300
From:	Αλέξανδρος Παπαδογιαννάκης 
	<psxlover@...mail.com>
To:	<linux-kernel@...r.kernel.org>
Subject: FW: sched_setaffinity not working with kernel 2.6.32.15

From: psxlover@...mail.com
To: mingo@...e.hu; peterz@...radead.org
Subject:
 sched_setaffinity not working with kernel 2.6.32.15
Date: Sun, 20 
Jun 2010 17:14:12 +0300

.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}

On kernel 2.6.32.15 after I execute sched_setaffinity even
though 
sched_getaffinity returns the right cpus the threads
of my program 
are running on different cpus.

  First time I came across the bug
 was on a PC on my unive-
rsity which had just been updated to Debian
 'squeeze'. I was
using a library calles hwloc to get information 
about the to-
pology of the system and bind threads to cpus. The 
binding
while it wasn't returning any error wasn't working (I used 
top
to check which cpus where being used). After contacting 
with 
the developers of hwloc they suggested that the pro-
blem is either 
in the kernel or in glibc.
  I made a virtual machine on my pc using 
the latest Debian
'squeeze' and the problem was there. So I tried an 
older
kernel I found in the Synaptic Package Manager and my pro-
gram
 was working fine. So the problem was in the kernel. I
e-mailed hwloc
 mailing list again and he suggested I tried
the vanilla kernels and 
use git bisect to find where the problem
started.
  With 2.6.34 
and 2.6.33.5 I had no problem but with 2.6.32.15
sched_setaffinity 
wasn't working. I used git bisect and in the 
end I got this:

c6fc81afa2d7ef2f775e48672693d8a0a8a7325d
 is the first bad commit
commit 
c6fc81afa2d7ef2f775e48672693d8a0a8a7325d
Author: John Wright 
<john.wright@...com>
Date:   Tue Apr 13 16:55:37 2010 -0600

 sched: Fix a race between ttwu() and migrate_task()

Based on commit e2912009fb7b715728311b0d8fe327a1432b3f79 upstream, but

 done differently as this issue is not present in .33 or .34 kernels due

 to rework in this area.

    If a task is in the TASK_WAITING
 state, then try_to_wake_up() is working
    on it, and it will place
 it on the correct cpu.

    This commit ensures that neither 
migrate_task() nor __migrate_task()
    calls set_task_cpu(p) while p
 is in the TASK_WAKING state.  Otherwise,
    there could be two 
concurrent calls to set_task_cpu(p), resulting in
    the task's 
cfs_rq being inconsistent with its cpu.

    Signed-off-by: 
John Wright <john.wright@...com>
    Cc: Ingo Molnar 
<mingo@...e.hu>
    Cc: Peter Zijlstra 
<peterz@...radead.org>
    Signed-off-by: Greg Kroah-Hartman 
<gregkh@...e.de>

:040000 040000 
a9d18950d8edddb761c0266706f671f0e9a006fe 
2c3a7d7d5e616ecc276b4e93f4b6e5162a9382c8 M    kernel

  I've 
attached a simple program that binds a few threads on
the first cpu. 
With 2.6.32.15 when I run it I can see with 
System Monitor that more
 than one cpu is being used by the
threads.

--------------------------
Alexandros
 Papadogiannakis 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
View attachment "test.c" of type "text/x-csrc" (2148 bytes)