linux-kernel - Re: [PATCH 2/4 v2] libata: Implement disk shock protection support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87fxnwkwov.fsf@denkblock.local>
Date:	Fri, 19 Sep 2008 17:00:16 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Tejun Heo <htejun@...il.com>
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

Tejun Heo <htejun@...il.com> wrote:
> 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.

Will do. By the way, it's just occurred to me that we really need to
call complete_all() in ata_scsi_park_store(). So, thanks for making me
think it all through once more.

Regards,

Elias
--
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/