On Sat, 3 Mar 2001, Jens Axboe wrote:
> On Sat, Mar 03 2001, Alexander Viro wrote:
> > > Look for the patch I posted yesterday (hint: just remove these two
> > > lines from loop_end_io_transfer)
> > >
> > > if (atomic_dec_and_test(&lo->lo_pending))
> > > up(&lo->lo_bh_mutex);
> >
> > Uhh... And what will compensate for atomic_inc() in loop_make_request() in
> > case of loop over block device?
>
> There is no atomic_inc() in loop_make_request, I moved it to
> count pending bh on the queue only. But hmm, we should not
> be able to remove it while it has bhs in flight. Ok, I'll
> rearrange this a bit again...
Notice that up() is triggered _only_ on the clr_fd() - until then
->lo_pending is at least 1. Lo_rundown is exactly that - mode when
we've already given that barrier up and just wait for the last
guy to up that semaphore while loop_thread queue is empty. Which
will make loop_thread terminate.
BTW, I think I see a possible problem. How about replacing
atomic_dec() in loop_thread with
if (atomic_dec_and_test(...))
break;
to handle the case where we have pending requests at the clr_fd time
and the last one happens to be in the queue?
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
