- 09 Oct, 2008 7 commits
-
-
Mel Gorman authored
commit 5bead2a0 upstream The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when scanning zonelists to keep track of where in the zonelist it is. The zoneref that is returned corresponds to the the next zone that is to be scanned, not the current one. It was intended to be treated as an opaque list. When the page allocator is scanning a zonelist, it marks elements in the zonelist corresponding to zones that are temporarily full. As the zonelist is being updated, it uses the cursor here; if (NUMA_BUILD) zlc_mark_zone_full(zonelist, z); This is intended to prevent rescanning in the near future but the zoneref cursor does not correspond to the zone that has been found to be full. This is an easy misunderstanding to make so this patch corrects the problem by changing zoneref cursor to be the current zone being scanned instead of the next one. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Cc: Andy Whitcroft <apw@shadowen.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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>
-
Yuri Tikhonov authored
commit de24125d upstream Should clear the next pointer of the TX if we are sure that the next TX (say NXT) will be submitted to the channel too. Overwise, we break the chain of descriptors, because we lose the information about the next descriptor to run. So next time, when invoke async_tx_run_dependencies() with TX, it's TX->next will be NULL, and NXT will be never submitted. Signed-off-by:
Yuri Tikhonov <yur@emcraft.com> Signed-off-by:
Ilya Yanok <yanok@emcraft.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Andrew Morton authored
commit 70bb0896 upstream mmc_block_open() increments md->usage although it returns with -EROFS when default mounting a MMC/SD card with write protect switch on. This reference counting bug prevents /dev/mmcblkX from being released on card removal, and situation worsen with reinsertion until the minor number range runs out. Reported-by: <sasin@solomon-systech.com> Acked-by:
Pierre Ossman <drzeus-list@drzeus.cx> Signed-off-by:
-
Andy Gospodarek authored
commit 15e79f24 upstream This commit dropped the setting of the default interrupt throttle rate. commit 021230d4 Author: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com> Date: Mon Mar 3 15:03:45 2008 -0800 ixgbe: Introduce MSI-X queue vector code The following patch adds it back. Without this the default value of 0 causes the performance of this card to be awful. Restoring these to the default values yields much better performance. This regression has been around since 2.6.25. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Sven Wegener authored
In Linus' tree: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commit;h=e74783ec3cb981211689bd2cfd3248f8dc48ec01 We need to convert the error pointer from class_create(), else we'll return the successful return code from register_chrdev() on failure. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Milan Broz authored
commit 9f497bcc upstream ACPI: Fix thermal shutdowns Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by:
Milan Broz <mbroz@redhat.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Chuck Ebbert authored
This patch is not needed in 2.6.27 because it has new c1e-aware idle code. In kernel 2.6.26 the 32-bit x86 timers are started earlier than before. This breaks AMD c1e detection trying to force timer broadcast for the local apic timer. Copy the code from the 64-bit kernel to force timer broadcast late. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=11427Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 08 Sep, 2008 33 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This resolves the build error introduced in 97348238 due to Greg applying the the incorrect patch. Thanks to Randy Dunlap for reporting this. Tested-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Tejun Heo authored
commit 4bdee6c5 upstream sata_mv allowed issuing two DMA commands concurrently which the hardware allows. Unfortunately, libata core layer isn't ready for this yet and spews ugly warning message and malfunctions on this. Don't allow concurrent DMA commands for now. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Avi Kivity authored
(cherry picked from commit cd5998eb) The shadow code assigns a pte directly in one place, which is nonatomic on i386 can can cause random memory references. Fix by using an atomic setter. Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Ingo Molnar authored
commit 9754a5b8 upstream x86: work around MTRR mask setting, v2 improve the debug printout: - make it actually display something - print it only once would be nice to have a WARN_ONCE() facility, to feed such things to kerneloops.org. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
J. Bruce Fields authored
commit 91b80969 upstream The array we kmalloc() here is not large enough. Thanks to Johann Dahm and David Richter for bug report and testing. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Cc: David Richter <richterd@citi.umich.edu> Tested-by:
Johann Dahm <jdahm@umich.edu> Signed-off-by:
-
Cyrill Gorcunov authored
commit 27df6f25 upstream Vegard Nossum reported ---------------------- > I noticed that something weird is going on with /proc/sys/sunrpc/transports. > This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When > I "cat" this file, I get the expected output: > $ cat /proc/sys/sunrpc/transports > tcp 1048576 > udp 32768 > But I think that it does not check the length of the buffer supplied by > userspace to read(). With my original program, I found that the stack was > being overwritten by the characters above, even when the length given to > read() was just 1. David Wagner added (among other things) that copy_to_user could be probably used here. Ingo Oeser suggested to use simple_read_from_buffer() here. The conclusion is that proc_do_xprt doesn't check for userside buffer size indeed so fix this by using Ingo's suggestion. Reported-by:
Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> CC: Ingo Oeser <ioe-lkml@rameria.de> Cc: Neil Brown <neilb@suse.de> Cc: Chuck Lever <chuck.lever@oracle.com> Cc: Greg Banks <gnb@sgi.com> Cc: Tom Tucker <tom@opengridcomputing.com> Signed-off-by:
-
Francois Romieu authored
commit a866bbf6 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Tested-by:
Alistair John Strachan <alistair@devzero.co.uk> Tested-by:
Timothy J Fontaine <tjfontaine@atxconsulting.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by:
-
Matt Carlson authored
patch 4ba526ce upstream The git commit 7c5026aa ("tg3: Add link state reporting to UMP firmware") introduced code that waits for previous firmware events to be serviced before attempting to submit a new event. Unfortunately that patch contained a bug that cause the driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended. This patch fixes that bug. This bug revealed that not all firmware versions service driver events though. Since we do not know which versions of the firmware do and don't service these events, the driver needs some way to minimize the effects of the delay. This patch solves the problem by recording a jiffies timestamp when it submits an event to the hardware. If the jiffies counter shows that 2.5 milliseconds have already passed, a wait is not needed and the driver can proceed to submit a new event. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Herbert Xu authored
crypto: authenc - Avoid using clobbered request pointer [ Upstream commit: a697690b ] Authenc works in two stages for encryption, it first encrypts and then computes an ICV. The context memory of the request is used by both operations. The problem is that when an asynchronous encryption completes, we will compute the ICV and then reread the context memory of the encryption to get the original request. It just happens that we have a buffer of 16 bytes in front of the request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger the bug. However, any attempt to uses a larger ICV instantly kills the machine when the first asynchronous encryption is completed. This patch fixes this by saving the request pointer before we start the ICV computation. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David S. Miller authored
[ Upstream commit f2b60794 ] First, lmb_enforce_memory_limit() interprets it's argument (mostly, heh) as a size limit not an address limit. So pass the raw cmdline_memory_size value into it. And we don't need to check it against zero, lmb_enforce_memory_limit() does that for us. Next, free_initmem() needs special handling when the kernel command line trims the available memory. The problem case is if the trimmed out memory is where the kernel image itself resides. When that memory is trimmed out, we don't add those physical ram areas to the sparsemem active ranges, amongst other things. Which means that this free_initmem() code will free up invalid page structs, resulting in either crashes or hangs. Just quick fix this by not freeing initmem at all if "mem=" was given on the boot command line. Signed-off-by:
-
David S. Miller authored
[ Upstream commit c918dcce ] If 'start' does not begin on a page boundary, we can overshoot past 'end'. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 37b08e34 ] Ever since commit 4c563f76 ("[XFRM]: Speed up xfrm_policy and xfrm_state walking") it is illegal to call __xfrm_state_destroy (and thus xfrm_state_put()) with xfrm_state_lock held. If we do, we'll deadlock since we have the lock already and __xfrm_state_destroy() tries to take it again. Fix this by pushing the xfrm_state_put() calls after the lock is dropped. Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit d9724055 ] The number of identifiers needs to be checked against the option length. Also, the identifier index provided needs to be verified to make sure that it doesn't exceed the bounds of the array. Signed-off-by:
Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 328fc47e ] The bonds check to prevent buffer overlflow was not exactly right. It still allowed overflow of up to 8 bytes which is sizeof(struct sctp_authkey). Since optlen is already checked against the size of that struct, we are guaranteed not to cause interger overflow either. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 7c19a3d2 ] This essentially reverts two commits: 1) 2e804627 ("[IPV4] MROUTE: Move PIM definitions to <linux/pim.h>.") and 2) 80a9492a ("[IPV4] MROUTE: Adjust include files for user-space.") which broke userpsace, in particular the XORP build as reported by Jose Calhariz, the debain package maintainer for XORP. Nothing originally in linux/mroute.h was exported to userspace ever, but some of this stuff started to be when it was moved into this new linux/pim.h, and that was wrong. If we didn't provide these definitions for 10 years we can reasonable expect that applications defined this stuff locally or used GLIBC headers providing the protocol definitions. And as such the only result of this can be conflict and userland build breakage. The commit #1 had such a short and terse commit message, that we cannot even know why such a move and set of new userland exports were even made. Signed-off-by:
-
Thomas Graf authored
[ No upstream commit, this is fixing code no longer in 2.6.27 ] nla_parse_nested_compat() was used to parse two different message formats in the netem and prio qdisc, when it was "fixed" to work with netem, it broke the multi queue support in the prio qdisc. Since the prio qdisc code in question is already removed in the development tree, this patch only fixes the regression in the stable tree. Based on original patch from Alexander H Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 30c2235c ] The structure used for SCTP_AUTH_KEY option contains a length that needs to be verfied to prevent buffer overflow conditions. Spoted by Eugene Teo <eteo@redhat.com>. Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit 5e739d17 ] All of the SCTP-AUTH socket options could cause a panic if the extension is disabled and the API is envoked. Additionally, there were some additional assumptions that certain pointers would always be valid which may not always be the case. This patch hardens the API and address all of the crash scenarios. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit d97106ea ] The socket lock is there to protect the normal UDP receive path. Encapsulation UDP sockets don't need that protection. In fact the locking is deadly for them as they may contain another UDP packet within, possibly with the same addresses. Also the nested bit was copied from TCP. TCP needs it because of accept(2) spawning sockets. This simply doesn't apply to UDP so I've removed it. Signed-off-by:
-
Jamal Hadi Salim authored
[ Upstream commit 76aab2c1 ] When an action is added several times with the same exact index it gets deleted on every even-numbered attempt. This fixes that issue. Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 69747650 ] Based upon a bug report by Josip Rodin. Packet schedulers should only return NET_XMIT_DROP iff the packet really was dropped. If the packet does reach the device after we return NET_XMIT_DROP then TCP can crash because it depends upon the enqueue path return values being accurate. Signed-off-by:
-
Brian Haley authored
[ Upstream commit 191cd582 ] ipv6_dev_get_saddr() blindly de-references dst_dev to get the network namespace, but some callers might pass NULL. Change callers to pass a namespace pointer instead. Signed-off-by:
Brian Haley <brian.haley@hp.com> Signed-off-by:
-
Brian Haley authored
[ Upstream commit 5e0115e5 ] Alexey Dobriyan wrote: > On Thu, Aug 07, 2008 at 07:00:56PM +0200, John Gumb wrote: >> Scenario: no ipv6 default route set. > >> # ip -f inet6 route get fec0::1 >> >> BUG: unable to handle kernel NULL pointer dereference at 00000000 >> IP: [<c0369b85>] rt6_fill_node+0x175/0x3b0 >> EIP is at rt6_fill_node+0x175/0x3b0 > > 0xffffffff80424dd3 is in rt6_fill_node (net/ipv6/route.c:2191). > 2186 } else > 2187 #endif > 2188 NLA_PUT_U32(skb, RTA_IIF, iif); > 2189 } else if (dst) { > 2190 struct in6_addr saddr_buf; > 2191 ====> if (ipv6_dev_get_saddr(ip6_dst_idev(&rt->u.dst)->dev, > ^^^^^^^^^^^^^^^^^^^^^^^^ > NULL > > 2192 dst, 0, &saddr_buf) == 0) > 2193 NLA_PUT(skb, RTA_PREFSRC, 16, &saddr_buf); > 2194 } The commit that changed this can't be reverted easily, but the patch below works for me. Fix NULL de-reference in rt6_fill_node() when there's no IPv6 input device present in the dst entry. Signed-off-by:
-
Ralf Baechle authored
[ Upstream commit ffb20847 ] Since 49ffcf8f ("sysctl: update sysctl_check_table") setting struct ctl_table.procname = NULL does no longer work as it used to the way the AX.25 code is expecting it to resulting in the AX.25 sysctl registration code to break if CONFIG_AX25_DAMA_SLAVE was not set as in some distribution kernels. Kernel releases from 2.6.24 are affected. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Adam Litke authored
commit 344c790e upstream I have gotten to the root cause of the hugetlb badness I reported back on August 15th. My system has the following memory topology (note the overlapping node): Node 0 Memory: 0x8000000-0x44000000 Node 1 Memory: 0x0-0x8000000 0x44000000-0x80000000 setup_zone_migrate_reserve() scans the address range 0x0-0x8000000 looking for a pageblock to move onto the MIGRATE_RESERVE list. Finding no candidates, it happily continues the scan into 0x8000000-0x44000000. When a pageblock is found, the pages are moved to the MIGRATE_RESERVE list on the wrong zone. Oops. setup_zone_migrate_reserve() should skip pageblocks in overlapping nodes. Signed-off-by:
Adam Litke <agl@us.ibm.com> Acked-by:
-
Will Newton authored
commit 363f66fe upstream Recent changes to tighten the check for UARTs that don't correctly re-assert THRE (01c194d9: "serial 8250: tighten test for using backup timer") caused problems when such a UART was opened for the second time - the bug could only successfully be detected at first initialization. For users of this version of this particular UART IP it is fatal. This patch stores the information about the bug in the bugs field of the port structure when the port is first started up so subsequent opens can check this bit even if the test for the bug fails. David Brownell: "My own exposure to this is that the UART on DaVinci hardware, which TI allegedly derived from its original 16550 logic, has periodically gone from working to unusable with the mainline 8250.c ... and back and forth a bunch. Currently it's "unusable", a regression from some previous versions. With this patch from Will, it's usable." Signed-off-by:
Will Newton <will.newton@gmail.com> Acked-by:
Alex Williamson <alex.williamson@hp.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Jan Altenberg authored
commit 73442daf upstream commit 945185a6 ("rtc: rtc_time_to_tm: use unsigned arithmetic") changed the some types in rtc_time_to_tm() to unsigned: void rtc_time_to_tm(unsigned long time, struct rtc_time *tm) { - register int days, month, year; + unsigned int days, month, year; This doesn't work for all cases, because days is checked for < 0 later on: if (days < 0) { year -= 1; days += 365 + LEAP_YEAR(year); } I think the correct fix would be to keep days signed and do an appropriate cast later on. Signed-off-by:
Jan Altenberg <jan.altenberg@linutronix.de> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com> Signed-off-by:
-
Andrew Morton authored
commit 8b76f46a upstream Fix a bug reported by and diagnosed by Aaron Straus. This is a regression intruduced into 2.6.26 by commit adc782da Author: Matt Mackall <mpm@selenic.com> Date: Tue Apr 29 01:03:07 2008 -0700 random: simplify and rename credit_entropy_store credit_entropy_bits() does: spin_lock_irqsave(&r->lock, flags); ... if (r->entropy_count > r->poolinfo->POOLBITS) r->entropy_count = r->poolinfo->POOLBITS; so there is a time window in which this BUG_ON(): static size_t account(struct entropy_store *r, size_t nbytes, int min, int reserved) { unsigned long flags; BUG_ON(r->entropy_count > r->poolinfo->POOLBITS); /* Hold lock while accounting */ spin_lock_irqsave(&r->lock, flags); can trigger. We could fix this by moving the assertion inside the lock, but it seems safer and saner to revert to the old behaviour wherein entropy_store.entropy_count at no time exceeds entropy_store.poolinfo->POOLBITS. Reported-by:
Aaron Straus <aaron@merfinllc.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jeff Layton authored
commit 838726c4 upstream The direct I/O write codepath for CIFS is done through cifs_user_write(). That function does not currently call generic_write_checks() so the file position isn't being properly set when the file is opened with O_APPEND. It's also not doing the other "normal" checks that should be done for a write call. The problem is currently that when you open a file with O_APPEND on a mount with the directio mount option, the file position is set to the beginning of the file. This makes any subsequent writes clobber the data in the file starting at the beginning. This seems to fix the problem in cursory testing. It is, however important to note that NFS disallows the combination of (O_DIRECT|O_APPEND). If my understanding is correct, the concern is races with multiple clients appending to a file clobbering each others' data. Since the write model for CIFS and NFS is pretty similar in this regard, CIFS is probably subject to the same sort of races. What's unclear to me is why this is a particular problem with O_DIRECT and not with buffered writes... Regardless, disallowing O_APPEND on an entire mount is probably not reasonable, so we'll probably just have to deal with it and reevaluate this flag combination when we get proper support for O_DIRECT. In the meantime this patch at least fixes the existing problem. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Jay Cliburn authored
commit 82c26a9d upstream The atl1 driver is causing stalled connections and file corruption whenever TSO is enabled. Two examples are here: http://lkml.org/lkml/2008/7/15/325 http://lkml.org/lkml/2008/8/18/543 Disable TSO by default until we can determine the source of the problem. Signed-off-by:
Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by:
-
Ayaz Abdulla authored
commit edcfe5f7 upstream Fix the checksum feature advertised in device flags. The hardware support TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers). However, the kernel feature flags do not distinguish IPv6 with/without extension headers. Therefore, the driver needs to use NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM since the latter includes all IPv6 packets. A future patch can be created to check for extension headers and perform software checksum calculation. Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Cc: Jeff Garzik <jgarzik@pobox.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
