All of lore.kernel.org
 help / color / mirror / Atom feed
From: srinivasa <srinivasa@in.ibm.com>
To: linux-fsdevel@vger.kernel.org, srinivds@in.ibm.com
Subject: Corruption in "b_assoc_buffer" list of bufferhead structure.
Date: Tue, 09 May 2006 11:41:58 +0530	[thread overview]
Message-ID: <446032AE.8030600@in.ibm.com> (raw)

Hi
  I have got a oops  in which "b_assoc_buffer" list of bufferhead is 
getting corrupted with strange values. It looks like a race problem 
,which is not reproducable at everytime. 
When I looked in to the code,I found that  "b_assoc_buffer" list is 
protected by a spinlock on "private_lock" of struct address_space. But 
there is one situation,where I suspect the chance of corruption. that is 
in try_to_free_buffers() of fs/buffer.c
When mapping becomes NULL, there is no lock protection and if 2 or more 
processors passes this condition and executes drop_buffers() 
simultaneously, there may be a chance of list corruption.

So could somebody please explain whether this situation exists or not?
======================================================================

int try_to_free_buffers(struct page *page)
{
        struct address_space * const mapping = page->mapping;
        struct buffer_head *buffers_to_free = NULL;
        int ret = 0;

        BUG_ON(!PageLocked(page));
        if (PageWriteback(page))
                return 0;

        if (mapping == NULL) {      /* can this still happen? */ <<<<here is my doubt>>>>>>
                ret = drop_buffers(page, &buffers_to_free);
                goto out;
        }

        spin_lock(&mapping->private_lock);
        ret = drop_buffers(page, &buffers_to_free);
        if (ret) {
                /*
                 * If the filesystem writes its buffers by hand (eg ext3)
                 * then we can have clean buffers against a dirty page.  We
                 * clean the page here; otherwise later reattachment of
buffers
                 * could encounter a non-uptodate page, which is
unresolvable.
                 * This only applies in the rare case where
try_to_free_buffers
                 * succeeds but the page is not freed.
                 */
                clear_page_dirty(page);
        }
        spin_unlock(&mapping->private_lock);
=========================================================================================


Thanks
Srinivasa DS





             reply	other threads:[~2006-05-09 17:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-09  6:11 srinivasa [this message]
2006-05-09 21:13 ` Corruption in "b_assoc_buffer" list of bufferhead structure Mingming Cao
2006-05-11 10:45   ` srinivasa

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=446032AE.8030600@in.ibm.com \
    --to=srinivasa@in.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=srinivds@in.ibm.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.