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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox