From: Andrew Morton <akpm@osdl.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: green@linuxhacker.ru, linux-kernel@vger.kernel.org
Subject: Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
Date: Sat, 1 Nov 2003 23:33:54 -0800 [thread overview]
Message-ID: <20031101233354.1f566c80.akpm@osdl.org> (raw)
In-Reply-To: <E1AGCUJ-00016g-00@gondolin.me.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.
next prev parent reply other threads:[~2003-11-02 7:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-28 15:49 lkml-031028
2003-10-28 18:36 ` Hans Reiser
2003-10-28 20:27 ` Oleg Drokin
2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
2003-10-29 6:56 ` lkml-031028
2003-10-29 17:44 ` lkml-031028
2003-10-29 20:31 ` Andrew Morton
2003-10-29 21:49 ` Oleg Drokin
2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
2003-10-30 6:51 ` lkml-031028
2003-11-02 7:17 ` Herbert Xu
2003-11-02 7:33 ` Andrew Morton [this message]
2003-11-02 9:18 ` Oleg Drokin
2003-11-02 9:27 ` Herbert Xu
2003-11-02 9:40 ` Andrew Morton
2003-11-02 9:54 ` Herbert Xu
2003-11-02 11:54 ` Hans Reiser
2003-11-02 21:09 ` Herbert Xu
2003-11-03 10:20 ` Stephan von Krawczynski
2003-11-04 8:10 ` Hans Reiser
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
2003-11-04 9:54 ` Hans Reiser
2003-11-04 23:49 ` Stephan von Krawczynski
2003-11-05 0:05 ` Mike Fedyk
2003-11-16 13:05 ` Pavel Machek
2003-11-16 3:55 ` Hans Reiser
2003-11-16 14:15 ` Stephan von Krawczynski
2003-11-16 17:05 ` Pavel Machek
2003-11-16 17:27 ` Valdis.Kletnieks
2003-11-16 17:40 ` Stephan von Krawczynski
2003-11-16 18:38 ` Valdis.Kletnieks
2003-11-16 22:54 ` Stephan von Krawczynski
2003-11-16 17:30 ` Stephan von Krawczynski
2003-11-02 11:50 ` Hans Reiser
2003-11-02 20:33 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031101233354.1f566c80.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=green@linuxhacker.ru \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®