From: Andreas Bombe <aeb@debian.org>
To: Joerg Dorchain <joerg@dorchain.net>
Cc: linux-m68k@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] amiflop: get rid of sleep_on calls
Date: Wed, 10 Dec 2008 01:48:10 +0100 [thread overview]
Message-ID: <20081210004810.GA5073@infernal.debian.net> (raw)
In-Reply-To: <20081209082608.GA10651@Redstar.dorchain.net>
On Tue, Dec 09, 2008 at 09:26:08AM +0100, Joerg Dorchain wrote:
> On Mon, Dec 08, 2008 at 04:59:38PM +0000, Andreas Bombe wrote:
> > The replacement for the unconditional sleep_on() in fd_motor_on() is a
> > complete_all() together with a INIT_COMPLETION() before the mod_timer()
> > call. It appears to me that fd_motor_on() might be called concurrently
> > and fd_select() does not guarantee mutual exclusivity in the case the
> > same drive gets selected again.
>
> Selecting the same drive repeatly does not matter. The selected
> drive is the one the next command or transfer applies to.
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.
next prev parent reply other threads:[~2008-12-10 1:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-08 16:59 [PATCH] amiflop: get rid of sleep_on calls Andreas Bombe
2008-12-09 8:26 ` Joerg Dorchain
2008-12-10 0:48 ` Andreas Bombe [this message]
2008-12-10 8:16 ` Joerg Dorchain
2008-12-16 20:23 ` Geert Uytterhoeven
2008-12-17 8:00 ` Joerg Dorchain
2008-12-09 8:31 ` Geert Uytterhoeven
2008-12-09 18:34 ` Andreas Bombe
2008-12-10 1:02 ` [PATCH v2] " Andreas Bombe
2008-12-14 16:21 ` Geert Uytterhoeven
2008-12-23 14:22 ` Andreas Bombe
2008-12-31 16:30 ` Geert Uytterhoeven
2008-12-13 15:20 ` [PATCH] " Kolbjørn Barmen
2008-12-13 21:30 ` Geert Uytterhoeven
2008-12-13 21:30 ` Geert Uytterhoeven
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=20081210004810.GA5073@infernal.debian.net \
--to=aeb@debian.org \
--cc=joerg@dorchain.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
/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.