From: Andrew Morton <andrewm@uow.edu.au>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Alexander Viro <viro@math.psu.edu>,
Jonathan Hudson <jonathan@daria.co.uk>,
linux-kernel@vger.kernel.org
Subject: Re: corruption
Date: Sat, 02 Dec 2000 14:59:30 +1100 [thread overview]
Message-ID: <3A2873A1.3EFEA29@uow.edu.au> (raw)
In-Reply-To: <b09.3a269edc.6bd12@trespassersw.daria.co.uk> <Pine.GSO.4.21.0011301400290.20801-100000@weyl.math.psu.edu> <3A26C82D.26267202@uow.edu.au>, <3A26C82D.26267202@uow.edu.au>; from andrewm@uow.edu.au on Fri, Dec 01, 2000 at 08:35:41AM +1100 <20001201141659.A4562@redhat.com>
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Fri, Dec 01, 2000 at 08:35:41AM +1100, Andrew Morton wrote:
> >
> > I bet this'll catch it:
> >
> > static __inline__ void list_del(struct list_head *entry)
> > {
> > __list_del(entry->prev, entry->next);
> > + entry->next = entry->prev = 0;
> > }
>
> No, because the buffer hash list is never referenced unless
> buffer->b_inode is non-null, so we can't ever do a double-list_del on
> the buffer.
>
> The patch below should fix it. It has been sent to Linus. The
> important part is the first hunk of the inode.c diff.
Testing test11-pre3 with your inode.c patch and the above list_del
patch. x86 dual processor, IDE. Same workload as before, except
I cut out misc001 (and the machine recovered almost immediately
when I killed everything! Need more testing to characterise this).
kernel BUG at inode.c:83! The trace is below. Now, this was
probably triggered by my list_del change. If so it means
that we're doing a list_empty() test on a list_head which
has actually been deleted from a list. So it's possibly the
actual assertion in destroy_inode() which is a little bogus.
But the wierd thing is that this BUG only hit a single time,
after three hours of intensive testing. If my theory is
right, the BUG should hit every time. Will investigate further...
ksymoops 0.7c on i686 2.4.0-test12-pre3. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12-pre3/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Reading Oops report from the terminal
Dec 2 13:15:45 mnm kernel: invalid operand: 0000
Dec 2 13:15:45 mnm kernel: CPU: 0
Dec 2 13:15:45 mnm kernel: EIP: 0010:[<c014570e>]
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 2 13:15:45 mnm kernel: EFLAGS: 00010282
Dec 2 13:15:45 mnm kernel: eax: 0000001a ebx: c78686e0 ecx: 00000000 edx: 0000002f
Dec 2 13:15:45 mnm kernel: esi: c025b800 edi: cd950960 ebp: c7869160 esp: ce611f3c
Dec 2 13:15:45 mnm kernel: ds: 0018 es: 0018 ss: 0018
Dec 2 13:15:45 mnm kernel: Process dbench (pid: 13094, stackpage=ce611000)
Dec 2 13:15:45 mnm kernel: Stack: c021b7e5 c021b8a5 00000053 c78686e0 c0146916 c78686e0 c7869160 c78686e0
Dec 2 13:15:45 mnm kernel: c0145096 c78686e0 00000000 ce610000 c013de4d c7869160 c7869160 c9b1e000
Dec 2 13:15:45 mnm kernel: ce611fa4 c7869160 cd9509d0 c013df25 cd950960 c7869160 ce610000 bffff5ca
Dec 2 13:15:45 mnm kernel: Call Trace: [<c021b7e5>] [<c021b8a5>] [<c0146916>] [<c0145096>] [<c013de4d>] [<c013df25>
Dec 2 13:15:45 mnm kernel: [<c010002b>]
Dec 2 13:15:45 mnm kernel: Code: 0f 0b 83 c4 0c 53 a1 10 d1 2a c0 50 e8 cd 3d fe ff 83 c4 08
>>EIP; c014570e <destroy_inode+1e/34> <=====
Trace; c021b7e5 <tvecs+5a3d/1a3d8>
Trace; c021b8a5 <tvecs+5afd/1a3d8>
Trace; c0146916 <iput+18e/194>
Trace; c0145096 <d_delete+66/ac>
Trace; c013de4d <vfs_unlink+18d/1c0>
Trace; c013df25 <sys_unlink+a5/118>
Trace; c010002b <startup_32+2b/cb>
Code; c014570e <destroy_inode+1e/34>
00000000 <_EIP>:
Code; c014570e <destroy_inode+1e/34> <=====
0: 0f 0b ud2a <=====
Code; c0145710 <destroy_inode+20/34>
2: 83 c4 0c add $0xc,%esp
Code; c0145713 <destroy_inode+23/34>
5: 53 push %ebx
Code; c0145714 <destroy_inode+24/34>
6: a1 10 d1 2a c0 mov 0xc02ad110,%eax
Code; c0145719 <destroy_inode+29/34>
b: 50 push %eax
Code; c014571a <destroy_inode+2a/34>
c: e8 cd 3d fe ff call fffe3dde <_EIP+0xfffe3dde> c01294ec <kmem_cache_free+0/7c>
Code; c014571f <destroy_inode+2f/34>
11: 83 c4 08 add $0x8,%esp
1 warning issued. Results may not be reliable.
-
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 prev parent reply other threads:[~2000-12-02 4:26 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-29 21:54 corruption Andries.Brouwer
2000-11-29 22:18 ` corruption Alexander Viro
2000-11-30 14:21 ` corruption Andrew Morton
2000-11-30 18:39 ` corruption Jonathan Hudson
2000-11-30 19:07 ` corruption Alexander Viro
2000-11-30 21:35 ` corruption Andrew Morton
2000-12-01 0:57 ` corruption Andrew Morton
2000-12-01 12:18 ` corruption Jens Axboe
2000-12-01 12:34 ` corruption Andrew Morton
2000-12-01 12:37 ` corruption Jens Axboe
2000-12-01 12:23 ` corruption Andrew Morton
2000-12-01 15:04 ` corruption Lawrence Walton
2000-12-01 14:16 ` corruption Stephen C. Tweedie
2000-12-01 23:28 ` corruption Andrew Morton
2000-12-02 0:30 ` corruption kumon
2000-12-02 3:59 ` Andrew Morton [this message]
2000-12-02 14:00 ` corruption Andrew Morton
2000-12-02 15:33 ` corruption Alexander Viro
2000-12-02 16:39 ` corruption Petr Vandrovec
2000-12-02 17:50 ` corruption Alexander Viro
2000-12-02 17:59 ` corruption Alexander Viro
2000-12-03 20:24 ` corruption Jonathan Hudson
2000-12-03 21:44 ` corruption Andrew Morton
2000-12-03 22:45 ` [resync?] corruption Alexander Viro
2000-12-04 0:56 ` Jeff V. Merkey
2000-12-04 15:00 ` corruption Stephen C. Tweedie
2000-12-04 15:19 ` corruption Alexander Viro
2000-12-01 17:29 ` corruption Jeff Garzik
[not found] <20001202161158.A475@ppc.vc.cvut.cz>
2000-12-02 15:35 ` corruption Petr Vandrovec
-- strict thread matches above, loose matches on Subject: below --
2000-11-29 13:44 corruption Andries.Brouwer
2000-11-29 14:10 ` corruption Tigran Aivazian
2000-11-29 14:16 ` corruption Alexander Viro
2000-11-29 14:26 ` corruption Jens Axboe
2000-11-29 11:16 corruption Andries.Brouwer
2000-11-29 17:47 ` corruption Linus Torvalds
2000-11-29 17:57 ` corruption Tigran Aivazian
2000-11-29 18:08 ` corruption Tigran Aivazian
2000-11-29 18:14 ` corruption Tigran Aivazian
2000-11-29 18:17 ` corruption Alexander Viro
2000-11-29 18:38 ` corruption Linus Torvalds
2000-11-29 18:47 ` corruption Tigran Aivazian
2000-11-29 18:07 ` corruption Zdenek Kabelac
2000-11-29 4:08 corruption Andries.Brouwer
2000-11-29 5:09 ` corruption Linus Torvalds
2000-11-29 9:08 ` corruption Alexander Viro
2000-11-29 9:20 ` corruption Tigran Aivazian
2000-11-29 9:26 ` corruption Alexander Viro
2000-11-29 10:52 ` corruption Tigran Aivazian
2000-11-29 18:56 ` corruption Andrea Arcangeli
2000-11-29 19:05 ` corruption Rik van Riel
2000-11-29 19:27 ` corruption Andrea Arcangeli
2000-11-29 20:02 ` corruption Rik van Riel
2000-11-29 19:25 ` corruption Linus Torvalds
2000-11-29 19:57 ` corruption Alexander Viro
2000-11-29 20:36 ` corruption Andrea Arcangeli
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=3A2873A1.3EFEA29@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=jonathan@daria.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=viro@math.psu.edu \
/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