From: Jeff Garzik <jeff@garzik.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
Boaz Harrosh <bharrosh@panasas.com>,
James.Bottomley@suse.de, nab@linux-iscsi.org,
linux-scsi@vger.kernel.org,
Linux IDE mailing list <linux-ide@vger.kernel.org>
Subject: Re: Full hostlock pushdown available
Date: Tue, 02 Nov 2010 14:13:20 -0400 [thread overview]
Message-ID: <4CD054C0.4010309@garzik.org> (raw)
In-Reply-To: <20101102175336.GA2167@basil.fritz.box>
On 11/02/2010 01:53 PM, Andi Kleen wrote:
>> Boaz' approach is OBVIOUSLY mechanical, correct and bisectable.
>> Yours is not.
>
> Sorry Jeff, but my patch has 100% the same locking order as Boaz.
> The only difference is in which function it is.
Incorrect. Please re-read your own code.
Your code eliminates the drop+reacquire of the host_lock, choosing
instead a brand new, untested, unreviewing locking scheme of holding the
host_lock for the entirety of libata's queuecommand run.
In contrast, Boaz' proposed pattern of adding stub functions such as
int queuecmd_unlocked(scsi_cmd cmd, callback done)
{
lock_irqsave
get serial
call driver's existing queuecommand
unlock_irqrestore
}
does not change libata's locking at all, because it does not modify a
driver's queuecommand at all. It is obviously correct.
Or to restate another way,
Current libata locking
----------------------
spin_lock_irqsave(host_lock)
spin_unlock(host_lock)
spin_lock(ap lock)
...
spin_unlock(ap lock)
spin_lock(host_lock)
spin_unlock_irqrestore(host_lock)
Andi's brand new locking scheme
(missing the release of host lock)
----------------------------------
spin_lock_irqsave(host_lock)
spin_lock(ap lock)
...
spin_unlock(ap lock)
spin_unlock_irqrestore(host_lock)
The two versions are quite obviously NOT equivalent in any way, because
you have ADDED the holding of host_lock for the duration of libata's
queuecommand.
Jeff
next prev parent reply other threads:[~2010-11-02 18:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101028150508.GA2385@basil.fritz.box>
[not found] ` <4CCD5F7F.8020808@panasas.com>
[not found] ` <tkrat.c4793af298337eff@s5r6.in-berlin.de>
[not found] ` <4CCE271D.7040400@garzik.org>
[not found] ` <20101101135338.GA25817@basil.fritz.box>
[not found] ` <4CCEE33F.5030300@garzik.org>
[not found] ` <20101101175742.GG25817@basil.fritz.box>
2010-11-01 18:59 ` Full hostlock pushdown available Jeff Garzik
2010-11-01 21:06 ` Nicholas A. Bellinger
2010-11-02 9:21 ` Andi Kleen
2010-11-02 15:59 ` Jeff Garzik
2010-11-02 17:53 ` Andi Kleen
2010-11-02 18:13 ` Jeff Garzik [this message]
2010-11-02 18:38 ` Nicholas A. Bellinger
2010-11-02 18:50 ` Jeff Garzik
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=4CD054C0.4010309@garzik.org \
--to=jeff@garzik.org \
--cc=James.Bottomley@suse.de \
--cc=andi@firstfloor.org \
--cc=bharrosh@panasas.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=stefanr@s5r6.in-berlin.de \
/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 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).