Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Firstly, this is truly a terrific kernel(for me), fixed alot of stability issues I had. Have to wonder why keyboard/mouse support is so well "hidden" though =) Anyway, my issue is a 'oops' whenever I mount a ISO image file.
(I have compiled the loop device as a module)

example :
spam michael # mount -o loop stuff/linux-cd/knoppix/orig/KNOPPIX_V3.1-08-11-2002-EN.iso /mnt/iso Then It becomes a zombie.

ksymoops 2.4.8 on i586 2.5.47-xfs. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.47-xfs/ (default)
-m /usr/src/linux/System.map (default)

Error (regular_file): read_system_map stat /usr/src/linux/System.map failed

Unable to handle kernel NULL pointer dereference at virtual address 00000000
00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210282
eax: c02b95c0 ebx: e4a4ec20 ecx: e4a4ec20 edx: cc192480
esi: e7faedc0 edi: e7faedc0 ebp: 00000000 esp: e073df24
ds: 0068 es: 0068 ss: 0068

Stack: c01cea8c cbf21348 e4a4ec20 e073df5c 00001000 ec9d4540 e073df64 00000000 
       ec9d46d2 e4a4ec20 e073df5c 00001000 ec9d4540 e073df64 00000000 00000000 
       cc226000 dfcb1000 00001000 c0116d8e 00000000 00000000 ec9d4722 cc226000 
Call Trace: [<c01cea8c>]  [<ec9d4540>]  [<ec9d46d2>]  [<ec9d4540>]  [<c0116d8e>]
  [<ec9d4722>]  [<ec9d479e>]  [<ec9d4d85>]  [<ec9d4ca0>]  [<c01070c1>] 
Code:  Bad EIP value.

Trace; c01cea8c <pagebuf_offset+1f8c/eb00>
Trace; ec9d4540 <[loop]lo_read_actor+0/100>
Trace; ec9d46d2 <[loop]do_lo_receive+92/a0>
Trace; ec9d4540 <[loop]lo_read_actor+0/100>
Trace; c0116d8e <__wake_up+6e/80>
Trace; ec9d4722 <[loop]lo_receive+42/80>
Trace; ec9d479e <[loop]do_bio_filebacked+3e/80>
Trace; ec9d4d85 <[loop]loop_thread+e5/160>
Trace; ec9d4ca0 <[loop]loop_thread+0/160>
Trace; c01070c1 <enable_hlt+1e1/200>

1 warning and 1 error issued. Results may not be reliable.

Thanks.

If your xfs[cvs] resembles the xfs source in 2.5.50-mm1, then it looks to me like fs/xfs/linux has a .sendfile = linvfs_sendfile in xfs_file.c (which assures the loop driver it can loop this file for reading), but lacks a .vop_ioctl = xfs_sendfile (and its extern) in xfs_vnodeops.c.

But I've not delved into XFS, for all I know that code may not be ready to use yet: Christoph can say. And to get further with the 2.5.47 loop, you'll also need this patch (in 2.5.48):

@@ -304,21 +304,16 @@
 {
 	struct lo_read_data cookie;
 	struct file *file;
-	int error;
+	int retval;
 
 	cookie.lo = lo;
 	cookie.data = kmap(bvec->bv_page) + bvec->bv_offset;
 	cookie.bsize = bsize;
-
-	/* umm, what does this lock actually try to protect? */
-	spin_lock_irq(&lo->lo_lock);
 	file = lo->lo_backing_file;
-	spin_unlock_irq(&lo->lo_lock);
-
-	error = file->f_op->sendfile(file, &pos, bvec->bv_len,
+	retval = file->f_op->sendfile(file, &pos, bvec->bv_len,
 			lo_read_actor, &cookie);
 	kunmap(bvec->bv_page);
-	return error;
+	return (retval < 0)? retval: 0;
 }
 
 static int

I've still had a few issues with the sendfile code. I hope I can get it working very soon. One of the problems is that the xfss tree is still at 2.5.47 and needs the below fix. If only the module mess in mainline could get sorted out a bit more..

It's fixed now.