Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756660Ab2EYIsa (ORCPT ); Fri, 25 May 2012 04:48:30 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:55831 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755944Ab2EYIs0 (ORCPT ); Fri, 25 May 2012 04:48:26 -0400 Message-ID: <1337935700.2932.18.camel@dabdike.int.hansenpartnership.com> Subject: Re: [PATCH 1/4] async: introduce 'async_domain' type From: James Bottomley To: Dan Williams Cc: mroos@linux.ee, linux-scsi@vger.kernel.org, Mark Brown , linux-kernel@vger.kernel.org, Arjan van de Ven , Liam Girdwood , "Rafael J. Wysocki" Date: Fri, 25 May 2012 09:48:20 +0100 In-Reply-To: References: <20120525074813.21933.91876.stgit@dwillia2-linux.jf.intel.com> <20120525075027.21933.75815.stgit@dwillia2-linux.jf.intel.com> <1337932267.2932.7.camel@dabdike.int.hansenpartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2651 Lines: 64 On Fri, 2012-05-25 at 01:18 -0700, Dan Williams wrote: > On Fri, May 25, 2012 at 12:51 AM, James Bottomley > wrote: > > On Fri, 2012-05-25 at 00:50 -0700, Dan Williams wrote: > >> This is in preparation for teaching async_synchronize_full() to sync all > >> pending async work, and not just on the async_running domain. This > >> conversion is functionally equivalent, just embedding the existing list > >> in a new async_domain type. > > > > This looks good, but I want Arjan and others who invented the async code > > to speed up boot to comment on all of this. What was the intention of > > async_synchronize_full() and if it wasn't to synchronise all domains, > > should we fix the documentation and add a new primitive to do that, > > since boot clearly assumes the all domains behaviour. > > > > In the mean time, this is probably all a bit much for a merge window, so > > I'll revert > > > > commit a7a20d103994fd760766e6c9d494daa569cbfe06 > > Author: Dan Williams > > Date: Thu Mar 22 17:05:11 2012 -0700 > > > > [SCSI] sd: limit the scope of the async probe domain > > > > And we'll put whatever is chosen in early for the next merge window. > > > > Makes sense... but could also go ahead with the smaller fix I posted > for 3.5. Meelis confirms it is working. OK, that's what I hadn't seen. I can't think of another way we could fail at the moment, except in suspend/resume because the scsi_complete_async_scans will be a nop. Can someone test the suspend/resume case? There is actually one good thing to come out of this: Rafael's commit commit c751085943362143f84346d274e0011419c84202 Author: Rafael J. Wysocki Date: Sun Apr 12 20:06:56 2009 +0200 PM/Hibernate: Wait for SCSI devices scan to complete during resume Actually broke the scsi_wait_scan module, because for modular SCSI (which is effectively all distributions) its scsi_complete_async_scans() is also a nop. I assume this means that no distributions rely on it any more and we can remove it? > Otherwise this leaves the pending libsas suspend/resume support in > limbo, since it will certainly deadlock in the case where any device > fails, or is slow to come back from resume. I appreciate this is a bug, but it's not quite as serious as breaking suspend and hibernate ... can we demonstrate they're still working? James -- 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/