Hello. David Brownell wrote:
Now I see three options.
1. Drivers need to cope with any context and any locks held. This seems to be hardly practical to me. We'd beg for bugs.
It's the situation we're in right now. So far there haven't been very many bugs.
Haven't been many reports mostly by chance. Mass storage could hit similar issues after scatterlist cleanup, ISTR.
I still wonder if it isn't possible to change the driver in question so that it drops its own lock before unlinking an URB.
That's what the SMP-unsafe patch I sent does. But the lock is needed, so long as the completion handler always touches the list ... the SMP-unsafety comes from having one bit of code walk that list while another removes things from it.
A notion that just landed in my greycells is to change the completion handler. If it sees a "purging" flag is set, it could just mark the SKB as "handled" and quickly exit, but not update that list ... the code that purges the queue would set a flag on each SKB (holding current lock), unlink, wait for all the urbs to have completed, then clean up.
I'll let that thought percolate a bit more. There are a few details to sort. Maybe someone else can do a patch befor I sort them. ;)
Any news from your greycells since January? Because the issue is still there... :-)
WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
