[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48D3B3EE.70702@gmail.com>
Date: Fri, 19 Sep 2008 07:15:10 -0700
From: Tejun Heo <htejun@...il.com>
To: Elias Oltmanns <eo@...ensachen.de>
CC: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Jeff Garzik <jeff@...zik.org>,
Randy Dunlap <randy.dunlap@...cle.com>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4 v2] libata: Implement disk shock protection support
Elias Oltmanns wrote:
>> 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.
>
> You are right that it isn't designed for this use case and my approach
> is somewhat hackish. Still, it really does exactly what we want. Please
> note that ap->park_req_pending is protected by the host lock; the call
> to complete() is atomic wrt the setting of ATA_EH_PARK for one of the
> devices on the port and so is the call to INIT_COMPLETION() wrt clearing
> ATA_EH_PARK requests for *all* devices on the port.
>
>> 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?
>
> Well, we don't really care about the done count after
> wait_for_completion_timeout() has returned. All that matters is that the
> done counter is cleared when all ATA_EH_PARK actions have been pulled in
> which happens at the start of each cycle over the loop.
>
> Perhaps I should add comments to this effect before
> wait_for_completion_timeout() as well as INIT_COMPLETION()?
Ah... I missed the pull_park_action part. Yes, in that case, it's
correct now but I would really appreciate you explain amply what's
going on inside the pull function and why it's needed.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists