Re: 2.6.0test9 Reiserfs boot time "buffer layer error atfs/buffer.c:431"

From: Andrew Morton
Date: Sun Nov 02 2003 - 02:32:38 EST


Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Andrew Morton <akpm@xxxxxxxx> wrote:
> >
> >> (These buffers are there because reiserfs first reads that offset (in bytes)
> >> with whatever current blocksize is, except they should have been invalidated of
> >> course).
> >> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> >> everything, truncate_inode_pages() should have done this.
> >
> > yup.
>
> The person who had the problem is actually using the Debian tree which
> carried over a patch from 2.4 that removed the truncate_inode_pages
> call in set_blocksize. So I appologise for the noise.

aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
any other changes?

> However, may I ask what is preventing us from achieving the goal that
> the page cache backed buffer heads can be resized without throwing away
> the pages?

That _should_ work. The pagecache pages should be in such a state that all
buffers are freeable and yes, we can leave the pagecache there. But this
could cause problems if the device was repartitioned in between, or if it
was hotswapped. I don't think we shoot down pagecache anywhere else for
this.



truncate_inode_pages() will unconditionally remove the pages from
pagecache: they're gone. So if some poorly behaved piece of code
(reiserfs's read_super_block()) holds a reference against a buffer, that
piece of code ends up owning the page - the VFS has lost interest in it.

This is almost always very bad - if truncate_inode_pages() against a
blockdev fails to cleanly remove all pages then it often means memory
leakage or data corruption. I would like to have a warning which detects
this case but I never got around to it.

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