commit c373e9c53f34979567e7baaa3abcc9258000a962 Author: Greg Kroah-Hartman Date: Wed Aug 20 11:11:37 2008 -0700 Linux 2.6.26.3 commit faf996d6cdc3a8e6205ae5226f667aa7d1f5f6c2 Author: Suresh Siddha Date: Fri Aug 15 10:13:20 2008 +1000 crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore() crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore() [ Upstream commit: e49140120c88eb99db1a9172d9ac224c0f2bbdd2 ] Wolfgang Walter reported this oops on his via C3 using padlock for AES-encryption: ################################################################## BUG: unable to handle kernel NULL pointer dereference at 000001f0 IP: [] __switch_to+0x30/0x117 *pde = 00000000 Oops: 0002 [#1] PREEMPT Modules linked in: Pid: 2071, comm: sleep Not tainted (2.6.26 #11) EIP: 0060:[] EFLAGS: 00010002 CPU: 0 EIP is at __switch_to+0x30/0x117 EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300 ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000) Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046 c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000 c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0 Call Trace: [] ? schedule+0x285/0x2ff [] ? pm_qos_requirement+0x3c/0x53 [] ? acpi_processor_idle+0x0/0x434 [] ? cpu_idle+0x73/0x7f [] ? rest_init+0x61/0x63 ======================= Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end() around the padlock instructions fix the oops. Suresh wrote: These padlock instructions though don't use/touch SSE registers, but it behaves similar to other SSE instructions. For example, it might cause DNA faults when cr0.ts is set. While this is a spurious DNA trap, it might cause oops with the recent fpu code changes. This is the code sequence that is probably causing this problem: a) new app is getting exec'd and it is somewhere in between start_thread() and flush_old_exec() in the load_xyz_binary() b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is cleared. c) Now we get an interrupt/softirq which starts using these encrypt/decrypt routines in the network stack. This generates a math fault (as cr0.ts is '1') which sets TS_USEDFPU and restores the math that is in the task's xstate. d) Return to exec code path, which does start_thread() which does free_thread_xstate() and sets xstate pointer to NULL while the TS_USEDFPU is still set. e) At the next context switch from the new exec'd task to another task, we have a scenarios where TS_USEDFPU is set but xstate pointer is null. This can cause an oops during unlazy_fpu() in __switch_to() Now: 1) This should happen with or with out pre-emption. Viro also encountered similar problem with out CONFIG_PREEMPT. 2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because kernel_fpu_begin() will manually do a clts() and won't run in to the situation of setting TS_USEDFPU in step "c" above. 3) This was working before the fpu changes, because its a spurious math fault which doesn't corrupt any fpu/sse registers and the task's math state was always in an allocated state. With out the recent lazy fpu allocation changes, while we don't see oops, there is a possible race still present in older kernels(for example, while kernel is using kernel_fpu_begin() in some optimized clear/copy page and an interrupt/softirq happens which uses these padlock instructions generating DNA fault). This is the failing scenario that existed even before the lazy fpu allocation changes: 0. CPU's TS flag is set 1. kernel using FPU in some optimized copy routine and while doing kernel_fpu_begin() takes an interrupt just before doing clts() 2. Takes an interrupt and ipsec uses padlock instruction. And we take a DNA fault as TS flag is still set. 3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts 4. We complete the padlock routine 5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes the optimized copy routine and does kernel_fpu_end(). At this point, we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll set and not cleared. 6. Now kernel resumes its user operation. And at the next context switch, kernel sees it has do a FP save as TS_USEDFPU is still set and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu() will take a DNA fault, as cr0.ts is '1' and now, because we are in __switch_to(), math_state_restore() will get confused and will restore the next task's FP state and will save it in prev tasks's FP state. Remember, in __switch_to() we are already on the stack of the next task but take a DNA fault for the prev task. This causes the fpu leakage. Fix the padlock instruction usage by calling them inside the context of new routines irq_ts_save/restore(), which clear/restore cr0.ts manually in the interrupt context. This will not generate spurious DNA in the context of the interrupt which will fix the oops encountered and the possible FPU leakage issue. Reported-and-bisected-by: Wolfgang Walter Signed-off-by: Suresh Siddha Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f8e6fcea9210eb5e2221643336f74ef007aab498 Author: Dean Hildebrand Date: Thu Aug 7 17:31:45 2008 -0700 PCI: Limit VPD length for Broadcom 5708S commit 35405f256de924be56ea5edaca4cdc627f1bb0f8 upstream BCM5706S wont work correctly unless VPD length truncated to 128 Signed-off-by: Dean Hildebrand Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit bd69c7363ab276ce44ed4632030221516cbe8038 Author: Jeff Layton Date: Fri Aug 1 13:08:14 2008 -0500 CIFS: properly account for new user= field in SPNEGO upcall string allocation commit 66b8bd3c405389213de1d6ba6c2565990f62004f upstream [CIFS] properly account for new user= field in SPNEGO upcall string allocation ...it doesn't look like it's being accounted for at the moment. Also try to reorganize the calculation to make it a little more evident what each piece means. This should probably go to the stable series as well... Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 978e8c75a78d16d933dfa471fa247e7e61c9f7a4 Author: Alan Stern Date: Tue Aug 5 10:46:23 2008 -0400 usb-storage: automatically recognize bad residues commit 59f4ff2ecff4cef36378928cec891785b402e80c upstream This patch (as1119b) will help to reduce the clutter of usb-storage's unusual_devs file by automatically detecting some devices that need the IGNORE_RESIDUE flag. The idea is that devices should never return a non-zero residue for an INQUIRY or a READ CAPACITY command unless they failed to transfer all the requested data. So if one of these commands transfers a standard amount of data but there is a positive residue, we know that the residue is bogus and we can set the flag. This fixes the problems reported in Bugzilla #11125. Signed-off-by: Alan Stern Tested-by: Matthew Frost Signed-off-by: Greg Kroah-Hartman commit b0d87b9307f9e4b5803a3cad3ad00bee4beb1966 Author: Alan Stern Date: Mon Aug 11 10:08:17 2008 -0400 usb-storage: revert DMA-alignment change for Wireless USB commit f756cbd458ab71c996a069cb3928fb1e2d7cd9cc upstream. This patch (as1110) reverts an earlier patch meant to help with Wireless USB host controllers. These controllers can have bulk maxpacket values larger than 512, which puts unusual constraints on the sizes of scatter-gather list elements. However it turns out that the block layer does not provide the support we need to enforce these constraints; merely changing the DMA alignment mask doesn't help. Hence there's no reason to keep the original patch. The Wireless USB problem will have to be solved a different way. In addition, there is a reason to get rid of the earlier patch. By dereferencing a pointer stored in the ep_in array of struct usb_device, the current code risks an invalid memory access when it runs concurrently with device removal. The members of that array are cleared before the driver's disconnect method is called, so it should not try to use them. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit ac2ef12020817c8e8edb7b4fe57f053c62cc833e Author: Andrew Vasquez Date: Thu Aug 14 09:39:35 2008 -0700 qla2xxx: Set an rport's dev_loss_tmo value in a consistent manner. [ Upstream commit 85821c906cf3563a00a3d98fa380a2581a7a5ff1 ] 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 Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 34b8cfcf1a9e12bbc1ede3165171fe7107594ba5 Author: Seokmann Ju Date: Thu Aug 14 09:37:34 2008 -0700 qla2xxx: Add dev_loss_tmo_callbk/terminate_rport_io callback support. [ Upstream commit 5f3a9a207f1fccde476dd31b4c63ead2967d934f ] Signed-off-by: Seokmann Ju Signed-off-by: Andrew Vasquez Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 66b53f4d3bf219053afa58c88c80a388131fd6df Author: Joerg Roedel Date: Sun Aug 17 00:25:07 2008 +0000 x86: fix setup code crashes on my old 486 box commit 7b27718bdb1b70166383dec91391df5534d449ee 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 Signed-off-by: "H. Peter Anvin" Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a6582aa43703213e727161911938db89c511aa57 Author: Jan Beulich Date: Sun Aug 17 00:25:05 2008 +0000 x86: fix spin_is_contended() commit 7bc069c6bc4ede519a7116be1b9e149a1dbf787a 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 Acked-by: Nick Piggin Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f04a00a3d88449b4a189fd39943d2b8b5aa19bdd Author: David S. Miller Date: Sun Aug 17 20:51:12 2008 -0700 sparc64: Handle stack trace attempts before irqstacks are setup. [ Upstream commit 6f63e781eaf6a741fc65f773017154b20ed4ce3b ] Things like lockdep can try to do stack backtraces before the irqstack blocks have been setup. So don't try to match their ranges so early on. Also, remove unused variable in save_stack_trace(). Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0c509d5a770861eed2814a4539fb5b474e742e46 Author: David S. Miller Date: Sun Aug 17 20:49:47 2008 -0700 sparc64: Implement IRQ stacks. [ Upstream commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd ] Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 664d412a9fcdbc6cb62bfa7299978c088db28bd2 Author: David S. Miller Date: Sun Aug 17 20:47:13 2008 -0700 sparc64: Make global reg dumping even more useful. [ Upstream commit 5afe27380bc42454254c9c83c045240249c15e35 ] Record one more level of stack frame program counter. Particularly when lockdep and all sorts of spinlock debugging is enabled, figuring out the caller of spin_lock() is difficult when the cpu is stuck on the lock. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fbcd513d29df1398572db0b5bd1cc6cfecd4b2fd Author: David S. Miller Date: Sun Aug 17 20:39:08 2008 -0700 sparc64: Fix recursion in stack overflow detection handling. [ Upstream commit c7498081a6f5d96c9f3243b6b5e020352903bfd2 ] The calls down into prom_printf() when we detect an overflowed stack can recurse again since the overflow stack will be "below" the current kernel stack limit. Prevent this by just returning straight if we are on the stack overflow safe stack already. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f8bb164b647b559370fdf0bb7941f8b2631ebaea Author: David S. Miller Date: Sun Aug 17 20:34:14 2008 -0700 sparc64: Fix end-of-stack checking in save_stack_trace(). [ Upstream commit 433c5f706856689be25928a99636e724fb3ea7cf ] Bug reported by Alexander Beregalov. Before we dereference the stack frame or try to peek at the pt_regs magic value, make sure the entire object is within the kernel stack bounds. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c8579c82a2404274193ac75fe27d68bf112b908c Author: Larry Finger Date: Tue Aug 5 23:20:56 2008 -0500 rtl8187: Fix lockups due to concurrent access to config routine With the rtl8187 driver, the config routine is not protected against access before a previous call has completed. When this happens, the TX loopback that is needed to change channels may cause the chip to be locked with a reset needed to restore communications. This patch entered mainline as commit 7dcdd073bf78bb6958bbc12a1a47754a0f3c4721. The problem was found by Herton Ronaldo Krzesinski , who also suggested this type of fix. Signed-off-by: Larry Finger Acked-by: Herton Ronaldo Krzesinski Acked-by: Hin-Tak Leung Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f733cd4d7fdbac8af0c711b4932e57909cab7883 Author: Bartlomiej Zolnierkiewicz Date: Wed Aug 6 18:40:27 2008 +0200 cs5520: add enablebits checking upstream commit is 24307ffabd5b39bad443641f54b12ee2ba7a38ac Based on sparse comments in OpenFirmware code (no Cx5510/Cx5520 datasheet here). This fixes 2.6.26 regression reported by TAKADA and caused by addition of warm-plug support. Tested-by: TAKADA Yoshihito Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 5f50704754d9014b68ea6f687941aee9ac3d7e43 Author: David Miller Date: Wed Aug 6 15:28:12 2008 -0700 radeon: misc corrections Commit efc491814308f89d5ef6c4fe19ae4552a67d4132 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: David S. Miller Acked-by: Benjamin Herrenschmidt Tested-by: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d389b252e7e2b9559011a370aafc0202f5107d25 Author: Jan Beulich Date: Tue Jul 22 13:04:18 2008 +0000 CIFS: Fix compiler warning on 64-bit commit 04e1e0cccade330ab3715ce59234f7e3b087e246 upstream. Signed-off-by: Steve French Cc: Eugene Teo Signed-off-by: Greg Kroah-Hartman commit 62a7eae37a749faf08e20cf540320e0e0228f403 Author: Dimitri Gorokhovik Date: Wed Jul 16 20:33:34 2008 +0200 ide: it821x in pass-through mode segfaults in 2.6.26-stable commit 84e0f3f6c1e26588fdcb9f1b0f99d0275229bc99 upstream The driver of ITE8212 in pass-through mode (it8212.noraid=1 on cmndline) attempts to use the field `.dma_host_set' of the struct ide_dma_ops in `ide_config_drive_speed' which is set to NULL by default. So give a value to all fields of the struct ide_dma_ops. Signed-off-by: Dimitri Gorokhovik Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit bee879f48e0df80fd44db4dbd0da0dbbc9340193 Author: Yinghai Lu Date: Mon May 12 17:40:39 2008 -0700 x86: amd opteron TOM2 mask val fix commit 8004dd965b13b01a96def054d420f6df7ff22d53 upstream. there is a typo in the mask value, need to remove that extra 0, to avoid 4bit clearing. Signed-off-by: Yinghal Lu Signed-off-by: Ingo Molnar Cc: maximilian attems Cc: Peter Palfrader Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 1c94e41a5734290d14d4ca122e5dd26269571f76 Author: Timur Tabi Date: Tue Aug 12 17:11:11 2008 +0200 ALSA: ASoC: fix SNDCTL_DSP_SYNC support in Freescale 8610 sound drivers Upstream-commit-id: bf9c8c9ddef7ef761ae9747349175adad0ef16ce If an OSS application calls SNDCTL_DSP_SYNC, then ALSA will call the driver's _hw_params and _prepare functions again. On the Freescale MPC8610 DMA ASoC driver, this caused the DMA controller to be unneccessarily re-programmed, and apparently it doesn't like that. The DMA will then not operate when instructed. This patch relocates much of the DMA programming to fsl_dma_open(), which is called only once. Signed-off-by: Timur Tabi Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b4160058ee2f44605bc52e2c1b49768a532c7140 Author: Jean Delvare Date: Tue Aug 12 10:52:06 2008 +0200 i2c: Let users select algorithm drivers manually again Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d24f8dcb7ead491704e274883b2c627062f6235 In kernel 2.6.26, the ability to select I2C algorithm drivers manually was removed, as all in-kernel drivers do that automatically. However there were some complaints that it was a problem for out-of-tree I2C bus drivers. In order to address these complaints, let's allow manual selection of these drivers again, but still hide them by default for better general user experience. This closes bug #11140: http://bugzilla.kernel.org/show_bug.cgi?id=11140 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 2ef8702257cd0b720b37e1fed3a9f668ec1b9c38 Author: Hans Verkuil Date: Tue Aug 12 10:50:29 2008 +0200 i2c: Fix NULL pointer dereference in i2c_new_probed_device 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 Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit d6de8583f2a55c6022e72756737aad16d3d9fa03 Author: Timur Tabi Date: Tue Aug 12 17:09:25 2008 +0200 ALSA: asoc: restrict sample rate and size in Freescale MPC8610 sound drivers Upstream-commid-id: be41e941d5f1a48bde7f44d09d56e8d2605f98e1 The Freescale MPC8610 SSI device has the option of using one clock for both transmit and receive (synchronous mode), or independent clocks (asynchronous). The SSI driver, however, programs the SSI into synchronous mode and then tries to program the clock registers independently. The result is that the wrong sample size is usually generated during recording. This patch fixes the discrepancy by restricting the sample rate and sample size of the playback and capture streams. The SSI driver remembers which stream is opened first. When a second stream is opened, that stream is constrained to the same sample rate and size as the first stream. A future version of this driver will lift the sample size restriction. Supporting independent sample rates is more difficult, because only certain codecs provide dual independent clocks. Signed-off-by: Timur Tabi Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d004377c91c70a7206e28a6e19e3c09c26e3eb9d Author: Marcus Sundberg Date: Thu Jul 10 21:28:08 2008 +0200 r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06 commit 77332894c21165404496c56763d7df6c15c4bb09 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 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 Signed-off-by: Francois Romieu Cc: Karsten Keil Signed-off-by: Greg Kroah-Hartman commit 1cdf9677200f042502c4b710c3e4dbfe76624168 Author: Julia Lawall Date: Wed Aug 13 18:00:30 2008 +0300 KVM: ia64: Fix irq disabling leak in error handling code (cherry picked from commit cab7a1eeeb007be309cd99cf14407261a72d2418) There is a call to local_irq_restore in the normal exit case, so it would seem that there should be one on an error return as well. The semantic patch that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // @@ expression l; expression E,E1,E2; @@ local_irq_save(l); ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E,l) when any when strict ( if (...) { ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E1,l) + local_irq_restore(l); return ...; } | if (...) + {local_irq_restore(l); return ...; + } | spin_unlock_irqrestore(E2,l); | local_irq_restore(l); ) // Signed-off-by: Julia Lawall Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 7827feb473214191591b0c74653e1155b3625bb0 Author: Marcelo Tosatti Date: Wed Aug 13 18:00:29 2008 +0300 KVM: task switch: translate guest segment limit to virt-extension byte granular field (cherry picked from commit c93cd3a58845012df2d658fecd0ac99f7008d753) If 'g' is one then limit is 4kb granular. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit cd0a0d2371464e0f80ef1229bf7aa73671ce10e1 Author: Avi Kivity Date: Wed Aug 13 18:00:28 2008 +0300 KVM: Avoid instruction emulation when event delivery is pending (cherry-picked from commit 577bdc496614ced56d999bbb425e85adf2386490) When an event (such as an interrupt) is injected, and the stack is shadowed (and therefore write protected), the guest will exit. The current code will see that the stack is shadowed and emulate a few instructions, each time postponing the injection. Eventually the injection may succeed, but at that time the guest may be unwilling to accept the interrupt (for example, the TPR may have changed). This occurs every once in a while during a Windows 2008 boot. Fix by unshadowing the fault address if the fault was due to an event injection. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 3756d6be6e5ee6a66aa18a8798eab81b56d1fe68 Author: Marcelo Tosatti Date: Wed Aug 13 18:00:27 2008 +0300 KVM: task switch: use seg regs provided by subarch instead of reading from GDT (cherry-picked from commit 34198bf8426276a2ce1e97056a0f02d43637e5ae) There is no guarantee that the old TSS descriptor in the GDT contains the proper base address. This is the case for Windows installation's reboot-via-triplefault. Use guest registers instead. Also translate the address properly. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 2594ba0ab5aeb2222e5a6aa00b117b07adb9d89d Author: Marcelo Tosatti Date: Wed Aug 13 18:00:26 2008 +0300 KVM: task switch: segment base is linear address (cherry picked from commit 98899aa0e0bf5de05850082be0eb837058c09ea5) The segment base is always a linear address, so translate before accessing guest memory. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit f6c6fd9055f298c8ac33d16ba8403a2968ec1840 Author: David S. Miller Date: Thu Jul 31 20:40:46 2008 -0700 sparc64: Do not clobber %g7 in setcontext() trap. [ Upstream commit 0a4949c4414af2eb91414bcd8e2a8ac3706f7dde ] That's the userland thread register, so we should never try to change it like this. Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ffcf147fd9ba78f295eca28047432d3854750186 Author: David S. Miller Date: Mon Jul 28 00:44:29 2008 -0700 sparc64: Fix global reg snapshotting on self-cpu. [ Upstream commit 17b6f586b8e27914b36c9ed7f3e4d289e6274a80 ] We were picking %i7 out of the wrong register window stack slot. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb059936d620e34e69b72a667ad23a84432a7b85 Author: Mikael Pettersson Date: Wed Jul 30 15:40:50 2008 -0700 sparc64: FUTEX_OP_ANDN fix [ Upstream commit d72609e17fd93bb2f7e0f7e1bdc70b6d20e43843 ] Correct sparc64's implementation of FUTEX_OP_ANDN to do a bitwise negate of the oparg parameter before applying the AND operation. All other archs that support FUTEX_OP_ANDN either negate oparg explicitly (frv, ia64, mips, sh, x86), or do so indirectly by using an and-not instruction (powerpc). Since sparc64 has and-not, I chose to use that solution. I've not found any use of FUTEX_OP_ANDN in glibc so the impact of this bug is probably minor. But other user-space components may try to use it so it should still get fixed. Signed-off-by: Mikael Pettersson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bf408b4303a36e6f70514249b71fbec3a84678b8 Author: Wei Yongjun Date: Thu Jul 31 20:46:47 2008 -0700 ipv6: Fix ip6_xmit to send fragments if ipfragok is true [ Upstream commit 77e2f14f71d68d05945f1d30ca55b5194d6ab1ce ] SCTP used ip6_xmit() to send fragments after received ICMP packet too big message. But while send packet used ip6_xmit, the skb->local_df is not initialized. So when skb if enter ip6_fragment(), the following code will discard the skb. ip6_fragment(...) { if (!skb->local_df) { ... return -EMSGSIZE; } ... } SCTP do the following step: 1. send packet ip6_xmit(skb, ipfragok=0) 2. received ICMP packet too big message 3. if PMTUD_ENABLE: ip6_xmit(skb, ipfragok=1) This patch fixed the problem by set local_df if ipfragok is true. Signed-off-by: Wei Yongjun Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6ff0921d313ec31aed068b456f132a005dce59f Author: Stephen Hemminger Date: Wed Jul 30 16:29:19 2008 -0700 random32: seeding improvement [ Upstream commit 697f8d0348a652593d195a13dd1067d9df911a82 ] The rationale is: * use u32 consistently * no need to do LCG on values from (better) get_random_bytes * use more data from get_random_bytes for secondary seeding * don't reduce state space on srandom32() * enforce state variable initialization restrictions Note: the second paper has a version of random32() with even longer period and a version of random64() if needed. Signed-off-by: Stephen Hemminger Signed-off-by: Andrew Morton Cc: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 689dafca8f3a1e442aa8f1005bca54dcea38f8ba Author: Florian Westphal Date: Sat Jul 26 02:21:54 2008 -0700 syncookies: Make sure ECN is disabled [ Upstream commit 16df845f4566bc252f3e09db12f5c2f22cb44226 ] ecn_ok is not initialized when a connection is established by cookies. The cookie syn-ack never sets ECN, so ecn_ok must be set to 0. Spotted using ns-3/network simulation cradle simulator and valgrind. Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fcdf47f94c53c5d39927831fb45725df47f4547c Author: Arnaldo Carvalho de Melo Date: Wed Aug 13 13:48:39 2008 -0700 dccp: change L/R must have at least one byte in the dccpsf_val field commit 3e8a0a559c66ee9e7468195691a56fefc3589740 upstream Thanks to Eugene Teo for reporting this problem. Signed-off-by: Eugene Teo Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 90cc576c1fbfbee4d4e1ada7d877c46969c7cd3b Author: Steve French Date: Fri Aug 15 19:05:06 2008 +0000 CIFS: if get root inode fails during mount, cleanup tree connection commit 2c731afb0d4ba16018b400c75665fbdb8feb2175 upstream Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 082e898def44f5faf1f3328f258d443500f7522b Author: Steve French Date: Fri Aug 15 19:05:03 2008 +0000 CIFS: mount of IPC$ breaks with iget patch commit ad661334b8ae421154b121ee6ad3b56807adbf11 upstream In looking at network named pipe support on cifs, I noticed that Dave Howell's iget patch: iget: stop CIFS from using iget() and read_inode() broke mounts to IPC$ (the interprocess communication share), and don't handle the error case (when getting info on the root inode fails). Thanks to Gunter who noted a typo in a debug line in the original version of this patch. CC: David Howells CC: Gunter Kukkukk Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d990bc6c4c3c2df9a1ed604aa99cdfe22ed76065 Author: Carlos Corbacho Date: Fri Aug 15 16:30:03 2008 +0000 acer-wmi: Fix wireless and bluetooth on early AMW0 v2 laptops commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 upstream In the old acer_acpi, I discovered that on some of the newer AMW0 laptops that supported the WMID methods, they don't work properly for setting the wireless and bluetooth values. So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the 'new' WMID methods for setting wireless & bluetooth to guarantee we always enable it. This was fixed in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi when it was merged. (Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't work with acer-wmi, where-as they did with the old acer_acpi). AK: fix compilation Signed-off-by: Carlos Corbacho Signed-off-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman commit db6d9c1f9a1beb1b20b7b0bd5e12a16c68a6465b Author: Sven Wegener Date: Thu Aug 14 03:55:22 2008 +0000 ipvs: Fix possible deadlock in estimator code commit 8ab19ea36c5c5340ff598e4d15fc084eb65671dc upstream There is a slight chance for a deadlock in the estimator code. We can't call del_timer_sync() while holding our lock, as the timer might be active and spinning for the lock on another cpu. Work around this issue by using try_to_del_timer_sync() and releasing the lock. We could actually delete the timer outside of our lock, as the add and kill functions are only every called from userspace via [gs]etsockopt() and are serialized by a mutex, but better make this explicit. Signed-off-by: Sven Wegener Acked-by: Simon Horman Signed-off-by: Greg Kroah-Hartman commit 6191b1862fd159d8bf6eeb5014d6415782e482ea Author: Andre Schenk Date: Thu Aug 14 03:55:19 2008 +0000 USB: ftdi_sio: Add USB Product Id for ELV HS485 commit b5894a500127fce1db1309db5f9ca8b77a2ac266 upstream USB product id registration for the ELV HS485 USB adapter (www.elv.de) to their home automation bus system. Applies to 2.6.26. Signed-off-by: Andre Schenk Signed-off-by: Greg Kroah-Hartman commit 6f035e79a3c306b4deb783501f7ba0f8023bf12b Author: Frederik Kriewitz Date: Thu Aug 14 03:55:16 2008 +0000 USB: ftdi_sio: add support for Luminance Stellaris Evaluation/Development Kits commit a00c3cadc2bf50b3c925acdb3d0e5789b1650498 upstream The Patch adds support for Luminance Stellaris Evaluation/Development Kits (FTDI 2232C based). The PIDs were missing. Successfully tested with a Stellaris LM3S8962 Evaluation kit. Signed-off-by: Frederik Kriewitz Signed-off-by: Greg Kroah-Hartman commit bb457a9869e945299445f13bf618975d1562ab83 Author: Alan Stern Date: Thu Aug 14 03:55:11 2008 +0000 usb-serial: don't release unregistered minors commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream This patch (as1121) fixes a bug in the USB serial core. When a device is unregistered, the core will give back its minors -- even if the device hasn't been assigned any! The patch reserves the highest minor value (255) to mean that no minor was assigned. It also removes some dead code and does a small style fixup. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 092634b61d9a75c491749dd983f8738312c1e547 Author: Dave Jones Date: Thu Aug 14 03:55:14 2008 +0000 USB: usb-storage: quirk around v1.11 firmware on Nikon D4 commit b9a097f26e55968cbc52e30a4a2e73d32d7604ce upstream usb-storage: quirk around v1.11 firmware on Nikon D40 https://bugzilla.redhat.com/show_bug.cgi?id=454028 Just as in earlier firmware versions, we need to perform this quirk for the latest version too. Speculatively do the entry for the D80 too, as they seem to have the same firmware problems historically. Signed-off-by: Dave Jones Cc: Johannes Berg Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 5f8cce5fbf66455061b08ebca511036a0f8e9489 Author: Alan Stern Date: Thu Aug 14 03:55:07 2008 +0000 usb-storage: unusual_devs entries for iRiver T10 and Datafab CF+SM reader commit 368ee6469c327364ea10082a348f91c1f5ba47f7 upstream This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card reader. Apparently these devices provide reasonable residue values for READ and WRITE operations, but not for others like INQUIRY or READ CAPACITY. This fixes the iRiver T10 problem reported in Bugzilla #11125. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 6fc7a3dba12db360e506b28c1660d1eb72403530 Author: Alan Stern Date: Thu Aug 14 03:55:09 2008 +0000 USB: fix interface unregistration logic commit 1a21175a615ed346e8043f5e9d60a672266b84b4 upstream This patch (as1122) fixes a bug: When an interface is unregistered, its children (sysfs files and endpoint devices) are unregistered after it instead of before. Signed-off-by: Alan Stern Tested-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman commit 184804574a9f6727ede1b1f6741f06122c485215 Author: Tollef Fog Heen Date: Thu Aug 14 03:55:05 2008 +0000 USB: pl2023: Remove USB id (4348:5523) handled by ch341 commit 8c809681ba0289afd0ed7bbb63679a0568dd441d upstream USB ID 4348:5523 is handled by the ch341 driver. Remove it from the pl2023 driver. Reverts 002e8f2c80c6be76bb312940bc278fc10b2b2487. Signed-off-by: Tollef Fog Heen Signed-off-by: Greg Kroah-Hartman commit 8226ee76cbed5dc35767bab6c044ee373145908e Author: Jean Delvare Date: Tue Aug 12 23:20:04 2008 +0000 matrox maven: fix a broken error path commit 5ede40f87957c6ededf9284c8339722a97b9dfb6 upstream I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd, sorry about that. The machine will crash if the i2c_attach_client() or maven_init_client() calls fail, although nobody has yet reported this happening. Signed-off-by: Jean Delvare Acked-by: Krzysztof Helt Cc: Petr Vandrovec Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1a71e43a51949bda90a6944ef27ae057df80dce6 Author: David Miller Date: Tue Aug 12 23:20:06 2008 +0000 radeonfb: fix accel engine hangs commit 969830b2fedf8336c41d6195f49d250b1e166ff8 upstream Some chips appear to have the 2D engine hang during screen redraw, typically in a sequence of copyarea operations. This appear to be solved by adding a flush of the engine destination pixel cache and waiting for the engine to be idle before issuing the accel operation. The performance impact seems to be fairly small. Here is a trace on an RV370 (PCI device ID 0x5b64), it records the RBBM_STATUS register, then the source x/y, destination x/y, and width/height used for the copy: ---------------------------------------- radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10] radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10] radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10] radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10] radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10] radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10] radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10] radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10] radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10] radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10] radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10] ---------------------------------------- When things are going fine the copies complete before the next ROP is even issued, but all of a sudden the 2D unit becomes active (bit 17 in RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit 14) are set as well. The FIFO begins to backup until it becomes full. What happens next is the radeon_fifo_wait() times out, and we access the chip illegally leading to a bus error which usually wedges the box. None of this makes it to the console screen, of course :-) radeon_fifo_wait() should be modified to reset the accelerator when this timeout happens instead of programming the chip anyways. ---------------------------------------- radeonfb: FIFO Timeout ! ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0) ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601] ERROR(0): TPC ERROR(0): M_SYND(0), E_SYND(0), Privileged ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus" ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000] ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000] ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000] ERROR(0): E-cache idx[800e40] tag[000000000e049f4c] ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000] Ker:xnel panic - not syncing: Irrecoverable deferred error trap. ---------------------------------------- Another quirk is that these copyarea calls will not happen until the first drivers/char/vt.c:redraw_screen() occurs. This will only happen if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen. This seems to happen because until a redraw_screen() the screen scrolling method used by fbcon is not finalized yet. I've seen this with other fb drivers too. So if all you do is boot straight into X you will never see this bug on the relevant chips. Signed-off-by: David S. Miller Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 24bad46e1e0c9b3882ecacdbefbbf63249419aaf Author: Oleg Nesterov Date: Tue Aug 12 15:30:06 2008 +0000 posix-timers: fix posix_timer_event() vs dequeue_signal() race commit ba661292a2bc6ddd305a212b0526e5dc22195fe7 upstream The bug was reported and analysed by Mark McLoughlin , the patch is based on his and Roland's suggestions. posix_timer_event() always rewrites the pre-allocated siginfo before sending the signal. Most of the written info is the same all the time, but memset(0) is very wrong. If ->sigq is queued we can race with collect_signal() which can fail to find this siginfo looking at .si_signo, or copy_siginfo() can copy the wrong .si_code/si_tid/etc. In short, sys_timer_settime() can in fact stop the active timer, or the user can receive the siginfo with the wrong .si_xxx values. Move "memset(->info, 0)" from posix_timer_event() to alloc_posix_timer(), change send_sigqueue() to set .si_overrun = 0 when ->sigq is not queued. It would be nice to move the whole sigq->info initialization from send to create path, but this is not easy to do without uglifying timer_create() further. As Roland rightly pointed out, we need more cleanups/fixes here, see the "FIXME" comment in the patch. Hopefully this patch makes sense anyway, and it can mask the most bad implications. Reported-by: Mark McLoughlin Signed-off-by: Oleg Nesterov Cc: Mark McLoughlin Cc: Oliver Pinter Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 88be1c98cbdfd8ba4e231dc37da368d64d832e9e Author: Oleg Nesterov Date: Tue Aug 12 15:30:09 2008 +0000 posix-timers: do_schedule_next_timer: fix the setting of ->si_overrun commit 54da1174922cddd4be83d5a364b2e0fdd693f513 upstream do_schedule_next_timer() sets info->si_overrun = timr->it_overrun_last, this discards the already accumulated overruns. Signed-off-by: Oleg Nesterov Cc: Mark McLoughlin Cc: Oliver Pinter Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 0c920358c215b6acb9a4000f63cb8dd6268624ea Author: Petr Tesarik Date: Wed Aug 6 00:05:07 2008 +0000 ide-cd: fix endianity for the error message in cdrom_read_capacity commit 938bb03d188a1e688fb0bcae49788f540193e80a uptream Aesthetic regards aside, commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667 still leaves a bug in the error message, because it uses the unconverted big-endian value for printk. Fix this by using a local variable in machine byte order. The result is correct, more readable, and also produces slightly shorter code on i386. Signed-off-by: Petr Tesarik Cc: Jens Axboe Cc: Jan Kara Cc: Andrew Morton Cc: Acked-by: Borislav Petkov [bart: __u32 -> u32] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit d6d033c731bbbdc700913790627968ef26ac29db Author: Tom Zanussi Date: Wed Aug 6 00:05:03 2008 +0000 relay: fix "full buffer with exactly full last subbuffer" accounting problem commit 32194450330be327f3b25bf6b66298bd122599e9 upstream In relay's current read implementation, if the buffer is completely full but hasn't triggered the buffer-full condition (i.e. the last write didn't cross the subbuffer boundary) and the last subbuffer is exactly full, the subbuffer accounting code erroneously finds nothing available. This patch fixes the problem. Signed-off-by: Tom Zanussi Cc: Eduard - Gabriel Munteanu Cc: Pekka Enberg Cc: Jens Axboe Cc: Mathieu Desnoyers Cc: Andrea Righi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1d1150e2b56c5e3bd2d3a4dd638764131471f26f Author: Ondrej Zajicek Date: Wed Aug 6 00:05:05 2008 +0000 vt8623fb: fix kernel oops commit 594a8819774b09ee5bf72d23300489459ff1f882 upstream commit 20e061fb750d36ec0ffcb2e44ed7dafa9018223b Author: Ondrej Zajicek Date: Mon Apr 28 02:15:18 2008 -0700 fbdev: framebuffer_alloc() fixes Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb. causes a null-pointer deref because "info->dev is NULL, info was just kzallocated". Signed-off-by: Ondrej Zajicek Reported-by: "MadLoisae@gmx.net" Tested-by: "MadLoisae@gmx.net" Cc: Alexey Dobriyan Cc: "Antonino A. Daplas" Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cdc884a8da08b6007154b32a7878cd7fba1cf033 Author: HighPoint Linux Team Date: Tue Aug 5 00:30:10 2008 +0000 SCSI: hptiop: add more PCI device IDs commit dd07428b44944b42f699408fe31af47977f1e733 upstream Add PCI device ID for new adapter models. Signed-off-by: HighPoint Linux Team Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 5290b82b78ac5d01fd4bd300c1f619d1c7c8b1c4 Author: Tim Wright Date: Tue Aug 5 00:30:07 2008 +0000 SCSI: block: Fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler. commit ad337591f4fd20de6a0ca03d6715267a5c1d2b16 upstream It seems cdrwtool in the udftools has been unusable on "modern" kernels for some time. A Google search reveals many people with the same issue but no solution (cdrwtool fails to format the disk). After spending some time tracking down the issue, it comes down to the following: The udftools still use the older CDROM_SEND_PACKET interface to send things like FORMAT_UNIT through to the drive. They should really be updated, but that's another story. Since most distros are using libata now, the cd or dvd burner appears as a SCSI device, and we wind up in block/scsi_ioctl.c. Here, the code tries to take the "struct cdrom_generic_command" and translate it and stuff it into a "struct sg_io_hdr" structure so it can pass it to the modern sg_io() routine instead. Unfortunately, there is one error, or rather an omission in the translation. The timeout that is passed in in the "struct cdrom_generic_command" is in HZ=100 units, and this is modified and correctly converted to jiffies by use of clock_t_to_jiffies(). However, a little further down, this cgc.timeout value in jiffies is simply copied into the sg_io_hdr timeout, which should be in milliseconds. Since most modern x86 kernels seems to be getting build with HZ=250, the timeout that is passed to sg_io and eventually converted to the timeout_per_command member of the scsi_cmnd structure is now four times too small. Since cdrwtool tries to set the timeout to one hour for the FORMAT_UNIT command, and it takes about 20 minutes to format a 4x CDRW, the SCSI error-handler kicks in after the FORMAT_UNIT completes because it took longer than the incorrectly-calculated timeout. [jejb: fix up whitespace] Signed-off-by: Tim Wright Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e957c8b154298a5a4869a50915fa65f6dab73f9b Author: James Bottomley Date: Tue Aug 5 00:30:02 2008 +0000 SCSI: scsi_transport_spi: fix oops in revalidate commit e8bac9e0647dd04c83fd0bfe7cdfe2f6dfb100d0 upstream The class_device->device conversion is causing an oops in revalidate because it's assuming that the device_for_each_child iterator will only return struct scsi_device children. The conversion made all former class_devices children of the device as well, so this assumption is broken. Fix it. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e563ea630d215ccb1103226c09efa35c3c4aebb7 Author: James Bottomley Date: Tue Aug 5 00:30:05 2008 +0000 SCSI: ses: fix VPD inquiry overrun commit 671a99c8eb2f1dde08ac5538d8cd912047c61ddf upstream There are a few kerneloops.org reports like this one: http://www.kerneloops.org/search.php?search=ses_match_to_enclosure That seem to imply we're running off the end of the VPD inquiry data (although at 512 bytes, it should be long enough for just about anything). we should be using correctly sized buffers anyway, so put those in and hope this oops goes away. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 84d21376c316abf7fd213f30f56781edf8c4e754 Author: KOSAKI Motohiro Date: Tue Aug 5 00:20:05 2008 +0000 mlock() fix return values commit a477097d9c37c1cf289c7f0257dffcfa42d50197 upstream Halesh says: Please find the below testcase provide to test mlock. Test Case : =========================== #include #include #include #include #include #include #include #include #include int main(void) { int fd,ret, i = 0; char *addr, *addr1 = NULL; unsigned int page_size; struct rlimit rlim; if (0 != geteuid()) { printf("Execute this pgm as root\n"); exit(1); } /* create a file */ if ((fd = open("mmap_test.c",O_RDWR|O_CREAT,0755)) == -1) { printf("cant create test file\n"); exit(1); } page_size = sysconf(_SC_PAGE_SIZE); /* set the MEMLOCK limit */ rlim.rlim_cur = 2000; rlim.rlim_max = 2000; if ((ret = setrlimit(RLIMIT_MEMLOCK,&rlim)) != 0) { printf("Cant change limit values\n"); exit(1); } addr = 0; while (1) { /* map a page into memory each time*/ if ((addr = (char *) mmap(addr,page_size, PROT_READ | PROT_WRITE,MAP_SHARED,fd,0)) == MAP_FAILED) { printf("cant do mmap on file\n"); exit(1); } if (0 == i) addr1 = addr; i++; errno = 0; /* lock the mapped memory pagewise*/ if ((ret = mlock((char *)addr, 1500)) == -1) { printf("errno value is %d\n", errno); printf("cant lock maped region\n"); exit(1); } addr = addr + page_size; } } ====================================================== This testcase results in an mlock() failure with errno 14 that is EFAULT, but it has nowhere been specified that mlock() will return EFAULT. When I tested the same on older kernels like 2.6.18, I got the correct result i.e errno 12 (ENOMEM). I think in source code mlock(2), setting errno ENOMEM has been missed in do_mlock() , on mlock_fixup() failure. SUSv3 requires the following behavior frmo mlock(2). [ENOMEM] Some or all of the address range specified by the addr and len arguments does not correspond to valid mapped pages in the address space of the process. [EAGAIN] Some or all of the memory identified by the operation could not be locked when the call was made. This rule isn't so nice and slighly strange. but many people think POSIX/SUS compliance is important. Reported-by: Halesh Sadashiv Tested-by: Halesh Sadashiv Signed-off-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman