Re: [BUG] loop.c oopses

[Jens Axboe]

On Tue, Jul 16 2002, Jari Ruusu wrote:
> Jens Axboe wrote:
> > On Tue, Jul 16 2002, Rik van Riel wrote:
> > > On Tue, 16 Jul 2002, Jens Axboe wrote:
> > > > On Tue, Jul 16 2002, Rik van Riel wrote:
> > > > Given the finite size of the pool and the possibly infinite stacking
> > > > level, yes that is possible. You may just run out of loop minors before
> > > > this happens [1]. Also note that you need more than a simple remapping,
> > > > crypto setup for instance.
> > >
> > > Or maybe SMP, with multiple CPUs submitting requests at the
> > > same time ?
> > 
> > It would still require a totally pathetic loop setup. More than 2 or 3
> > stacked loop devices that are not using remapping would crawl
> 
> remapping?
> 
> > performance wise. Now make that eg 32 "indirections" (allocations and
> > copies on _each_ i/o), and I think you'll find that the system would be
> > impossible to use long before this theoretical dead lock would be hit.
> 
> Jens,
> 
> Your remapping code has _never_ worked. This is because your remapping is
> supposedly enabled in none_status(), but init hook of type 0 transfer is
> never called (check the code in loop_init_xfer). And, even if were enabled,
> you would quickly notice that lo->lo_pending count is never decremented in
> your 'remap' code.

That might be so for the 2.5 code base, I know for a fact that it worked
when it was implemented in 2.4. Maybe with the same lo_pending bug, I
dunno.

> The patch below fixes that remap issue, plus uncounted number of other loop
> issues. For example, device backed loops use pre-allocated pages for zero VM
> pressure.
> 
> Too bad you seem to be filtering my emails.

Please calm down. You sent me two mails that I haven't gotten around to
yet, excuse me for not making loop my top priority.

That said, please do split up the patches as Andrew/wli suggested. For
the 2.5 one I'd be inclined to just take it as-is, but the 2.4 patch
definitely needs to be split.

-- 
Jens Axboe