LKML Archive on 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
next prev parent reply other threads:[~2008-09-19 12:16 UTC|newest]
Thread overview: 28+ 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
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 \
--subject='Re: [PATCH 2/4 v2] libata: Implement disk shock protection support' \
/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
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).