I'm getting various oopses in 2.6 due to actconfig being NULL
unexpectedly in devio.c, namely in these releaseintf and findintif:

static int releaseintf(struct dev_state *ps, unsigned int intf)
{
        struct usb_device *dev;
        struct usb_interface *iface;
        int err;

        if (intf >= 8*sizeof(ps->ifclaimed))
                return -EINVAL;
        err = -EINVAL;
        dev = ps->dev;
        down(&dev->serialize);
        if (test_and_clear_bit(intf, &ps->ifclaimed)) {
                iface = dev->actconfig->interface[intf]; <== actconfig is NULL
                usb_driver_release_interface(&usbdevfs_driver, iface);
                err = 0;
        }
        up(&dev->serialize);
        return err;
}


static int findintfif(struct usb_device *dev, unsigned int ifn)
{
        unsigned int i, j;
        struct usb_interface *iface;
        struct usb_host_interface *alts;

        if (ifn & ~0xff)
                return -EINVAL;
        for (i = 0; i < dev->actconfig->desc.bNumInterfaces; i++) {  <= actconfig is 
NULL
                iface = dev->actconfig->interface[i];
                for (j = 0; j < iface->num_altsetting; j++) {
                        alts = &iface->altsetting[j];
                        if (alts->desc.bInterfaceNumber == ifn)
                                return i;
                }
        }
        return -ENOENT; 
}


Unable to handle kernel NULL pointer dereference at virtual address 0000000c
printing eip:
e0bfaa5a
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<e0bfaa5a>]    Not tainted
EFLAGS: 00010286
EIP is at releaseintf+0x7a/0xa0 [usbcore]
eax: 00000000   ebx: d92d2c1c   ecx: d92d2c1c   edx: daae3f38
esi: d92d2bf8   edi: 00000000   ebp: db2f7ecc   esp: db2f7eb4
ds: 007b   es: 007b   ss: 0068
Process modem_run (pid: 3791, threadinfo=db2f6000 task=d9010960)
Stack: e0c0180c 00000077 ffffffea 00000000 daae3f38 dffc6194 db2f7ef8 e0bfb173 
daae3f38 00000000 c0177993 c3b59000 dffccf78 00000282 db3e5f60 db3e5f60 
00000000 db2f7f1c c01779ec db2afe3c db3e5f60 db2afe3c db290f38 db3e5f60 
Call Trace:
[<e0bfb173>] usbdev_release+0x1c3/0x220 [usbcore]
[<c0177993>] __fput+0xb3/0x120
[<c01779ec>] __fput+0x10c/0x120
[<c01759a7>] filp_close+0x57/0x80
[<c012a3f7>] put_files_struct+0x67/0xd0
[<c012b728>] do_exit+0x2b8/0x970
[<c0297727>] sys_socketcall+0x167/0x290
[<c012be90>] do_group_exit+0x40/0x220
[<c010a3af>] syscall_call+0x7/0xb

Code: 8b 44 b8 0c c7 04 24 60 ba c0 e0 89 44 24 04 e8 b2 2c ff ff 


Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
e0bfabd5
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<e0bfabd5>]    Not tainted
EFLAGS: 00010246
EIP is at findintfif+0x25/0x70 [usbcore]
eax: 00000000   ebx: dba45f38   ecx: fffffff2   edx: 00000002
esi: ffffffea   edi: 00000000   ebp: dbe51ef4   esp: dbe51ee0
ds: 007b   es: 007b   ss: 0068
Process modem_run (pid: 3612, threadinfo=dbe50000 task=dbe02960)
Stack: 00000000 e0bfacc3 dba45f38 8004550f dba45f40 dbe51f08 e0bfd0cc db92fbf8 
00000002 dba45f38 dbe51f58 e0bfdcfe dba45f38 bffff924 ffffffe7 dffc6194 
dbe51f4c c0196763 d92f4f38 c037d2b0 c0177993 dc7b6000 dffccf78 00000292 
Call Trace:
[<e0bfacc3>] usbdev_open+0x23/0x310 [usbcore]
[<e0bfd0cc>] proc_claiminterface+0x2c/0x50 [usbcore]
[<e0bfdcfe>] usbdev_ioctl+0x36e/0x3a0 [usbcore]
[<c0196763>] dput+0x23/0x6f0
[<c0177993>] __fput+0xb3/0x120
[<c0190365>] file_ioctl+0x65/0x1d0
[<c01906f0>] sys_ioctl+0x220/0x3f0
[<c017692f>] sys_read+0x3f/0x60
[<c010a3af>] syscall_call+0x7/0xb

Code: 0f b6 50 04 39 d7 73 30 89 55 f0 8b 44 b8 0c 31 c9 8b 58 08 


The first oops occurs always at system shutdown.  The second oops occurs
sometimes at system startup.  I can "fix" the first one by replacing
        down(&dev->serialize);
with
        lock_kernel();
and
        up(&dev->serialize);
with
        unlock_kernel();
in releasintf.  The logic here is that although usbdev_release takes the BKL,
it can lose it while sleeping in the down(&dev->serialize) in releaseintf,
which is not what is intended I guess (and since it eliminates the first oops,
there must be some truth to this theory).  However things are more complicated
because usb_driver_release_interface(&usbdevfs_driver, iface) can also sleep,
which might also cause problems.  I haven't analysed this yet.  Maybe this
change also fixed the second oops, but since that one only occurs about one
time in four, it is hard to be sure.

I will of course look into this further, but I thought I would mention it now in
case anyone has any ideas.

Ciao,

Duncan.


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to