From: Tejun Heo <tj@kernel.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?
Date: Thu, 29 Jun 2017 15:53:22 -0400 [thread overview]
Message-ID: <20170629195322.GB9745@htj.duckdns.org> (raw)
In-Reply-To: <20170629181057.GA5228@linux.vnet.ibm.com>
Hello, Paul.
On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote:
> If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait()
> must have executed before CPU 1's spin_lock(). However, even on x86,
> CPU 0's prior writes can be reordered with its subsequent reads, which
> means that r1 == 0 is possible, which means that the above condition
> could hold, even on x86.
I see. Ah, that's a mind bender.
> One of the uses of spin_unlock_wait() is in ata_scsi_cmd_error_handler()
> in the file drivers/ata/libata-eh.c. Your commit ad9e27624479b
> ("libata-eh-fw: update ata_scsi_error() for new EH") last touched it,
> though it predates that commit.
>
> My question to you is whether the code in ata_scsi_cmd_error_handler()
> needs release semantics. If it does, my recommendation is to replace
> the spin_unlock_wait(ap->lock) with this (adding the needed curly braces,
> of course):
>
> spin_lock(ap->lock);
> spin_unlock(ap->lock);
>
> If the code only needs acquire semantics, no change required.
>
> If your code requires release semantics, and there is some reason why
> my suggested replacement above is a bad idea, please let me know!
That part of the code should be dead now. I don't think we no longer
have any driver which doesn't have error handler set. I should rip
out that if/else. Also, ACQUIRE semantics should be enough there.
Nothing changes from the EH side there.
Thanks.
--
tejun
next prev parent reply other threads:[~2017-06-29 19:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 18:10 Paul E. McKenney
2017-06-29 19:53 ` Tejun Heo [this message]
2017-06-29 20:14 ` Paul E. McKenney
2017-06-29 20:17 ` Tejun Heo
2017-06-29 20:48 ` Paul E. McKenney
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=20170629195322.GB9745@htj.duckdns.org \
--to=tj@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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
all inboxes | Powered by JetHome®