In the __getcpu function, lsl is using the wrong target and destination
registers. Luckily, the compiler tends to choose %eax for both variables,
so it has been working so far.
Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available")
Signed-off-by: Samuel Neves <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Acked-by: Andy Lutomirski <email address hidden>
Cc: <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Nobuhiro Iwamatsu (CIP) <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Ian May <email address hidden>
6263da1...
by
Evalds Iodzevics <email address hidden>
x86/microcode/intel: replace sync_core() with native_cpuid_reg(eax)
On Intel it is required to do CPUID(1) before reading the microcode
revision MSR. Current code in 4.4 an 4.9 relies on sync_core() to call
CPUID, unfortunately on 32 bit machines code inside sync_core() always
jumps past CPUID instruction as it depends on data structure boot_cpu_data
witch are not populated correctly so early in boot sequence.
It depends on:
commit 5dedade6dfa2 ("x86/CPU: Add native CPUID variants returning a single
datum")
This patch is for 4.4 but also should apply to 4.9
The variable 'name' is released multiple times in the error path,
which may cause double free issues.
This problem is avoided by adding a goto label to release the memory
uniformly. And this change also makes the code a bit more cleaner.
This function is only called from lpddr_probe(). We free "lpddr" both
here and in the caller, so it's a double free. The best place to free
"lpddr" is in lpddr_probe() so let's delete this one.
The __torture_print_stats() function in locktorture.c carefully
initializes local variable "min" to statp[0].n_lock_acquired, but
then compares it to statp[i].n_lock_fail. Given that the .n_lock_fail
field should normally be zero, and given the initialization, it seems
reasonable to display the maximum and minimum number acquisitions
instead of miscomputing the maximum and minimum number of failures.
This commit therefore switches from failures to acquisitions.
And this turns out to be not only a day-zero bug, but entirely my
own fault. I hate it when that happens!
Fixes: 0af3fe1efa53 ("locktorture: Add a lock-torture kernel module")
Reported-by: Will Deacon <email address hidden>
Signed-off-by: Paul E. McKenney <email address hidden>
Acked-by: Will Deacon <email address hidden>
Cc: Davidlohr Bueso <email address hidden>
Cc: Josh Triplett <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Ian May <email address hidden>
593143f...
by
Stephen Rothwell <email address hidden>
ev_byte_channel_send() assumes that its third argument is a 16 byte
array. Some places where it is called it may not be (or we can't
easily tell if it is). Newer compilers have started producing warnings
about this, so make sure we actually pass a 16 byte array.
There may be more elegant solutions to this, but the driver is quite
old and hasn't been updated in many years.
The warnings (from a powerpc allyesconfig build) are:
In file included from include/linux/byteorder/big_endian.h:5, from arch/powerpc/include/uapi/asm/byteorder.h:14, from include/asm-generic/bitops/le.h:6, from arch/powerpc/include/asm/bitops.h:250, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:19, from arch/powerpc/include/asm/bug.h:109, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/gfp.h:5, from include/linux/slab.h:15, from drivers/tty/ehv_bytechan.c:24:
drivers/tty/ehv_bytechan.c: In function ‘ehv_bc_udbg_putc’:
arch/powerpc/include/asm/epapr_hcalls.h:298:20: warning: array subscript 1 is outside array bounds of ‘const char[1]’ [-Warray-bounds]
298 | r6 = be32_to_cpu(p[1]);
include/uapi/linux/byteorder/big_endian.h:40:51: note: in definition of macro ‘__be32_to_cpu’
40 | #define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
| ^
arch/powerpc/include/asm/epapr_hcalls.h:298:7: note: in expansion of macro ‘be32_to_cpu’
298 | r6 = be32_to_cpu(p[1]);
| ^~~~~~~~~~~
drivers/tty/ehv_bytechan.c:166:13: note: while referencing ‘data’
166 | static void ehv_bc_udbg_putc(char c)
| ^~~~~~~~~~~~~~~~
Fixes: dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver")
Signed-off-by: Stephen Rothwell <email address hidden>
Tested-by: Laurentiu Tudor <email address hidden>
[mpe: Trim warnings from change log]
Signed-off-by: Michael Ellerman <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Ian May <email address hidden>
342990b...
by
Dan Carpenter <email address hidden>
fbdev: potential information leak in do_fb_ioctl()
The "fix" struct has a 2 byte hole after ->ywrapstep and the
"fix = info->fix;" assignment doesn't necessarily clear it. It depends
on the compiler. The solution is just to replace the assignment with an
memcpy().
Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held")
Signed-off-by: Dan Carpenter <email address hidden>
Cc: Andrew Morton <email address hidden>
Cc: Arnd Bergmann <email address hidden>
Cc: "Eric W. Biederman" <email address hidden>
Cc: Andrea Righi <email address hidden>
Cc: Daniel Vetter <email address hidden>
Cc: Sam Ravnborg <email address hidden>
Cc: Maarten Lankhorst <email address hidden>
Cc: Daniel Thompson <email address hidden>
Cc: Peter Rosin <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Gerd Hoffmann <email address hidden>
Signed-off-by: Bartlomiej Zolnierkiewicz <email address hidden>
Link: https://patchwork<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Ian May <email address hidden>
The SPA of the GCR3 table root pointer[51:31] masks 20 bits. However,
this requires 21 bits (Please see the AMD IOMMU specification).
This leads to the potential failure when the bit 51 of SPA of
the GCR3 table root pointer is 1'.
Signed-off-by: Adrian Huang <email address hidden>
Fixes: 52815b75682e2 ("iommu/amd: Add support for IOMMUv2 domain mode")
Signed-off-by: Joerg Roedel <email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Ian May <email address hidden>
