From: Ion Badulescu <ionut@cs.columbia.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.4.0test10 crash (RAID+SMP)
Date: Mon, 6 Nov 2000 16:02:40 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.21.0011061601120.7242-100000@age.cs.columbia.edu> (raw)
[s/rutgers.edu/kernel.org/]
On Tue, 7 Nov 2000 09:19:12 +1100 (EST), Neil Brown <neilb@cse.unsw.edu.au>
wrote:
> On Monday November 6, jgarzik@mandrakesoft.com wrote:
>> If multiple interrupts are hitting a single code path (like IDE irqs 14
>> -and- 15), you definitely have to think about that. The reentrancy
>> guarantee only exists when a single IRQ is assigned to a single
>> handler...
>>
> The b_end_io routine that raid1 attaches to io request buffer_heads
> that are used for resyncing had a side effect of re-enabling
> interrupts. As it is called from an interrupt context, this is
> clearly a bug. It allowed another interrupt to be serviced before a
> previous interrupt had been completed, which is a problem waiting to
> happen.
> In this case, it became a real problem because the first interrupt had
> grabbed a spinlock (I didn't bother to discover which one) and the
> second interrupt tried to grab the same spinlock. This produced the
> deadlock which the NMI-Oopser detected and reported.
You are absolutely right, it is a bug, but Jeff is also right in pointing
that the bug won't hit you unless you have two different hardware IRQ's
being serviced by the same code. Otherwise, just enabling the interrupts
won't re-enable _your_ IRQ, so another interrupt triggered by your IRQ
won't be serviced until you exit the handler.
It could also be that the code is running with SA_INTERRUPT and is relying
on the fact that _all_ interrupts are disabled. That's less likely,
especially since AFAIK the interrupts are disabled only on the local
processor, so it's not much of a guarantee on SMP.
In any case, a bug is a bug and should get fixed, no question about it. :)
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2000-11-07 0:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 0:02 Ion Badulescu [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-11-05 21:08 Kernel 2.4.0test10 crash (RAID+SMP) ryan
2000-11-06 0:04 ` Keith Owens
2000-11-06 1:39 ` ryan
2000-11-06 3:12 ` Neil Brown
2000-11-06 0:09 ` ryan
2000-11-06 9:00 ` Jeff Garzik
2000-11-06 9:40 ` Andre Hedrick
2000-11-06 22:19 ` Neil Brown
2000-11-06 11:51 ` Jason Straight
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=Pine.LNX.4.21.0011061601120.7242-100000@age.cs.columbia.edu \
--to=ionut@cs.columbia.edu \
--cc=linux-kernel@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 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).