linux-kernel - Re: [PATCH] amiflop: get rid of sleep

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]

Date:	Wed, 10 Dec 2008 09:16:40 +0100
From:	Joerg Dorchain <joerg@...chain.net>
To:	linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] amiflop: get rid of sleep_on calls

On Wed, Dec 10, 2008 at 01:48:10AM +0100, Andreas Bombe wrote:
> I think we're not talking about the same problem.  If I were to use
> complete() together with wait_for_completion() there would be a problem
> if fd_motor_on() can get as far as wait_for_completion() while a
> previous completion is yet uncompleted.  This can not happen for
> different drives, as the fd_select() would block.  If it could happen
> for the same drive, the complete() would allow only one task to
> continue.  The complete_all() takes care of that.
> 
> If requests are serialized for a drive so that there won't ever be two
> running at the same time for certain (thinking about it, it's probable),
> I could make it a simple complete().  It's hardly worth the risk,
> however.

IIRC (have not touched the driver for quite some time) at a
certain stage all requests for a specific drive are serialized.
The amiga floppy drives read and write whole tracks only, so
follow-up acesses are likely to be on the same track and then
served from the buffer of decoded blocks. I you do wild track
jumping, it is slower than the original AmigaOS-driver.

But as I am not sure, and floppy drives are slow anyway, the
complete_all() won't give any notable performance penalty, I guess.

Joerg

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)