From: Greg Kroah-Hartman Date: Mon, 19 Nov 2007 23:05:53 +0000 (-0800) Subject: added another patch to 2.6.22 review based on Hugh's comments X-Git-Tag: v2.6.22.14~6 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8f92be96cf061ac2f77b008fc5611271134e93c6;p=thirdparty%2Fkernel%2Fstable-queue.git 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 index 00000000000..cbae0dab5b8 --- /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 +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 + +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 +Cc: Erez Zadok +Reviewed-by: Pekka Enberg +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 3220eadfcb3..60669e61869 100644 --- 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