Hi,
On Wed, 2005-04-06 at 11:01, Hifumi Hisashi wrote:
> I have measured the bh refcount before the buffer_uptodate() for a few days.
> I found out that the bh refcount sometimes reached to 0 .
> So, I think following modifications are effective.
>
> diff -Nru 2.4.30-rc3/fs/jbd/commit.c 2.4.30-rc3_patch/fs/jbd/commit.c
> --- 2.4.30-rc3/fs/jbd/commit.c 2005-04-06 17:14:47.000000000 +0900
> +++ 2.4.30-rc3_patch/fs/jbd/commit.c 2005-04-06 17:18:49.000000000 +0900
> @@ -302,11 +303,14 @@
> if (unlikely(!buffer_uptodate(bh)))
> err = -EIO;
> /* the journal_head may have been removed now */
> + put_bh(bh);
> lock_journal(journal);
> goto write_out_data;
...
In further testing, this chunk is causing some problems. It is entirely
legal for a buffer to be !uptodate here, although the path is somewhat
convoluted. The trouble is, once the IO has completed,
journal_dirty_data() can steal the buffer from the committing
transaction. And once that happens, journal_unmap_buffer() can then
release the buffer and clear the uptodate bit.
I've run this under buffer tracing and can show you this exact path on a
trace. It only takes a few seconds to reproduce under fsx.
For this to have happened, though, journal_dirty_data needs to have
waited on the data, so it has an opportunity to see the !uptodate state
at that point.
I think it's safe enough to sidestep this by double-checking to see
whether the bh is still on the committing transaction after we've waited
for the buffer and retaken journaling locks, but before testing
buffer_uptodate().
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
