- 08 Sep, 2008 40 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 <gregkh@suse.de>
-
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:
Jeff Garzik <jgarzik@redhat.com> Cc: Martin Michlmayr <tbm@cyrius.com> Cc: Mark Lord <liml@rtr.ca> Cc: Artem Bokhan <aptem@ngs.ru> 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:
Mel Gorman <mel@csn.ul.ie> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Cc: Nishanth Aravamudan <nacc@us.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-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:
-
FUJITA Tomonori authored
commit 76029ff3 upstream The commit 68154e90 introduced bio_copy_kern() to add bounce support to blk_rq_map_kern. bio_copy_kern() uses bio->bv_len to copy data for READ commands after the completion but it doesn't work with a request that partially completed. SCSI always completes a PC request as a whole but seems some don't. This patch fixes bio_copy_kern to handle the above case. As bio_copy_user does, bio_copy_kern uses struct bio_map_data to store struct bio_vec. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Reported-by:
Nix <nix@esperi.org.uk> Tested-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
FUJITA Tomonori authored
commit aefcc28a upstream The commit c5dec1c3 introduced __bio_copy_iov() to add bounce support to blk_rq_map_user_iov. __bio_copy_iov() uses bio->bv_len to copy data for READ commands after the completion but it doesn't work with a request that partially completed. SCSI always completes a PC request as a whole but seems some don't. Signed-off-by:
-
Clemens Ladisch authored
commit 3d839e5b upstream Date: Tue, 26 Aug 2008 11:06:26 +0200 Subject: ALSA: oxygen: prevent muting of nonexistent AC97 controls The Xonar DX does not have CD Capture controls, so we have to check that a control actually exists before muting it. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Stefan Weinhuber authored
commit 49fd38bd upstream The Perform Subsystem Function/Prepare for Read Subsystem Data command requires 12 bytes of parameter data, but the respective data structure dasd_psf_prssd_data has a length of 16 bytes. Current storage servers ignore the obsolete bytes, but older models fail to execute the command and report an incorrect length error. This causes the device initilization for these devices to fail. To fix this problem we need to correct the dasd_psf_prssd_data structure and shorten it to the correct length. Reported-by:
Ivan Warren <ivan@vmfacility.fr> Reviewed-by:
Stefan Weinhuber <wein@de.ibm.com> Signed-off-by:
-
Samuel Sieb authored
commit c6744955 upstream Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped booting starting at v2.6.22. The reason is this commit: > commit f25f64ed > Author: Juergen Beisert <juergen@kreuzholzen.de> > Date: Sun Jul 22 11:12:38 2007 +0200 > > x86: Replace NSC/Cyrix specific chipset access macros by inlined functions. this commit activated a macro which was dormant before due to (buggy) macro side-effects. I've looked through various datasheets and found that the GXm and GXLV Geode processors don't have an incrementor. Remove the incrementor setup entirely. As the incrementor value differs according to clock speed and we would hope that the BIOS configures it correctly, it is probably the right solution. Signed-off-by:
-
Yinghai Lu authored
commit 38cc1c3d upstream Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is usable. Booting with mtrr_show showed us the BIOS-initialized MTRR settings - which are all wrong. So the root cause is that the BIOS has not set the mask correctly: > [ 0.429971] MSR00000200: 00000000d0000000 > [ 0.433305] MSR00000201: 0000000ff0000800 > should be ==> [ 0.433305] MSR00000201: 0000003ff0000800 > > [ 0.436638] MSR00000202: 00000000e0000000 > [ 0.439971] MSR00000203: 0000000fe0000800 > should be ==> [ 0.439971] MSR00000203: 0000003fe0000800 > > [ 0.443304] MSR00000204: 0000000000000006 > [ 0.446637] MSR00000205: 0000000c00000800 > should be ==> [ 0.446637] MSR00000205: 0000003c00000800 > > [ 0.449970] MSR00000206: 0000000400000006 > [ 0.453303] MSR00000207: 0000000fe0000800 > should be ==> [ 0.453303] MSR00000207: 0000003fe0000800 > > [ 0.456636] MSR00000208: 0000000420000006 > [ 0.459970] MSR00000209: 0000000ff0000800 > should be ==> [ 0.459970] MSR00000209: 0000003ff0000800 So detect this borkage and add the prefix 111. Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
commit 74573ee7 upstream On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote: > I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify" > and the kernel oopsed: > > BUG: unable to handle kernel NULL pointer dereference at 00000458 > IP: [<c0444b52>] mutex_unlock+0x0/0xb > [<c03830ae>] acm_tty_open+0x4c/0x214 Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Tested-by:
Andrei Popa <andrei.popa@i-neo.ro> Signed-off-by:
-
