Re: [OOPS] 2.5.63 - NULL pointer dereference in loop device

[Jonah Sherman <jsherman@stuy.edu>]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Tue, Feb 25, 2003 at 09:15:56PM +0000, Hugh Dickins wrote:
> If you "losetup /dev/loop0 /dev/hdN", then it's LO_FLAGS_BH_REMAP
> and doesn't even call bio_copy: it doesn't copy bio or buffers or

It appears this way if you just look at none_status, but you didn't look
at loop_init_xfer().  Notice that it doesn't call xfer->init unless
type != 0, so that flag is infact never set.

> pages (unless you have highmem, which you don't mention: then its
> pointless wasteful blk_queue_bounce might cause trouble), it's a
> straight route through to disk, which should be using mempools
> to complete i/o even if the rest of the system is out of memory.

I'm not using highmem.

> Of course the loop driver is wrong to ignore NULL return from bio_copy
> (if you used losetup -e), and there's a lot of unnecessary allocation
> and copying and a lot of opportunity for deadlock, for which I have
> some perpetually unfinished patches.
> 
> But the loop to disk is relatively straightforward, pdflush should
> take care of the dirty pages Andrew worries about (though in writing
> to blockdev when there's highmem, pdflush may kick in too late); and
> I couldn't even reproduce your oops using "-e xor".
> 
> Can you shed more light on how to reproduce this?

The block dev it is being used on must be larger than your RAM.  I don't
have any swap on this machine, so I don't know if it must be bigger than
that too.  Maybe disabling swap before testing this oops will make it
work?

In any case, the patch sent by Andrew Morton fixed this bug.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]