0) I ran into something very similar on a (self compiled) vanilla v3.0.4 (under fc14). As far as I can remember what triggered this in my case is just suspending that machine (while bluetooth was on).

1) Some interesting lines of the log of that session:
usb 3-1: USB disconnect, device number 4
btusb_bulk_complete: hci0 urb ffff88012f957948 failed to resubmit (19)
btusb_bulk_complete: hci0 urb ffff880130ed8210 failed to resubmit (19)
btusb_intr_complete: hci0 urb ffff88013b40b318 failed to resubmit (19)
btusb_send_frame: hci0 urb ffff880132e2d108 submission failed
general protection fault: 0000 [#1] SMP 
CPU 0 
Modules linked in: rfcomm bnep nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc kvm_intel kvm uinput snd_hda_codec_analog arc4 snd_hda_intel snd_hda_codec iwl4965 snd_hwdep snd_seq snd_seq_device thinkpad_acpi btusb snd_pcm iwl_legacy e1000e snd_timer snd soundcore iTCO_wdt iTCO_vendor_support pcspkr mac80211 cfg80211 bluetooth microcode snd_page_alloc rfkill i2c_i801 firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci mmc_core yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]

Pid: 21, comm: khubd Not tainted 3.0.4-local0.fc14.x86_64 #1 LENOVO 76735GG/76735GG
RIP: 0010:[<ffffffff8137d9c5>]  [<ffffffff8137d9c5>] usb_driver_release_interface+0x12/0x82
RSP: 0018:ffff880134e27b80  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff880132646360 RCX: 0040000000004006
RDX: 0000000000000006 RSI: 6b6b6b6b6b6b6b6b RDI: ffffffffa0165010
RBP: ffff880134e27ba0 R08: ffff88013b400000 R09: 000000000000005a
R10: ffff880134e27b20 R11: ffffffffa0162d25 R12: ffff880132644240
R13: ffff88013b428000 R14: 0000000000000000 R15: ffffffffa0165010
FS:  0000000000000000(0000) GS:ffff88013ba00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003f43803b35 CR3: 000000012f9df000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khubd (pid: 21, threadinfo ffff880134e26000, task ffff880134e48000)
Stack:
 ffff880134e27ba0 ffff880132646360 ffff880132644240 ffff88013b428000
 ffff880134e27bd0 ffffffffa0162cb9 ffff880132644270 ffff880132644270
 ffff880132644240 ffff880132642968 ffff880134e27c20 ffffffff8137d8e0
Call Trace:
 [<ffffffffa0162cb9>] btusb_disconnect+0xa1/0xc7 [btusb]
 [<ffffffff8137d8e0>] usb_unbind_interface+0x74/0x147
 [<ffffffff8131cef6>] __device_release_driver+0x86/0xd2
 [<ffffffff8131cf60>] device_release_driver+0x1e/0x2b
 [<ffffffff8131ca97>] bus_remove_device+0xcb/0xdc
 [<ffffffff8131a392>] device_del+0x138/0x18a
 [<ffffffff8137ba58>] usb_disable_device+0xb7/0x1f0
 [<ffffffff813741b7>] usb_disconnect+0xe9/0x161
 [<ffffffff813762c0>] hub_thread+0x7eb/0x120a
 [<ffffffff8104e9cd>] ? mmdrop+0x1a/0x2a
 [<ffffffff8104ec08>] ? finish_task_switch+0xac/0xdd
 [<ffffffff8107a76a>] ? wake_up_bit+0x2a/0x2a
 [<ffffffff81375ad5>] ? usb_remote_wakeup+0x64/0x64
 [<ffffffff8107a25c>] kthread+0xa0/0xa8
 [<ffffffff8108fdfe>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffff814f7464>] kernel_thread_helper+0x4/0x10
 [<ffffffff814efa54>] ? retint_restore_args+0x13/0x13
 [<ffffffff8107a1bc>] ? __init_kthread_worker+0x5b/0x5b
 [<ffffffff814f7460>] ? gs_change+0x13/0x13
Code: 4c 89 ef e8 24 fe ff ff 48 83 c4 18 31 c0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 66 66 66 66 90 
RIP  [<ffffffff8137d9c5>] usb_driver_release_interface+0x12/0x82
 RSP <ffff880134e27b80>
---[ end trace 4fa8e296e963698c ]---

2) Peeking at vmlinux with gdb:
(gdb) info line 484
Line 484 of "drivers/usb/core/driver.c" starts at address 0xffffffff8137d9c5 <usb_driver_release_interface+18>
   and ends at 0xffffffff8137d9cc <usb_driver_release_interface+25>.
