added another patch to 2.6.22 review based on Hugh's comments

diff --git a/review-2.6.22/fix-tmpfs-bug-and-aop_writepage_activate.patch b/review-2.6.22/fix-tmpfs-bug-and-aop_writepage_activate.patch
new file mode 100644 (file)
index 0000000..cbae0da
--- /dev/null
+++ b/review-2.6.22/fix-tmpfs-bug-and-aop_writepage_activate.patch
@@ -0,0 +1,67 @@
+From stable-bounces@linux.kernel.org Mon Oct 29 14:38:02 2007
+From: Hugh Dickins <hugh@veritas.com>
+Date: Mon, 29 Oct 2007 14:37:20 -0700
+Subject: fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE
+To: torvalds@linux-foundation.org
+Cc: penberg@cs.helsinki.fi, hugh@veritas.com, akpm@linux-foundation.org, ezk@cs.sunysb.edu, stable@kernel.org
+Message-ID: <200710292137.l9TLbK6t024569@imap1.linux-foundation.org>
+
+
+From: Hugh Dickins <hugh@veritas.com>
+
+patch 487e9bf25cbae11b131d6a14bdbb3a6a77380837 in mainline.
+
+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 <hugh@veritas.com>
+Cc: Erez Zadok <ezk@cs.sunysb.edu>
+Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ mm/shmem.c |   15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -911,6 +911,21 @@ static int shmem_writepage(struct page *
+       struct inode *inode;
+ 
+       BUG_ON(!PageLocked(page));
++      /*
++       * 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;
++      }
+       BUG_ON(page_mapped(page));
+ 
+       mapping = page->mapping;

diff --git a/review-2.6.22/series b/review-2.6.22/series
index 3220eadfcb3cc4fa498f9cccd86c8af8699e7adf..60669e618695da0d5326dd5175590e6f5f4e5093 100644 (file)
--- a/review-2.6.22/series
+++ b/review-2.6.22/series
@@ -2,6 +2,7 @@ slub-fix-memory-leak-by-not-reusing-cpu_slab.patch
 fix-compat-futex-hangs.patch
 x86-fix-tsc-clock-source-calibration-error.patch
 writeback-don-t-propagate-aop_writepage_activate.patch
+fix-tmpfs-bug-and-aop_writepage_activate.patch
 fix-param_sysfs_builtin-name-length-check.patch
 netfilter-nf_conntrack_tcp-fix-connection-reopening.patch
 fix-teql-oops.patch