lkml.org 
[lkml]   [2002]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][RFC] task cpu affinity syscalls for 2.4-O(1)
On Mon, Apr 22, 2002 at 03:34:13PM -0400, Robert Love wrote:
>
> I have a request for comments:
>
> The locking is no good in this patch. set_cpus_allowed is not atomic
> and it is certainly not safe to hold a spinlock across a call to it.
> However, before we call set_cpus_allowed we need a valid reference to
> the task and assurance the task won't slip away out from under us.
>

Robert,

I don't have a suggestion for the locking yet, but rather a question
about the current code that you may be able to answer. At the end
of set_cpus_allowed(), there is this block of code:

init_MUTEX_LOCKED(&req.sem);
req.task = p;
list_add(&req.list, &rq->migration_queue);
task_rq_unlock(rq, &flags);
wake_up_process(rq->migration_thread);

down(&req.sem);

After releasing the runqueue lock, what prevents p from moving to
(and running on) another CPU via the load_balance() mechanism
before the migration thread is scheduled? I couldn't find anything
in the code to prevent this, and it looks like bad things would
happen if it did. Of course, this assumes we are not running in
the context of p while calling set_cpus_allowed() for p.

P.S. Thanks for porting O(1) to 2.4!
--
Mike
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.056 / U:3.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site