(gdb) disass /m usb_driver_release_interface+18,+7
Dump of assembler code from 0xffffffff8137d9c5 to 0xffffffff8137d9cc:
480	{

481		struct device *dev = &iface->dev;
482	
483		/* this should never happen, don't release something that's not ours */
484		if (!dev->driver || dev->driver != &driver->drvwrap.driver)
   0xffffffff8137d9c5 <usb_driver_release_interface+18>:	mov    0x140(%rsi),%rax

End of assembler dump.
(gdb) print ((size_t) &((struct usb_interface *)0)->dev)
$4 = 48
(gdb) print ((size_t) &((struct device *)0)->driver)
$5 = 272

3) It seems the code faults while accessing iface->dev->driver, which is at offset (48 + 272 =) 0x140 of struct usb_interface. Somehow, *iface is used after free (and after poisoning, see the contents of the RSI register). I'm not fluent enough in the btusb driver, the usb subsystem and the base driver code to pinpoint what chain of events makes that possible.

Already discussed at lkml: https://lkml.org/lkml/2011/8/15/400 (with a similar analysis as I cobbled together in comment #1). No solution yet, apparently.

From the LKML thread:
> Also, can you add some debugging statements to
> drivers/bluetooth/btusb.c?  in btusb_disconnect(), it would be good to
> see the values of intf, data, data->intf, and data->isoc.  In addition
> (with caution), data->intf->dev.driver and data->isoc->dev.driver.

(In reply to comment #3)
> From the LKML thread:
> > Also, can you add some debugging statements to
> > drivers/bluetooth/btusb.c?  in btusb_disconnect(), it would be good to
> > see the values of intf, data, data->intf, and data->isoc.  In addition
> > (with caution), data->intf->dev.driver and data->isoc->dev.driver.

I already did. Nothing very suspicious showed up. To my annoyance I've also been unable to reproduce this. I hope to post a, well, analysis of the debug output at some later time.

(In reply to comment #4)
> I hope to post a, well, analysis of the debug
> output at some later time.

But first a preliminary theory. What happens if
    btusb_destruct()

is called before
    btusb_disconnect()

That will basically 
    kfree(hdev->driver_data)

which would pull the "intfdata" from under "intf" (since hdev->driver_data and intf's "intfdata" are the same thing) doesn't it?

btusb_destruct() is called by the the bluetooth code, while btusb_disconnect() is called by the usb code.

Is there anything that makes sure that btusb_destruct() doesn't run too early?

(In reply to comment #5) 
> Is there anything that makes sure that btusb_destruct() doesn't run too early?

And see, just before the faulting call of
   usb_driver_release_interface()

we have a call to
   hci_unregister_dev()

which finally calls
   __hci_dev_put()

which will finally invoke
   d->destruct(d)

which here will be
   btusb_destruct()

So, perhaps, every now and then, while the kernel is rather busy going into suspend to ram, that last call will already be finished before
    usb_driver_release_interface()

is run, giving "intf" an already freed "intfdata". Does this make sense?

(In reply to comment #6)
> Does this make sense?

0) The call to hci_unregister_dev() is of course wrapped in a neatly balanced pair of __hci_dev_hold() and __hci_dev_put(). But as far as I can see hci_unregister_dev() decrements hdev->refcnt twice:
   1) first through the hci_dev_do_close() call;
   2) then through the __hci_dev_put() call.

1) So even if hdev->refcnt is one after we've been trough btusb_open(), as it seems to be, it should be zero once we call usb_driver_release_interface().

2) But that would mean the non-crashing case - ie, the common case - would be a case of use after free, wouldn't it?

3) A fresh pair of eyes parsing this code might be needed ...

Paul, Mikko, does this still happen on 3.2.7 or newer?

I started bluetooth pairing and switched bluetooth+wifi off with hw-switch.

The resulting stack trace looks quite much like the original one. The code seems to manage to progress two more methods further into the stack before failing.

general protection fault: 0000 [#1] SMP 
CPU 7 
Modules linked in: fuse rfcomm bnep btusb bluetooth lockd sunrpc coretemp arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev cdc_ncm v4l2_compat_ioctl32 usbnet cdc_acm
ec_conexant microcode iwlwifi i2c_i801 mac80211 iTCO_wdt cfg80211 iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc e1000e snd_timer thinkpad_acpi snd soundco
an kvm_intel kvm uinput btrfs libcrc32c zlib_deflate sdhci_pci firewire_ohci sdhci firewire_core mmc_core crc_itu_t
 nouveau mxm_wmi wmi video drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan]

