All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Elias Oltmanns <eo@nebensachen.de>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Jeff Garzik <jeff@garzik.org>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4 v2] libata: Implement disk shock protection support
Date: Fri, 19 Sep 2008 05:14:23 -0700	[thread overview]
Message-ID: <48D3979F.10305@gmail.com> (raw)
In-Reply-To: <87skrwmpng.fsf@denkblock.local>

Hello, Elias.

Elias Oltmanns wrote:
>>> +	do {
>>> +		unsigned long now;
>>> +
>>> +		deadline = jiffies;
>>> +		ata_port_for_each_link(link, ap) {
>>> +			ata_link_for_each_dev(dev, link) {
>>> +				struct ata_eh_info *ehi = &link->eh_context.i;
>>> +
>>> +				if (dev->class != ATA_DEV_ATA)
>>> +					continue;
>>> +
>>> +				ata_eh_pull_action(link, dev, ATA_EH_PARK);
>>> +				if (ehi->dev_action[dev->devno] & ATA_EH_PARK) {
>>> +					unsigned long tmp =
>>> +						dev->unpark_deadline;
>>> +
>>> +					if (time_before(deadline, tmp))
>>> +						deadline = tmp;
>>> +					else if (time_before_eq(tmp, jiffies))
>>> +						continue;
>>> +				}
>>> +
>>> +				ata_eh_park_issue_cmd(dev, 1);
>>> +			}
>>> +		}
>>> +		now = jiffies;
>>> +		if (time_before_eq(deadline, now))
>>> +			break;
>>> +		prepare_to_wait(&ata_scsi_park_wq, &wait, TASK_UNINTERRUPTIBLE);
>> Doesn't prepare_to_wait() have to come before pull_action and timeout
>> check?  Which in turn means that it should be a completion instead of
>> wait combined with INIT_COMPLETION because thread state can't be used
>> to track wake up as ata_eh_park_issue_cmd() sleeps.
> 
> Very well spotted, I obviously have to get to know more about these
> things.

Yay, even I am right sometimes.  :-)

> Now, even though I believe that I got the general point you are
> making, I'm not quite sure about what you are saying about wait combined
> with INIT_COMPLETION not being the right thing. In fact, that's
> precisely what I'm going to propose as a solution to our problem. Please
> tell me if I got something fundamentally wrong here.
> 
> The thing grew into a rather more complex problem than I had thought at
> first,

The code itself isn't too bad, I think.

> so I'm just resending the whole patch. Please let me know what
> you think.
> 
> @@ -2830,6 +2878,51 @@ int ata_eh_recover(struct ata_port *ap, ata_prereset_fn_t prereset,
>  		}
>  	}
>  
> +	do {
> +		unsigned long now;
> +
> +		ata_eh_pull_park_action(ap);
> +		deadline = jiffies;
> +		ata_port_for_each_link(link, ap) {
> +			ata_link_for_each_dev(dev, link) {
> +				struct ata_eh_context *ehc = &link->eh_context;
> +				unsigned long tmp;
> +
> +				if (dev->class != ATA_DEV_ATA)
> +					continue;
> +				if (!(ehc->i.dev_action[dev->devno] &
> +				      ATA_EH_PARK))
> +					continue;
> +				tmp = dev->unpark_deadline;
> +				if (time_before(deadline, tmp))
> +					deadline = tmp;
> +				else if (time_before_eq(tmp, jiffies))
> +					continue;
> +				if (ehc->unloaded_mask & (1 << dev->devno))
> +					continue;
> +
> +				ata_eh_park_issue_cmd(dev, 1);
> +			}
> +		}
> +
> +		now = jiffies;
> +		if (time_before_eq(deadline, now))
> +			break;
> +
> +		deadline = wait_for_completion_timeout(&ap->park_req_pending,
> +						       deadline - now);
> +	} while (deadline);

This should basically work but completion isn't really designed for
this type of continuous events where single consumption should clear
all pending events.  INIT_COMPLETION comes close but it doesn't lock,
so can't guarantee anything.  What's necessary is the counterpart for
complete_all() for the wait.

Well, anyways, I think the issue is slightly out of scope for this
patch and the only side effect is possibly looping over the do {}
while () block several times unnecessarily on certain cases, so I
think just noting about it should be enough for now.

Can you please add explanation above wait_for_complete_timeout() that
all done counts should be cleared here but aren't and as a result the
loop might repeat determinate number of times unnecessarily and resend
as proper patch?

Thanks for your patience.

-- 
tejun

  reply	other threads:[~2008-09-19 12:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17 16:28 Disk shock protection in GNU/Linux Elias Oltmanns
2008-09-17 16:34 ` [PATCH 1/4 v2] Introduce ata_id_has_unload() Elias Oltmanns
2008-09-17 16:57   ` Tejun Heo
2008-09-18 23:24     ` Bartlomiej Zolnierkiewicz
2008-09-17 16:37 ` [PATCH 2/4 v2] libata: Implement disk shock protection support Elias Oltmanns
2008-09-17 18:03   ` Tejun Heo
2008-09-17 18:08   ` Tejun Heo
2008-09-17 18:09   ` Tejun Heo
2008-09-19  9:49     ` Elias Oltmanns
2008-09-19 12:14       ` Tejun Heo [this message]
2008-09-19 14:06         ` Elias Oltmanns
2008-09-19 14:15           ` Tejun Heo
2008-09-19 15:00             ` Elias Oltmanns
2008-09-20  4:48               ` Tejun Heo
2008-09-17 16:38 ` [PATCH 3/4 v2] ide: " Elias Oltmanns
2008-09-18 23:24   ` Bartlomiej Zolnierkiewicz
2008-09-19  0:28     ` Elias Oltmanns
2008-09-19  0:47       ` Bartlomiej Zolnierkiewicz
2008-10-04  9:44     ` Elias Oltmanns
2008-10-04 13:49       ` Elias Oltmanns
2008-10-04 23:16         ` Elias Oltmanns
2008-10-08 18:56           ` Bartlomiej Zolnierkiewicz
2008-09-17 16:40 ` [PATCH 4/4 v2] Add documentation for hard disk shock protection interface Elias Oltmanns
2008-09-18 23:28   ` Bartlomiej Zolnierkiewicz
2008-10-04  9:55     ` Elias Oltmanns
2008-10-08 18:56       ` Bartlomiej Zolnierkiewicz
2008-09-19  4:21   ` Grant Grundler
2008-09-19 12:08     ` Elias Oltmanns
     [not found]   ` <1221724782.3261.13.camel@raz>
2008-09-19  9:50     ` [PATCH 4/4 v2] Add documentation for hard disk shockprotection interface Elias Oltmanns
2008-09-19 20:03       ` raz ben yehuda
2008-09-19 22:05         ` Elias Oltmanns
2008-09-20 23:25           ` Tejun Heo

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=48D3979F.10305@gmail.com \
    --to=htejun@gmail.com \
    --cc=bzolnier@gmail.com \
    --cc=eo@nebensachen.de \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.