On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum <oli...@neukum.org> wrote: >> The work will complete when memory is reclaimed, and the rx/tx path is >> still working, so memory reclaim can continue and the deadlock may not >> be caused, may it? > > Only if the memory allocation goes to the same interface. If the blocking > interface > is storage, something bad happens (data loss not deadlock)
OK, got it, it should be both since reset can't move on, so memory reclaim can't complete to satisfy the allocation. But I am wondering if it is a case which is worth the consideration. Almost all USB probe() allocate memory with GFP_KERNEL, then the similar scenario(data loss only this time) might happen too. Do we need to fix all USB drivers? Wrt. the usbnet_status_start() API, looks no good reason to call it in another queue context, it should be enough to call it in probe() or bind() if init_status() can be put before info->bind() in usbnet_probe(). Then looks the mem_flags isn't needed in both cases, and we should always take GFP_NOIO inside the API? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
