Andrew Morton wrote:
>
> "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...
>
It appears that this problem is not fixed.
My destroy_inode() is now
static void destroy_inode(struct inode *inode)
{
if (!list_empty(&inode->i_dirty_buffers)) {
printk("&inode->i_dirty_buffers=0x%p\n", &inode->i_dirty_buffers);
printk("next=0x%p\n", inode->i_dirty_buffers.next);
printk("prev=0x%p\n", inode->i_dirty_buffers.prev);
BUG();
}
kmem_cache_free(inode_cachep, (inode));
}
After 45 minutes of running the previously described tests:
Dec 2 16:14:30 mnm kernel: &inode->i_dirty_buffers=0xcfe16878
Dec 2 16:14:30 mnm kernel: next=0xc16f3678
Dec 2 16:14:30 mnm kernel: prev=0xc16f3678
Dec 2 16:14:30 mnm kernel: kernel BUG at inode.c:86!
We're throwing away an inode which has live data on its
dirty buffers list.
This is 2.4.0-test11-pre3 + list_del patch + sct's inode
patch (buffer.c, inode.c). x86 dual processor. gcc 2.91.66.
I rediffed my tree. No rogue patches.
It's not an SMP thing - the address patterns match up with the
previously reported uniprocessor corruption.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
