From patchwork Wed Mar 14 21:33:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 146724 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 98645B6EEC for ; Thu, 15 Mar 2012 08:33:29 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761149Ab2CNVd2 (ORCPT ); Wed, 14 Mar 2012 17:33:28 -0400 Received: from mga09.intel.com ([134.134.136.24]:45040 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757051Ab2CNVd1 (ORCPT ); Wed, 14 Mar 2012 17:33:27 -0400 Received: from mail-iy0-f180.google.com ([209.85.210.180]) by mga09.intel.com with ESMTP/TLS/RC4-SHA; 14 Mar 2012 14:33:27 -0700 Received: by iage36 with SMTP id e36so3187137iag.25 for ; Wed, 14 Mar 2012 14:33:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:to:cc:date:in-reply-to:references:content-type :x-mailer:content-transfer-encoding:message-id:mime-version :x-gm-message-state; bh=YVndyeSIHt6u1stE3qjDDyKcPFRKY+flbDDmjVfcO28=; b=X++8KGotEqqyNcUGRClxwrOn6k6kdXYvjnl5KtjE0x8U5Q7KDbRhtnZnxepylkHxbn T1Tps9B48nPb70yVkBseAHHJTPpffveLWE0+4XxwL+N3S+lhXdNrinyeLESvRxSwYPeL /w1cdfERH/OGgD04Ws7UroLJpmuwZWyZVR18vXidmoeFqzx8c8Q74QqLuELOWBlvhbel F0aNl0l7a+vP9TJqev9SqdKoFz3LCURw4Dqy71RqHR6XrF6zpW284Xe1/o7sPWcKqGDG QN8rH0WYE1ZkM/A3RC53ZM4ccEJygFApewP0U5PbF5Kd0AFIWRQ1XSi6M8cdk/YJipmr umxQ== Received: by 10.50.11.227 with SMTP id t3mr14138478igb.45.1331760787530; Wed, 14 Mar 2012 14:33:07 -0700 (PDT) Received: from [192.168.0.8] (static-50-53-161-131.bvtn.or.frontiernet.net. [50.53.161.131]) by mx.google.com with ESMTPS id mk10sm15126485igc.4.2012.03.14.14.33.06 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 14:33:07 -0700 (PDT) Subject: Re: [isci PATCH v3 3/4] libsas: suspend / resume support From: Dan Williams To: Alan Stern Cc: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org, Jacek Danecki Date: Wed, 14 Mar 2012 14:33:05 -0700 In-Reply-To: References: X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Message-ID: <1331760786.17334.18.camel@ultramagnus.opencreations.com> Mime-Version: 1.0 X-Gm-Message-State: ALoCoQncVK1wkypYtA1fTS1rYX1ZF3upwDnnTgEXFMel/h3ak2Tf9U0LnslFxQeRBMDwKg7seE5p Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Wed, 2012-03-14 at 17:11 -0400, Alan Stern wrote: > I see. It's a nasty situation; I guess the best way to describe it is > a conflict between the requirements of the PM and SCSI subsystems: > > The PM core runs suspend and resume operations in async > threads, and these threads need to acquire the device lock; > > The sd driver needs to insure that async probing is finished > when starting its remove routine, and it is called with the > device lock held. > > The best solution might be to use a workqueue for sd's async probing > instead of the "async" threads. Then the work routine could be > cancelled without doing async_synchronize_full(). Hmm... I was wondering why we needed a kernel global sync. If this is just for probe work what about just doing something like the following? Keep the sync operation local to probe-work and not entangle with the resume-work? I'll give this a shot when I get back to my test system. --- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index bd17cf8..ec69e35 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2629,6 +2629,8 @@ static void sd_probe_async(void *data, async_cookie_t cookie) put_device(&sdkp->dev); } +static LIST_HEAD(sd_probe_domain); + /** * sd_probe - called during driver initialization and whenever a * new scsi device is attached to the system. It is called once @@ -2717,7 +2719,7 @@ static int sd_probe(struct device *dev) dev_set_drvdata(dev, sdkp); get_device(&sdkp->dev); /* prevent release before async_schedule */ - async_schedule(sd_probe_async, sdkp); + async_schedule_domain(sd_probe_async, sdkp, &sd_probe_domain); return 0; @@ -2751,7 +2753,7 @@ static int sd_remove(struct device *dev) sdkp = dev_get_drvdata(dev); scsi_autopm_get_device(sdkp->device); - async_synchronize_full(); + async_synchronize_full_domain(&sd_probe_domain); blk_queue_prep_rq(sdkp->device->request_queue, scsi_prep_fn); blk_queue_unprep_rq(sdkp->device->request_queue, NULL); device_del(&sdkp->dev);