lkml.org 
[lkml]   [2011]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] block integrity: Fix write after checksum calculation problem
    On Tue 22-03-11 12:23:01, Darrick J. Wong wrote:
    > On Fri, Mar 18, 2011 at 08:28:26PM -0600, Andreas Dilger wrote:
    > > 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.
    >
    > I figured out that the recursive locking errors only happened in the
    > set_memory_rw half of the ro/rw memory pair, and that I could make them go away
    > (for now) by do set_memory_rw in the kintegrityd workqueue. Then I added a
    > call to set_page_writeback just prior to the set_memory_ro call, though that
    > resulted in a lot of complaints about invalid page states and the like. It
    > would seem that the memory pages that arrive in bio_integrity_prep from jbd2
    > don't have the writeback flag set, and setting it causes problems for it. The
    > writeback flag is set on all the pages that are associated with a checksum
    > failure, I noticed.
    Yeah, pages submitted by jbd2 don't have writeback flag set because they
    are metadata blocks written directly via buffer heads. But as you noted,
    these are protected in a different way by the journalling layer so
    shouldn't need to worry.

    > As for changing pte's around... does that set_memory_ro change the pte flags
    > for all running processes? I'm not so sure it does for anything other than the
    > current process. I think I saw a flush_tlb call in there... though I don't
    > think it helps me much.
    >
    > If I /don't/ set the flag, the frequency of the errors decreases further to
    > about once an hour, but I still see the occasional error. :/ Currently I'm
    > trying to figure out how one might distinguish dirty pages that shouldn't have
    > writeback set vs. pages that ought to have it but don't.
    It's difficult at the block layer... If page->mapping->host is not a
    device inode, the page should have PageWriteback set. If it is a device
    inode, you don't know - JBD2 will submit pages without PageWriteback set,
    flusher thread will submit pages with PageWriteback set. And both is OK
    since we use buffer state for synchronization.

    Honza
    --
    Jan Kara <jack@suse.cz>
    SUSE Labs, CR


    \
     
     \ /
      Last update: 2011-03-22 22:57    [W:3.705 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site