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 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.