From: Andrew Morton <akpm@zip.com.au>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Paul Clements <Paul.Clements@SteelEye.com>,
marcelo@conectiva.com.br, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.18 raid1 - fix SMP locking/interrupt errors, fix resync counter errors
Date: Sun, 24 Mar 2002 15:24:05 -0800 [thread overview]
Message-ID: <3C9E6014.BB3DE865@zip.com.au> (raw)
In-Reply-To: message from Paul Clements on Friday March 22 <15518.22081.287786.88466@notabene.cse.unsw.edu.au>
Neil Brown wrote:
>
> ...
> The save/restore versions are only needed if the code might be called
> from interrupt context.
Or if the caller may wish to keep interrupts disabled.
> However the routines where you made this
> change: raid1_grow_buffers, raid1_shrink_buffers, close_sync,
> are only ever called from process context, with interrupts enabled.
> Or am I missing something?
If those functions are always called with interrupts enabled then
no, you're not missing anything ;)
However a bare spin_unlock_irq() in a function means that
callers which wish to keep interrupts disabled are subtly
subverted. We've had bugs from this before.
So the irqrestore functions are much more robust. I believe
that they should be the default choice. The non-restore
versions should be viewed as a micro-optimised version,
to be used with caution. The additional expense of the save/restore
is quite tiny - 20-30 cycles, perhaps.
-
next prev parent reply other threads:[~2002-03-24 23:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-24 22:42 [PATCH] 2.4.18 raid1 - fix SMP locking/interrupt errors, fix resync counter errors Neil Brown
2002-03-24 23:24 ` Andrew Morton [this message]
2002-03-25 18:33 ` Paul Clements
2002-03-25 18:52 ` Paul Clements
-- strict thread matches above, loose matches on Subject: below --
2002-03-26 1:52 Neil Brown
2002-03-26 22:06 ` Paul Clements
2002-03-22 18:28 Paul Clements
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=3C9E6014.BB3DE865@zip.com.au \
--to=akpm@zip.com.au \
--cc=Paul.Clements@SteelEye.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=neilb@cse.unsw.edu.au \
/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