On 2003.03.15 15:23 Zwane Mwaikambo wrote:
> On Sat, 15 Mar 2003, dan carpenter wrote:
>
> > > Apart from the schedule with the ide_lock held, what is that code actually
> > > doing?
> > >
> > > Zwane
> >
> > Hm... Good question. I have no idea what the while loop is for.
>
> I suppose the magik is in the comments;
>
> /* first null the handler for the drive and let any process
> * doing IO (on another CPU) run to (partial) completion
> * the lock prevents processing new requests */
>
Indeed. If you get there, the command in progress is hung.
To be able to restart the device, the old command needs to be
aborted. But that is an inherently racy undertaking.
Nominally, I just want to set HWGROUP(drive)->handler = NULL.
But there is a small chance, that there is actually (interrupt)
activity going on for the command, which would result in a new
entry in HWGROUP(drive)->handler popping up after it is cleared.
The loop as programmed significantly increases the odds that
the old command is really aborted.
It may not be elegant to schedule(1) with the lock taken, but it
does work.
However, my latest patch doesn't seem to be applied, since in my
version I have a set_current_state(TASK_INTERRUPTIBLE); before
the schedule.
Regards, Willem Riede.
-
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 : Sat Mar 15 2003 - 22:00:43 EST