Elevator bug in concert with usb-storage

From: Fredrik Tolf (fredrik_at_dolda2000.com)
Date: 10/23/03

  • Next message: Joseph D. Wagner: "Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture" 
    Date:	Thu, 23 Oct 2003 04:25:37 +0200
To: linux-kernel@vger.kernel.org

    Hello,

    I believe that there is a bug in the usb-storage code. I'm using
    2.6.0-test8-mm1, but I have experienced this in essentially all
    2.6.0-test* kernels. Mostly anytime when I remove a usb-storage device
    (especially before umounting it), I get a SEGV followed by general
    unstability in the SCSI subsys.

    After doing some research, I believe it is because the I/O scheduler
    is released before the SCSI subsys stops using it. Here is the SEGV
    report:

    Unable to handle kernel NULL pointer dereference at virtual address 00000001
     printing eip:
    00000001
    *pde = 00000000
    Oops: 0000 [#1]
    PREEMPT
    CPU: 0
    EIP: 0060:[<00000001>] Not tainted VLI
    EFLAGS: 00010202
    EIP is at 0x1
    eax: d8b83180 ebx: dafc4e00 ecx: 00000000 edx: dafc4e00
    esi: dafc4e10 edi: c03465e0 ebp: d990fe64 esp: d990fe58
    ds: 007b es: 007b ss: 0068
    Process umount (pid: 1744, threadinfo=d990e000 task=d8ba4080)
    Stack: c02173d7 dafc4e00 d8b83180 d990fe78 c0218f5d dafc4e00 df774800 c03465b0
           d990fe8c e0952fb5 dafc4e00 db8e3ca0 c03465b0 d990fe9c e0953f83 df774800
           00000000 d990feac c021480a df774980 df7749a8 d990fec4 c01c26e3 df7749a8
    Call Trace:
     [<c02173d7>] elevator_exit+0x2d/0x3c
     [<c0218f5d>] blk_cleanup_queue+0x65/0x70
     [<e0952fb5>] scsi_free_sdev+0x11f/0x15a [scsi_mod]
     [<e0953f83>] scsi_device_dev_release+0x15/0x22 [scsi_mod]
     [<c021480a>] device_release+0x1a/0x60
     [<c01c26e3>] kobject_cleanup+0x63/0x70
     [<e094eb1c>] scsi_device_put+0x68/0xa6 [scsi_mod]
     [<e08a94cb>] sd_release+0x27/0x46 [sd_mod]
     [<c01569c5>] blkdev_put+0x1a7/0x1bc
     [<c015698f>] blkdev_put+0x171/0x1bc
     [<c015566b>] kill_block_super+0x25/0x2c
     [<c01548c7>] deactivate_super+0x67/0xae
     [<c01686c2>] sys_umount+0x36/0x84
     [<c014e9c5>] filp_close+0x43/0x66
     [<c016871d>] sys_oldumount+0xd/0x10
     [<c02bafeb>] syscall_call+0x7/0xb

    Code: Bad EIP value.

    It seems as if the elevator_exit_fn is set to 1, and there is a
    message logged just before the SEGV report spits out that an I/O
    scheduler is released, which makes me draw the conclusion that the
    kernel tries to free the I/O scheduler twice.

    My apologies for taking up your time if this is a known a fixed
    problem. However, if it is, can you point me to some information on
    how to remedy it?

    If it isn't, please tell me how I can help fix this.

    Also, between the message that indicates that the I/O scheduler has
    been released and the SEGV, there are two messages from the hotplug
    handler, indicating that it can't the agents for "block" and "scsi"
    (in that order), if that helps you determine the order of
    things. There is also another message of the same kind for "block"
    just before the I/O scheduler is first released.

    Thank you for your time!

    Fredrik Tolf

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Joseph D. Wagner: "Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture"

    Relevant Pages

    • Re: Elevator bug in concert with usb-storage
      ... >I believe that there is a bug in the usb-storage code. ... Here is the SEGV ... > printing eip: ... >kernel tries to free the I/O scheduler twice. ...
      (Linux-Kernel)
    • Re: Burning a kernel
      ... Just applying basic knowledge regarding the kernel to ... > kernel's default I/O scheduler. ... Why was building a custom version of the kernel necessary? ... ..the Sin of Ignorance, ...
      (Fedora)
    • Re: most lightweight debian server
      ... You might want to use a different scheduler and I/O scheduler than the ... default if you use a 2.6.24 kernel. ... mentioned Apache, set up a minimal Apache, jettison unneeded modules, ... Add RAM if at all possible. ...
      (Debian-User)
    • Re: Burning a kernel
      ... Just applying basic knowledge regarding the kernel to ... > kernel's default I/O scheduler. ... Why was building a custom version of the kernel necessary? ...
      (Fedora)
    • [PATCH try #1] Kconfig: cleanup block/Kconfig.iosched help descriptions
      ... More information is added to each of the I/O scheduler choices and they ... show how to switch the scheduler for block devices at runtime, ... it that the kernel won't be able to load the module off disk before ... +config IOSCHED_CFQ ...
      (Linux-Kernel)