On Fri, Apr 12, 2013 at 6:02 PM, Oliver Neukum <oliver@xxxxxxxxxx> wrote: > On Friday 12 April 2013 17:42:46 Ming Lei wrote: >> On Fri, Apr 12, 2013 at 2:37 PM, Oliver Neukum <oliver@xxxxxxxxxx> 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. > > The remedy is close to trivial, so yes. > >> 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? > > No. We assume that probing happens before the interfaces are used. > Furthermore, if this turns out to be real, we can reuse your fix for the > general (w.o. work queue) reset case. See driver load/bind path(driver_attach()/driver_bound()), both may happen anytime on unbind interface. Yes, we can easily address it with the PF_MEMALLOC_NOIO trick, but can we afford NOIO allocation in probe() path for all 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(). > > We are talking about a generic helper. And the fix is really simple. > We just pass mem_flags and all is well. If the API can be made better > at next to no cost, we do it. > >> Then looks the mem_flags isn't needed in both cases, and we should >> always take GFP_NOIO inside the API? > > We cannot. GFP_ATOMIC may be needed. And no, we atre not going to > unconditionally use GFP_ATOMIC :-; It depend on the probe() case, :-) Thanks, -- Ming Lei -- 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
