Messages in this thread | | | Date | Mon, 18 Dec 2006 18:22:42 +1100 | From | Nick Piggin <> | Subject | Re: 2.6.19 file content corruption on ext3 |
| |
Andrew Morton wrote: > On Mon, 18 Dec 2006 15:51:52 +1100 > Nick Piggin <nickpiggin@yahoo.com.au> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |