On Mon, 22 Oct 2012 17:06:46 +0200 Jan Kara <jack@xxxxxxx> wrote: > On s390 any write to a page (even from kernel itself) sets architecture > specific page dirty bit. Thus when a page is written to via buffered write, HW > dirty bit gets set and when we later map and unmap the page, page_remove_rmap() > finds the dirty bit and calls set_page_dirty(). > > Dirtying of a page which shouldn't be dirty can cause all sorts of problems to > filesystems. The bug we observed in practice is that buffers from the page get > freed, so when the page gets later marked as dirty and writeback writes it, XFS > crashes due to an assertion BUG_ON(!PagePrivate(page)) in page_buffers() called > from xfs_count_page_state(). > > Similar problem can also happen when zero_user_segment() call from > xfs_vm_writepage() (or block_write_full_page() for that matter) set the > hardware dirty bit during writeback, later buffers get freed, and then page > unmapped. > > Fix the issue by ignoring s390 HW dirty bit for page cache pages of mappings > with mapping_cap_account_dirty(). This is safe because for such mappings when a > page gets marked as writeable in PTE it is also marked dirty in do_wp_page() or > do_page_fault(). When the dirty bit is cleared by clear_page_dirty_for_io(), > the page gets writeprotected in page_mkclean(). So pagecache page is writeable > if and only if it is dirty. > > Thanks to Hugh Dickins <hughd@xxxxxxxxxx> for pointing out mapping has to have > mapping_cap_account_dirty() for things to work and proposing a cleaned up > variant of the patch. > > The patch has survived about two hours of running fsx-linux on tmpfs while > heavily swapping and several days of running on out build machines where the > original problem was triggered. That seems a fairly serious problem. To which kernel version(s) should we apply the fix? > diff --git a/mm/rmap.c b/mm/rmap.c It's a bit surprising that none of the added comments mention the s390 pte-dirtying oddity. I don't see an obvious place to mention this, but I for one didn't know about this and it would be good if we could capture the info _somewhere_? -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
