Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e5e5673f828623e58a401862b33173591faaeaff
Commit:     e5e5673f828623e58a401862b33173591faaeaff
Parent:     c71551ad309c46d9d2433a9b688491edbd10c806
Author:     Nathan Lynch <[EMAIL PROTECTED]>
AuthorDate: Wed Jan 10 23:15:28 2007 -0800
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Thu Jan 11 18:18:20 2007 -0800

    [PATCH] sched: tasks cannot run on cpus onlined after boot
    
    Commit 5c1e176781f43bc902a51e5832f789756bff911b ("sched: force /sbin/init
    off isolated cpus") sets init's cpus_allowed to a subset of cpu_online_map
    at boot time, which means that tasks won't be scheduled on cpus that are
    added to the system later.
    
    Make init's cpus_allowed a subset of cpu_possible_map instead.  This should
    still preserve the behavior that Nick's change intended.
    
    Thanks to Giuliano Pochini for reporting this and testing the fix:
    
    http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029397.html
    
    Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
    Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
    Cc: Nick Piggin <[EMAIL PROTECTED]>
    Cc: <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 kernel/sched.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 3df33da..cca93cc 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -6865,7 +6865,7 @@ void __init sched_init_smp(void)
 
        lock_cpu_hotplug();
        arch_init_sched_domains(&cpu_online_map);
-       cpus_andnot(non_isolated_cpus, cpu_online_map, cpu_isolated_map);
+       cpus_andnot(non_isolated_cpus, cpu_possible_map, cpu_isolated_map);
        if (cpus_empty(non_isolated_cpus))
                cpu_set(smp_processor_id(), non_isolated_cpus);
        unlock_cpu_hotplug();
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to