This decreases the number of syscalls per read/write by half.
Signed-off-by: Anton Ivanov <aivanov@brocade.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Software IRQ processing in generic architectures assumes that the
exit out of hard IRQ may have re-enabled interrupts (some
architectures may have an implicit EOI). It presumes them enabled
and toggles the flags once more just in case unless this is turned
off in the architecture specific hardirq.h by setting
__ARCH_IRQ_EXIT_IRQS_DISABLED
This patch adds this to UML where due to the way IRQs are handled
it is an optimization (it works fine without it too).
Signed-off-by: Anton Ivanov <aivanov@brocade.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
The existing IRQ handler design in UML does not prevent reentrancy
This is mitigated by fd-enable/fd-disable semantics for the IO
portion of the UML subsystem. The timer, however, can and is
re-entered resulting in very deep stack usage and occasional
stack exhaustion.
This patch prevents this by checking if there is a timer
interrupt in-flight before processing any pending timer interrupts.
Signed-off-by: Anton Ivanov <aivanov@brocade.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
I was seeing some really weird behaviour where piping UML's output
somewhere would cause output to get duplicated:
$ ./vmlinux | head -n 40
Checking that ptrace can change system call numbers...Core dump limits :
soft - 0
hard - NONE
OK
Checking syscall emulation patch for ptrace...Core dump limits :
soft - 0
hard - NONE
OK
Checking advanced syscall emulation patch for ptrace...Core dump limits :
soft - 0
hard - NONE
OK
Core dump limits :
soft - 0
hard - NONE
This is because these tests do a fork() which duplicates the non-empty
stdout buffer, then glibc flushes the duplicated buffer as each child
exits.
A simple workaround is to flush before forking.
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Pull MIPS fixes from Ralf Baechle:
- Fix bitrot in __get_user_unaligned()
- EVA userspace accessor bug fixes.
- Fix for build issues with certain toolchains.
- Fix build error for VDSO with particular toolchain versions.
- Fix build error due to a variable that should have been removed by an
earlier patch
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Fix bitrot in __get_user_unaligned()
MIPS: Fix build error due to unused variables.
MIPS: VDSO: Fix build error
MIPS: CPS: drop .set mips64r2 directives
MIPS: uaccess: Take EVA into account in [__]clear_user
MIPS: uaccess: Take EVA into account in __copy_from_user()
MIPS: uaccess: Fix strlen_user with EVA
A handful of fixes for OMAP, i.MX, Allwinner and Tegra:
- A clock rate and a PHY setup fix for i.MX6Q/DL
- A couple of fixes for the reduced serial bus (sunxi-rsb) on Allwinner
- UART wakeirq fix for an OMAP4 board, timer config fixes for AM43XX.
- Suspend fix for Tegra124 Chromebooks
- Fix for missing implicit include that's different between ARM/ARM64
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWgDAQAAoJEIwa5zzehBx3muAP/RJD+oERDw/XiBSCl4k4kvTZ
M4ep2ExO/GPXewKXyK7rlbNWMitBwttdT5OmXuuxT7BA/ODAGk90uvZSebIHRxkh
bqnt+3njeR3M6FrTp6Np+yCh3I0hLYJoRInV3Vh8XQcml0LobIIq2BbdahIg/2JO
sSDLAzJSR15CfnnKOSexvfRFoslLaKG0ffbxmR32HiMgnbq8ZfkRr7fANsrXTzoX
oHxEV0uQXBY0d1TQ71rT/4KdTKN9QsdJI6xAjUGH95MYu+ZE0DEnW/wodd/f4e+p
dyV+qoS2LHJnhYgJho3r19icM0iyNRm0Yt0GqP7ERN/y5GGa41slE9eThMG7WQ4h
Ot5DEF2GmP7tSYhp4pqEeLqHnfou9+WzxxNP6wxGceqlg9EPuPRtzdCPStZYW4rD
6+SQCvFs0vHZlEbbAfQLhRgDpvr9enGjCcWm6ntUcgwxFy0CPmRV9g5gIeipZOwi
QfJM233tudUkDQxJYrCEgKxHy3a7T3K9LgYMM0VO1JRAEpaPIBmxZ0A+Y84WJbTE
7r+r3eDC8RFF3bLbNRb/Ogt5OHOQUdElhRXcyz/BYA/X4HOT4wyVNM12aBlmW9uN
aDB4HWE2lKV/h2pxWRR1Hem1NHYRUpcdVzkwRvncDHnxCAmb82BE2x1Ub3+fqa0v
f0eO7GjUDRdPsQXn0zZn
=kNRV
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A smallish set of fixes that we've been sitting on for a while now,
flushing the queue here so they go in. Summary:
A handful of fixes for OMAP, i.MX, Allwinner and Tegra:
- A clock rate and a PHY setup fix for i.MX6Q/DL
- A couple of fixes for the reduced serial bus (sunxi-rsb) on
Allwinner
- UART wakeirq fix for an OMAP4 board, timer config fixes for AM43XX.
- Suspend fix for Tegra124 Chromebooks
- Fix for missing implicit include that's different between
ARM/ARM64"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: tegra: Fix suspend hang on Tegra124 Chromebooks
bus: sunxi-rsb: Fix peripheral IC mapping runtime address
bus: sunxi-rsb: Fix primary PMIC mapping hardware address
ARM: dts: Fix UART wakeirq for omap4 duovero parlor
ARM: OMAP2+: AM43xx: select ARM TWD timer
ARM: OMAP2+: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST
fsl-ifc: add missing include on ARM64
ARM: dts: imx6: Fix Ethernet PHY mode on Ventana boards
ARM: dts: imx: Fix the assigned-clock mismatch issue on imx6q/dl
bus: sunxi-rsb: unlock on error in sunxi_rsb_read()
ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property
- Unwinder rework (A revert followed by better fix)
- Build errors: MMUv2, modules with -Os
- highmem section mismatch build splat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWfjpNAAoJEGnX8d3iisJeC08P+wRkkvtK0R5iZPqfTdSUaxFz
CYoVM8mAMF+non+b7a4bWHChDJ+HlHxqsQWbq2A/EsET/TOXmnr28KquC/qfplwd
p2I38xxsCSHK0hU1+x47VdxZdtO5VNdp+fsq7CQbHLUwg9TMCK4t8OpslrA3IbOG
W+YlHQ+7Wwgu1GbHhWOHDTPb/yqX0WByX211HomURlo9Ppi3Xv3W6xK7uGn0wUxS
DKp0pEWhLs8UQh6zGAf3zFJVjuuWpJHwAoXmQgfEeXYkA/ZOBCEh8sf+/fFZMxuK
RAItN1ZTV3HwIYh3ykJyap877MBksb7nsCE5R0l+LQW0nV485omfJgWvo2hFUL5D
Nrr93bcu8msn/mKfYtBaaQdohwlGsNY5GFaRGEv6TgKZWifFX+uUOBnZnbr2RLvn
3/cDeeK/24sYvxaHGvBs3tjnJkwWPpofr9ZHCnQT+X8MgxjHQhcBesDq/8lb90m6
G2RRqXQomdKkMBacejpKyvnulTEwMrU9itpxyIT7wfxCVGKxfdWHNHLW8KNtXsDn
02Ae7XUyuciV6RIF9lXyGa+I73T/4/ut02b4Qq7PrdfLQucwZKjIQ9nj1Om9+taV
1nSdm+VttO/Nqu2PoMKluxNHBpS1kxzEVFZWa/mXfFs+qmwRMLyKqjz0Tog+hBCv
O7951Yzp3J88HTQIwUMD
=h2pT
-----END PGP SIGNATURE-----
Merge tag 'arc-4.4-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
"Sorry for this late pull request, but these are all important fixes
for code introduced/updated in this release which we will otherwise
end up back porting.
- Unwinder rework (A revert followed by better fix)
- Build errors: MMUv2, modules with -Os
- highmem section mismatch build splat"
* tag 'arc-4.4-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: dw2 unwind: Catch Dwarf SNAFUs early
ARC: dw2 unwind: Don't bail for CIE.version != 1
Revert "ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing"
ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE
ARC: mm: fix building for MMU v2
ARC: mm: HIGHMEM: Fix section mismatch splat
Pull parisc system call restart fix from Helge Deller:
"The architectural design of parisc always uses two instructions to
call kernel syscalls (delayed branch feature). This means that the
instruction following the branch (located in the delay slot of the
branch instruction) is executed before control passes to the branch
destination.
Depending on which assembler instruction and how it is used in
usersapce in the delay slot, this sometimes made restarted syscalls
like futex() and poll() failing with -ENOSYS"
* 'parisc-4.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix syscall restarts
Pull sparc fixes from David Miller:
1) Finally make perf stack backtraces stable on sparc, several problems
(mostly due to the context in which the user copies from the stack
are done) contributed to this.
From Rob Gardner.
2) Export ADI capability if the cpu supports it.
3) Hook up userfaultfd system call.
4) When faults happen during user copies we really have to clean up and
restore the FPU state fully. Also from Rob Gardner
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
tty/serial: Skip 'NULL' char after console break when sysrq enabled
sparc64: fix FP corruption in user copy functions
sparc64: Perf should save/restore fault info
sparc64: Ensure perf can access user stacks
sparc64: Don't set %pil in rtrap_nmi too early
sparc64: Add ADI capability to cpu capabilities
tty: serial: constify sunhv_ops structs
sparc: Hook up userfaultfd system call
Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.
Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.
The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.
The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.
This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.
n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address. This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There have been several reports of random processes being killed with
a bus error or segfault during userspace stack walking in perf. One
of the root causes of this problem is an asynchronous modification to
thread_info fault_address and fault_code, which stems from a perf
counter interrupt arriving during kernel processing of a "benign"
fault, such as a TSB miss. Since perf_callchain_user() invokes
copy_from_user() to read user stacks, a fault is not only possible,
but probable. Validity checks on the stack address merely cover up the
problem and reduce its frequency.
The solution here is to save and restore fault_address and fault_code
in perf_callchain_user() so that the benign fault handler is not
disturbed by a perf interrupt.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an interrupt (such as a perf counter interrupt) is delivered
while executing in user space, the trap entry code puts ASI_AIUS in
%asi so that copy_from_user() and copy_to_user() will access the
correct memory. But if a perf counter interrupt is delivered while the
cpu is already executing in kernel space, then the trap entry code
will put ASI_P in %asi, and this will prevent copy_from_user() from
reading any useful stack data in either of the perf_callchain_user_X
functions, and thus no user callgraph data will be collected for this
sample period. An additional problem is that a fault is guaranteed
to occur, and though it will be silently covered up, it wastes time
and could perturb state.
In perf_callchain_user(), we ensure that %asi contains ASI_AIUS
because we know for a fact that the subsequent calls to
copy_from_user() are intended to read the user's stack.
[ Use get_fs()/set_fs() -DaveM ]
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 28a1f53 delays setting %pil to avoid potential
hardirq stack overflow in the common rtrap_irq path.
Setting %pil also needs to be delayed in the rtrap_nmi
path for the same reason.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add ADI (Application Data Integrity) capability to cpu capabilities list.
ADI capability allows virtual addresses to be encoded with a tag in
bits 63-60. This tag serves as an access control key for the regions
of virtual address with ADI enabled and a key set on them. Hypervisor
encodes this capability as "adp" in "hwcap-list" property in machine
description.
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After hooking up system call, userfaultfd selftest was successful for
both 32 and 64 bit version of test.
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- A series of fixes to the MTRR emulation, tested in the BZ by several users
so they should be safe this late
- A fix for a division by zero
- Two very simple ARM and PPC fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJWeV/6AAoJEL/70l94x66DqzsH/05YnLi2GsX5WeZHMfIUgzgT
S/GoIkA7A4E2eXVoGg824MWppSViUzZkWgYFQTG4+KY9WPXzm9z2ij7DIlUHCD6n
QfevgQx1kIu1obyhm6bYM2xUdM3f7NCsQgw9bXZObB0ay+b/+GjR9/RbCbx60EO5
K1P+kveK6PFlS9/hc0PLztu6WkPV9BCO1RJUbeAEdnrMbpuQfHC+coR7MHRCiv2V
iy8f1CqrGaO5YPm9/3GbdH1xMKew4OZShOxTXwtvUThdrLkks2c8sk6FoLzqkznH
LMHVIpkm4mrIgThZG7VqZMXOrWvBtsCt04Vr9MzCM6QetB02b/Uz0xKvMYx2kZQ=
=pmYz
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
- A series of fixes to the MTRR emulation, tested in the BZ by several
users so they should be safe this late
- A fix for a division by zero
- Two very simple ARM and PPC fixes
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Reload pit counters for all channels when restoring state
KVM: MTRR: treat memory as writeback if MTRR is disabled in guest CPUID
KVM: MTRR: observe maxphyaddr from guest CPUID, not host
KVM: MTRR: fix fixed MTRR segment look up
KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX
KVM: arm/arm64: vgic: Fix kvm_vgic_map_is_active's dist check
kvm: x86: move tracepoints outside extended quiescent state
KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR
Pull s390 fixes from Martin Schwidefsky:
"Two late bug fixes for kernel 4.4.
Merry Christmas"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/dis: Fix handling of format specifiers
s390/zcrypt: Fix AP queue handling if queue is full
Enabling CPUFreq support for Tegra124 Chromebooks is causing the Tegra124
to hang when resuming from suspend.
When CPUFreq is enabled, the CPU clock is changed from the PLLX clock to
the DFLL clock during kernel boot. When resuming from suspend the CPU
clock is temporarily changed back to the PLLX clock before switching back
to the DFLL. If the DFLL is operating at a much lower frequency than the
PLLX when we enter suspend, and so the CPU voltage rail is at a voltage
too low for the CPUs to operate at the PLLX frequency, then the device
will hang.
Please note that the PLLX is used in the resume sequence to switch the CPU
clock from the very slow 32K clock to a faster clock during early resume
to speed up the resume sequence before the DFLL is resumed.
Ideally, we should fix this by setting the suspend frequency so that it
matches the PLLX frequency, however, that would be a bigger change. For
now simply disable CPUFreq support for Tegra124 Chromebooks to avoid the
hang when resuming from suspend.
Fixes: 9a0baee960 ("ARM: tegra: Enable CPUFreq support for Tegra124
Chromebooks")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Fix a pointer cast typo introduced in v4.4-rc5 especially visible for
the i386 subarchitecture where it results in a kernel crash.
[ Also removed pointless cast as per Al Viro - Linus ]
Fixes: 8090bfd2bb ("um: Fix fpstate handling")
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Cc: Jeff Dike <jdike@addtoit.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CPU_IDLE and ARM TWD timer. This is probably a common configuration setup
for people making products with these SoCs so let's make sure it works.
Also a wakeirq fix for duovero parlor making my life a bit easier as that
allows me to run basic PM regression tests on it.
It would be nice to have these in v4.4, but if it gets too late for that
because of the holidays, it is not super critical if these get merged for
v4.5.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWeGJhAAoJEBvUPslcq6VzU4wQAJqyWnzl5+frGf8TeTJTwAD2
yDXbiTDYAZAZ4ajFY5aocrAvQfd/z9zU4ar6liylfAMzOM3S4HRDTaUYc2jbr42s
+uNNRY3EGMRzbLuRfyZZRgui0aImBpIDXhBhK1njQoYWt9wWIVxNCv2I9pImWm+n
kyZBDK7xIunQTndgMIMTk8MPVQ5tbPrFbkOWUAZT2bIOmhhhjf/fdMpVL47tbssc
5XuS5YmyglT3spdaYzrAfZbxf19+CMVmTh2KD9FZOCv4OZPXvPOJ3JkqrJeARvPI
Idt6DjitznShJ7wQuIuRH+uS7N2fEDviZR3Of1kZBawBxt7ig58O7TizZLRUtTk+
Uj2QuXfccw8qu122chdpCI1eV5oOok157V3Yhsm7Oyi12H/eu5WMee2boJh6cz9R
KIih+5/FX6yUCgfHow7XR6vpQ2A50BJoU55+EB3yb81hsy/t4eHxbFaJfUcs7DNg
yLjtAxL1tO96VNFF+Kdgps69AOaHbo7/rNYgRvRZ4uxdSkE+YJhnHfcu6m59lFSR
k7Ybw+CCvZ+jH3IE+aGLumPguL10ntytv16G2UDwCzuvCaq59fUPUOCdxuBf+RNB
3Bd1NCkcsi8xPSypf7YXa3AfNM2XkNprHVZJadM57EBE3bVZ19+1OiBtf2gn+YAE
72gzwGGPixUNr8OjZNX0
=tGjX
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.4/fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Few fixes for omaps to allow am437x only builds to boot properly with
CPU_IDLE and ARM TWD timer. This is probably a common configuration setup
for people making products with these SoCs so let's make sure it works.
Also a wakeirq fix for duovero parlor making my life a bit easier as that
allows me to run basic PM regression tests on it.
It would be nice to have these in v4.4, but if it gets too late for that
because of the holidays, it is not super critical if these get merged for
v4.5.
* tag 'omap-for-v4.4/fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Fix UART wakeirq for omap4 duovero parlor
ARM: OMAP2+: AM43xx: select ARM TWD timer
ARM: OMAP2+: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST
Signed-off-by: Olof Johansson <olof@lixom.net>
- Fix Ethernet PHY mode on i.MX6 Ventana boards, which can result in
a non-functional Ethernet when Marvell phy driver rather than generic
phy driver is selected.
- Fix an assigned-clock configuration bug on imx6qdl-sabreauto board
which was introduced by commit ed339363de ("ARM: dts:
imx6qdl-sabreauto: Allow HDMI and LVDS to work simultaneously").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWcnPzAAoJEFBXWFqHsHzOvfAIALZo+lVpA3c89ZuDJn0bKfsI
hsV2wfMW1N5BhLN0AGjNIk/nk/YWhZ57gZyQ8miMdz2VeQRSgcjRaFFfEGRGOGop
OrrKpgmRKmUNxMrvztLlMmb1hGxpHOO7z/CXO3UrzDRIiw9lzxYymt0Re2UHiE1u
+tekMe7xBdimfMVmcM8RX/FOZC81tUjH3W8fyPbbzTTgrAnLPmXcfjtHkXy2VPw0
5ikWCJhFWB9ODnmKHbdA7YsNh52JAe5BieWiLXzLj33XJNDBbiFBbBltbo+BJZnp
ZaIek/fGHbq7ouCSLdRq7SEQn6ZbjpHhlic/okqNX0ux29QpY2GKTbiq8fLmcLU=
=wMKP
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
The i.MX fixes for 4.4, 3rd round:
- Fix Ethernet PHY mode on i.MX6 Ventana boards, which can result in
a non-functional Ethernet when Marvell phy driver rather than generic
phy driver is selected.
- Fix an assigned-clock configuration bug on imx6qdl-sabreauto board
which was introduced by commit ed339363de ("ARM: dts:
imx6qdl-sabreauto: Allow HDMI and LVDS to work simultaneously").
* tag 'imx-fixes-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx6: Fix Ethernet PHY mode on Ventana boards
ARM: dts: imx: Fix the assigned-clock mismatch issue on imx6q/dl
Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash. This will ensure
that 0 values are converted to 65536 as per the spec.
This is CVE-2015-7513.
Signed-off-by: Andy Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Virtual machines can be run with CPUID such that there are no MTRRs.
In that case, the firmware will never enable MTRRs and it is obviously
undesirable to run the guest entirely with UC memory. Check out guest
CPUID, and use WB memory if MTRR do not exist.
Cc: qemu-stable@nongnu.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Conversion of MTRRs to ranges used the maxphyaddr from the boot CPU.
This is wrong, because var_mtrr_range's mask variable then is discontiguous
(like FF00FFFF000, where the first run of 0s corresponds to the bits
between host and guest maxphyaddr). Instead always set up the masks
to be full 64-bit values---we know that the reserved bits at the top
are zero, and we can restore them when reading the MSR. This way
var_mtrr_range gets a mask that just works.
Fixes: a13842dc66
Cc: qemu-stable@nongnu.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This fixes the slow-down of VM running with pci-passthrough, since some MTRR
range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE. Memory in the
0K-640K range was incorrectly treated as uncacheable.
Fixes: f7bfb57b3e
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561
Cc: qemu-stable@nongnu.org
Signed-off-by: Alexis Dambricourt <alexis.dambricourt@gmail.com>
[Use correct BZ for "Fixes" annotation. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
c861519fcf ("MIPS: Fix delay loops which may
be removed by GCC.") which made it upstream was an outdated version of the
patch and is lacking some the removal of two variables that became unused
thus resulting in further warnings and build breakage. The commit
from ae878615d7cee5d7346946cf1ae1b60e427013c2 was correct however.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit ebb5e78cc6 ("MIPS: Initial implementation of a VDSO") introduced a
build error.
For MIPS VDSO to be compiled it requires binutils version 2.25 or above but
the check in the Makefile had inverted logic causing it to be compiled in if
binutils is below 2.25.
This fixes the following compilation error:
CC arch/mips/vdso/gettimeofday.o
/tmp/ccsExcUd.s: Assembler messages:
/tmp/ccsExcUd.s:62: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
/tmp/ccsExcUd.s:467: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
make[1]: *** [arch/mips/vdso] Error 2
make: *** [arch/mips] Error 2
[ralf@linux-mips: Fixed Sergei's complaint on the formatting of the
cited commit and generally reformatted the log message.]
Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
Cc: alex@alex-smith.me.uk
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11745/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 977e043d5e ("MIPS: kernel: cps-vec: Replace mips32r2 ISA level
with mips64r2") leads to .set mips64r2 directives being present in 32
bit (ie. CONFIG_32BIT=y) kernels. This is incorrect & leads to MIPS64
instructions being emitted by the assembler when expanding
pseudo-instructions. For example the "move" instruction can legitimately
be expanded to a "daddu". This causes problems when the kernel is run on
a MIPS32 CPU, as CONFIG_32BIT kernels of course often are...
Fix this by dropping the .set <ISA> directives entirely now that Kconfig
should be ensuring that kernels including this code are built with a
suitable -march= compiler flag.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: <stable@vger.kernel.org> # 3.16+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10869/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
__clear_user() (and clear_user() which uses it), always access the user
mode address space, which results in EVA store instructions when EVA is
enabled even if the current user address limit is KERNEL_DS.
Fix this by adding a new symbol __bzero_kernel for the normal kernel
address space bzero in EVA mode, and call that from __clear_user() if
eva_kernel_access().
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10844/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When EVA is in use, __copy_from_user() was unconditionally using the EVA
instructions to read the user address space, however this can also be
used for kernel access. If the address isn't a valid user address it
will cause an address error or TLB exception, and if it is then user
memory may be read instead of kernel memory.
For example in the following stack trace from Linux v3.10 (changes since
then will prevent this particular one still happening) kernel_sendmsg()
set the user address limit to KERNEL_DS, and tcp_sendmsg() goes on to
use __copy_from_user() with a kernel address in KSeg0.
[<8002d434>] __copy_fromuser_common+0x10c/0x254
[<805710e0>] tcp_sendmsg+0x5f4/0xf00
[<804e8e3c>] sock_sendmsg+0x78/0xa0
[<804e8f28>] kernel_sendmsg+0x24/0x38
[<804ee0f8>] sock_no_sendpage+0x70/0x7c
[<8017c820>] pipe_to_sendpage+0x80/0x98
[<8017c6b0>] splice_from_pipe_feed+0xa8/0x198
[<8017cc54>] __splice_from_pipe+0x4c/0x8c
[<8017e844>] splice_from_pipe+0x58/0x78
[<8017e884>] generic_splice_sendpage+0x20/0x2c
[<8017d690>] do_splice_from+0xb4/0x110
[<8017d710>] direct_splice_actor+0x24/0x30
[<8017d394>] splice_direct_to_actor+0xd8/0x208
[<8017d51c>] do_splice_direct+0x58/0x7c
[<8014eaf4>] do_sendfile+0x1dc/0x39c
[<8014f82c>] SyS_sendfile+0x90/0xf8
Add the eva_kernel_access() check in __copy_from_user() like the one in
copy_from_user().
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10843/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The strlen_user() function calls __strlen_kernel_asm in both branches of
the eva_kernel_access() conditional. For EVA it should be calling
__strlen_user_eva for user accesses, otherwise it will load from the
kernel address space instead of the user address space, and the access
checking will likely be ineffective at preventing it due to EVA's
overlapping user and kernel address spaces.
This was found after extending the test_user_copy module to cover user
string access functions, which gave the following error with EVA:
test_user_copy: illegal strlen_user passed
Fortunately the use of strlen_user() has been all but eradicated from
the mainline kernel, so only out of tree modules could be affected.
Fixes: e3a9b07a9c ("MIPS: asm: uaccess: Add EVA support for str*_user operations")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/10842/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
On parisc syscalls which are interrupted by signals sometimes failed to
restart and instead returned -ENOSYS which in the worst case lead to
userspace crashes.
A similiar problem existed on MIPS and was fixed by commit e967ef02
("MIPS: Fix restart of indirect syscalls").
On parisc the current syscall restart code assumes that all syscall
callers load the syscall number in the delay slot of the ble
instruction. That's how it is e.g. done in the unistd.h header file:
ble 0x100(%sr2, %r0)
ldi #syscall_nr, %r20
Because of that assumption the current code never restored %r20 before
returning to userspace.
This assumption is at least not true for code which uses the glibc
syscall() function, which instead uses this syntax:
ble 0x100(%sr2, %r0)
copy regX, %r20
where regX depend on how the compiler optimizes the code and register
usage.
This patch fixes this problem by adding code to analyze how the syscall
number is loaded in the delay branch and - if needed - copy the syscall
number to regX prior returning to userspace for the syscall restart.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Blingly ignoring CIE.version != 1 was a bad idea.
It still leaves "desirability" when running perf with callgraphing where libgcc
symbols might show in hotspot.
More importantly, basic CIE.version == 3 support already exists in code:
|
| retAddrReg = state.version <= 1 ? *ptr++ : get_uleb128(&ptr, end);
|
Next commit with simply add continue-not-bail for CIE.version != 1
This reverts commit 323f41f9e7.
At -Os, ARC gcc generates millicode thunk for function prologue/epilogue,
which are served by libgcc.
Modules historically are NOT linked with libgcc to avoid code bloat, reducing
runtime relocation fixups etc. I even once tried doing that but got lost
in makefile intricacies.
This means modules at -Os don't get the millicode thunks, causing build
failures below:
| MODPOST 5 modules
| ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined!
|....
|....
Workaround that by inhibiting millicode thunks for loadable modules
Fixes STAR 9000641864:
("Linux built with optimizations for size emits errors for modules")
Reported-by: Anton Kolesov <akolesov@synosys.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC700 cores with MMU v2 don't have IC_PTAG AUX register and so we only
define ARC_REG_IC_PTAG for MMU versions >= 3.
But current implementation of cache_line_loop_vX() routines assumes
availability of all of them (v2, v3 and v4) simultaneously.
And given undefined ARC_REG_IC_PTAG if CONFIG_MMU_VER=2 we're seeing
compilation problem:
---------------------------------->8-------------------------------
CC arch/arc/mm/cache.o
arch/arc/mm/cache.c: In function '__cache_line_loop_v3':
arch/arc/mm/cache.c:270:13: error: 'ARC_REG_IC_PTAG' undeclared (first use in this function)
aux_tag = ARC_REG_IC_PTAG;
^
arch/arc/mm/cache.c:270:13: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:258: recipe for target 'arch/arc/mm/cache.o' failed
---------------------------------->8-------------------------------
The simples fix is to have ARC_REG_IC_PTAG defined regardless MMU
version being used.
We don't use it in cache_line_loop_v2() anyways so who cares.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
| WARNING: vmlinux.o(.text+0xd6c2): Section mismatch in reference from the function alloc_kmap_pgtable() to the function
| .init.text:__alloc_bootmem_low()
The function alloc_kmap_pgtable() references the function __init __alloc_bootmem_low().
This is often because alloc_kmap_pgtable lacks a __init annotation or the annotation of __alloc_bootmem_low is wrong.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
- Partial revert of "powerpc: Individual System V IPC system calls"
- pr_warn_once on unsupported OPAL_MSG type from Stewart
- Fix deadlock in opal-irqchip introduced by "Fix double endian conversion" from Alistair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWdTe9AAoJEFHr6jzI4aWANO4QAJwqS2Zhga0v/JSqMUpKgrlM
aFMLp6nM25wHkFmRBbIgJbkQAqG+2Sl43OARuJ4y4b3J9fqjKBXxzymgPQ+Y1OlR
xd+psLmfRf5r/cge45UgILhxE5LFckVIVg/uYkeI5zfRq9TqYes1Ys+7nGpV7IdB
zWXseulscE/KcEbDHlBexN9/FujONZk6DU6m17TzJbkiptn+7CA0AahbWsK9t05g
jXCppDPvGYvYGYQ4Y0G8Qnp3jELDlmPhwYWGLw7gruGTHSfbMQxhFokembk/HDcx
tSetmTBzGt384h7dVJD6HF89VuwgqECBIL8hl0cajFkjkzgdIieDuEGWM1yov4+R
7Tv05aO/5xYUy5vTk5qkMfywH+TQOwVjr3p3KZgGdj8ddYu7Sk4rRwKK/4cN1M7W
/RrRzeSOJ2RkTedzu1/sd0h49r2o7tUtgC0rKosDBkibCk135yNa3pe7FKHyR8NW
a/B57u6+wFvf374TUVMavcSeRvIa4cQ3YuMPcM8ykrEUJWB+QVEXPNiTNG5rux4Z
4+VX9n0/LhsEu+dGMrdWkpEUSCXi4p6AQHKpTDocWSfEiGNU77b1vF7va06T34fN
nbp6O0dXFnTgX6IJ8jEQzc8bELElFNw0gfgH6vHpgh6dkFEyL/ew0mJqQJ17bJLF
HUxdt4/OgNVj5htfeKDI
=58wA
-----END PGP SIGNATURE-----
Merge tag 'powerpc-4.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
- Partial revert of "powerpc: Individual System V IPC system calls"
- pr_warn_once on unsupported OPAL_MSG type from Stewart
- Fix deadlock in opal-irqchip introduced by "Fix double endian
conversion" from Alistair
* tag 'powerpc-4.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion"
powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type
Partial revert of "powerpc: Individual System V IPC system calls"
Looks like we're missing the wakeirq for the console uart for
duovero parlor. Let's add that as without it console acess just
hangs with PM enabled.
Cc: Arun Bharadwaj <arun@gumstix.com>
Cc: Ash Charles <ash@gumstix.com>
Cc: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Tony Lindgren <tony@atomide.com>
- XSA-155 security fixes to backend drivers.
- XSA-157 security fixes to pciback.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWdDrXAAoJEFxbo/MsZsTR3N0H/0Lvz6MWBARCje7livbz7nqE
PS0Bea+2yAfNhCDDiDlpV0lor8qlyfWDF6lGhLjItldAzahag3ZDKDf1Z/lcQvhf
3MwFOcOVZE8lLtvLT6LGnPuehi1Mfdi1Qk1/zQhPhsq6+FLPLT2y+whmBihp8mMh
C12f7KRg5r3U7eZXNB6MEtGA0RFrOp0lBdvsiZx3qyVLpezj9mIe0NueQqwY3QCS
xQ0fILp/x2EnZNZuzgghFTPRxMAx5ReOezgn9Rzvq4aThD+irz1y6ghkYN4rG2s2
tyYOTqBnjJEJEQ+wmYMhnfCwVvDffztG+uI9hqN31QFJiNB0xsjSWFCkDAWchiU=
=Argz
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.4-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen bug fixes from David Vrabel:
- XSA-155 security fixes to backend drivers.
- XSA-157 security fixes to pciback.
* tag 'for-linus-4.4-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen-pciback: fix up cleanup path when alloc fails
xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.
xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device has MSI(X) enabled.
xen/pciback: Do not install an IRQ handler for MSI interrupts.
xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled
xen/pciback: Return error on XEN_PCI_OP_enable_msi when device has MSI or MSI-X enabled
xen/pciback: Save xen_pci_op commands before processing it
xen-scsiback: safely copy requests
xen-blkback: read from indirect descriptors only once
xen-blkback: only read request operation from shared ring once
xen-netback: use RING_COPY_REQUEST() throughout
xen-netback: don't use last request to determine minimum Tx credit
xen: Add RING_COPY_REQUEST()
xen/x86/pvh: Use HVM's flush_tlb_others op
xen: Resume PMU from non-atomic context
xen/events/fifo: Consume unprocessed events when a CPU dies
The print_insn() function returns strings like "lghi %r1,0". To escape the
'%' character in sprintf() a second '%' is used. For example "lghi %%r1,0"
is converted into "lghi %r1,0".
After print_insn() the output string is passed to printk(). Because format
specifiers like "%r" or "%f" are ignored by printk() this works by chance
most of the time. But for instructions with control registers like
"lctl %c6,%c6,780" this fails because printk() interprets "%c" as
character format specifier.
Fix this problem and escape the '%' characters twice.
For example "lctl %%%%c6,%%%%c6,780" is then converted by sprintf()
into "lctl %%c6,%%c6,780" and by printk() into "lctl %c6,%c6,780".
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Commit 25642e1459 ("powerpc/opal-irqchip: Fix double endian
conversion") fixed an endian bug by calling opal_handle_events() in
opal_event_unmask().
However this introduced a deadlock if we find an event is active
during unmasking and call opal_handle_events() again. The bad call
sequence is:
opal_interrupt()
-> opal_handle_events()
-> generic_handle_irq()
-> handle_level_irq()
-> raw_spin_lock(&desc->lock)
handle_irq_event(desc)
unmask_irq(desc)
-> opal_event_unmask()
-> opal_handle_events()
-> generic_handle_irq()
-> handle_level_irq()
-> raw_spin_lock(&desc->lock) (BOOM)
When generating multiple opal events in quick succession this would lead
to the following stall warnings:
EEH: Fenced PHB#0 detected, location: U78C9.001.WZS09XA-P1-C32
INFO: rcu_sched detected stalls on CPUs/tasks:
12-...: (1 GPs behind) idle=68f/140000000000001/0 softirq=860/861 fqs=2065
15-...: (1 GPs behind) idle=be5/140000000000001/0 softirq=1142/1143 fqs=2065
(detected by 13, t=2102 jiffies, g=1325, c=1324, q=602)
NMI watchdog: BUG: soft lockup - CPU#18 stuck for 22s! [irqbalance:2696]
INFO: rcu_sched detected stalls on CPUs/tasks:
12-...: (1 GPs behind) idle=68f/140000000000001/0 softirq=860/861 fqs=8371
15-...: (1 GPs behind) idle=be5/140000000000001/0 softirq=1142/1143 fqs=8371
(detected by 20, t=8407 jiffies, g=1325, c=1324, q=1290)
This patch corrects the problem by queuing the work if an event is
active during unmasking, which is similar to the pre-endian fix
behaviour.
Fixes: 25642e1459 ("powerpc/opal-irqchip: Fix double endian conversion")
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Reported-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Pull libnvdimm fixes from Dan Williams:
- Two bug fixes for misuse of PAGE_MASK in scatterlist and dma-debug.
These are tagged for -stable. The scatterlist impact is potentially
corrupted dma addresses on HIGHMEM enabled platforms.
- A minor locking fix for the NFIT hot-add implementation that is new
in 4.4-rc. This would only trigger in the case a hot-add raced
driver removal.
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dma-debug: Fix dma_debug_entry offset calculation
Revert "scatterlist: use sg_phys()"
nfit: acpi_nfit_notify(): Do not leave device locked
Make sure to tell the kernel that AM437x devices have ARM TWD timer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
[grygorii.strashko@ti.com: drop ARM Global timer selection, because
it's incompatible with PM (cpuidle/cpufreq). So, it's unsafe to enable
it unconditionally]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
System will misbehave in the following case:
- AM43XX only build (UP);
- CONFIG_CPU_IDLE=y
- ARM TWD timer enabled and selected as clockevent device.
In the above case, It's expected that broadcast timer will be used as
backup timer when CPUIdle will put MPU in low power states where ARM
TWD will stop and lose its context. But, the CONFIG_SMP might not be
selected when kernel is built for AM43XX SoC only and, as result,
GENERIC_CLOCKEVENTS_BROADCAST option will not be selected also. This
will break CPUIdle and System will stuck in low power states.
Hence, fix it by selecting GENERIC_CLOCKEVENTS_BROADCAST option for
AM43XX SoCs always and add empty tick_broadcast() function
implementation - no need to send any IPI on UP. After this change
timer1 will be selected as broadcast timer the same way as for SMP,
and CPUIdle will work properly.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When running on newer OPAL firmware that supports sending extra
OPAL_MSG types, we would print a warning on *every* message received.
This could be a problem for kernels that don't support OPAL_MSG_OCC
on machines that are running real close to thermal limits and the
OCC is throttling the chip. For a kernel that is paying attention to
the message queue, we could get these notifications quite often.
Conceivably, future message types could also come fairly often,
and printing that we didn't understand them 10,000 times provides
no further information than printing them once.
Cc: stable@vger.kernel.org
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
