Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933928Ab2J3QBA (ORCPT ); Tue, 30 Oct 2012 12:01:00 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:49104 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754082Ab2J3QA6 (ORCPT ); Tue, 30 Oct 2012 12:00:58 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 31 Oct 2012 00:00:56 +0800 Message-ID: Subject: Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio() From: Ming Lei To: Alan Stern Cc: linux-kernel@vger.kernel.org, Oliver Neukum , Minchan Kim , Greg Kroah-Hartman , "Rafael J. Wysocki" , Jens Axboe , "David S. Miller" , Andrew Morton , netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2280 Lines: 55 On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern wrote: > > Okay, I see your point. But acquiring the lock here doesn't solve the > problem. Suppose a thread is about to reset a USB mass-storage device. > It acquires the lock and sees that the noio flag is clear. But before > it can issue the reset, another thread sets the noio flag. If the USB mass-storage device is being reseted, the flag should be set already generally. If the flag is still unset, that means the disk/network device isn't added into system(or removed just now), so memory allocation with block I/O should be allowed during the reset. Looks it isn't one problem, isn't it? > I'm not sure what the best solution is. > >> The lock needn't to be held when the function is called inside >> pm_runtime_set_memalloc_noio(), so the bitfield flag should >> be checked directly without holding power lock in dev_memalloc_noio(). > > Yes. > > A couple of other things... Runtime resume can be blocked by runtime > suspend, if a resume is requested while the suspend is in progress. > Therefore the runtime suspend code also needs to save-set-restore the > noio flag. Looks the simplest approach is to handle the noio flag thing at the start and end of rpm_resume. > Also, we should set the noio flag at the start of > usb_stor_control_thread, because everything that thread does can > potentially block an I/O operation. Yes, it should be done, and all GFP_NOIO in usbcore should be converted into GFP_KERNEL together. And the work shouldn't be started until the patchset is merged. > Lastly, pm_runtime_get_memalloc_noio always returns false when > CONFIG_PM_RUNTIME is disabled. But we still need to prevent I/O during > usb_reset_device even when there's no runtime PM. Maybe the simplest > answer is always to set noio during resets. That would also help with > the race described above. I have thought about this. IMO, pm_runtime_get_memalloc_noio should return true always if CONFIG_PM_RUNTIME is unset. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/