lkml.org 
[lkml]   [2004]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: crashes in prune_icache() in 2.4.26
From
Made a little more progress...

Turns out the infinite loop wasn't in the CONFIG_HIGMEM while() loop, but
rather in the while() loop at the top of the code. Sorry about that. I
misunderstood the disassembly until now.
So basically both types of crashes I am seeing (NULL deref and infinite
loop) are happening in the primary/top while() loop of prune_icache()
and I suspect they are both the result of a corrupted inode_unused list.
Now I am trying to figure out where/how the inode_unused list is getting
corrupted... If anyone has any existing code for validating list
integrity, which I could sprinkle around the code, I'd love a copy.

Thanks,
Chris

On Mon, 31 May 2004, Chris Caputo wrote:
> [CC'ed lkml in case anyone else wants to take a shot.]
>
> A little more info... I added some printk's to the function to highlight
> the input value of parameter 'goal' and also to show where the function
> was returning.
>
> My understanding is these printk's all happened in rapid succession:
>
> entry > prune_icache(goal = 92370)
> exit < prune_icache() at if (goal <= 0)
>
> Above the function completed without entering the CONFIG_HIGHMEM while
> loop.
>
> entry > prune_icache(goal = 94037)
> exit < prune_icache() - end of function
>
> Above the function went through the CONFIG_HIGHMEM while loop. This was
> the first time this happened since boot, after a number of
> prune_icache() calls that had returned prior to the CONFIG_HIGHMEM while
> loop.
>
> entry > prune_icache(goal = 98609)
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
>
> The final printk above shows the function being entered and then hitting
> the NULL dereference.
>
> Chris
>
> On Sun, 30 May 2004, Chris Caputo wrote:
> > Hi. I have been experiencing a number of crashes in fs/inode.c's
> > prune_icache() function. I found on linux.bkbits.net that you made the
> > most recent major change to this function back in January. With that in
> > mind I hope it is okay to write directly to you.
> >
> > I have experienced two kinds of crashes with this function.
> >
> > The first is in the older part of the code. Basically the inode_unused
> > list is somehow getting corrupt and when it does an Oops happens at:
> >
> > entry = entry->prev; (line 808 of the 2.4.26 fs/inode.c)
> >
> > I haven't yet figured out how it is getting corrupt so any tips welcome.
> >
> > A second problem I have seen is that my system has gotten into an infinite
> > loop in the while loop in the CONFIG_HIGHMEM part of the prune_icache()
> > code. I haven't yet figured out why. But I am curious about the code at
> > the beginning of the loop:
> >
> > while (goal-- > 0) {
> > if (list_empty(&inode_unused_pagecache))
> > break;
> > entry = inode_unused_pagecache.prev;
> > list_del(entry);
> > list_add(entry, &inode_unused_pagecache);
> >
> > Is the intent of the last 3 lines to remove the entry from the end of the
> > linked-list and then add it to the front, as a way of traversing the list?
> > Or is it intended that the add be an add to the inode_unused list as
> > opposed to the inode_unused_pagecache list?
> >
> > I'd love to figure out the problems I am experiencing, so any advice on
> > how to proceed is welcome. The bug happens every few days on our main
> > fileserver and I have been able to reproduce it on a test fileserver too.
> >
> > Chris
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site