linux/arch, branch v3.0.22

xen pvhvm: do not remap pirqs onto evtchns if !xen_have_vector_callback

2012-02-20T20:48:13Z

commit 207d543f472c1ac9552df79838dc807cbcaa9740 upstream. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: GPMC: fix device size setup

2012-02-13T19:06:05Z

commit 8ef5d844cc3a644ea6f7665932a4307e9fad01fa upstream. following statement can only change device size from 8-bit(0) to 16-bit(1), but not vice versa: regval |= GPMC_CONFIG1_DEVICESIZE(wval); so as this field has 1 reserved bit, that could be used in future, just clear both bits and then OR with the desired value Signed-off-by: Yegor Yefremov Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers

2012-02-13T19:06:05Z

commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream. If we are context switched whilst copying into a thread's vfp_hard_struct then the partial copy may be corrupted by the VFP context switching code (see "ARM: vfp: flush thread hwstate before restoring context from sigframe"). This patch updates the ptrace VFP set code so that the thread state is flushed before the copy, therefore disabling VFP and preventing corruption from occurring. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7307/1: vfp: fix ptrace regset modification race

2012-02-13T19:06:05Z

commit 247f4993a5974e6759606c4d380748eecfd273ff upstream. In a preemptible kernel, vfp_set() can be preempted, causing the hardware VFP context to be switched while the thread vfp state is being read and modified. This leads to a race condition which can cause the thread vfp state to become corrupted if lazy VFP context save occurs due to preemption in between the time thread->vfpstate is read and the time the modified state is written back. This may occur if preemption occurs during the execution of a ptrace() call which modifies the VFP register state of a thread. Such instances should be very rare in most realistic scenarios -- none has been reported, so far as I am aware. Only uniprocessor systems should be affected, since VFP context save is not currently lazy in SMP kernels. The problem was introduced by my earlier patch migrating to use regsets to implement ptrace. This patch does a vfp_sync_hwstate() before reading thread->vfpstate, to make sure that the thread's VFP state is not live in the hardware registers while the registers are modified. Thanks to Will Deacon for spotting this. Signed-off-by: Dave Martin Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe

2012-02-13T19:06:04Z

commit 2af276dfb1722e97b190bd2e646b079a2aa674db upstream. Following execution of a signal handler, we currently restore the VFP context from the ucontext in the signal frame. This involves copying from the user stack into the current thread's vfp_hard_struct and then flushing the new data out to the hardware registers. This is problematic when using a preemptible kernel because we could be context switched whilst updating the vfp_hard_struct. If the current thread has made use of VFP since the last context switch, the VFP notifier will copy from the hardware registers into the vfp_hard_struct, overwriting any data that had been partially copied by the signal code. Disabling preemption across copy_from_user calls is a terrible idea, so instead we move the VFP thread flush *before* we update the vfp_hard_struct. Since the flushing is performed lazily, this has the effect of disabling VFP and clearing the CPU's VFP state pointer, therefore preventing the thread from being updated with stale data on the next context switch. Tested-by: Peter Maydell Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

net: bpf_jit: fix divide by 0 generation

2012-02-03T17:19:04Z

[ Upstream commit d00a9dd21bdf7908b70866794c8313ee8a5abd5c ] Several problems fixed in this patch : 1) Target of the conditional jump in case a divide by 0 is performed by a bpf is wrong. 2) Must 'generate' the full function prologue/epilogue at pass=0, or else we can stop too early in pass=1 if the proglen doesnt change. (if the increase of prologue/epilogue equals decrease of all instructions length because some jumps are converted to near jumps) 3) Change the wrong length detection at the end of code generation to issue a more explicit message, no need for a full stack trace. Reported-by: Phil Oester Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards

2012-02-03T17:18:58Z

commit 612539e81f655f6ac73c7af1da8701c1ee618aee upstream. On v7, we use the same cache maintenance instructions for data lines as for unified lines. This was not the case for v6, where HARVARD_CACHE was defined to indicate the L1 cache topology. This patch removes the erroneous compile-time check for HARVARD_CACHE in proc-v7.S, ensuring that we perform I-side invalidation at boot. Reported-and-Acked-by: Shawn Guo Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

mach-ux500: enable ARM errata 764369

2012-02-03T17:18:57Z

commit d65015f7c5c5be9fd3f5e567889c844ba81bdc9c upstream. This applies ARM errata 764369 for all ux500 platforms. Signed-off-by: Srinidhi Kasagar Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

x86/microcode_amd: Add support for CPU family specific container files

2012-02-03T17:18:56Z

commit 5b68edc91cdc972c46f76f85eded7ffddc3ff5c2 upstream. We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by: Andreas Herrmann Cc: Borislav Petkov Cc: Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86/uv: Fix uv_gpa_to_soc_phys_ram() shift

2012-02-03T17:18:55Z

commit 5a51467b146ab7948d2f6812892eac120a30529c upstream. uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by: Russ Anderson Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman