From: Mingming Cao <cmm@us.ibm.com>
To: Zwane Mwaikambo <zwane@linuxpower.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: kernel BUG at fs/ext3/balloc.c:942!
Date: 07 May 2004 10:23:20 -0700 [thread overview]
Message-ID: <1083950602.15980.18416.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0405051729140.2284@montezuma.fsmlabs.com>
On Wed, 2004-05-05 at 14:31, Zwane Mwaikambo wrote:
> Shout at me if you need something else, right now i need to reboot my
> workstation.
Thanks for working this problem with us.
The problem is that the reservation window is being discard too early in
ext3_release_file(). ext3_release_file() calls
ext3_discard_resercation() on the last file_close(). It is possible for
two process who open same file for write, while one process discarded a
reservation window when it is the last one closed it's own filp, while
another process is in the middle of using that reservation window for
block allocation on that inode.
We should really discard the reservation window on the last writer on
the inode, instead of the last writer on the filp.
Here is the patch to fix this issue.
This should fix a reservation window race between multiple processes when one process closed the file while another one is in the middle of block allocation using the inode's reservation window. reservation window should be discard on the last writer on the inode, not the last writer on the filp.
---
src-ming/fs/ext3/file.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN fs/ext3/file.c~ext3_reservation_discard_race_fix fs/ext3/file.c
--- src/fs/ext3/file.c~ext3_reservation_discard_race_fix 2004-05-06 22:46:44.338842592 -0700
+++ src-ming/fs/ext3/file.c 2004-05-07 00:48:58.059947520 -0700
@@ -33,7 +33,8 @@
*/
static int ext3_release_file (struct inode * inode, struct file * filp)
{
- if (filp->f_mode & FMODE_WRITE)
+ /* if we are the last writer on the inode, drop the block reservation */
+ if (filp->f_mode & FMODE_WRITE && (atomic_read(&inode->i_writecount) == 1))
ext3_discard_reservation(inode);
if (is_dx(inode) && filp->private_data)
ext3_htree_free_dir_info(filp->private_data);
_
next prev parent reply other threads:[~2004-05-07 17:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-05 21:31 kernel BUG at fs/ext3/balloc.c:942! Zwane Mwaikambo
2004-05-05 22:24 ` Rob Shakir
2004-05-06 12:32 ` Chris Mason
2004-05-06 17:00 ` Rob Shakir
2004-05-07 17:23 ` Mingming Cao [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-03 23:15 Philip Molter
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=1083950602.15980.18416.camel@localhost.localdomain \
--to=cmm@us.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zwane@linuxpower.ca \
/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