Re: [PATCH]CPU hotplug breaks wake_up_new_task

From: Srivatsa Vaddagiri (vatsa_at_in.ibm.com)
Date: 05/31/05

  • Next message: Nick Piggin: "Re: [PATCH]CPU hotplug breaks wake_up_new_task"
    Date:	Tue, 31 May 2005 15:10:45 +0530
    To: Shaohua Li <shaohua.li@intel.com>
    
    

    On Tue, May 31, 2005 at 07:29:39AM +0000, Shaohua Li wrote:
    > Hi,
    > There is a race condition at wake_up_new_task at CPU hotplug case.
    > Say do_fork
    > copy_process (which sets new forked task's current cpu, cpu_allowed)
    > <-------- the new forked task's current cpu is offline
    > wake_up_new_task
    > wake_up_new_task will put the forked task into a dead cpu.

    This was noticed/fixed long back. Apparently somebody has reintroduced
    the bug. The simple fix for this race is:

    --- kernel/fork.c.org 2005-05-31 14:57:15.000000000 +0530
    +++ kernel/fork.c 2005-05-31 15:07:20.000000000 +0530
    @@ -1024,8 +1024,7 @@ static task_t *copy_process(unsigned lon
              * parent's CPU). This avoids alot of nasty races.
              */
             p->cpus_allowed = current->cpus_allowed;
    - if (unlikely(!cpu_isset(task_cpu(p), p->cpus_allowed)))
    - set_task_cpu(p, smp_processor_id());
    + set_task_cpu(p, smp_processor_id());
     
             /*
              * Check for pending SIGKILL! The new thread should not be allowed

    Could you test and check if it avoids whatever problem you are seeing?

    -- 
    Thanks and Regards,
    Srivatsa Vaddagiri,
    Linux Technology Center,
    IBM Software Labs,
    Bangalore, INDIA - 560017
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Nick Piggin: "Re: [PATCH]CPU hotplug breaks wake_up_new_task"

    Relevant Pages

    • Re: panic in RELENG_5 UMA - two new stack traces
      ... We definitely see that the bug is a race, ... there is one for race between incoming ARP reply and ... Does it look like fixing this bug may fix a lot of the ...
      (freebsd-stable)
    • Re: [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch
      ... and we should simply fix generic_file_direct_IO to avoid doing so. ... The race that we need to worry about is between background writeouts ... This is the same race that we have been discussing (background writer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Status of IEEE1394 vulnerability in 2.4
      ... I have yet to fix them. ... firmware in an external device. ... The other bug about allocating huge amounts of memory is just plain wrong, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] fix spurious OOM kills
      ... > early-oom failures in my queue (the VM bug was introduced sometime ... It solves one of the problems, but your fix is really the only complete ... And I mean christmas 2004. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2/2] sysfs: fix race condition around sd->s_dentry, take#2
      ... people actually seeing the race, ... and has not seen it with this patch in place. ... The other bug they were seeing even more often was the sysfs_readdir ... Is any fix for that problem being ...
      (Linux-Kernel)