All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Steven Dake <sdake@mvista.com>, Stian Jordet <liste@jordet.nu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	sct@redhat.logos.cnet, Andrew Morton <akpm@osdl.org>
Subject: Re: [2.4] page->buffers vanished in journal_try_to_free_buffers()
Date: Mon, 21 Jun 2004 12:53:13 -0300	[thread overview]
Message-ID: <20040621155313.GA12559@logos.cnet> (raw)
In-Reply-To: <1087830410.2719.53.camel@sisko.scot.redhat.com>

Hi Stephen,

On Mon, Jun 21, 2004 at 04:06:50PM +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Thu, 2004-06-17 at 14:16, Marcelo Tosatti wrote:
> 
> > Stephen, Andrew, do you have any idea how the buffers could have vanished
> > under us with the page locked? That should not be possible. 
> 
> No, especially not on UP as Frank reported.  
> 
> > I dont see how this "page->buffers = NULL" could be caused by hardware problem, 
> > which is usually one or two bit flip.
> 
> We don't know for sure that it's page->buffers.  If we have gone round
> the bh->b_this_page loop already, we could have ended up following the
> pointers either to an invalid bh, or to one that's not on the current
> page.  So it could also be the previous buffer's b_this_page that got
> clobbered, rather than page->buffers.
> 
> That's possible in this case, but it's still a bit surprising that we'd
> *always* get a NULL pointer rather than some other random pointer as a
> result. 

I dont remember seeing any case which was not a NULL pointer dereference.

> The buffer-ring debug patch that you posted looks like the obvious way
> to dig further into this.  If that doesn't get anyway, we can also trap
> the case where following bh->b_this_page gives us a buffer whose b_page
> is on a different page.

Fine.  Just printing out bh->b_page at debug_page() will allow us to verify that, yes?

--- transaction.c.orig  2004-06-21 12:50:01.090082264 -0300
+++ transaction.c       2004-06-21 12:50:45.574319632 -0300
@@ -1704,9 +1704,9 @@ void debug_page(struct page *p)
                 p->index, atomic_read(&p->count), p->flags);
  
        while (bh) {
-               printk(KERN_ERR "%s: bh b_next:%p blocknr:%lu b_list:%u state:%lx\n",
+               printk(KERN_ERR "%s: bh b_next:%p blocknr:%lu b_list:%u state:%lx b_page:%p\n",
                        __FUNCTION__, bh->b_next, bh->b_blocknr, bh->b_list,
-                               bh->b_state);
+                               bh->b_state, bh->b_page);
                bh = bh->b_this_page;
        }
 }




  reply	other threads:[~2004-06-21 16:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-03 18:26 Oopses with both recent 2.4.x kernels and 2.6.x kernels Stian Jordet
2004-02-05 23:51 ` Marcelo Tosatti
2004-03-02 11:03   ` Stian Jordet
2004-03-02 12:31     ` Stian Jordet
2004-03-09 19:22       ` Marcelo Tosatti
2004-03-09 22:28         ` Stian Jordet
2004-06-14 17:07     ` Steven Dake
2004-06-14 18:26       ` Chris Shoemaker
2004-06-15 13:16       ` Marcelo Tosatti
2004-06-15 14:35         ` Stian Jordet
2004-06-15 17:56         ` Steven Dake
2004-06-17 13:16           ` [2.4] page->buffers vanished in journal_try_to_free_buffers() Marcelo Tosatti
2004-06-18  3:08             ` Andrew Morton
2004-06-19 19:48               ` Marcelo Tosatti
2004-06-19 19:50                 ` Frank van Maarseveen
2004-06-19 22:17                   ` Marcelo Tosatti
2004-06-19 22:44                     ` Frank van Maarseveen
2004-06-19 20:04                 ` Andrew Morton
2004-06-20  7:56                 ` Willy Tarreau
2004-06-21 15:06             ` Stephen C. Tweedie
2004-06-21 15:53               ` Marcelo Tosatti [this message]
2004-06-22 22:13                 ` Stephen C. Tweedie

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=20040621155313.GA12559@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liste@jordet.nu \
    --cc=sct@redhat.com \
    --cc=sct@redhat.logos.cnet \
    --cc=sdake@mvista.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.