All of lore.kernel.org
 help / color / mirror / Atom feed
From: devzero@web.de
To: agk@redhat.com, breeves@redhat.com
Cc: dm-devel@redhat.com
Subject: bug in dm-loop? - was:Re: Re: device mapper integrated loops - and one more year !
Date: Sun, 21 Jan 2007 18:16:43 +0100	[thread overview]
Message-ID: <1574903375@web.de> (raw)

hello !

if these is the most recent versions of dm-loop patch (don`t actually know for sure, see my last mail):

http://kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-loop.patch
http://kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-add-loop.patch

then i may have found some bug, i`d like to report.

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@localhost ~ # ls -la /dev/mapper/loop0
brw------- 1 root root 252, 0 21. Jan 17:25 /dev/mapper/loop0

works !

hooray - great work !


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]
PREEMPT SMP 
Modules linked in: dm_loop ipv6 snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus pcnet32 i2c_piix4 i2c_core agpgart
CPU:    0
EIP:    0060:[<d097589c>]    Not tainted VLI
EFLAGS: 00010292   (2.6.20-rc5 #1)
EIP is at loop_setup_size+0x1c/0x1f0 [dm_loop]
eax: 00000000   ebx: cb3289c0   ecx: d097105c   edx: d0971020
esi: ffffffea   edi: 00000001   ebp: d0971020   esp: cad47e58
ds: 007b   es: 007b   ss: 0068
Process dmlosetup (pid: 1787, ti=cad46000 task=cfe13aa0 task.ti=cad46000)
Stack: c018ab46 00000008 cd08fbc0 c017a806 00000000 00000000 cfec9ee8 cfec9ec0 
       c018fcd3 cd4bc180 cacbe118 d097105c d0971020 cb3289c0 cb3289c0 ffffffea 
       00000001 d0971020 d0975bd3 d0978181 d09761b5 cb3289f8 cb3280c0 d0971020 
Call Trace:
 [<c018ab46>] dput+0x86/0x140
 [<c017a806>] __fput+0xf6/0x170
 [<c018fcd3>] mntput_no_expire+0x13/0x70
 [<d0975bd3>] loop_ctr+0xd3/0x170 [dm_loop]
 [<c049016b>] dm_table_add_target+0x12b/0x1e0
 [<c04928c0>] populate_table+0x80/0xe0
 [<c049297e>] table_load+0x5e/0x110
 [<c0492920>] table_load+0x0/0x110
 [<c04930db>] ctl_ioctl+0xcb/0x130
 [<c0534ebc>] __up+0x1c/0x20
 [<c018595a>] do_ioctl+0x6a/0xa0
 [<c0185b1e>] vfs_ioctl+0x5e/0x1d0
 [<c0185ccd>] sys_ioctl+0x3d/0x70
 [<c0103252>] sysenter_past_esp+0x5f/0x85
 =======================
Code: d0 e8 f9 19 7b ef eb b3 8d b4 26 00 00 00 00 55 57 56 53 83 ec 38 89 44 24 34 89 54 24 30 89 4c 24 2c 8b 40 04 8b 80 8c 00 00 00 <8b> 18 8b 4b 44 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 89 
EIP: [<d097589c>] loop_setup_size+0x1c/0x1f0 [dm_loop] SS:ESP 0068:cad47e58
 
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.


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...." !?

regards
roland



> -----Ursprüngliche Nachricht-----
> Von: devzero@web.de
> Gesendet: 20.01.07 15:57:23
> An: breeves@redhat.com
> CC: dm-devel@redhat.com
> Betreff: Re: Re: device mapper integrated loops - and one more year !


> Hello Bryn, 
> 
> 
> >I'll see if we can get a revised version of the current patch for wider
> >testing in the next couple of weeks - let me know if you would be
> >interested in trying this out.
> 
> not sure if i sent a reply to this or have missed this -  but, yes - i`m still interested very much in using dm-loop !
> 
> is there anything new with this?
> do i have to expect issues with files >2gb ? (i need to loopback mount dvd iso-images)
> 
> is there a download url for the latest dm-loop patch so i can do some tests and report feedback ?
> 
> i couldn`t find it at http://sources.redhat.com/cgi-bin/cvsweb.cgi/device-mapper/?cvsroot=dm  and i`m not sure if i should take that one from http://kernel.org/pub/linux/kernel/people/agk/patches/2.6/
> 
> TIA
> roland
> 
> 
> 
> > Hello !
> > 
> > after desparately seeking for a solution to have more than 256 loop
> > devices (for a huge cd-rom server), i have recently come across
> > dm-loop, which looks very promising (to replace loop.c)
> > 
> > can i have more than 256 devices which this?
> 
> Hi Roland,
> 
> Yes, dm-loop will support as many loop devices as device-mapper can allow.
> 
> > our cd-rom server is going to have more than 256 iso-images soon and
> > i need to upgrade to a more recent OS, anyway, so this won`t be a 
> > problem that dm-loop is so brand new.
> > 
> > but - any timeline for dm-loop mainline inclusion ?
> > 
> > should i wait for 2.6.19 or 2.6.20 ?
> 
> There isn't a fixed timeline. We are currently working to improve the
> lookup code - the prototype patch uses a linear search which doesn't
> scale well for large/fragmented image files. I have some tests running
> at the moment and we hope to have something soon - the results so far
> are good, it's just a case of selecting between a couple of different
> methods.
> 
> The changes dm-loop requires in device-mapper core are pretty minor and
> have already been merged in 2.6.19, so it's just the dm-loop patch
> itself remaining.
> 
> > is it already useable with less recent kernels, i.e. can i download
> > dm-loop patch and recent dmsetup tool and use with older kernel ?
> 
> This should work fine - there are a couple of known issues with the
> existing patch, but unless you are using large images (>2G), or have a
> severely fragmented filesystem you shouldn't run into these.
> 
> I'll see if we can get a revised version of the current patch for wider
> testing in the next couple of weeks - let me know if you would be
> interested in trying this out.
> 
> Thanks,
> 
> Bryn.


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

             reply	other threads:[~2007-01-21 17:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21 17:16 devzero [this message]
2007-01-22 10:00 ` bug in dm-loop? - was:Re: Re: device mapper integrated loops - and one more year ! Bryn M. Reeves
2007-01-22 22:00   ` roland
2007-01-22 22:10     ` Bryn M. Reeves
2007-01-22 22:42       ` roland
2007-01-22 23:20         ` Bryn M. Reeves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1574903375@web.de \
    --to=devzero@web.de \
    --cc=agk@redhat.com \
    --cc=breeves@redhat.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.