lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Nov 2009 21:18:39 +0100
From:	Marcel Holtmann <>
To:	Linus Torvalds <>
Cc:	"Rafael J. Wysocki" <>,
	Thomas Gleixner <>,
	Mike Galbraith <>, Ingo Molnar <>,
	LKML <>,
	pm list <>,
	Greg KH <>,
	Jesse Barnes <>,
	Tejun Heo <>, Oleg Nesterov <>,
	Oliver Neukum <>,
Subject: Re: GPF in run_workqueue()/list_del_init(cwq-> on
 resume (was: Re: Help needed: Resume problems in 2.6.32-rc, perhaps related
 to preempt_count leakage in keventd)

Hi Linus,

> > I thought that the problem was somehow related to user space, because it only
> > happens after we've thawed tasks.  At least, all of the call traces I was able
> > to collect indicated so.
> > 
> > Moreover, in a few cases I got
> > 
> > kernel: PM: Finishing wakeup.
> > kernel: Restarting tasks ...
> > kernel: usb 5-2: USB disconnect, address 2
> > kernel: done.
> > bluetoothd[3445]: HCI dev 0 unregistered
> > bluetoothd[3445]: Unregister path: /org/bluez/3445/hci0
> > bluetoothd[3445]: Unregistered interface org.bluez.NetworkPeer on path /org/bluez/3445/hci0
> > bluetoothd[3445]: Unregistered interface org.bluez.NetworkHub on path /org/bluez/3445/hci0
> > bluetoothd[3445]: Unregistered interface org.bluez.NetworkRouter on path /org/bluez/3445/hci0
> > kernel: Slab corruption: size-512 start=ffff88007f1182b0, len=512
> > 
> > and so on (of course, the bluetoothd PID was different each time), so I thought
> > that the problem might be related to Bluetooth.
> Hmm. Sounds reasonable. It's still that 'size-512', but if the sound 
> subsystem and the bluetooth code both happen to use that size, that would 
> explain why there was sound data in the slab.
> > So, I've disabled the Bluetooth subsystem in the kernel config and I'm not able
> > to reproduce the problem any more (at least not within 50 consecutive
> > suspend-resume and hibernate-resume cycles).  Thus Bluetooth seems to be
> > at least necessary to reproduce the issue and perhaps it's also the cause of
> > it.
> Which BT driver are you using? Maybe it's specific to the low-level 
> driver?
> For example, I could imagine that (say) a USB bluetooth dongle (I think 
> they are common for for mice, and are sometimes built-in on the 
> motherboard) could get the USB "disconnect" event, and get freed while 
> some work from the resume is still pending.
> I'm looking at btusb_disconnect(), for example. It's one of the few BT 
> drivers that seem to use workqueues, and I'm not seeing a 
> cancel_work_sync() in the disconnect routine - but maybe the btusb_close() 
> routine is called indirectly some way that I just don't see.

so the btusb_close() should be called before btusb_destruct() and the
destruct() callback is only when the last reference count gets dropped
and we do have to free the memory. So it seems we are doing something
wrong in btusb_close(). The close() callback is triggered via
hci_unregister_dev() from btusb_disconnect().

As it seems the btusb_close() only cancels the work workqueue and not
the waker workqueue. Could that be the problem.

Oliver, what do you think?



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists