Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759606Ab2J3Piu (ORCPT ); Tue, 30 Oct 2012 11:38:50 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:51416 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1758566Ab2J3Pir (ORCPT ); Tue, 30 Oct 2012 11:38:47 -0400 Date: Tue, 30 Oct 2012 11:38:46 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ming Lei cc: linux-kernel@vger.kernel.org, Oliver Neukum , Minchan Kim , Greg Kroah-Hartman , "Rafael J. Wysocki" , Jens Axboe , "David S. Miller" , Andrew Morton , , , , Subject: Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2209 Lines: 57 On Tue, 30 Oct 2012, Ming Lei wrote: > >> +bool pm_runtime_get_memalloc_noio(struct device *dev) > >> +{ > >> + bool ret; > >> + spin_lock_irq(&dev->power.lock); > >> + ret = dev->power.memalloc_noio_resume; > >> + spin_unlock_irq(&dev->power.lock); > >> + return ret; > >> +} > > > > You don't need to acquire and release a spinlock just to read the > > value. Reading bitfields _is_ SMP-safe; writing them is not. > > Thanks for your review. > > As you pointed out before, the flag need to be checked before > resetting usb devices, so the lock should be held to make another > context(CPU) see the updated value suppose one context(CPU) > call pm_runtime_set_memalloc_noio() to change the flag at the > same time. 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. 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. 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. 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. Alan Stern -- 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/