Pid: 47, comm: khubd Not tainted 3.3.0-0.rc4.git1.4.fc17.x86_64 #1 LENOVO 42844DG/42844DG
RIP: 0010:[<ffffffffa078d175>]  [<ffffffffa078d175>] hci_conn_hash_flush+0x95/0x120 [bluetooth]
RSP: 0018:ffff880429e73b40  EFLAGS: 00010296
RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffea00109da780 RDI: ffffffffa03c98e0
RBP: ffff880429e73b60 R08: ffff88042769f260 R09: 0000000100180010
R10: ffff88042769f268 R11: 0000000000000000 R12: ffff8804274f4d00
R13: ffff8804274f4bd0 R14: ffff880394438000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88042d400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f077512067c CR3: 000000041b7b5000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khubd (pid: 47, threadinfo ffff880429e72000, task ffff880429d42690)
Stack:
 ffff880429e73b60 6b6b6b6b6b6b6b6b ffff8804274f4290 ffff8804274f42a0
 ffff880429e73b90 ffffffffa07866b8 ffff8804274f4290 0000000000000000
 ffff88041b6b5cd0 ffff880394438000 ffff880429e73bb0 ffffffffa078a267
Call Trace:
 [<ffffffffa07866b8>] hci_dev_do_close+0xc8/0x340 [bluetooth]
 [<ffffffffa078a267>] hci_unregister_dev+0x47/0x1a0 [bluetooth]
 [<ffffffffa03c62b2>] btusb_disconnect+0x72/0x100 [btusb]
 [<ffffffff8148d403>] usb_unbind_interface+0x53/0x180
 [<ffffffff8141215c>] __device_release_driver+0x7c/0xe0
 [<ffffffff814121ee>] device_release_driver+0x2e/0x40
 [<ffffffff814118a2>] bus_remove_device+0x102/0x180
 [<ffffffff8140eb37>] device_del+0x137/0x1c0
 [<ffffffff8148afd0>] usb_disable_device+0xb0/0x250
 [<ffffffff81481c1a>] usb_disconnect+0xaa/0x160
 [<ffffffff81484029>] hub_thread+0x4f9/0x1630
 [<ffffffff810cda3d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff8108ac00>] ? wake_up_bit+0x40/0x40
 [<ffffffff81483b30>] ? usb_remote_wakeup+0x70/0x70
 [<ffffffff8108a3d7>] kthread+0xb7/0xc0
 [<ffffffff810cda3d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff816a88f4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8169ecb4>] ? retint_restore_args+0x13/0x13
 [<ffffffff8108a320>] ? kthread_worker_fn+0x1a0/0x1a0
 [<ffffffff816a88f0>] ? gs_change+0x13/0x13
Code: fd ff ff 48 8b 03 48 89 45 e8 48 8b 5d e8 e8 83 98 8f e0 85 c0 74 0f e8 7a 98 8f e0 85 c0 75 56 66 0f 1f 44 00 00 49 39 dc 74 3b <0f> b6 53 21 66 c7 43 1e 09 00 80 fa 01 74 14 73 8a be 16 00 00 
RIP  [<ffffffffa078d175>] hci_conn_hash_flush+0x95/0x120 [bluetooth]
 RSP <ffff880429e73b40>

OK, let's move it to rawhide since it is still hitting the latest kernel.

*** Bug 797590 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> Paul, Mikko, does this still happen on 3.2.7 or newer?

0) I've never been able to reproduce this.

1) For what it's worth, I seem to remember trying different things to trigger this (eg, disabling bluetooth manually while already going into suspend) for some time without any luck. I've also run with bluetooth enabled on two machines (one running F14 and now F16, one tracking Rawhide) for months on end, in which I suspended hundreds of times, without triggering this GPF even once.

1) So, from my perspective this is just an odd bug I ran into just once and which I was also unable to pinpoint in the code (see comment #1, comment #5, comment #6, and comment #7).

one of the bluetooth developers noted this morning that commit 3c4e0df028935618d052235ba85bc7079be13394 (not yet in mainline) might solve this. I'll backport it to f15/f16 when I figure out where that commit lives.

I can no longer reproduce this bug in kernel-3.5.0-0.rc6.git2.1.fc18.

The bug might have been fixed already in earlier kernels, but I have not tried to reproduce this bug on them.