On 2011-03-18, at 6:07 PM, Darrick J. Wong wrote: >> Ok, here's what I have so far. I took everyone's suggestions of where to add >> calls to wait_on_page_writeback, which seems to handle the multiple-write case >> adequately. Unfortunately, it is still possible to generate checksum errors by >> scribbling furiously on a mmap'd region, even after adding the writeback wait >> in the ext4 writepage function. Oddly, I couldn't break btrfs with mmap by >> removing its wait_for_page_writeback call, so I suspect there's a bit more >> going on in btrfs than I've been able to figure out. > I wonder, is it possible for this to happen: > > 1. Thread A mmaps a page and tries to write to it. ext4_page_mkwrite executes, > but there's no ongoing writeback, so it returns without delay. > 2. Thread A starts writing furiously to the page. > 3. Thread B runs fsync() or something that results in the page being > checksummed and scheduled for writeout. > 4. Thread A continues to write furiously(!) on that same page before the > controller finishes the DMA transfer. Right, page_mkwrite() is only called for the ro->rw transition. > 5. Disk gets the page, which now doesn't match its checksum, and *boom* > > After letting the stress tool run for a few days, I can say fairly confidently > that the write() case doesn't seem to fail regardless of the O_DIRECT setting. > However, with writes to mmap regions, failures happen about once every 20-40 > minutes, even with O_DIRECT set. To me this suggests some sort of race > condition that we seem to win except once every 20 minutes. > > I then thought, if page_mkwrite contains a wait_on_page_writeback, then perhaps > there's something that I could do just prior to calculating the DIF checksum > that would cause any subsequent write attempts to be shuffled back into > page_mkwrite. I tried the set_memory_ro thing again, though that led to some > recursive lock errors and I noticed that those functions only seem to exist in > arch/x86/. Next I tried directly mucking with PTEs, in addition to feeling > messy, only seemed to corrupt memory. :) This seems like the best solution, IMHO, to ensure that mmap is blocked in page_mkwrite() before it has any chance to dirty the page undergoing checksum. The trick is that you need to set_page_writeback() before setting the page read-only, otherwise the race still exists. > Is there a "correct" way to take a writeable page and make it so that any > process trying to write to it ends up hitting the page fault handler where we > can then wait for writeback? Or perhaps I am simply barking up the wrong tree? > > (Just FYI I took the old copy-everything-to-bounce-buffers patch that few > people liked for a second spin, and the errors did not surface regardless of > what combination of write/mmap and directio/bufferedio I told it to use.) I wouldn't be so much against memcpy() for mmap pages, but it does seem kind of gross that mmap is forcing data copies when a major reason to use mmap is to AVOID data copies. >>> The set_memory_ro debugging trick didn't ferret out any write paths that I >>> didn't catch... though it did have the effect of causing occasional fsync() >>> deadlocks. I suppose I could sprinkle in a few more of those write calls to >>> see what happens. >>> >>> Either way, I'm emailing to ask everyone's advice since I've run out of ideas. >>> Or: Did I miss something? >>> >>> Thanks all for the feedback so far! >>> >>> -- >>> fs: Wait for page writeback when rewrite detected >>> >>> Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> >>> --- >>> >>> fs/buffer.c | 4 +++- >>> fs/ext4/inode.c | 3 +++ >>> mm/filemap.c | 15 +++++++++++++-- >>> 3 files changed, 19 insertions(+), 3 deletions(-) >>> >>> diff --git a/fs/buffer.c b/fs/buffer.c >>> index 2219a76..39e934c 100644 >>> --- a/fs/buffer.c >>> +++ b/fs/buffer.c >>> @@ -2379,8 +2379,10 @@ block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf, >>> ret = VM_FAULT_OOM; >>> else /* -ENOSPC, -EIO, etc */ >>> ret = VM_FAULT_SIGBUS; >>> - } else >>> + } else { >>> + wait_on_page_writeback(page); >>> ret = VM_FAULT_LOCKED; >>> + } >> >> I think this needs to wait before the __block_write_begin() call, >> not after it. i.e. wait before the page is mapped, not afterwards. >> >> .... >>> diff --git a/mm/filemap.c b/mm/filemap.c >>> index 83a45d3..f201d80 100644 >>> --- a/mm/filemap.c >>> +++ b/mm/filemap.c >>> @@ -2217,8 +2217,8 @@ EXPORT_SYMBOL(generic_file_direct_write); >>> * Find or create a page at the given pagecache position. Return the locked >>> * page. This function is specifically for buffered writes. >>> */ >>> -struct page *grab_cache_page_write_begin(struct address_space *mapping, >>> - pgoff_t index, unsigned flags) >>> +struct page *__grab_cache_page_write_begin(struct address_space *mapping, >>> + pgoff_t index, unsigned flags) >>> { >>> int status; >>> struct page *page; >>> @@ -2243,6 +2243,17 @@ repeat: >>> } >>> return page; >>> } >>> +struct page *grab_cache_page_write_begin(struct address_space *mapping, >>> + pgoff_t index, unsigned flags) >>> +{ >>> + struct page *p; >>> + >>> + p = __grab_cache_page_write_begin(mapping, index, flags); >>> + if (p) >>> + wait_on_page_writeback(p); >>> + >>> + return p; >>> +} >>> EXPORT_SYMBOL(grab_cache_page_write_begin); >> >> Not much point in add in a wrapper when nothing else calls >> __grab_cache_page_write_begin(), which should also be static.... >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> david@xxxxxxxxxxxxx >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html