2.6.18-rc5-mm1 - bd_claim_by_disk oops

2.6.18-rc5-mm1 - bd_claim_by_disk oops

[John Stoffel]

I got the following on 2.6.18-rc5-mm1 when trying to lvextend a test
logical volume that I had just created.  This came about because I
have been trying to expand some LVs on my system, which are based on a
VG ontop of an MD mirror pair.  It's an SMP box too if that means
anything.  

device-mapper: table: 253:3: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: table: 253:3: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: table: 253:2: linear: dm-linear: Device lookup failed
device-mapper: ioctl: error adding target to table
BUG: unable to handle kernel paging request at virtual address
6f72702e
 printing eip:
c018505b
*pde = 00000000
Oops: 0000 [#1]
4K_STACKS SMP 
last sysfs file: /block/dm-2/removable
Modules linked in: rfcomm l2cap bluetooth sbp2 i2c_piix4 ohci1394
evdev snd_ens1
371 snd_rawmidi snd_ac97_codec snd_ac97_bus i2c_core snd_pcm snd_timer
snd sound
core snd_page_alloc ieee1394 uhci_hcd ohci_hcd usb_storage
CPU:    1
EIP:    0060:[<c018505b>]    Not tainted VLI
EFLAGS: 00010292   (2.6.18-rc5-mm1 #1) 
EIP is at bd_claim_by_disk+0x9b/0x1c0
eax: e6622ba0   ebx: 6f72702e   ecx: c16decbc   edx: 6f72702e
esi: 00000000   edi: e4a11220   ebp: c16dec80   esp: c62e1ca4
ds: 007b   es: 007b   ss: 0068
Process lvextend (pid: 2926, ti=c62e1000 task=dccfa580
task.ti=c62e1000)
Stack: c047cefa c16dec8c c16dec80 e3e31920 d1130e80 c16dec80 c035f9c8
fffffff4 
       e128d160 00900000 e3e31920 c036040c f0a5915c c042bf66 c62e1d50
c62e1d4c 
       c0500f0c e128d160 f0a5915c f0a1b080 e128d0c0 00000000 00000001
c0500f0c 
Call Trace:
 [<c035f9c8>] open_dev+0x48/0x80
 [<c036040c>] dm_get_device+0x20c/0x480
 [<c0243537>] vsscanf+0x447/0x490
 [<c0360ca9>] linear_ctr+0x99/0x110
 [<c035ff0d>] dm_table_add_target+0x17d/0x2e0
 [<c0361e6a>] table_load+0xba/0x1d0
 [<c0362b9d>] ctl_ioctl+0x22d/0x2a0
 [<c028b594>] n_tty_receive_buf+0x324/0x1070
 [<c0361db0>] table_load+0x0/0x1d0
 [<c016c2d8>] do_ioctl+0x78/0x90
 [<c016c34c>] vfs_ioctl+0x5c/0x2b0
 [<c016c5dd>] sys_ioctl+0x3d/0x70
 [<c0102f33>] syscall_call+0x7/0xb
 =======================
Code: 3c 8b 13 0f 18 02 90 8d 4d 3c 39 cb 0f 84 24 01 00 00 8b 47 0c
3b 43 0c 75
 0f e9 ab 00 00 00 90 3b 43 0c 0f 84 a1 00 00 00 89 d3 <8b> 12 0f 18
02 90 39 cb
 75 eb e8 d6 a9 0b 00 85 c0 89 47 0c 0f 
EIP: [<c018505b>] bd_claim_by_disk+0x9b/0x1c0 SS:ESP 0068:c62e1ca4
 

Re: 2.6.18-rc5-mm1 - bd_claim_by_disk oops

[John Stoffel]

John> I got the following on 2.6.18-rc5-mm1 when trying to lvextend a
John> test logical volume that I had just created.  This came about
John> because I have been trying to expand some LVs on my system,
John> which are based on a VG ontop of an MD mirror pair.  It's an SMP
John> box too if that means anything.

John> device-mapper: table: 253:3: linear: dm-linear: Device lookup failed
John> device-mapper: ioctl: error adding target to table
John> device-mapper: table: 253:3: linear: dm-linear: Device lookup failed
John> device-mapper: ioctl: error adding target to table
John> device-mapper: table: 253:2: linear: dm-linear: Device lookup failed
John> device-mapper: ioctl: error adding target to table

There error I got was:

  # lvextend -v -L +1g /dev/data_vg/home_lv
    Finding volume group data_vg
    Archiving volume group "data_vg" metadata (seqno 16).
    Extending logical volume home_lv to 52.00 GB
    Creating volume group backup "/etc/lvm/backup/data_vg" (seqno 17).
    Found volume group "data_vg"
    Found volume group "data_vg"
    Loading data_vg-home_lv table
    device-mapper: reload ioctl failed: Invalid argument
    Failed to suspend home_lv

I've found a solution to this problem of NOT being able to use
'lvextend' on some LVM2 Logical Volumes (LV).  Basically, I had to
apply the following patch to 2.6.18-rc6-mm2 to get it to work
properly.  I don't know why this wasn't reported here to the kernel
people.

Thanks,
John

----------------------------------------------------------------------

If a matching bd_holder is found in bd_holder_list,
add_bd_holder() completes its job by just incrementing the reference count.
In this case, it should be considered as success but it used to return 'fail'
to let the caller free temporary bd_holder.
Fixed it to return success and free given object by itself.

Also, if either one of symlinking fails, the bd_holder should not
be added to the list so that it can be discarded later.
Otherwise, the caller will free bd_holder which is in the list.

This patch is neccessary only for -mm (later than 2.6.18-rc1-mm1).

 fs/block_dev.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>

diff -urp linux-2.6.18-rc5-mm1.orig/fs/block_dev.c linux-2.6.18-rc5-mm1/fs/block_dev.c
--- linux-2.6.18-rc5-mm1.orig/fs/block_dev.c	2006-09-11 19:33:35.000000000 -0400
+++ linux-2.6.18-rc5-mm1/fs/block_dev.c	2006-09-11 19:21:46.000000000 -0400
@@ -655,8 +655,8 @@ static void free_bd_holder(struct bd_hol
  * If there is no matching entry with @bo in @bdev->bd_holder_list,
  * add @bo to the list, create symlinks.
  *
- * Returns 0 if @bo was added to the list.
- * Returns -ve if @bo wasn't used by any reason and should be freed.
+ * Returns 0 if symlinks are created or already there.
+ * Returns -ve if something fails and @bo can be freed.
  */
 static int add_bd_holder(struct block_device *bdev, struct bd_holder *bo)
 {
@@ -669,7 +669,9 @@ static int add_bd_holder(struct block_de
 	list_for_each_entry(tmp, &bdev->bd_holder_list, list) {
 		if (tmp->sdir == bo->sdir) {
 			tmp->count++;
-			return -EEXIST;
+			/* We've already done what we need to do here. */
+			free_bd_holder(bo);
+			return 0;
 		}
 	}
 
@@ -682,7 +684,8 @@ static int add_bd_holder(struct block_de
 		if (ret)
 			del_symlink(bo->sdir, bo->sdev);
 	}
-	list_add_tail(&bo->list, &bdev->bd_holder_list);
+	if (ret == 0)
+		list_add_tail(&bo->list, &bdev->bd_holder_list);
 	return ret;
 }

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/