linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Tejun Heo <tj@kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Alan Stern <stern@rowland.harvard.edu>,
	Oliver Neukum <oliver@neukum.org>, Jeff Wu <jeff.wu@amd.com>,
	Aaron Lu <aaron.lwe@gmail.com>, Shane Huang <shane.huang@amd.com>,
	linux-ide@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v8 09/11] block: add a new interface to block events
Date: Tue, 30 Oct 2012 15:04:17 +0800	[thread overview]
Message-ID: <508F7BF1.1040009@intel.com> (raw)
In-Reply-To: <20121029153536.GL5171@htj.dyndns.org>

On 10/29/2012 11:35 PM, Tejun Heo wrote:
> Hello,
> 
> On Mon, Oct 29, 2012 at 05:01:36PM +0800, Aaron Lu wrote:
>> ODD_suspend                        disk_events_workfn
>>   ata_port_suspend                   check_events
>>     disk_block_events                  resume ODD
>>       cancel_delayed_work_sync           resume parent
>>       (waiting for disk_events_workfn)   (waiting for suspend callback)
> 
> I don't understand why solving it needs to be this elaborate.
							:-)

> check_event() can retry.  Just add a per-sr mutex which is try-locked
> by sr_block_check_events() and grab it when entering zero power.

Good suggestion. I didn't think about solving it this way.

Many people suggest me that ZPODD is pure SATA/ACPI stuff, and should
not pollute sr driver, so I was trying hard not to touch sr while
preparing these patches, unless there is no other choice(like the
blocking event interface).

So I'm not sure if your suggestion is the way to go.

James, what do you think? Is it OK if I add a mutex into the scsi_cd
structure to do this? Of course I'll define this only under
CONFIG_SATA_ZPODD.

> 
>> +/*
>> + * Under some circumstances, there is a race between the calling thread
>> + * of disk_block_events and the events checking function. To avoid such a race,
>> + * this function will check if the delayed work is pending. If not, it means
>> + * the work is either not queued or is already running, false is returned.
>> + * And if yes, try to cancel the delayed work. If succedded, disk_block_events
>> + * will be called and there is no worry that cancel_delayed_work_sync will
>> + * deadlock the events checking function. And if failed, false is returned.
>> + */
>> +bool disk_try_block_events(struct gendisk *disk)
>> +{
>> +	struct disk_events *ev = disk->ev;
>> +
>> +	if (!ev)
>> +		return false;
>> +
>> +	if (delayed_work_pending(&ev->dwork)) {
> 
> And please don't use delayed_work_pending() like this.  It doesn't add
> anything.  cancel_delayed_work() already needs to perform all the
> necessary tests.

OK, thanks for the suggestion.

-Aaron

> 
>> +		if (cancel_delayed_work(&disk->ev->dwork)) {
>> +			disk_block_events(disk);
>> +			return true;
>> +		}
>> +	}
>> +
>> +	return false;
>> +}
> 
> Thanks.
> 


  reply	other threads:[~2012-10-30  7:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29  9:01 [PATCH v8 00/11] ZPODD Patches Aaron Lu
2012-10-29  9:01 ` [PATCH v8 01/11] scsi: sr: support runtime pm Aaron Lu
2012-10-29  9:01 ` [PATCH v8 02/11] ata: zpodd: Add CONFIG_SATA_ZPODD Aaron Lu
2012-10-29 18:11   ` James Bottomley
2012-10-30  3:19     ` Aaron Lu
2012-10-29  9:01 ` [PATCH v8 03/11] ata: zpodd: identify and init ZPODD devices Aaron Lu
2012-10-29  9:01 ` [PATCH v8 04/11] libata: acpi: move acpi notification code to sata_zpodd Aaron Lu
2012-10-29  9:01 ` [PATCH v8 05/11] libata-eh: allow defer in ata_exec_internal Aaron Lu
2012-10-29 15:20   ` Tejun Heo
2012-10-30  3:00     ` Aaron Lu
2012-10-30  3:01       ` Tejun Heo
2012-10-30  3:09         ` Aaron Lu
2012-10-31 21:52           ` Tejun Heo
2012-11-01  2:35             ` Aaron Lu
2012-11-01 16:03               ` Tejun Heo
2012-11-02  0:43                 ` Aaron Lu
2012-10-29  9:01 ` [PATCH v8 06/11] ata: zpodd: check loading mechanism for ODD Aaron Lu
2012-10-29  9:01 ` [PATCH v8 07/11] libata: separate ATAPI code Aaron Lu
2012-10-29  9:01 ` [PATCH v8 08/11] ata: zpodd: check zero power ready status Aaron Lu
2012-10-29  9:01 ` [PATCH v8 09/11] block: add a new interface to block events Aaron Lu
2012-10-29 15:35   ` Tejun Heo
2012-10-30  7:04     ` Aaron Lu [this message]
2012-10-31 21:51       ` Tejun Heo
2012-11-01  6:30         ` Aaron Lu
2012-10-29  9:01 ` [PATCH v8 10/11] scsi: sr: support (un)block events Aaron Lu
2012-10-29 18:11   ` James Bottomley
2012-10-29 22:22     ` Alan Stern
2012-10-30  4:34       ` James Bottomley
2012-10-30  5:02     ` Aaron Lu
2012-10-29  9:01 ` [PATCH v8 11/11] ata: zpodd: handle power transition of ODD Aaron Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=508F7BF1.1040009@intel.com \
    --to=aaron.lu@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aaron.lwe@gmail.com \
    --cc=jeff.wu@amd.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=rjw@sisk.pl \
    --cc=shane.huang@amd.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).