linux/include, branch v2.6.26.4

net: Unbreak userspace which includes linux/mroute.h

2008-09-08T11:44:25Z

[ Upstream commit 7c19a3d280297d43ef5ff7c6b205dc208a16d3d1 ] This essentially reverts two commits: 1) 2e8046271f68198dd37451017c1a4a2432e4ec68 ("[IPV4] MROUTE: Move PIM definitions to .") and 2) 80a9492a33dd7d852465625022d56ff76d62174d ("[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: David S. Miller Signed-off-by: Greg Kroah-Hartman

netns: Add network namespace argument to rt6_fill_node() and ipv6_dev_get_saddr()

2008-09-08T11:44:23Z

[ Upstream commit 191cd582500f49b32a63040fedeebb0168c720af ] 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 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

fbdefio: add set_page_dirty handler to deferred IO FB

2008-09-08T11:44:16Z

commit d847471d063663b9f36927d265c66a270c0cfaab upstream Fixes kernel BUG at lib/radix-tree.c:473. Previously the handler was incidentally provided by tmpfs but this was removed with: commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1 Author: Hugh Dickins 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 Cc: Jaya Kumar Cc: Nick Piggin Cc: Peter Zijlstra Cc: Hugh Dickins Cc: Johannes Weiner Cc: Jeremy Fitzhardinge Cc: Kel Modderman Cc: Markus Armbruster Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()

2008-08-20T18:05:15Z

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

x86: fix spin_is_contended()

2008-08-20T18:05:13Z

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

sparc64: Implement IRQ stacks.

2008-08-20T18:05:11Z

[ Upstream commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd ] Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

sparc64: Make global reg dumping even more useful.

2008-08-20T18:05:11Z

[ 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

radeon: misc corrections

2008-08-20T18:05:10Z

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

sparc64: FUTEX_OP_ANDN fix

2008-08-20T18:05:05Z

[ 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

usb-serial: don't release unregistered minors

2008-08-20T18:05:02Z

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