linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: linux-kernel@vger.kernel.org, lkml-031028@amos.mailshell.com
Subject: Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
Date: Wed, 29 Oct 2003 14:19:31 -0800	[thread overview]
Message-ID: <20031029141931.6c4ebdb5.akpm@osdl.org> (raw)
In-Reply-To: <200310292149.h9TLnsNq024151@car.linuxhacker.ru>

Oleg Drokin <green@linuxhacker.ru> wrote:
>
> Hello!
> 
> Andrew Morton <akpm@osdl.org> wrote:
> >> Here are the results (output of dmesg) from booting a kernel with this
> >> patch:
> >> set_blocksize: size=4096
> >> buffer layer error at fs/buffer.c:431
> AM> hm, that didn't tell us much :(
> AM> Could you add Oleg's patch as well?
> 
> Actually it will say that device's block size is 4096 (confirming
> last set_blocksize was at least partially succesful),

Assuming that the printk is for the correct filesystem, yes.

> but what
> it does not tell us is how those buffers have survived after blocksize
> was changed and all buffers were invalidated.

Well reiserfs shouldn't be doing this:

    bh = sb_bread (s, offset / s->s_blocksize);
    ...
    sb_set_blocksize (s, sb_blocksize(rs));
    brelse (bh);

but still, truncate_inode_pages() should be removing all those pages
unconditionally.


> (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.

> So probably this page means do_invalidate_page() ... -> try_to_free_buffers()
> have failed for whatever reason.

See the pinned buffer, above.

> We did not write there yet, so this is not PageWriteback case.
> But if the read is still going on, I guess we won't free the page/buffers?
> Or am I missing some wait_on_buffer()?
> But anyway that might explains buffers being still in page, but not such
> a page present in a mapping. (except if we have not pickup this page from a list
> of free pages not looking that it still have stale buffers)

Yes, the page should have been removed from the mapping.


Amos, could you add this as well?

 25-akpm/mm/truncate.c |    8 ++++++++
 1 files changed, 8 insertions(+)

diff -puN mm/truncate.c~truncate_inode_pages-check mm/truncate.c
--- 25/mm/truncate.c~truncate_inode_pages-check	Wed Oct 29 14:13:43 2003
+++ 25-akpm/mm/truncate.c	Wed Oct 29 14:15:06 2003
@@ -174,6 +174,14 @@ void truncate_inode_pages(struct address
 		}
 		pagevec_release(&pvec);
 	}
+
+	if (lstart == 0) {
+		WARN_ON(mapping->nrpages);
+		WARN_ON(!list_empty(&mapping->clean_pages));
+		WARN_ON(!list_empty(&mapping->dirty_pages));
+		WARN_ON(!list_empty(&mapping->locked_pages));
+		WARN_ON(!list_empty(&mapping->io_pages));
+	}
 }
 
 EXPORT_SYMBOL(truncate_inode_pages);

_


  reply	other threads:[~2003-10-29 22:19 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" 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 [this message]
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
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=20031029141931.6c4ebdb5.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=green@linuxhacker.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml-031028@amos.mailshell.com \
    /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;
as well as URLs for NNTP newsgroup(s).