On Mon, 18 Dec 2006 18:22:42 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> 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. I don't follow that. The linkage between pte-dirtiness and buffer_heads is a bit hard to follow without also considering page-dirtiness. > > 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. Think so. We do have a problem here, but only on threaded apps, I believe. rtorrent doesn't appear to be threaded, and the bug is hit on non-preempt UP. > >>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. try_to_free_buffers() isn't called against a page which doesn't have buffers. It'll oops. > Were you testing with preempt? nope, just SMP. - 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/