Hi Jonathan, On Sun, May 20, 2012 at 10:38 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > However that doesn't explain changes like moving the acquisition of > dev->kfref about 30 lines down.
There's an extra dereference on the error path that should get a patch in 3.5/3.6. > Can you explain what the part of the > patch preventing a panic does, for example by providing an example > trace of the panic? This would make it easier to see how to safely > backport the fix and which kernels need it. Here's a screenshot of the panic: http://plugable.com/wp-content/uploads/2012/05/udlfb_usb_hcd_free_panic.jpg This is an older report of likely the same thing: http://lists.freedesktop.org/archives/libdlo/2010-October/000779.html The panic (race condition) seems to happen when we get: 1) probe() which triggers some long running operations 2) the hardware is removed when those operations are still in process 3) panic happens during the disconnect() tear-down process in that case This is most common when we're doing big USB multiseat setups, where lots of USB plug/unplug is happening. By getting the (unnecessarily) long-running operations out of probe, we don't hit the panic, even with extensive stress testing. Because automatic USB multiseat is only in recent distros (Fedora 17 and hopefully others) that are running 3.3 (or later), it's the backport to 3.3 that is most valuable to end users. Hope this background helps. Thanks, Bernie -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
