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