From: Greg Kroah-Hartman Date: Thu, 19 Jun 2008 20:57:24 +0000 (-0700) Subject: more patches for .25 X-Git-Tag: v2.6.25.8~3 X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=ac07e81b190fe6a33b9c6e2a80f94add21b76f15;p=thirdparty%2Fkernel%2Fstable-queue.git more patches for .25 --- diff --git a/queue-2.6.25/nf_conntrack-fix-ctnetlink-related-crash-in-nf_nat_setup_info.patch b/queue-2.6.25/nf_conntrack-fix-ctnetlink-related-crash-in-nf_nat_setup_info.patch new file mode 100644 index 00000000000..a5905b60752 --- /dev/null +++ b/queue-2.6.25/nf_conntrack-fix-ctnetlink-related-crash-in-nf_nat_setup_info.patch @@ -0,0 +1,81 @@ +From stable-bounces@linux.kernel.org Thu Jun 19 06:06:30 2008 +From: Patrick McHardy +Date: Thu, 19 Jun 2008 15:05:43 +0200 (MEST) +Subject: nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info() +To: stable@kernel.org +Cc: netfilter-devel@vger.kernel.org, Patrick McHardy , davem@davemloft.net +Message-ID: <20080619130543.26204.13895.sendpatchset@localhost.localdomain> + +From: Patrick McHardy + +netfilter: nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info() + +Upstream commit ceeff7541e5a4ba8e8d97ffbae32b3f283cb7a3f + +When creation of a new conntrack entry in ctnetlink fails after having +set up the NAT mappings, the conntrack has an extension area allocated +that is not getting properly destroyed when freeing the conntrack again. +This means the NAT extension is still in the bysource hash, causing a +crash when walking over the hash chain the next time: + +BUG: unable to handle kernel paging request at 00120fbd +IP: [] nf_nat_setup_info+0x221/0x58a +*pde = 00000000 +Oops: 0000 [#1] PREEMPT SMP + +Pid: 2795, comm: conntrackd Not tainted (2.6.26-rc5 #1) +EIP: 0060:[] EFLAGS: 00010206 CPU: 1 +EIP is at nf_nat_setup_info+0x221/0x58a +EAX: 00120fbd EBX: 00120fbd ECX: 00000001 EDX: 00000000 +ESI: 0000019e EDI: e853bbb4 EBP: e853bbc8 ESP: e853bb78 + DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 +Process conntrackd (pid: 2795, ti=e853a000 task=f7de10f0 task.ti=e853a000) +Stack: 00000000 e853bc2c e85672ec 00000008 c0561084 63c1db4a 00000000 00000000 + 00000000 0002e109 61d2b1c3 00000000 00000000 00000000 01114e22 61d2b1c3 + 00000000 00000000 f7444674 e853bc04 00000008 c038e728 0000000a f7444674 +Call Trace: + [] nla_parse+0x5c/0xb0 + [] ctnetlink_change_status+0x190/0x1c6 + [] ctnetlink_new_conntrack+0x189/0x61f + [] update_curr+0x3d/0x52 + [] nfnetlink_rcv_msg+0xc1/0xd8 + [] nfnetlink_rcv_msg+0x18/0xd8 + [] nfnetlink_rcv_msg+0x0/0xd8 + [] netlink_rcv_skb+0x2d/0x71 + [] nfnetlink_rcv+0x19/0x24 + [] netlink_unicast+0x1b3/0x216 + ... + +Move invocation of the extension destructors to nf_conntrack_free() +to fix this problem. + +Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10875 + +Reported-and-Tested-by: Krzysztof Piotr Oledzki +Signed-off-by: Patrick McHardy +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/netfilter/nf_conntrack_core.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/net/netfilter/nf_conntrack_core.c ++++ b/net/netfilter/nf_conntrack_core.c +@@ -199,8 +199,6 @@ destroy_conntrack(struct nf_conntrack *n + if (l4proto && l4proto->destroy) + l4proto->destroy(ct); + +- nf_ct_ext_destroy(ct); +- + rcu_read_unlock(); + + spin_lock_bh(&nf_conntrack_lock); +@@ -523,6 +521,7 @@ static void nf_conntrack_free_rcu(struct + + void nf_conntrack_free(struct nf_conn *ct) + { ++ nf_ct_ext_destroy(ct); + call_rcu(&ct->rcu, nf_conntrack_free_rcu); + } + EXPORT_SYMBOL_GPL(nf_conntrack_free); diff --git a/queue-2.6.25/nf_conntrack_h323-fix-memory-leak-in-module-initialization-error-path.patch b/queue-2.6.25/nf_conntrack_h323-fix-memory-leak-in-module-initialization-error-path.patch new file mode 100644 index 00000000000..52ddc2208bf --- /dev/null +++ b/queue-2.6.25/nf_conntrack_h323-fix-memory-leak-in-module-initialization-error-path.patch @@ -0,0 +1,34 @@ +From stable-bounces@linux.kernel.org Thu Jun 19 06:06:18 2008 +From: Patrick McHardy +Date: Thu, 19 Jun 2008 15:05:45 +0200 (MEST) +Subject: nf_conntrack_h323: fix memory leak in module initialization error path +To: stable@kernel.org +Cc: netfilter-devel@vger.kernel.org, Patrick McHardy , davem@davemloft.net +Message-ID: <20080619130544.26204.28566.sendpatchset@localhost.localdomain> + +From: Patrick McHardy + +netfilter: nf_conntrack_h323: fix memory leak in module initialization error path + +Upstream commit 8a548868db62422113104ebc658065e3fe976951 + +Properly free h323_buffer when helper registration fails. + +Signed-off-by: Patrick McHardy +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/netfilter/nf_conntrack_h323_main.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/net/netfilter/nf_conntrack_h323_main.c ++++ b/net/netfilter/nf_conntrack_h323_main.c +@@ -1799,6 +1799,7 @@ err3: + err2: + nf_conntrack_helper_unregister(&nf_conntrack_helper_h245); + err1: ++ kfree(h323_buffer); + return ret; + } + diff --git a/queue-2.6.25/nf_conntrack_h323-fix-module-unload-crash.patch b/queue-2.6.25/nf_conntrack_h323-fix-module-unload-crash.patch new file mode 100644 index 00000000000..f9c278e8d28 --- /dev/null +++ b/queue-2.6.25/nf_conntrack_h323-fix-module-unload-crash.patch @@ -0,0 +1,129 @@ +From stable-bounces@linux.kernel.org Thu Jun 19 06:06:37 2008 +From: Patrick McHardy +Date: Thu, 19 Jun 2008 15:05:46 +0200 (MEST) +Subject: nf_conntrack_h323: fix module unload crash +To: stable@kernel.org +Cc: netfilter-devel@vger.kernel.org, Patrick McHardy , davem@davemloft.net +Message-ID: <20080619130545.26204.86975.sendpatchset@localhost.localdomain> + +From: Patrick McHardy + +netfilter: nf_conntrack_h323: fix module unload crash + +Upstream commit a56b8f81580761c65e4d8d0c04ac1cb7a788bdf1 + +The H.245 helper is not registered/unregistered, but assigned to +connections manually from the Q.931 helper. This means on unload +existing expectations and connections using the helper are not +cleaned up, leading to the following oops on module unload: + +CPU 0 Unable to handle kernel paging request at virtual address c00a6828, epc == 802224dc, ra == 801d4e7c +Oops[#1]: +Cpu 0 +$ 0 : 00000000 00000000 00000004 c00a67f0 +$ 4 : 802a5ad0 81657e00 00000000 00000000 +$ 8 : 00000008 801461c8 00000000 80570050 +$12 : 819b0280 819b04b0 00000006 00000000 +$16 : 802a5a60 80000000 80b46000 80321010 +$20 : 00000000 00000004 802a5ad0 00000001 +$24 : 00000000 802257a8 +$28 : 802a4000 802a59e8 00000004 801d4e7c +Hi : 0000000b +Lo : 00506320 +epc : 802224dc ip_conntrack_help+0x38/0x74 Tainted: P +ra : 801d4e7c nf_iterate+0xbc/0x130 +Status: 1000f403 KERNEL EXL IE +Cause : 00800008 +BadVA : c00a6828 +PrId : 00019374 +Modules linked in: ip_nat_pptp ip_conntrack_pptp ath_pktlog wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_dev ath_dfs ath_rate_atheros wlan ath_hal ip_nat_tftp ip_conntrack_tftp ip_nat_ftp ip_conntrack_ftp pppoe ppp_async ppp_deflate ppp_mppe pppox ppp_generic slhc +Process swapper (pid: 0, threadinfo=802a4000, task=802a6000) +Stack : 801e7d98 00000004 802a5a60 80000000 801d4e7c 801d4e7c 802a5ad0 00000004 + 00000000 00000000 801e7d98 00000000 00000004 802a5ad0 00000000 00000010 + 801e7d98 80b46000 802a5a60 80320000 80000000 801d4f8c 802a5b00 00000002 + 80063834 00000000 80b46000 802a5a60 801e7d98 80000000 802ba854 00000000 + 81a02180 80b7e260 81a021b0 819b0000 819b0000 80570056 00000000 00000001 + ... +Call Trace: + [<801e7d98>] ip_finish_output+0x0/0x23c + [<801d4e7c>] nf_iterate+0xbc/0x130 + [<801d4e7c>] nf_iterate+0xbc/0x130 + [<801e7d98>] ip_finish_output+0x0/0x23c + [<801e7d98>] ip_finish_output+0x0/0x23c + [<801d4f8c>] nf_hook_slow+0x9c/0x1a4 + +One way to fix this would be to split helper cleanup from the unregistration +function and invoke it for the H.245 helper, but since ctnetlink needs to be +able to find the helper for synchonization purposes, a better fix is to +register it normally and make sure its not assigned to connections during +helper lookup. The missing l3num initialization is enough for this, this +patch changes it to use AF_UNSPEC to make it more explicit though. + +Reported-by: liannan +Signed-off-by: Patrick McHardy +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + + +--- + net/netfilter/nf_conntrack_h323_main.c | 21 ++++++++++++++------- + 1 file changed, 14 insertions(+), 7 deletions(-) + +--- a/net/netfilter/nf_conntrack_h323_main.c ++++ b/net/netfilter/nf_conntrack_h323_main.c +@@ -617,6 +617,7 @@ static struct nf_conntrack_helper nf_con + .me = THIS_MODULE, + .max_expected = H323_RTP_CHANNEL_MAX * 4 + 2 /* T.120 */, + .timeout = 240, ++ .tuple.src.l3num = AF_UNSPEC, + .tuple.dst.protonum = IPPROTO_UDP, + .help = h245_help + }; +@@ -1758,6 +1759,7 @@ static void __exit nf_conntrack_h323_fin + nf_conntrack_helper_unregister(&nf_conntrack_helper_ras[0]); + nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[1]); + nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[0]); ++ nf_conntrack_helper_unregister(&nf_conntrack_helper_h245); + kfree(h323_buffer); + pr_debug("nf_ct_h323: fini\n"); + } +@@ -1770,27 +1772,32 @@ static int __init nf_conntrack_h323_init + h323_buffer = kmalloc(65536, GFP_KERNEL); + if (!h323_buffer) + return -ENOMEM; +- ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[0]); ++ ret = nf_conntrack_helper_register(&nf_conntrack_helper_h245); + if (ret < 0) + goto err1; +- ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[1]); ++ ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[0]); + if (ret < 0) + goto err2; +- ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[0]); ++ ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[1]); + if (ret < 0) + goto err3; +- ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[1]); ++ ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[0]); + if (ret < 0) + goto err4; ++ ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[1]); ++ if (ret < 0) ++ goto err5; + pr_debug("nf_ct_h323: init success\n"); + return 0; + +-err4: ++err5: + nf_conntrack_helper_unregister(&nf_conntrack_helper_ras[0]); +-err3: ++err4: + nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[1]); +-err2: ++err3: + nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[0]); ++err2: ++ nf_conntrack_helper_unregister(&nf_conntrack_helper_h245); + err1: + return ret; + } diff --git a/queue-2.6.25/series b/queue-2.6.25/series index e10d7e4f436..5d8e00cd634 100644 --- a/queue-2.6.25/series +++ b/queue-2.6.25/series @@ -8,3 +8,8 @@ b43-fix-possible-null-pointer-dereference-in-dma-code.patch scsi_host-regression-fix-scsi-host-leak.patch acpica-ignore-acpi-table-signature-for-load-operator.patch scsi-sr-fix-corrupt-cd-data-after-media-change-and-delay.patch +nf_conntrack-fix-ctnetlink-related-crash-in-nf_nat_setup_info.patch +nf_conntrack_h323-fix-module-unload-crash.patch +nf_conntrack_h323-fix-memory-leak-in-module-initialization-error-path.patch +x86-remove-mwait-capability-c-state-check.patch +x86-disable-mwait-for-amd-family-10h-11h-cpus.patch diff --git a/queue-2.6.25/x86-disable-mwait-for-amd-family-10h-11h-cpus.patch b/queue-2.6.25/x86-disable-mwait-for-amd-family-10h-11h-cpus.patch new file mode 100644 index 00000000000..78137e9ec2b --- /dev/null +++ b/queue-2.6.25/x86-disable-mwait-for-amd-family-10h-11h-cpus.patch @@ -0,0 +1,138 @@ +From vegard.nossum@gmail.com Thu Jun 19 07:34:37 2008 +From: Thomas Gleixner +Date: Thu, 19 Jun 2008 16:34:26 +0200 +Subject: x86: disable mwait for AMD family 10H/11H CPUs +To: stable@kernel.org +Cc: Greg KH , Ingo Molnar , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org +Message-ID: <20080619143426.GB3243@damson.getinternet.no> +Content-Disposition: inline + + +From: Thomas Gleixner + +back-ported from upstream commit e9623b35599fcdbc00c16535cbefbb4d5578f4ab by Vegard Nossum + + +The previous revert of 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec left +out the mwait disable condition for AMD family 10H/11H CPUs. + +Andreas Herrman said: + +It depends on the CPU. For AMD CPUs that support MWAIT this is wrong. +Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then +depend on a clock divisor and current Pstate of the core. + +If all cores of a processor are in halt state (C1) the processor can +enter the C1E (C1 enhanced) state. If mwait is used this will never +happen. + +Thus HLT saves more power than MWAIT here. + +It might be best to switch off the mwait flag for these AMD CPU +families like it was introduced with commit +f039b754714a422959027cb18bb33760eb8153f0 (x86: Don't use MWAIT on AMD +Family 10) + +Re-add the AMD families 10H/11H check and disable the mwait usage for +those. + +Signed-off-by: Thomas Gleixner +Signed-off-by: Vegard Nossum +Cc: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/process_32.c | 29 ++++++++++++++++++++++++++++- + arch/x86/kernel/process_64.c | 29 ++++++++++++++++++++++++++++- + 2 files changed, 56 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/process_32.c ++++ b/arch/x86/kernel/process_32.c +@@ -259,6 +259,33 @@ static void mwait_idle(void) + mwait_idle_with_hints(0, 0); + } + ++/* ++ * mwait selection logic: ++ * ++ * It depends on the CPU. For AMD CPUs that support MWAIT this is ++ * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings ++ * then depend on a clock divisor and current Pstate of the core. If ++ * all cores of a processor are in halt state (C1) the processor can ++ * enter the C1E (C1 enhanced) state. If mwait is used this will never ++ * happen. ++ * ++ * idle=mwait overrides this decision and forces the usage of mwait. ++ */ ++static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c) ++{ ++ if (force_mwait) ++ return 1; ++ ++ if (c->x86_vendor == X86_VENDOR_AMD) { ++ switch(c->x86) { ++ case 0x10: ++ case 0x11: ++ return 0; ++ } ++ } ++ return 1; ++} ++ + void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c) + { + static int selected; +@@ -271,7 +298,7 @@ void __cpuinit select_idle_routine(const + " performance may degrade.\n"); + } + #endif +- if (cpu_has(c, X86_FEATURE_MWAIT)) { ++ if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) { + /* + * Skip, if setup has overridden idle. + * One CPU supports mwait => All CPUs supports mwait +--- a/arch/x86/kernel/process_64.c ++++ b/arch/x86/kernel/process_64.c +@@ -254,6 +254,33 @@ static void mwait_idle(void) + } + } + ++/* ++ * mwait selection logic: ++ * ++ * It depends on the CPU. For AMD CPUs that support MWAIT this is ++ * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings ++ * then depend on a clock divisor and current Pstate of the core. If ++ * all cores of a processor are in halt state (C1) the processor can ++ * enter the C1E (C1 enhanced) state. If mwait is used this will never ++ * happen. ++ * ++ * idle=mwait overrides this decision and forces the usage of mwait. ++ */ ++static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c) ++{ ++ if (force_mwait) ++ return 1; ++ ++ if (c->x86_vendor == X86_VENDOR_AMD) { ++ switch(c->x86) { ++ case 0x10: ++ case 0x11: ++ return 0; ++ } ++ } ++ return 1; ++} ++ + void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c) + { + static int selected; +@@ -266,7 +293,7 @@ void __cpuinit select_idle_routine(const + " performance may degrade.\n"); + } + #endif +- if (cpu_has(c, X86_FEATURE_MWAIT)) { ++ if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) { + /* + * Skip, if setup has overridden idle. + * One CPU supports mwait => All CPUs supports mwait diff --git a/queue-2.6.25/x86-remove-mwait-capability-c-state-check.patch b/queue-2.6.25/x86-remove-mwait-capability-c-state-check.patch new file mode 100644 index 00000000000..c624b551aba --- /dev/null +++ b/queue-2.6.25/x86-remove-mwait-capability-c-state-check.patch @@ -0,0 +1,95 @@ +From vegard.nossum@gmail.com Thu Jun 19 07:32:23 2008 +Date: Thu, 19 Jun 2008 16:32:14 +0200 +From: Ingo Molnar +Subject: x86: remove mwait capability C-state check +To: stable@kernel.org +Cc: Greg KH , Ingo Molnar , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org +Message-ID: <20080619143214.GA3243@damson.getinternet.no> +Content-Disposition: inline + +From: Ingo Molnar + +back-ported from upstream commit a738d897b7b03b83488ae74a9bc03d26a2875dc6 by Vegard Nossum + +Vegard Nossum reports: + +| powertop shows between 200-400 wakeups/second with the description +| ": Rescheduling interrupts" when all processors have load (e.g. +| I need to run two busy-loops on my 2-CPU system for this to show up). +| +| The bisect resulted in this commit: +| +| commit 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec +| Date: Wed Jan 30 13:33:16 2008 +0100 +| +| x86: use the correct cpuid method to detect MWAIT support for C states + +remove the functional effects of this patch and make mwait unconditional. + +A future patch will turn off mwait on specific CPUs where that causes +power to be wasted. + +Bisected-by: Vegard Nossum +Tested-by: Vegard Nossum +Signed-off-by: Ingo Molnar +Signed-off-by: Vegard Nossum +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/process_32.c | 10 +--------- + arch/x86/kernel/process_64.c | 11 +---------- + 2 files changed, 2 insertions(+), 19 deletions(-) + +--- a/arch/x86/kernel/process_32.c ++++ b/arch/x86/kernel/process_32.c +@@ -259,14 +259,6 @@ static void mwait_idle(void) + mwait_idle_with_hints(0, 0); + } + +-static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c) +-{ +- if (force_mwait) +- return 1; +- /* Any C1 states supported? */ +- return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0; +-} +- + void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c) + { + static int selected; +@@ -279,7 +271,7 @@ void __cpuinit select_idle_routine(const + " performance may degrade.\n"); + } + #endif +- if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) { ++ if (cpu_has(c, X86_FEATURE_MWAIT)) { + /* + * Skip, if setup has overridden idle. + * One CPU supports mwait => All CPUs supports mwait +--- a/arch/x86/kernel/process_64.c ++++ b/arch/x86/kernel/process_64.c +@@ -254,15 +254,6 @@ static void mwait_idle(void) + } + } + +- +-static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c) +-{ +- if (force_mwait) +- return 1; +- /* Any C1 states supported? */ +- return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0; +-} +- + void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c) + { + static int selected; +@@ -275,7 +266,7 @@ void __cpuinit select_idle_routine(const + " performance may degrade.\n"); + } + #endif +- if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) { ++ if (cpu_has(c, X86_FEATURE_MWAIT)) { + /* + * Skip, if setup has overridden idle. + * One CPU supports mwait => All CPUs supports mwait