On Friday 24 April 2009, Sergei Shtylyov wrote: > 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? Not on *this* front, no. :( > Because the issue is still there... :-) Yeah, I see it a bit more too. I've got one board which I use with an ASIX based Ethernet adapter; that shows the problem. - Dave -- 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
