Commit:     487e9bf25cbae11b131d6a14bdbb3a6a77380837
Parent:     8bca44bbd39007065cc6a4e3a50201475629a6cf
Author:     Hugh Dickins <[EMAIL PROTECTED]>
AuthorDate: Mon Oct 29 14:37:20 2007 -0700
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Tue Oct 30 08:06:55 2007 -0700

    It's possible to provoke unionfs (not yet in mainline, though in mm and
    some distros) to hit shmem_writepage's BUG_ON(page_mapped(page)).  I expect
    it's possible to provoke the 2.6.23 ecryptfs in the same way (but the
    2.6.24 ecryptfs no longer calls lower level's ->writepage).
    This came to light with the recent find that AOP_WRITEPAGE_ACTIVATE could
    leak from tmpfs via write_cache_pages and unionfs to userspace.  There's
    already a fix (e423003028183df54f039dfda8b58c49e78c89d7 - writeback: don't
    propagate AOP_WRITEPAGE_ACTIVATE) in the tree for that, and it's okay so
    far as it goes; but insufficient because it doesn't address the underlying
    issue, that shmem_writepage expects to be called only by vmscan (relying on
    backing_dev_info capabilities to prevent the normal writeback path from
    ever approaching it).
    That's an increasingly fragile assumption, and ramdisk_writepage (the other
    source of AOP_WRITEPAGE_ACTIVATEs) is already careful to check
    wbc->for_reclaim before returning it.  Make the same check in
    shmem_writepage, thereby sidestepping the page_mapped BUG also.
    Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
    Cc: Erez Zadok <[EMAIL PROTECTED]>
    Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
 mm/shmem.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 404e53b..253d205 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -915,6 +915,21 @@ static int shmem_writepage(struct page *page, struct 
writeback_control *wbc)
        struct inode *inode;
+       /*
+        * shmem_backing_dev_info's capabilities prevent regular writeback or
+        * sync from ever calling shmem_writepage; but a stacking filesystem
+        * may use the ->writepage of its underlying filesystem, in which case
+        * we want to do nothing when that underlying filesystem is tmpfs
+        * (writing out to swap is useful as a response to memory pressure, but
+        * of no use to stabilize the data) - just redirty the page, unlock it
+        * and claim success in this case.  AOP_WRITEPAGE_ACTIVATE, and the
+        * page_mapped check below, must be avoided unless we're in reclaim.
+        */
+       if (!wbc->for_reclaim) {
+               set_page_dirty(page);
+               unlock_page(page);
+               return 0;
+       }
        mapping = page->mapping;
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to