From: Jamie Clark <jclark@metaparadigm.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: 2.4.23aa1 ext3 oops
Date: Thu, 18 Dec 2003 14:19:50 +0800 [thread overview]
Message-ID: <3FE14706.3070003@metaparadigm.com> (raw)
In-Reply-To: <1071661358.13152.26.camel@imladris.demon.co.uk>
David Woodhouse wrote:
>On Thu, 2003-12-11 at 10:33 +0800, Jamie Clark wrote:
>
>
>>After a quick browse of the assembler output the zeroing would appear to
>>be part of the list_del inline, and edi seems to equate to &sb.
>>
>>
>Seems reasonable. It does look like something's stomped on sb->s_dirty.
>
>
>>__mark_inode_dirty() does not appear to take sb_lock before adding to
>>the s_dirty list. Could that be the culprit?
>>
>>
>
>I don't think so; it's holding the inode_lock which should be
>sufficient. Besides -- in practice all updates to the 4-byte pointer
>sb->s_dirty.next are going to be atomic, and there's no reason _ever_
>for it to be set to d7ffbc08. It's hard to see how a simple locking
>problem is going to cause such a thing.
>
>
True. I confess I didn't think too hard after narrowing down where it
tripped up.
>How repeatable is this?
>
The first oops ocurred after 4 or 5 days. My second run crashed in the
first night, this time in filemap.c: precheck_file_write().
This oops seemed to be at or near the first dereference of inode, before
the f_flags test.
/* FIXME: this is for backwards compatibility with 2.4 */
if (!S_ISBLK(inode->i_mode) && (file->f_flags & O_APPEND))
*ppos = pos = inode->i_size;
>>EIP; c01306fb <precheck_file_write+53/1f8> <=====
Trace; c01308f8 <generic_file_write_nolock+58/4c8>
Trace; c013108f <generic_file_write+13f/158>
Trace; c016f3a7 <ext3_file_write+23/bc>
Trace; c0140e57 <sys_write+8f/100>
Trace; c0107133 <system_call+33/38>
>Can you turn on slab poisoning?
>
>
Is CONFIG_DEBUG_SLAB all that I need?
I'm currently running 2.4.23aa1 with the inode.c patch reversions as
Marcelo first suggested. When (IF) that crashes, or if I can get the
test running on another SMP box I will revert to 2.4.23 + the qla2300
driver that I need for the fibre-channel array.
-Jamie
next prev parent reply other threads:[~2003-12-18 6:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-04 2:49 2.4.23pre6aa3 scsi oops Jamie Clark
2003-11-04 10:28 ` Andrea Arcangeli
2003-11-04 11:52 ` Jamie Clark
2003-11-04 12:48 ` Andrea Arcangeli
2003-11-27 3:21 ` 2.4.23pre6aa3 - possible ext3 deadlock Jamie Clark
2003-11-27 12:56 ` Jan Kara
2003-12-06 1:05 ` 2.4.23pre6aa3 scsi oops Andrea Arcangeli
2003-12-06 1:39 ` Jamie Clark
2003-12-11 2:33 ` 2.4.23aa1 ext3 oops Jamie Clark
2003-12-16 15:15 ` Marcelo Tosatti
2003-12-16 15:55 ` Jamie Clark
2003-12-17 11:42 ` David Woodhouse
2003-12-18 6:19 ` Jamie Clark [this message]
2003-12-18 6:25 ` David Woodhouse
2003-12-18 7:33 ` Jamie Clark
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=3FE14706.3070003@metaparadigm.com \
--to=jclark@metaparadigm.com \
--cc=andrea@suse.de \
--cc=dwmw2@infradead.org \
--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).