Andrew Morton wrote:
On Mon, 18 Dec 2006 15:51:52 +1100
Nick Piggin <[email protected]> wrote:
I think the problem Andrew identified is real.
I don't. In fact I don't think I described any problem (well, I tried to,
but then I contradicted myself).
By saying that there shouldn't be any dirty ptes if there are no
dirty buffers? But in that case the _page_ shouldn't be dirty either,
so that clear_page_dirty would be redundant. But presumably it isn't.
Six hours here of fsx-linux plus high memory pressure on SMP on 1k
blocksize ext3, mainline. Zero failures. It's unlikely that this testing
would pass, yet people running normal workloads are able to easily trigger
failures. I suspect we're looking in the wrong place.
Yes I could believe it the corruption is caused by something else
completely.
The issue is the disconnect between the pte dirtiness and a filesystem
bringing buffers clean.
Really? The dirtying direction goes pte_dirty->PG_dirty->BH_Dirty and the
cleaning direction goes !BH_Dirty->!PG_dirty->!pte_dirty. That's pretty
simple, setting aside races.
In the try_to_free_buffers case there's a large time inverval between
!BH_Dirty and !PG_dirty, but that shouldn't affect anything.
After try_to_free_buffers detaches the buffers from the page, a
pagefault can come in, and mark the pte writeable, then set_page_dirty
(which finds no buffers, so only sets PG_dirty).
The page can now get dirtied through this mapping.
try_to_free_buffers then goes on to clean the page and ptes.
I really thought you were the one who identified this race, and I didn't
see where you showed it is safe.
It may be very unlikely with small SMPs, but less so with preempt. All
we have to do is preempt at spin_unlock in try_to_free_buffers AFAIKS.
Were you testing with preempt?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
