> Eric Sandeen wrote:
> >Andrew Morton wrote:
> >
> >
> >>On Thu, 12 Oct 2006 14:28:20 +0200
> >>Jan Kara <[email protected]> wrote:
> >>
> >>
> >>
> >>>Where can we call
> >>>journal_dirty_data() without PageLock?
> >>>
> >>>
> >>block_write_full_page() will unlock the page, so ext3_writepage()
> >>will run journal_dirty_data_fn() against an unlocked page.
> >>
> >>I haven't looked into the exact details of the race, but it should
> >>be addressable via jbd_lock_bh_state() or j_list_lock coverage
> >>
> >I'm testing with something like this now; seem sane?
> >
> >journal_dirty_data & journal_unmap_data both check do
> >jbd_lock_bh_state(bh) close to the top... journal_dirty_data_fn has
> >checked buffer_mapped before getting into journal_dirty_data, but that
> >state may
> >change before the lock is grabbed. Similarly re-check after we drop the
> >lock.
> >
> >
> This is exactly the solution I proposed earlier (to check
> buffer_mapped() before calling submit_bh()).
> But at that time, Jan pointed out that the whole handling is wrong.
Yes, and it was. However it turned out that there are more problems
than I thought ;).
> But if this is the only case we need to handle, I am okay with this band
> aid :)
I think Eric's patch may be a part of it. But we still need to check whether
the buffer is not after EOF before submitting it (or better said just
after we manage to lock the buffer). Because while we are waiting for
the buffer lock, journal_unmap_buffer() can still come and steal the
buffer - at least the write-out in journal_dirty_data() definitely needs
the check if I haven't overlooked something.
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
-
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]
