- Sep 08, 2008
-
-
Greg Kroah-Hartman authored
-
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:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
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:
-
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:
-
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:
-
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:
-
Al Viro authored
commit 82d63fc9 upstream After commit a97c9bf3 (fix cramfs making duplicate entries in inode cache) in kernel 2.6.14, named-pipe on cramfs does not work properly. It seems the commit make all named-pipe on cramfs share their inode (and named-pipe buffer). Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino == 1 immediately. Reported-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> 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:
-
Ian Campbell authored
commit d847471d upstream Fixes kernel BUG at lib/radix-tree.c:473. Previously the handler was incidentally provided by tmpfs but this was removed with: commit 14fcc23f Author: Hugh Dickins <hugh@veritas.com> Date: Mon Jul 28 15:46:19 2008 -0700 tmpfs: fix kernel BUG in shmem_delete_inode relying on this behaviour was incorrect in any case and the BUG also appeared when the device node was on an ext3 filesystem. v2: override a_ops at open() time rather than mmap() time to minimise races per AKPM's concerns. Signed-off-by:
Ian Campbell <ijc@hellion.org.uk> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Hugh Dickins <hugh@veritas.com> Cc: Johannes Weiner <hannes@saeurebad.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Kel Modderman <kel@otaku42.de> Cc: Markus Armbruster <armbru@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> 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:
Jeff Garzik <jgarzik@redhat.com> 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:
-
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:
-
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:
-
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:
-
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:
-
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:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
- Aug 20, 2008
-
-
Greg Kroah-Hartman authored
-
Andrew Vasquez authored
[ Upstream commit 85821c90 ] As there's no point in adding a fixed-fudge value (originally 5 seconds), honor the user settings only. We also remove the driver's dead-callback get_rport_dev_loss_tmo function (qla2x00_get_rport_loss_tmo()). Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Seokmann Ju authored
[ Upstream commit 5f3a9a20 ] Signed-off-by:
Seokmann Ju <seokmann.ju@qlogic.com> Signed-off-by:
-
Joerg Roedel authored
commit 7b27718b upstream yesterday I tried to reactivate my old 486 box and wanted to install a current Linux with latest kernel on it. But it turned out that the latest kernel does not boot because the machine crashes early in the setup code. After some debugging it turned out that the problem is the query_ist() function. If this interrupt with that function is called the machine simply locks up. It looks like a BIOS bug. Looking for a workaround for this problem I wrote the attached patch. It checks for the CPUID instruction and if it is not implemented it does not call the speedstep BIOS function. As far as I know speedstep should be available since some Pentium earliest. Alan Cox observed that it's available since the Pentium II, so cpuid levels 4 and 5 can be excluded altogether. H. Peter Anvin cleaned up the code some more: > Right in concept, but I dislike the implementation (duplication of the > CPU detect code we already have). Could you try this patch and see if > it works for you? which, with a small modification to fix a build error with it the resulting kernel boots on my machine. Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
"H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Jan Beulich authored
commit 7bc069c6 upstream The masked difference is what needs to be compared against 1, rather than the difference of masked values (which can be negative). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Jan Beulich authored
commit 04e1e0cc upstream. Signed-off-by:
-
Hans Verkuil authored
Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b Fix a NULL pointer dereference that happened when calling i2c_new_probed_device on one of the addresses for which we use byte reads instead of quick write for detection purpose (that is: 0x30-0x37 and 0x50-0x5f). Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
David Howells authored
commit 252815b0 upstream Fix a range check in netfilter IP NAT for SNMP to always use a big enough size variable that the compiler won't moan about comparing it to ULONG_MAX/8 on a 64-bit platform. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Marcus Sundberg authored
commit 77332894 upstream The magic write to register 0x82 will often cause PCI config space on my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop) to be filled with ones during driver load, and thus breaking NIC operation until reboot. If it does not happen on first driver load it can easily be reproduced by unloading and loading the driver a few times. The magic write was added long ago by this commit: Author: François Romieu <romieu@fr.zoreil.com> Date: Sat Jan 10 06:00:46 2004 -0500 [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one(): - phy capability settings allows lower or equal capability as suggested in Realtek's changes; - I/O voodoo; - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/; - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/; - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication of code (yep, the u16 -> int conversions should work as expected); - variable renames and whitepace changes ignored. As the 8168 wasn't supported by that version this patch simply removes the bogus write from mac versions <= RTL_GIGA_MAC_VER_06. [The change above makes sense for the 8101/8102 too -- Ueimor] Signed-off-by:
Marcus Sundberg <marcus@ingate.com> Signed-off-by:
-
David Miller authored
Commit efc49181 upstream radeon: misc corrections I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that hangs in my sparc64 boxes when the init scripts set the font. The problem goes away if I disable acceleration. I haven't figured out that bug yet, but along the way I found some corrections to make based upon some auditing. 1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver and the XORG video driver differ. I've made the kernel match what XORG is using. 2) In radeonfb_engine_reset() we have top-level code structure that roughly looks like: if (family is 300, 350, or V350) do this; else do that; ... if (family is NOT 300, OR family is NOT 350, OR family is NOT V350) do another thing; this last conditional makes no sense, is always true, and obviously was likely meant to be "family is NOT 300, 350, or V350". So I've made the code match the intent. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
-
Ingo Molnar authored
commit b6d8adf4 upstream. Include limits.h to get a definition of PATH_MAX. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Jeff Dike authored
commit 7c1fed03 upstream My copying of linux/init.h didn't go far enough. The definition of __used singled out gcc minor version 3, but didn't care what the major version was. This broke when unit-at-a-time was added and gcc started throwing out initcalls. This results in an early boot crash when ptrace tries to initialize a process with an empty, uninitialized register set. Signed-off-by:
-
Jeff Dike authored
commit 4f81c535 upstream There are various constraints on the use of unit-at-a-time: - i386 uses no-unit-at-a-time for pre-4.0 (not 4.3) - x86_64 uses unit-at-a-time always Uli reported a crash on x86_64 with gcc 4.1.2 with unit-at-a-time, resulting in commit c0a18111 Ingo reported a gcc internal error with gcc 4.3 with no-unit-at-a-timem, resulting in 22eecde2 Benny Halevy is seeing extern inlines not resolved with gcc 4.3 with no-unit-at-a-time This patch reintroduces unit-at-a-time for gcc >= 4.0, bringing back the possibility of Uli's crash. If that happens, we'll debug it. I started seeing both the internal compiler errors and unresolved inlines on Fedora 9. This patch fixes both problems, without so far reintroducing the crash reported by Uli. Signed-off-by:
-
Jeff Dike authored
commit f1ef9167 upstream Fedora broke PTRACE_SYSEMU again, and UML crashes as a result when it doesn't need to. This patch makes the PTRACE_SYSEMU check fail gracefully and makes UML fall back to PTRACE_SYSCALL. Signed-off-by:
-
Jeff Dike authored
commit 3d5ede6f upstream We lost the marking of SIGWINCH as being OK to receive during stub execution, causing a panic should that happen. Cc: Benedict Verheyen <benedict.verheyen@gmail.com> Signed-off-by:
-
Jeff Dike authored
commit 8bfd04b9 upstream x86_64 defines either memcpy or __memcpy depending on the gcc version, and it looks like UML needs to follow that in its exporting. Cc: Gabriel C <nix.or.die@googlemail.com> Signed-off-by:
-
Al Viro authored
commit 3e3b48e5 upstream Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Tom Spink authored
commit 40fb16a3 upstream This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages from zero onwards until a valid page is found. Because the bottom of the address space may not be zero, it's not sufficient to assume the top of the address space is the size of the address space. The size is the difference between the top address and bottom address. [jdike@addtoit.com: changed the name to reflect that this function is supposed to return the top of the process address space, not its size and changed the return value to reflect that. Also some minor formatting changes] Signed-off-by:
Tom Spink <tspink@gmail.com> Signed-off-by:
-
Jeff Dike authored
commit 06e1e4ff upstream Protection against the host's time going backwards (eg, ntp activity on the host) by keeping track of the time at the last tick and if it's greater than the current time, keep time stopped until the host catches up. Cc: Nix <nix@esperi.org.uk> Signed-off-by:
-
Al Viro authored
commit 296cd66f upstream Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Jeff Dike authored
commit fe2cc53e upstream Alarm delivery could be noticably late in the !CONFIG_NOHZ case because lost ticks weren't being taken into account. This is now treated more carefully, with the time between ticks being calculated and the appropriate number of ticks delivered to the timekeeping system. Cc: Nix <nix@esperi.org.uk> Signed-off-by:
-
Jeff Dike authored
commit 60a2988a upstream The top of physical memory should be below the initial process stack, not the top of the address space, at least for as long as the stack isn't known to the kernel VM system and appropriately reserved. Cc: "Christopher S. Aker" <caker@theshore.net> Signed-off-by:
-
Jeff Dike authored
commit cfd28f66 upstream UML's supposed nanosecond clock interacts badly with NTP when NTP decides that the clock has drifted ahead and needs to be slowed down. Slowing down the clock is done by decrementing the cycle-to-nanosecond multiplier, which is 1. Decrementing that gives you 0 and time is stopped. This is fixed by switching to a microsecond clock, with a multiplier of 1000. Signed-off-by:
-
