From: Greg Kroah-Hartman Date: Thu, 20 Oct 2011 22:14:39 +0000 (-0700) Subject: 3.0 patches X-Git-Tag: v3.0.8~6 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e67fd7a54eda00c02fccf5c3d541f06ade29fbb4;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0 patches --- diff --git a/queue-3.0/mm-fix-race-between-mremap-and-removing-migration-entry.patch b/queue-3.0/mm-fix-race-between-mremap-and-removing-migration-entry.patch new file mode 100644 index 00000000000..6f07b1aa3a9 --- /dev/null +++ b/queue-3.0/mm-fix-race-between-mremap-and-removing-migration-entry.patch @@ -0,0 +1,74 @@ +From 486cf46f3f9be5f2a966016c1a8fe01e32cde09e Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Wed, 19 Oct 2011 12:50:35 -0700 +Subject: mm: fix race between mremap and removing migration entry +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hugh Dickins + +commit 486cf46f3f9be5f2a966016c1a8fe01e32cde09e upstream. + +I don't usually pay much attention to the stale "? " addresses in +stack backtraces, but this lucky report from Pawel Sikora hints that +mremap's move_ptes() has inadequate locking against page migration. + + 3.0 BUG_ON(!PageLocked(p)) in migration_entry_to_page(): + kernel BUG at include/linux/swapops.h:105! + RIP: 0010:[] [] + migration_entry_wait+0x156/0x160 + [] handle_pte_fault+0xae1/0xaf0 + [] ? __pte_alloc+0x42/0x120 + [] ? do_huge_pmd_anonymous_page+0xab/0x310 + [] handle_mm_fault+0x181/0x310 + [] ? vma_adjust+0x537/0x570 + [] do_page_fault+0x11d/0x4e0 + [] ? do_mremap+0x2d5/0x570 + [] page_fault+0x1f/0x30 + +mremap's down_write of mmap_sem, together with i_mmap_mutex or lock, +and pagetable locks, were good enough before page migration (with its +requirement that every migration entry be found) came in, and enough +while migration always held mmap_sem; but not enough nowadays, when +there's memory hotremove and compaction. + +The danger is that move_ptes() lets a migration entry dodge around +behind remove_migration_pte()'s back, so it's in the old location when +looking at the new, then in the new location when looking at the old. + +Either mremap's move_ptes() must additionally take anon_vma lock(), or +migration's remove_migration_pte() must stop peeking for is_swap_entry() +before it takes pagetable lock. + +Consensus chooses the latter: we prefer to add overhead to migration +than to mremapping, which gets used by JVMs and by exec stack setup. + +Reported-and-tested-by: Paweł Sikora +Signed-off-by: Hugh Dickins +Acked-by: Andrea Arcangeli +Acked-by: Mel Gorman +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/migrate.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -120,10 +120,10 @@ static int remove_migration_pte(struct p + + ptep = pte_offset_map(pmd, addr); + +- if (!is_swap_pte(*ptep)) { +- pte_unmap(ptep); +- goto out; +- } ++ /* ++ * Peek to check is_swap_pte() before taking ptlock? No, we ++ * can race mremap's move_ptes(), which skips anon_vma lock. ++ */ + + ptl = pte_lockptr(mm, pmd); + } diff --git a/queue-3.0/series b/queue-3.0/series index ec2775ad52c..5b037c80d1e 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -19,3 +19,6 @@ xfs-do-not-update-xa_last_pushed_lsn-for-locked-items.patch xfs-force-the-log-if-we-encounter-pinned-buffers-in-.iop_pushbuf.patch xfs-revert-to-using-a-kthread-for-ail-pushing.patch firewire-sbp2-fix-panic-after-rmmod-with-slow-targets.patch +vfs-fix-automount-for-negative-autofs-dentries.patch +mm-fix-race-between-mremap-and-removing-migration-entry.patch +x25-prevent-skb-overreads-when-checking-call-user-data.patch diff --git a/queue-3.0/vfs-fix-automount-for-negative-autofs-dentries.patch b/queue-3.0/vfs-fix-automount-for-negative-autofs-dentries.patch new file mode 100644 index 00000000000..44bb4fcdec7 --- /dev/null +++ b/queue-3.0/vfs-fix-automount-for-negative-autofs-dentries.patch @@ -0,0 +1,61 @@ +From 5a30d8a2b8ddd5102c440c7e5a7c8e1fd729c818 Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Mon, 11 Jul 2011 14:20:57 +0100 +Subject: VFS: Fix automount for negative autofs dentries + +From: David Howells + +commit 5a30d8a2b8ddd5102c440c7e5a7c8e1fd729c818 upstream. +[ backport for 3.0.x: LOOKUP_PARENT => LOOKUP_CONTINUE by Chuck Ebbert + ] + +Autofs may set the DCACHE_NEED_AUTOMOUNT flag on negative dentries. These +need attention from the automounter daemon regardless of the LOOKUP_FOLLOW flag. + +Signed-off-by: David Howells +Acked-by: Ian Kent +Signed-off-by: Al Viro +Cc: Chuck Ebbert +Signed-off-by: Greg Kroah-Hartman + +--- + fs/namei.c | 24 +++++++++++++++--------- + 1 file changed, 15 insertions(+), 9 deletions(-) + +--- a/fs/namei.c ++++ b/fs/namei.c +@@ -779,19 +779,25 @@ static int follow_automount(struct path + if ((flags & LOOKUP_NO_AUTOMOUNT) && !(flags & LOOKUP_CONTINUE)) + return -EISDIR; /* we actually want to stop here */ + +- /* We want to mount if someone is trying to open/create a file of any +- * type under the mountpoint, wants to traverse through the mountpoint +- * or wants to open the mounted directory. +- * ++ /* + * We don't want to mount if someone's just doing a stat and they've + * set AT_SYMLINK_NOFOLLOW - unless they're stat'ing a directory and + * appended a '/' to the name. + */ +- if (!(flags & LOOKUP_FOLLOW) && +- !(flags & (LOOKUP_CONTINUE | LOOKUP_DIRECTORY | +- LOOKUP_OPEN | LOOKUP_CREATE))) +- return -EISDIR; +- ++ if (!(flags & LOOKUP_FOLLOW)) { ++ /* We do, however, want to mount if someone wants to open or ++ * create a file of any type under the mountpoint, wants to ++ * traverse through the mountpoint or wants to open the mounted ++ * directory. ++ * Also, autofs may mark negative dentries as being automount ++ * points. These will need the attentions of the daemon to ++ * instantiate them before they can be used. ++ */ ++ if (!(flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY | ++ LOOKUP_OPEN | LOOKUP_CREATE)) && ++ path->dentry->d_inode) ++ return -EISDIR; ++ } + current->total_link_count++; + if (current->total_link_count >= 40) + return -ELOOP; diff --git a/queue-3.0/x25-prevent-skb-overreads-when-checking-call-user-data.patch b/queue-3.0/x25-prevent-skb-overreads-when-checking-call-user-data.patch new file mode 100644 index 00000000000..45ffe97e5b9 --- /dev/null +++ b/queue-3.0/x25-prevent-skb-overreads-when-checking-call-user-data.patch @@ -0,0 +1,36 @@ +From 7f81e25befdfb3272345a2e775f520e1d515fa20 Mon Sep 17 00:00:00 2001 +From: Matthew Daley +Date: Fri, 14 Oct 2011 18:45:05 +0000 +Subject: x25: Prevent skb overreads when checking call user data + +From: Matthew Daley + +commit 7f81e25befdfb3272345a2e775f520e1d515fa20 upstream. + +x25_find_listener does not check that the amount of call user data given +in the skb is big enough in per-socket comparisons, hence buffer +overreads may occur. Fix this by adding a check. + +Signed-off-by: Matthew Daley +Cc: Eric Dumazet +Cc: Andrew Hendry +Acked-by: Andrew Hendry +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/x25/af_x25.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/x25/af_x25.c ++++ b/net/x25/af_x25.c +@@ -295,7 +295,8 @@ static struct sock *x25_find_listener(st + * Found a listening socket, now check the incoming + * call user data vs this sockets call user data + */ +- if(skb->len > 0 && x25_sk(s)->cudmatchlength > 0) { ++ if (x25_sk(s)->cudmatchlength > 0 && ++ skb->len >= x25_sk(s)->cudmatchlength) { + if((memcmp(x25_sk(s)->calluserdata.cuddata, + skb->data, + x25_sk(s)->cudmatchlength)) == 0) {