• Linus Torvalds's avatar
    Re-introduce page mapping check in mark_buffer_dirty() · 8e9d78ed
    Linus Torvalds authored
    In commit a8e7d49a ("Fix race in
    create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test
    for a NULL page mapping unintentionally when some of the code inside
    __set_page_dirty() was moved to the callers.
    
    That removal generally didn't matter, since a filesystem would serialize
    truncation (which clears the page mapping) against writing (which marks
    the buffer dirty), so locking at a higher level (either per-page or an
    inode at a time) should mean that the buffer page would be stable.  And
    indeed, nothing bad seemed to happen.
    
    Except it turns out that apparently reiserfs does something odd when
    under load and writing out the journal, and we have a number of bugzilla
    entries that look similar:
    
    	http://bugzilla.kernel.org/show_bug.cgi?id=13556
    	http://bugzilla.kernel.org/show_bug.cgi?id=13756
    	http://bugzilla.kernel.org/show_bug.cgi?id=13876
    
    and it looks like reiserfs depended on that check (the common theme
    seems to be "data=journal", and a journal writeback during a truncate).
    
    I suspect reiserfs should have some additional locking, but in the
    meantime this should get us back to the pre-2.6.29 behavior.
    Pattern-pointed-out-by: default avatarRoland Kletzing <devzero@web.de>
    Cc: stable@kernel.org (2.6.29 and 2.6.30)
    Cc: Jeff Mahoney <jeffm@suse.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    8e9d78ed
buffer.c 88.9 KB