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/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:35 EST