Messages in this thread | | | Date | Tue, 22 Aug 2006 21:57:04 +0400 | From | Oleg Nesterov <> | Subject | Re: [PATCH] sys_ioprio_set: don't disable irqs |
| |
On 08/21, Andrew Morton wrote: > > On Mon, 21 Aug 2006 00:50:34 +0400 > Oleg Nesterov <oleg@tv-sign.ru> wrote: > > > Question: why do we need to disable irqs in exit_io_context() ? > > iirc it was to prevent IRQ-context code from getting a hold on > current->io_context and then playing around with it while it's getting > freed. > > In practice, a preempt_disable() there would probably suffice (ie: if this > CPU is running an ISR, it won't be running exit_io_context as well). But > local_irq_disable() is clearer, albeit more expensive.
Looks like my understanding of block I/O is even less than nothing :(
irq_disable() can't prevent from IRQ-context code playing with our io_context on other CPUs. But this doesn't matter, we are only changing ioc->task.
What does matter, we are clearing the pointer to it: task_struct->io_context, and IRQ should not look at it, no?
Or... Do you mean it is possible to submit I/O from IRQ on behalf of current ????? In that case current_io_context() will re-instantiate ->io_context after irq_enable(). What is exit_io_context() for then? It is only called from do_exit() when we know the task won't start IO.
(please don't beat a newbie)
> > Why do we need ->alloc_lock to clear io_context->task ? > > To prevent races against elv_unregister(), I guess.
elv_unregister() takes task_lock(), should see ->io_context == NULL.
Oleg.
- 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/
| |