commit df0f66d3f4bd0ea859b2f4f8438914024b4a411f Author: Greg Kroah-Hartman Date: Fri Dec 18 13:31:34 2009 -0800 Linux 2.6.27.42 commit e435e49fbe434428e3bccc5263888cea908ff9f1 Author: Alan Cox Date: Tue Dec 15 16:46:40 2009 -0800 matroxfb: fix problems with display stability commit 8c651311a3a08c1e4815de6933e00a760e498dae upstream. Regression caused in 2.6.23 and then despite repeated requests never fixed or dealt with (Petr promised to sort it in 2008 but seems to have forgotten). Enough is enough - remove the problem line that was added. If it upsets someone they've had two years to deal with it and at the very least it'll rattle their cage and wake them up. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709 Signed-off-by: Alan Cox Reported-by: Damon Tested-by: Ruud van Melick Cc: Petr Vandrovec Cc: Pekka Enberg Cc: Paul A. Clarke Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 78ba3f31ee0e1adaa141ab4cafac9df53c6c020a Author: David Woodhouse Date: Wed Dec 16 03:27:20 2009 +0000 jffs2: Fix long-standing bug with symlink garbage collection. commit 2e16cfca6e17ae37ae21feca080a6f2eca9087dc upstream. Ever since jffs2_garbage_collect_metadata() was first half-written in February 2001, it's been broken on architectures where 'char' is signed. When garbage collecting a symlink with target length above 127, the payload length would end up negative, causing interesting and bad things to happen. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 196dc9ece8c31f9b876f33f2ac3b4597fd08930e Author: Jean Delvare Date: Fri Oct 2 11:28:18 2009 +0200 backlight: lcd - Fix wrong sizeof commit 1e0fa6bd8c7468067f2e988c7a416dafd0651c34 upstream. Which is why I have always preferred sizeof(struct foo) over sizeof(var). Signed-off-by: Jean Delvare Signed-off-by: Richard Purdie Signed-off-by: Greg Kroah-Hartman commit c5867ee54f6b42a56af99ddc233caa41760fb8fe Author: Tony Cook Date: Tue Dec 8 23:25:47 2009 +0100 USB: fix mos7840 problem with minor numbers commit 37768adf9a1d49aeac0db1ba3dc28b3274b7b789 upstream This patch fixes a problem with any mos7840 device where the use of the field "minor" before it is initialised results in all the devices being overlaid in memory (minor = 0 for all instances) Contributed by: Phillip Branch Backported to .27 by Christoph Biedl Signed-off-by: Tony Cook Signed-off-by: Greg Kroah-Hartman commit 89af7ec4eabe69cfe47d3975668d43d94d24f6c9 Author: Jiri Bohac Date: Wed Sep 2 11:00:46 2009 +0200 fix csum_ipv6_magic() commit 5afe18d2f58812f3924edbd215464e5e3e8545e7 upstream. The 32-bit parameters (len and csum) of csum_ipv6_magic() are passed in 64-bit registers in2 and in4. The high order 32 bits of the registers were never cleared, and garbage was sometimes calculated into the checksum. Fix this by clearing the high order 32 bits of these registers. Signed-off-by: Jiri Bohac Signed-off-by: Tony Luck Cc: Dennis Schridde Signed-off-by: Greg Kroah-Hartman commit 96924acfccdb9b91c68cb649bbb5bab618dd002a Author: Joe Perches Date: Mon Nov 9 17:58:50 2009 -0800 x86: GART: pci-gart_64.c: Use correct length in strncmp commit 41855b77547fa18d90ed6a5d322983d3fdab1959 upstream. Signed-off-by: Joe Perches LKML-Reference: <1257818330.12852.72.camel@Joe-Laptop.home> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 55de2daba843d0884557063003e7bb90525c0dc1 Author: Tejun Heo Date: Mon Oct 26 15:41:46 2009 +0100 x86: Fix iommu=nodac parameter handling commit 2ae8bb75db1f3de422eb5898f2a063c46c36dba8 upstream. iommu=nodac should forbid dac instead of enabling it. Fix it. Signed-off-by: Tejun Heo Acked-by: FUJITA Tomonori Cc: Matteo Frigo LKML-Reference: <4AE5B52A.4050408@kernel.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 73c22292dd7a0742761dc60a6bff6e8b363d90df Author: Darrick J. Wong Date: Wed Dec 2 15:05:56 2009 -0800 x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree commit 4528752f49c1f4025473d12bc5fa9181085c3f22 upstream. On a multi-node x3950M2 system, there's a slight oddity in the PCI device tree for all secondary nodes: 30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) ...as compared to the primary node: 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) In both nodes, the LSI RAID controller hangs off a CalIOC2 device, but on the secondary nodes, the BIOS hides the VGA device and substitutes the device tree ending with the disk controller. It would seem that Calgary devices don't necessarily appear at the top of the PCI tree, which means that the current code to find the Calgary IOMMU that goes with a particular device is buggy. Rather than walk all the way to the top of the PCI device tree and try to match bus number with Calgary descriptor, the code needs to examine each parent of the particular device; if it encounters a Calgary with a matching bus number, simply use that. Otherwise, we BUG() when the bus number of the Calgary doesn't match the bus number of whatever's at the top of the device tree. Extra note: This patch appears to work correctly for the x3950 that came before the x3950 M2. Signed-off-by: Darrick J. Wong Acked-by: Muli Ben-Yehuda Cc: FUJITA Tomonori Cc: Joerg Roedel Cc: Yinghai Lu Cc: Jon D. Mason Cc: Corinna Schultz LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b4e45e390a3ffc03c6fdb1d76f99e28ae6c1a852 Author: Leann Ogasawara Date: Fri Dec 4 15:42:22 2009 -0800 x86: ASUS P4S800 reboot=bios quirk commit 4832ddda2ec4df96ea1eed334ae2dbd65fc1f541 upstream. Bug reporter noted their system with an ASUS P4S800 motherboard would hang when rebooting unless reboot=b was specified. Their dmidecode didn't contain descriptive System Information for Manufacturer or Product Name, so I used their Base Board Information to create a reboot quirk patch. The bug reporter confirmed this patch resolves the reboot hang. Handle 0x0001, DMI type 1, 25 bytes System Information Manufacturer: System Manufacturer Product Name: System Name Version: System Version Serial Number: SYS-1234567890 UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F Wake-up Type: Power Switch Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P4S800 Version: REV 1.xx Serial Number: xxxxxxxxxxx BugLink: http://bugs.launchpad.net/bugs/366682 ASUS P4S800 will hang when rebooting unless reboot=b is specified. Add a quirk to reboot through the bios. Signed-off-by: Leann Ogasawara LKML-Reference: <1259972107.4629.275.camel@emiko> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit eb283d0aa32cb05ef629931c4fceeb7ef051e406 Author: Mikael Pettersson Date: Thu Dec 3 15:52:44 2009 +0100 x86, apic: Enable lapic nmi watchdog on AMD Family 11h commit 7d1849aff6687a135a8da3a75e32a00e3137a5e2 upstream. The x86 lapic nmi watchdog does not recognize AMD Family 11h, resulting in: NMI watchdog: CPU not supported As far as I can see from available documentation (the BKDM), family 11h looks identical to family 10h as far as the PMU is concerned. Extending the check to accept family 11h results in: Testing NMI watchdog ... OK. I've been running with this change on a Turion X2 Ultra ZM-82 laptop for a couple of weeks now without problems. Signed-off-by: Mikael Pettersson Cc: Andreas Herrmann Cc: Joerg Roedel LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0603673f2eb85facfbffc5c42604684a021c507b Author: Roel Kluin Date: Fri Nov 20 15:34:13 2009 -0300 V4L/DVB: Fix test in copy_reg_bits() commit c95a419a5604ec8a23cd73f61e9bb151e8cbe89b upstream. The reg_pair2[j].reg was tested twice. Signed-off-by: Roel Kluin Acked-by: Michael Krufky Signed-off-by: Andrew Morton Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d66f16e8a63d1f2198bc2cd8e6bd91b5378fca20 Author: Michael Buesch Date: Mon Nov 23 20:58:06 2009 +0100 ssb: Fix range check in sprom write commit e33761e6f23881de9f3ee77cc2204ab2e26f3d9a upstream. The range check in the sprom image parser hex2sprom() is broken. One sprom word is 4 hex characters. This fixes the check and also adds much better sanity checks to the code. We better make sure the image is OK by doing some sanity checks to avoid bricking the device by accident. Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4a4e3688bd53ac0bb5d40d33a666e9e343da562b Author: Sergei Shtylyov Date: Fri Nov 27 22:29:02 2009 +0400 pata_hpt{37x|3x2n}: fix timing register masks (take 2) commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream. These drivers inherited from the older 'hpt366' IDE driver the buggy timing register masks in their set_piomode() metods. As a result, too low command cycle active time is programmed for slow PIO modes. Quite fortunately, it's later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA mode #N also reprograms already set PIO data timings, usually to MWDMA mode # max(N, 2) timings... However, the drivers added some breakage of their own too: the bit that they set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of the command cycle setup time; also, setting it in DMA mode is wrong as this bit is only for PIO actually and clearing it for PIO modes is not needed as no mode in any timing table has it set... Fix all this, inverting the masks while at it, like in the 'hpt366' and 'pata_hpt366' drivers; bump the drivers' versions, accounting for recent patches that forgot to do it... Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit bdbff270b10274766fa5365fea7f461dca693144 Author: Amerigo Wang Date: Mon Dec 14 17:57:37 2009 -0800 hfs: fix a potential buffer overflow commit ec81aecb29668ad71f699f4e7b96ec46691895b6 upstream. A specially-crafted Hierarchical File System (HFS) filesystem could cause a buffer overflow to occur in a process's kernel stack during a memcpy() call within the hfs_bnode_read() function (at fs/hfs/bnode.c:24). The attacker can provide the source buffer and length, and the destination buffer is a local variable of a fixed length. This local variable (passed as "&entry" from fs/hfs/dir.c:112 and allocated on line 60) is stored in the stack frame of hfs_bnode_read()'s caller, which is hfs_readdir(). Because the hfs_readdir() function executes upon any attempt to read a directory on the filesystem, it gets called whenever a user attempts to inspect any filesystem contents. [amwang@redhat.com: modify this patch and fix coding style problems] Signed-off-by: WANG Cong Cc: Eugene Teo Cc: Roman Zippel Cc: Al Viro Cc: Christoph Hellwig Cc: Alexey Dobriyan Cc: Dave Anderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e6ebd01ffd7b79678dfdda1d3b5653e8aea3eb41 Author: Jay Fenlason Date: Fri Dec 11 14:23:58 2009 -0500 firewire: ohci: handle receive packets with a data length of zero commit 8c0c0cc2d9f4c523fde04bdfe41e4380dec8ee54 upstream. Queueing to receive an ISO packet with a payload length of zero silently does nothing in dualbuffer mode, and crashes the kernel in packet-per-buffer mode. Return an error in dualbuffer mode, because the DMA controller won't let us do what we want, and work correctly in packet-per-buffer mode. Signed-off-by: Jay Fenlason Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 7a3390e41955ec09330821ba7b5231fc5b333453 Author: Mathieu Desnoyers Date: Tue Nov 17 14:40:26 2009 -0800 debugfs: fix create mutex racy fops and private data commit d3a3b0adad0865c12e39b712ca89efbd0a3a0dbc upstream. Setting fops and private data outside of the mutex at debugfs file creation introduces a race where the files can be opened with the wrong file operations and private data. It is easy to trigger with a process waiting on file creation notification. Signed-off-by: Mathieu Desnoyers Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ff932efbb7317d906ba8441759ee6c11510e972d Author: Sebastian Andrzej Siewior Date: Sun Oct 25 15:37:58 2009 +0100 signal: Fix alternate signal stack check commit 2a855dd01bc1539111adb7233f587c5c468732ac upstream. All architectures in the kernel increment/decrement the stack pointer before storing values on the stack. On architectures which have the stack grow down sas_ss_sp == sp is not on the alternate signal stack while sas_ss_sp + sas_ss_size == sp is on the alternate signal stack. On architectures which have the stack grow up sas_ss_sp == sp is on the alternate signal stack while sas_ss_sp + sas_ss_size == sp is not on the alternate signal stack. The current implementation fails for architectures which have the stack grow down on the corner case where sas_ss_sp == sp.This was reported as Debian bug #544905 on AMD64. Simplified test case: http://download.breakpoint.cc/tc-sig-stack.c The test case creates the following stack scenario: 0xn0300 stack top 0xn0200 alt stack pointer top (when switching to alt stack) 0xn01ff alt stack end 0xn0100 alt stack start == stack pointer If the signal is sent the stack pointer is pointing to the base address of the alt stack and the kernel erroneously decides that it has already switched to the alternate stack because of the current check for "sp - sas_ss_sp < sas_ss_size" On parisc (stack grows up) the scenario would be: 0xn0200 stack pointer 0xn01ff alt stack end 0xn0100 alt stack start = alt stack pointer base (when switching to alt stack) 0xn0000 stack base This is handled correctly by the current implementation. [ tglx: Modified for archs which have the stack grow up (parisc) which would fail with the correct implementation for stack grows down. Added a check for sp >= current->sas_ss_sp which is strictly not necessary but makes the code symetric for both variants ] Signed-off-by: Sebastian Andrzej Siewior Cc: Oleg Nesterov Cc: Roland McGrath Cc: Kyle McMartin LKML-Reference: <20091025143758.GA6653@Chamillionaire.breakpoint.cc> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman