lkml.org 
[lkml]   [2000]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG in ext2


On Sun, 6 Aug 2000, Andrew Morton wrote:

> > > I'm getting a 100% reproducible assertion failure at balloc.c:558:
> > >
> > > * way it could happen, thus the BUG().
> > > */
> > > if (*prealloc_count)
> > > BUG();
> > > *prealloc_count = 0;
> > > *prealloc_block = next_block;
> > > /* Writer: end */
> > >
> > > This is happening when running mmap002. I've put a gdb backtrace up at
> > > http://www.uow.edu.au/~andrewm/ext2.txt
> >
> > Unfortunately, the whole ext2 block allocation code was re-written
> > recently by Al Viro for test6-pre1, and it looks like it has bugs (see
> > also thread <test6-pre2 loop in ext2_get_block>)...
>
> I suspect this problem is a simple one. Replacing the BUG() with a
> printk(*prealloc_count) reveals that it is non-zero about six times during an
> mmap002 run. Values vary from 1 to 7. No problems observed from this
> workaround.

Interesting... _If_ that happens - we have a bug somewhere that gives us a
slow block leak.

Look: if *prealloc_count is non-zero - we have several blocks (from
*prealloc_block to *prealloc_block+*prealloc_count-1) marked as busy in
the bitmap, but not attached to inode (yet). The next lines destroy all
information about them - here's an instant leak for you. Normally
ext2_discard_prealloc() would take care about freeing them, but it is not
going to find them...

_If_ that assertion is triggered - too bad, it means that we just didn't
notice that leak until now.


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

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans