summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2008-06-24Linux 2.6.25.9v2.6.25.9Greg Kroah-Hartman
2008-06-24Fix ZERO_PAGE breakage with vmwareLinus Torvalds
commit 672ca28e300c17bf8d792a2a7a8631193e580c74 upstream Commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f ("Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP") broke vmware, as reported by Jeff Chua: "This broke vmware 6.0.4. Jun 22 14:53:03.845: vmx| NOT_IMPLEMENTED /build/mts/release/bora-93057/bora/vmx/main/vmmonPosix.c:774" and the reason seems to be that there's an old bug in how we handle do FOLL_ANON on VM_SHARED areas in get_user_pages(), but since it only triggered if the whole page table was missing, nobody had apparently hit it before. The recent changes to 'follow_page()' made the FOLL_ANON logic trigger not just for whole missing page tables, but for individual pages as well, and exposed this problem. This fixes it by making the test for when FOLL_ANON is used more careful, and also makes the code easier to read and understand by moving the logic to a separate inline function. Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24hwmon: (adt7473) Initialize max_duty_at_overheat before useJean Delvare
commit ed4ec814e45ae8b1596aea0a29b92f6c3614acaa upstream data->max_duty_at_overheat is not updated in adt7473_update_device, so it might be used before it is initialized (if the user reads from sysfs file max_duty_at_crit before writing to it.) Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24hwmon: (lm85) Fix function RANGE_TO_REG()Jean Delvare
Function RANGE_TO_REG() is broken. For a requested range of 2000 (2 degrees C), it will return an index value of 15, i.e. 80.0 degrees C, instead of the expected index value of 0. All other values are handled properly, just 2000 isn't. The bug was introduced back in November 2004 by this patch: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=1c28d80f1992240373099d863e4996cdd5d646d0 In Linus' kernel I decided to rewrite the whole function in a way which was more obviously correct. But for -stable let's just do the minimal fix. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24watchdog: hpwdt: fix use of inline assemblyLinus Torvalds
commit 1f6ef2342972dc7fd623f360f84006e2304eb935 upstream The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken, and included all the function prologue and epilogue stuff, even though it was itself then inside a C function where the compiler would add its own prologue and epilogue on top of it all. This then just _happened_ to work if you had exactly the right compiler version and exactly the right compiler flags, so that gcc just happened to not create any prologue at all (the gcc-generated epilogue wouldn't matter, since it would never be reached). But the more proper way to fix it is to simply not do this. Move the inline asm to the top level, with no surrounding function at all (the better alternative would be to remove the prologue and make it actually use proper description of the arguments to the inline asm, but that's a bigger change than the one I'm willing to make right now). Tested-by: S.Çağlar Onur <caglar@pardus.org.tr> Acked-by: Thomas Mingarelli <Thomas.Mingarelli@hp.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits.Jeremy Fitzhardinge
commit ad524d46f36bbc32033bb72ba42958f12bf49b06 upstream When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can potentially have the same number of physical address bits as the 64-bit host ("Enhanced Legacy PAE Paging"). This means, in theory, we could have up to 52 bits of physical address in a pte. The 32-bit kernel uses a 32-bit unsigned long to represent a pfn. This means that it can only represent physical addresses up to 32+12=44 bits wide. Rather than widening pfns everywhere, just set 2^44 as the Linux x86_32-PAE architectural limit for physical address size. This is a bugfix for two cases: 1. running a 32-bit PAE kernel on a machine with more than 64GB RAM. 2. running a 32-bit PAE Xen guest on a host machine with more than 64GB RAM In both cases, a pte could need to have more than 36 bits of physical, and masking it to 36-bits will cause fairly severe havoc. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24x86: use BOOTMEM_EXCLUSIVE on 32-bitBernhard Walle
commit d3942cff620bea073fc4e3c8ed878eb1e84615ce upstream This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for i386 and prints a error message on failure. The patch is still for 2.6.26 since it is only bug fixing. The unification of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24Add return value to reserve_bootmem_node()Bernhard Walle
commit 71c2742f5e6348d76ee62085cf0a13e5eff0f00e upstream This patch changes the function reserve_bootmem_node() from void to int, returning -ENOMEM if the allocation fails. This fixes a build problem on x86 with CONFIG_KEXEC=y and CONFIG_NEED_MULTIPLE_NODES=y Signed-off-by: Bernhard Walle <bwalle@suse.de> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24sctp: Make sure N * sizeof(union sctp_addr) does not overflow.David S. Miller
commit 735ce972fbc8a65fb17788debd7bbe7b4383cc62 upstream As noticed by Gabriel Campana, the kmalloc() length arg passed in by sctp_getsockopt_local_addrs_old() can overflow if ->addr_num is large enough. Therefore, enforce an appropriate limit. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIPLinus Torvalds
commit 89f5b7da2a6bad2e84670422ab8192382a5aeb9f upstream KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit 557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") removed the ZERO_PAGE from the VM mappings, any users of get_user_pages() will generally now populate the VM with real empty pages needlessly. We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but since fault handling no longer uses ZERO_PAGE for new anonymous pages, we now need to handle that special case in follow_page() instead. In particular, the removal of ZERO_PAGE effectively removed the core file writing optimization where we would skip writing pages that had not been populated at all, and increased memory pressure a lot by allocating all those useless newly zeroed pages. This reinstates the optimization by making the unmapped PTE case the same as for a non-existent page table, which already did this correctly. While at it, this also fixes the XIP case for follow_page(), where the caller could not differentiate between the case of a page that simply could not be used (because it had no "struct page" associated with it) and a page that just wasn't mapped. We do that by simply returning an error pointer for pages that could not be turned into a "struct page *". The error is arbitrarily picked to be EFAULT, since that was what get_user_pages() already used for the equivalent IO-mapped page case. [ Also removed an impossible test for pte_offset_map_lock() failing: that's not how that function works ] Acked-by: Oleg Nesterov <oleg@tv-sign.ru> Acked-by: Nick Piggin <npiggin@suse.de> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-24atl1: relax eeprom mac address error checkRadu Cristescu
upstream commit: 58c7821c4264a7ddd6f0c31c5caaf393b3897f10 The atl1 driver tries to determine the MAC address thusly: - If an EEPROM exists, read the MAC address from EEPROM and validate it. - If an EEPROM doesn't exist, try to read a MAC address from SPI flash. - If that fails, try to read a MAC address directly from the MAC Station Address register. - If that fails, assign a random MAC address provided by the kernel. We now have a report of a system fitted with an EEPROM containing all zeros where we expect the MAC address to be, and we currently handle this as an error condition. Turns out, on this system the BIOS writes a valid MAC address to the NIC's MAC Station Address register, but we never try to read it because we return an error when we find the all- zeros address in EEPROM. This patch relaxes the error check and continues looking for a MAC address even if it finds an illegal one in EEPROM. http://ubuntuforums.org/showthread.php?t=562617 [jacliburn@bellsouth.net: backport to 2.6.25.7] Signed-off-by: Radu Cristescu <advantis@gmx.net> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21Linux 2.6.25.8v2.6.25.8Greg Kroah-Hartman
2008-06-21x86: disable mwait for AMD family 10H/11H CPUsThomas 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 <tglx@linutronix.de> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21x86: remove mwait capability C-state checkIngo Molnar
back-ported from upstream commit a738d897b7b03b83488ae74a9bc03d26a2875dc6 by Vegard Nossum Vegard Nossum reports: | powertop shows between 200-400 wakeups/second with the description | "<kernel IPI>: 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 <vegard.nossum@gmail.com> Tested-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21nf_conntrack_h323: fix memory leak in module initialization error pathPatrick 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 <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21nf_conntrack_h323: fix module unload crashPatrick 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 <liannan@twsz.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()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: [<c03d394b>] 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:[<c03d394b>] 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: [<c038e728>] nla_parse+0x5c/0xb0 [<c0397c1b>] ctnetlink_change_status+0x190/0x1c6 [<c0397eec>] ctnetlink_new_conntrack+0x189/0x61f [<c0119aee>] update_curr+0x3d/0x52 [<c03902d1>] nfnetlink_rcv_msg+0xc1/0xd8 [<c0390228>] nfnetlink_rcv_msg+0x18/0xd8 [<c0390210>] nfnetlink_rcv_msg+0x0/0xd8 [<c038d2ce>] netlink_rcv_skb+0x2d/0x71 [<c0390205>] nfnetlink_rcv+0x19/0x24 [<c038d0f5>] 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 <ole@ans.pl> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21SCSI: sr: fix corrupt CD data after media change and delayJames Bottomley
commit: d1daeabf0da5bfa1943272ce508e2ba785730bf0 upstream Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> If you delay 30s or more before mounting a CD after inserting it then the kernel has the wrong value for the CD size. http://marc.info/?t=121276133000001 The problem is in sr_test_unit_ready(): the function eats unit attentions without adjusting the sdev->changed status. This means that when the CD signals changed media via unit attention, we can ignore it. Fix by making sr_test_unit_ready() adjust the changed status. Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21ACPICA: Ignore ACPI table signature for Load() operatorBob Moore
upstream bc45b1d39a925b56796bebf8a397a0491489d85c Without this patch booting with acpi_osi="!Windows 2006" is required for several machines to function properly with cpufreq due to failure to load a Vista specific table with a bad signature. Only "SSDT" is acceptable to the ACPI spec, but tables are seen with OEMx and null sigs. Therefore, signature validation is worthless. Apparently MS ACPI accepts such signatures, ACPICA must be compatible. http://bugzilla.kernel.org/show_bug.cgi?id=9919 http://bugzilla.kernel.org/show_bug.cgi?id=10383 http://bugzilla.kernel.org/show_bug.cgi?id=10454 https://bugzilla.novell.com/show_bug.cgi?id=396311 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21scsi_host regression: fix scsi host leakMike Christie
The patch is upstream as commit 3ed7897242b7efe977f3a8d06d4e5a4ebe28b10e A different backport is necessary because of the class_device to device conversion post 2.6.25. commit 9c7701088a61cc0cf8a6e1c68d1e74e3cc2ee0b7 Author: Dave Young <hidave.darkstar@gmail.com> Date: Tue Jan 22 14:01:34 2008 +0800 scsi: use class iteration api Isn't a correct replacement for the original hand rolled host lookup. The problem is that class_find_child would get a reference to the host's class device which is never released. Since the host class device holds a reference to the host gendev, the host can never be freed. In 2.6.25 we started using class_find_device, and this function also gets a reference to the device, so we end up with an extra ref and the host will not get released. This patch adds a class_put_device to balance the class_find_device() get. I kept the scsi_host_get in scsi_host_lookup, because the target layer is using scsi_host_lookup and it looks like it needs the SHOST_DEL check. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21b43: Fix possible NULL pointer dereference in DMA codeMichael Buesch
a cut-down version of commit 028118a5f09a9c807e6b43e2231efdff9f224c74 upstream This fixes a possible NULL pointer dereference in an error path of the DMA allocation error checking code. In case the DMA allocation address is invalid, the dev pointer is dereferenced for unmapping of the buffer. Reported-by: Miles Lane <miles.lane@gmail.com> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21b43: Fix noise calculation WARN_ONMichael Buesch
commit 98a3b2fe435ae76170936c14f5c9e6a87548e3ef upstream. This removes a WARN_ON that is responsible for the following koops: http://www.kerneloops.org/searchweek.php?search=b43_generate_noise_sample The comment in the patch describes why it's safe to simply remove the check. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21virtio_net: Fix skb->csum_start computationMark McLoughlin
commit 23cde76d801246a702e7a84c3fe3d655b35c89a1 upstream. hdr->csum_start is the offset from the start of the ethernet header to the transport layer checksum field. skb->csum_start is the offset from skb->head. skb_partial_csum_set() assumes that skb->data points to the ethernet header - i.e. it computes skb->csum_start by adding the headroom to hdr->csum_start. Since eth_type_trans() skb_pull()s the ethernet header, skb_partial_csum_set() should be called before eth_type_trans(). (Without this patch, GSO packets from a guest to the world outside the host are corrupted). Signed-off-by: Mark McLoughlin <markmc@redhat.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21opti621: remove DMA supportBartlomiej Zolnierkiewicz
commit f361037631ba547ea88adf8d2359d810c1b2605a upstream These controllers don't support DMA. Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code. Tested-by: Juergen Kosel <juergen.kosel@gmx.de> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21opti621: disable read prefetchBartlomiej Zolnierkiewicz
commit 62128b2ca812c1266f4ff7bac068bf0b626c6179 upstream This fixes 2.6.25 regression (kernel.org bugzilla bug #10723) caused by: commit 912fb29a36a7269ac1c4a4df45bc0ac1d2637972 Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Fri Oct 19 00:30:11 2007 +0200 opti621: always tune PIO ... Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code. Bisected-by: Juergen Kosel <juergen.kosel@gmx.de> Tested-by: Juergen Kosel <juergen.kosel@gmx.de> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-21Fix tty speed handling on 8250Alan Cox
commit e991a2bd4fa0b2f475b67dfe8f33e8ecbdcbb40b upstream. We try and write the correct speed back but the serial midlayer already mangles the speed on us and that means if we request B0 we report back B9600 when we should not. For now we'll hack around this in the drivers and serial code, pending a better long term solution. Signed-off-by: Alan Cox <alan@redhat.com> 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>
2008-06-21x86-64: Fix "bytes left to copy" return value for copy_from_user()Linus Torvalds
commit 42a886af728c089df8da1b0017b0e7e6c81b5335 upstream Most users by far do not care about the exact return value (they only really care about whether the copy succeeded in its entirety or not), but a few special core routines actually care deeply about exactly how many bytes were copied from user space. And the unrolled versions of the x86-64 user copy routines would sometimes report that it had copied more bytes than it actually had. Very few uses actually have partial copies to begin with, but to make this bug even harder to trigger, most x86 CPU's use the "rep string" instructions for normal user copies, and that version didn't have this issue. To make it even harder to hit, the one user of this that really cared about the return value (and used the uncached version of the copy that doesn't use the "rep string" instructions) was the generic write routine, which pre-populated its source, once more hiding the problem by avoiding the exception case that triggers the bug. In other words, very special thanks to Bron Gondwana who not only triggered this, but created a test-program to show it, and bisected the behavior down to commit 08291429cfa6258c4cd95d8833beb40f828b194e ("mm: fix pagecache write deadlocks") which changed the access pattern just enough that you can now trigger it with 'writev()' with multiple iovec's. That commit itself was not the cause of the bug, it just allowed all the stars to align just right that you could trigger the problem. [ Side note: this is just the minimal fix to make the copy routines (with __copy_from_user_inatomic_nocache as the particular version that was involved in showing this) have the right return values. We really should improve on the exceptional case further - to make the copy do a byte-accurate copy up to the exact page limit that causes it to fail. As it is, the callers have to do extra work to handle the limit case gracefully. ] Reported-by: Bron Gondwana <brong@fastmail.fm> Cc: Nick Piggin <npiggin@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16Linux 2.6.25.7v2.6.25.7Greg Kroah-Hartman
2008-06-16mac80211: send association event on IBSS createDan Williams
patch 507b06d0622480f8026d49a94f86068bb0fd6ed6 upstream Otherwise userspace has no idea the IBSS creation succeeded. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16x86: fix recursive dependenciesRoman Zippel
commit 823c248e7cc75b4f22da914b01f8e5433cff197e in mainline The proper dependency check uncovered a few dependency problems, the subarchitecture used a mixture of selects and depends on SMP and PCI dependency was messed up. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
2008-06-16bttv: Fix a deadlock in the bttv driverArjan van de Ven
commit 81b2dbcad86732ffc02bad87aa25c4651199fc77 in mainline. vidiocgmbuf() does this: mutex_lock(&fh->cap.vb_lock); retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize, V4L2_MEMORY_MMAP); and videobuf_mmap_setup() then just does mutex_lock(&q->vb_lock); ret = __videobuf_mmap_setup(q, bcount, bsize, memory); mutex_unlock(&q->vb_lock); which is an obvious double-take deadlock. This patch fixes this by having vidiocgmbuf() just call the __videobuf_mmap_setup function instead. Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org> Reported-by: Koos Vriezen <koos.vriezen@gmail.com> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16Kconfig: introduce ARCH_DEFCONFIG to DEFCONFIG_LISTSam Ravnborg
commit 73531905ed53576d9e8707659a761e7046a60497 in mainline. init/Kconfig contains a list of configs that are searched for if 'make *config' are used with no .config present. Extend this list to look at the config identified by ARCH_DEFCONFIG. With this change we now try the defconfig targets last. This fixes a regression reported by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.cArjan van de Ven
commit 03a74dcc7eebe6edd778317e82fafdf71e68488c in mainline. enable_irq_wake() and disable_irq_wake() need to be balanced. However, serial_core.c calls these for different conditions during the suspend and resume functions... This is causing a regular WARN_ON() as found at http://www.kerneloops.org/search.php?search=set_irq_wake This patch makes the conditions for triggering the _wake enable/disable sequence identical. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> 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>
2008-06-16CPUFREQ: Fix format string bug.Chris Wright
commit 326f6a5c9c9e1a62aec37bdc0c3f8d53adabe77b upstream Format string bug. Not exploitable, as this is only writable by root, but worth fixing all the same. From: Chris Wright <chrisw@sous-sol.org> Spotted-by: Ilja van Sprundel <ilja@netric.org> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16cifs: fix oops on mount when CONFIG_CIFS_DFS_UPCALL is enabledMarcin Slusarz
simple "mount -t cifs //xxx /mnt" oopsed on strlen of options http://kerneloops.org/guilty.php?guilty=cifs_get_sb&version=2.6.25-release&start=16711 \ 68&end=1703935&class=oops Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16m68k: Add ext2_find_{first,next}_bit() for ext4Aneesh Kumar K.V
commit 69c5ddf58a03da3686691ad2f293bc79fd977c10 upstream Add ext2_find_{first,next}_bit(), which are needed for ext4. They're derived out of the ext2_find_next_zero_bit found in the same file. Compile tested with crosstools [Reworked to preserve all symmetry with ext2_find_{first,next}_zero_bit()] This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10393 Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> 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>
2008-06-16IB/umem: Avoid sign problems when demoting npages to integerRoland Dreier
commit 8079ffa0e18baaf2940e52e0c118eef420a473a4 upstream On a 64-bit architecture, if ib_umem_get() is called with a size value that is so big that npages is negative when cast to int, then the length of the page list passed to get_user_pages(), namely min_t(int, npages, PAGE_SIZE / sizeof (struct page *)) will be negative, and get_user_pages() will immediately return 0 (at least since 900cf086, "Be more robust about bad arguments in get_user_pages()"). This leads to an infinite loop in ib_umem_get(), since the code boils down to: while (npages) { ret = get_user_pages(...); npages -= ret; } Fix this by taking the minimum as unsigned longs, so that the value of npages is never truncated. The impact of this bug isn't too severe, since the value of npages is checked against RLIMIT_MEMLOCK, so a process would need to have an astronomical limit or have CAP_IPC_LOCK to be able to trigger this, and such a process could already cause lots of mischief. But it does let buggy userspace code cause a kernel lock-up; for example I hit this with code that passes a negative value into a memory registartion function where it is promoted to a huge u64 value. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp))Ilpo Järvinen
[ upstream commit: 8aca6cb1179ed9bef9351028c8d8af852903eae2 ] It is possible that this skip path causes TCP to end up into an invalid state where ca_state was left to CA_Open while some segments already came into sacked_out. If next valid ACK doesn't contain new SACK information TCP fails to enter into tcp_fastretrans_alert(). Thus at least high_seq is set incorrectly to a too high seqno because some new data segments could be sent in between (and also, limited transmit is not being correctly invoked there). Reordering in both directions can easily cause this situation to occur. I guess we would want to use tcp_moderate_cwnd(tp) there as well as it may be possible to use this to trigger oversized burst to network by sending an old ACK with huge amount of SACK info, but I'm a bit unsure about its effects (mainly to FlightSize), so to be on the safe side I just currently fixed it minimally to keep TCP's state consistent (obviously, such nasty ACKs have been possible this far). Though it seems that FlightSize is already underestimated by some amount, so probably on the long term we might want to trigger recovery there too, if appropriate, to make FlightSize calculation to resemble reality at the time when the losses where discovered (but such change scares me too much now and requires some more thinking anyway how to do that as it likely involves some code shuffling). This bug was found by Brian Vowell while running my TCP debug patch to find cause of another TCP issue (fackets_out miscount). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16forcedeth: msi interruptsAyaz Abdulla
commit 4db0ee176e256444695ee2d7b004552e82fec987 upstream Add a workaround for lost MSI interrupts. There is a race condition in the HW in which future interrupts could be missed. The workaround is to toggle the MSI irq mask. Added cleanup based on comments from Andrew Morton. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-06-16hgafb: resource management fixKrzysztof Helt
commit 630c270183133ac25bef8c8d726ac448df9b169a upstream Date: Thu, 12 Jun 2008 15:21:29 -0700 Subject: hgafb: resource management fix Release ports which are requested during detection which are not freed if there is no hga card. Otherwise there is a crash during cat /proc/ioports command. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> 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>
2008-06-16cciss: add new hardware supportMike Miller
commit 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302 upstream Date: Thu, 12 Jun 2008 15:21:34 -0700 Subject: cciss: add new hardware support Add support for the next generation of HP Smart Array SAS/SATA controllers. Shipping date is late Fall 2008. Bump the driver version to 3.6.20 to reflect the new hardware support from patch 1 of this set. Signed-off-by: Mike Miller <mike.miller@hp.com> Cc: Jens Axboe <jens.axboe@oracle.com> 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>
2008-06-16mmc: wbsd: initialize tasklets before requesting interruptChuck Ebbert
commit cef33400d0349fb24b6f8b7dea79b66e3144fd8b upstream With CONFIG_DEBUG_SHIRQ set we will get an interrupt as soon as we allocate one. Tasklets may be scheduled in the interrupt handler but they will be initialized after the handler returns, causing a BUG() in kernel/softirq.c when they run. Should fix this Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=449817 Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Acked-by: Pierre Ossman <drzeus@drzeus.cx> 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>
2008-06-16tcp FRTO: work-around inorder receiversIlpo Järvinen
[ upstream commit: 79d44516b4b178ffb6e2159c75584cfcfc097914 ] If receiver consumes segments successfully only in-order, FRTO fallback to conventional recovery produces RTO loop because FRTO's forward transmissions will always get dropped and need to be resent, yet by default they're not marked as lost (which are the only segments we will retransmit in CA_Loss). Price to pay about this is occassionally unnecessarily retransmitting the forward transmission(s). SACK blocks help a bit to avoid this, so it's mainly a concern for NewReno case though SACK is not fully immune either. This change has a side-effect of fixing SACKFRTO problem where it didn't have snd_nxt of the RTO time available anymore when fallback become necessary (this problem would have only occured when RTO would occur for two or more segments and ECE arrives in step 3; no need to figure out how to fix that unless the TODO item of selective behavior is considered in future). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reported-by: Damon L. Chesser <damon@damtek.com> Tested-by: Damon L. Chesser <damon@damtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16tcp FRTO: SACK variant is errorneously used with NewRenoIlpo Järvinen
[ upstream commit: 62ab22278308a40bcb7f4079e9719ab8b7fe11b5 ] Note: there's actually another bug in FRTO's SACK variant, which is the causing failure in NewReno case because of the error that's fixed here. I'll fix the SACK case separately (it's a separate bug really, though related, but in order to fix that I need to audit tp->snd_nxt usage a bit). There were two places where SACK variant of FRTO is getting incorrectly used even if SACK wasn't negotiated by the TCP flow. This leads to incorrect setting of frto_highmark with NewReno if a previous recovery was interrupted by another RTO. An eventual fallback to conventional recovery then incorrectly considers one or couple of segments as forward transmissions though they weren't, which then are not LOST marked during fallback making them "non-retransmittable" until the next RTO. In a bad case, those segments are really lost and are the only one left in the window. Thus TCP needs another RTO to continue. The next FRTO, however, could again repeat the same events making the progress of the TCP flow extremely slow. In order for these events to occur at all, FRTO must occur again in FRTOs step 3 while the key segments must be lost as well, which is not too likely in practice. It seems to most frequently with some small devices such as network printers that *seem* to accept TCP segments only in-order. In cases were key segments weren't lost, things get automatically resolved because those wrongly marked segments don't need to be retransmitted in order to continue. I found a reproducer after digging up relevant reports (few reports in total, none at netdev or lkml I know of), some cases seemed to indicate middlebox issues which seems now to be a false assumption some people had made. Bugzilla #10063 _might_ be related. Damon L. Chesser <damon@damtek.com> had a reproducable case and was kind enough to tcpdump it for me. With the tcpdump log it was quite trivial to figure out. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16tcp FRTO: Fix fallback to conventional recoveryIlpo Järvinen
[ upstream commit: a1c1f281b84a751fdb5ff919da3b09df7297619f ] It seems that commit 009a2e3e4ec ("[TCP] FRTO: Improve interoperability with other undo_marker users") run into another land-mine which caused fallback to conventional recovery to break: 1. Cumulative ACK arrives after FRTO retransmission 2. tcp_try_to_open sees zero retrans_out, clears retrans_stamp which should be kept like in CA_Loss state it would be 3. undo_marker change allowed tcp_packet_delayed to return true because of the cleared retrans_stamp once FRTO is terminated causing LossUndo to occur, which means all loss markings FRTO made are reverted. This means that the conventional recovery basically recovered one loss per RTT, which is not that efficient. It was quite unobvious that the undo_marker change broken something like this, I had a quite long session to track it down because of the non-intuitiviness of the bug (luckily I had a trivial reproducer at hand and I was also able to learn to use kprobes in the process as well :-)). This together with the NewReno+FRTO fix and FRTO in-order workaround this fixes Damon's problems, this and the first mentioned are enough to fix Bugzilla #10063. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reported-by: Damon L. Chesser <damon@damtek.com> Tested-by: Damon L. Chesser <damon@damtek.com> Tested-by: Sebastian Hyrwall <zibbe@cisko.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16tcp: fix skb vs fack_count out-of-sync conditionIlpo Järvinen
[ upstream commit: a6604471db5e7a33474a7f16c64d6b118fae3e74 ] This bug is able to corrupt fackets_out in very rare cases. In order for this to cause corruption: 1) DSACK in the middle of previous SACK block must be generated. 2) In order to take that particular branch, part or all of the DSACKed segment must already be SACKed so that we have that in cache in the first place. 3) The new info must be top enough so that fackets_out will be updated on this iteration. ...then fack_count is updated while skb wasn't, then we walk again that particular segment thus updating fack_count twice for a single skb and finally that value is assigned to fackets_out by tcp_sacktag_one. It is safe to call tcp_sacktag_one just once for a segment (at DSACK), no need to call again for plain SACK. Potential problem of the miscount are limited to premature entry to recovery and to inflated reordering metric (which could even cancel each other out in the most the luckiest scenarios :-)). Both are quite insignificant in worst case too and there exists also code to reset them (fackets_out once sacked_out becomes zero and reordering metric on RTO). This has been reported by a number of people, because it occurred quite rarely, it has been very evasive. Andy Furniss was able to get it to occur couple of times so that a bit more info was collected about the problem using a debug patch, though it still required lot of checking around. Thanks also to others who have tried to help here. This is listed as Bugzilla #10346. The bug was introduced by me in commit 68f8353b48 ([TCP]: Rewrite SACK block processing & sack_recv_cache use), I probably thought back then that there's need to scan that entry twice or didn't dare to make it go through it just once there. Going through twice would have required restoring fack_count after the walk but as noted above, I chose to drop the additional walk step altogether here. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16l2tp: Fix possible oops if transmitting or receiving when tunnel goes downJames Chapman
[ upstream commit: 24b95685ffcdb3dc28f64b9e8af6ea3e8360fbc5 ] Some problems have been experienced in the field which cause an oops in the pppol2tp driver if L2TP tunnels fail while passing data. The pppol2tp driver uses private data that is referenced via the sk->sk_user_data of its UDP and PPPoL2TP sockets. This patch makes sure that the driver uses sock_hold() when it holds a reference to the sk pointer. This affects its sendmsg(), recvmsg(), getname(), [gs]etsockopt() and ioctl() handlers. Tested by ISP where problem was seen. System has been up 10 days with no oops since running this patch. Without the patch, an oops would occur every 1-2 days. Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16l2tp: Fix possible WARN_ON from socket code when UDP socket is closedJames Chapman
[ upstream commit: 199f7d24ae59894243687a234a909f44a8724506 ] If an L2TP daemon closes a tunnel socket while packets are queued in the tunnel's reorder queue, a kernel warning is logged because the socket is closed while skbs are still referencing it. The fix is to purge the queue in the socket's release handler. WARNING: at include/net/sock.h:351 udp_lib_unhash+0x41/0x68() Pid: 12998, comm: openl2tpd Not tainted 2.6.25 #8 [<c0423c58>] warn_on_slowpath+0x41/0x51 [<c05d33a7>] udp_lib_unhash+0x41/0x68 [<c059424d>] sk_common_release+0x23/0x90 [<c05d16be>] udp_lib_close+0x8/0xa [<c05d8684>] inet_release+0x42/0x48 [<c0592599>] sock_release+0x14/0x60 [<c059299f>] sock_close+0x29/0x30 [<c046ef52>] __fput+0xad/0x15b [<c046f1d9>] fput+0x17/0x19 [<c046c8c4>] filp_close+0x50/0x5a [<c046da06>] sys_close+0x69/0x9f [<c04048ce>] syscall_call+0x7/0xb Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16tcp: Limit cwnd growth when deferring for GSOJohn Heffner
[ upstream commit: 246eb2af060fc32650f07203c02bdc0456ad76c7 ] This fixes inappropriately large cwnd growth on sender-limited flows when GSO is enabled, limiting cwnd growth to 64k. [ Backport to 2.6.25 by replacing sk->sk_gso_max_size with 65536 -DaveM ] Signed-off-by: John Heffner <johnwheffner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2008-06-16tcp: Allow send-limited cwnd to grow up to max_burst when gso disabledJohn Heffner
[ upstream commit: ce447eb91409225f8a488f6b7b2a1bdf7b2d884f ] This changes the logic in tcp_is_cwnd_limited() so that cwnd may grow up to tcp_max_burst() even when sk_can_gso() is false, or when sysctl_tcp_tso_win_divisor != 0. Signed-off-by: John Heffner <johnwheffner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-11-01 10:36:16 +0000