On Wed, 8 Jun 2016, Michał Pecio wrote: > > The best way to protect against this is to call INIT_LIST_HEAD in > > ed_alloc() and list_del_init() in finish_unlinks(). > > This means silently sweeping a whole class of bugs under the rug. > I wouldn't want to have this in mainline. And as for longterm, I think > my approach has the advantage of not pretending to be anything more than > just a nasty hack to keep thing from burning. > > Though, on second thought, I'm not sure if preventing this panic is a > good idea at all. We still don't know what kind of dark powers allow > these EDs to bypass periodic_link and cannot prove that there won't > be some memory corruption *after* the evaded crash, even if the evasion > itself happens "legally", before ed_free. > > Maybe it's safer to just let things burn. Well, there haven't been any complaints about this until you reported the problem. If anybody else was relying on the driver exceeding the maximum allowed bandwidth, wouldn't they run across the same BUG as you did? In which case there wouldn't be any downside to putting your patch in the -stable kernels. Alan Stern -- 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
