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

From: Andrew Morton (akpm_at_osdl.org)
Date: 11/02/03

  • Next message: Geoffrey Lee: "Re: [patch] reproducible athlon mce fix" 
    Date:	Sat, 1 Nov 2003 23:33:54 -0800
To: Herbert Xu <herbert@gondor.apana.org.au>

    Herbert Xu <herbert@gondor.apana.org.au> wrote:
    >
    > Andrew Morton <akpm@osdl.org> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Geoffrey Lee: "Re: [patch] reproducible athlon mce fix"

    Relevant Pages

    • Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
      ... >> The person who had the problem is actually using the Debian tree which ... Sigh. ... > pagecache: they're gone. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 12/17] vfs: pagecache usage optimization for pagesize!=blocksize
      ... pagecache of corresponding index but this page is not uptodate, ... the other testing buffer uptodate then reading from the ... this is basically the same class of data race ...
      (Linux-Kernel)
    • Re: Question about buffer.c
      ... mounted loop device the buffer cache memory is growing up - I want to ... freeing it when you are done with everything. ... Note that buffers are used just to make access to data in pagecache ...
      (Linux-Kernel)
    • RE: why swap at all?
      ... Once the pagecache fills up, ... > opinion on the direction VM system development should go. ... > very ambitious goals. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 2] mm: speculative get_page
      ... There isn't because higher order pages aren't used for pagecache. ... There are appropriate memory barriers: ... Send instant messages to your online friends http://au.messenger.yahoo.com ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)