[dm-devel] Re: bug in dm-loop? - was:Re: Re: device mapper integrated loops - and one more year !

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

devzero at web.de wrote:
> 
> i was doing some testing of dm-loop with latest dmsetup on a 2.6.20-rc5 system.
> 
> i did some basic test, which seems to work ok.
> 
> i can now map a file to become /dev/mapper/loop0
> 
> dmlosetup loop0 test.img 
> 
> -> device-mapper: loop: Finalized extent map of 1232 bytes, 44 entries.
> 
> root at localhost ~ # ls -la /dev/mapper/loop0
> brw------- 1 root root 252, 0 21. Jan 17:25 /dev/mapper/loop0

Great! Am glad this much is working for you!

> 
> while fiddling around a little bit, i accidentally tried to map that file a second time - anyway, i would expect this is quite ok and should work.
> 
> dmlosetup loop1 test.img 
> 
> this bails out with the following error, leaving trace in dmesg:  
> 
> device-mapper: loop: file is already in use: /root/device-mapper/dmsetup/test.dat
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> d097589c
> *pde = 00000000
> Oops: 0000 [#1]

The dm-loop target only allows a file to be mapped once. That said, it
should just return the error, not oops the kernel!

This is fixed in my CVS copy of this patch - I'm attaching a patch that
you can apply on top of the one that you already have that includes this
fix plus a couple of other minor fixes/enhancements.

I'll also get the version on kernel.org updated - thanks for catching this!

> after this, if i do 
> dmlosetup -d loop1
> dmlosetup -d loop0
> 
> i cannot "rmmod dm-loop" , now telling me "device is in use", but it isn`t ! 
> 
> so, this looks like a bug to me, leaving dm-loop in an inconsitent state.

Unfortunately, after an oops in a kernel module you're pretty much
forced to reboot - the kernel terminates the code path that caused the
fault, leaving a hanging reference count on the module.

> furthermore, one question about naming conventions :
> 
> dmlosetup testloop1 test.dat
> dmlosetup: Could not parse loop_device testloop1
> Usage:
> 
> losetup [-d|-a] [-e encryption] [-o offset] [-f|loop_device] [file]
> 
> Couldn't process command line.
> 
> 
> so, it`s mandatory that loop_device needs to begin with "loop...." !?
> 

It is at the moment :) The current command line parameters try to be as
faithful as possible to the nomrmal losetup, where devices are normally
named as (/dev/)loopN. We can't exactly match that without disrupting
users of the regular loop driver though, so this should probably be relaxed.

Thanks for testing!

Bryn.





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFtItQ6YSQoMYUY94RAijWAJ47OJL21+0W3yiMqbq51k3EHAw0WACfaefN
PjSa8djCMZuyZ/gGyUAikp0=
=3bv3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dm-loop.fix_busy_image.patch
Type: text/x-patch
Size: 2834 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20070122/112b3644/attachment.bin>