All the ColdFire IO access support code has been moved to io_no.h.
This means that all ColdFire support is at least now consistent no
matter whether the MMU is enabled or not for them.
Now that io_mm.h has reverted to only support the traditional m68k MMU
enabled processors we can remove the ColdFire specific definitions.
We can also remove the old ColdFire PCI bus IO access functions.
The new io_no.h uses asm-generic/io.h to provide all the basic support.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Use the io_no.h IO access support for all ColdFire systems, no matter
whether configured with MMU enabled or disabled. Previously there was
subtle differences in IO access functions used in both cases, and these
resulted in broken behavior for some drivers.
As observed and reported by Angelo when using MMU enabled systems the
read/write family of functions was using little endian access, while the
non-MMU enabled systems were using native endian. This results in drivers
that are shared across Freescale processors (for some of the common
internal SoC peripherals) not working - since they are wired up for native
endian access.
This problem brings to light issues with PCI bus access and local
peripheral access - but these are not addressed with this fix.
Reported-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Ultimately we want the ColdFire IO access support to be consisent no matter
whether it is configured with MMU enabled or disabled. To acheive that we
need to get all the ColdFire IO access support code together in one place,
in this case io_no.h. The last big piece not in io_no.h is the PCI bus
support functions.
Define the IO mapping addresses required to use the asm-generic IO
access functions. They can provide everything we need - no need for us
to duplicate or have local in/out or read/write access functions.
Note that this support is not active yet, since we haven't done the
full switch over to using the asm-generic functions yet. And also note
that we do not yet remove the old PCI functions from io_mm.h yet.
Consolodating all this IO access support in a single place will make
it easier in the future to enable PCI bus support for non-MMU enabled
ColdFire (which we currently cannot do).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Create a new header file, kmap.h, that groups all the definitions and
functions associated with the io mapping and remapping.
Currently the functions are spread across raw_io.h and io_mm.h. And in
the future we will want to use these in io_no.h as well. So it makes
sense to move them all together into a single header file.
It is named after the arch/m68k/mm/kmap.c file that actually implements
many of the exported functions.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Tested-by: Angelo Dureghello <angelo@sysam.it>
The primary and fundamental access macros are really the __raw versions.
So make them the actual implementation for access, and not the read/write
access macros. The read/write macros and functions are built on top of
the raw access (with byte swapping or other actions as required).
This in itself causes no functional change right now. But it will make it
easier to fix and resolve problems with PCI bus access in the future.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
There is nothing really special about the non-MMU m68k IO access functions.
So we can easily switch to using the asm-generic/io.h functions.
The only thing we do need to handle is that historically the m68k IO access
functions for readw/readl/writew/writel use native CPU endian ordering. So
for us on m68k/ColdFire that means they are big-endian. Leave the existing
set of _raw_read/__raw_write and read/write macros in place to deal with
them. (They are ripe for later cleanup, but that is for another patch).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
The non-MMU and ColdFire IO access functions will be moving to using the
asm-generic/io.h in the near future. To make that possible we need define
guards around the m68k specific virt_to_phys() and phys_to_virt()
functions.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
Move a copy of the definitions of the *_relaxed() macros into io_no.h
and io_mm.h. This precedes a change to the io_no.h file to use
asm-generic/io.h. They will be removed from io_no.h at that point.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Angelo Dureghello <angelo@sysam.it>
Tested-by: Angelo Dureghello <angelo@sysam.it>
- enable -fno-tree-loop-im only when supported
- add -fno-PIE option before the asm-goto test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbCkFPAAoJED2LAQed4NsGZVwP/juiS21QZAiQbUdX3FRcyYGs
+FDNLOwNdSU18QkdVrcJ4tG8hxBZqhIU0kq1MVE72Yo10xX8u7ssUJ0ttrUo5qIb
vlXtnqMOaZgLWnoNMGlDVPnNBxZh2UscbvjVGa5m9eqXrCU9AtQiCCoSceRtka12
tOBbfeTeJ8Ab2BKfzHcuqS+DSURkQGTyG4q1ZMxmdtIsltbZIez/zauRtAU/ULKx
Ed6HAdNiiMXRwsXnAwcGnJe9FyW7UPjZOdLn0vSizZQe8BJ+H+EotZy7FO8L407w
lgLVccCSZEFAilJRR+Xa1pMlg1KwSINcMK9BVOjIeeZL0kAIaC1zzVaPEbZ1MyDA
HKtX/MeDGX52ZW9SBCFQYKVsZQecYtyr27Z+c+8Af37sB3/ffBSeQc7YilsIGjSZ
MWARYbkOAcUif8IG6ymnEv2a4IOcD4rYNMkUfs8vXeJjejiP5rhA8zxWYng1DRmw
0g4x2iQeY7erUu/elflNa94e+PSgnwnmzWdloBqcmOtGxV+K+9BVaNsVmchyMAzt
PbQq1T8zodfr2+Jsf+yj1rWv3fLnahYh/WVAKj1rB/+Q31sYfvPlEmzayk2k9enK
Sgu5amtl64tgZD3zcSs1Ik39Ioe7s1Kf0W1Li8f2v1JR5t38UX5zkOa+O5w+sq77
NSBoCCRtn0eY3j/wo5kS
=r3P/
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull more Kbuild fixes from Masahiro Yamada:
- enable '-fno-tree-loop-im' only when supported
- add '-fno-PIE' option before the asm-goto test
* tag 'kbuild-fixes-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
Makefile: disable PIE before testing asm goto
kbuild: gcov: enable -fno-tree-loop-im if supported
A few more fixes for v4.17:
- A fix for a crash in scm_call_atomic on qcom platforms
- Display fix for Allwinner A10
- A fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al)
- A fix for eMMC corruption on hikey
- i2c-gpio descriptor tables for ixp4xx
+ a small typo fix
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAlsJynEPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3QEkP/A5dGXeQkArCWPvWoFr+20KjIS07f7F8olNy
9JKG3R2uEZsqjD3c6HFkd1abTtUQmgg/hmpxakAI8vbypA4gsq9jyFC6TxqsBSyz
uw7hQ5XcGA99pQXp8jYUrazi/XnG9Wm8LLBslsx75wJwNikzlAl6PStKDFcz0Pr6
A9JXWnqFY50YRzUr4y9GrSo3o4dvVniF3PUFEwnYliUI5qszph2/rwaE2zLQt/PT
X0DMA4v+c+4ngS5TGipY4vFjRyvsOv/NeDQzGTvGcU6QMdP4ZEsQBrye6BqowmaD
DqaoSHvsi7Lel4u29p5KyBKrM0bAhtFX+iCGiqTfkKwRWHkh7CHombUk2qX/9OJW
oB9orkKgiP35xAL5xFmB5tf03s0tQ8/qicE72tGW/TVIEBX/l+ymD76DH4rmYvRw
wNZ+HwHrMVkYgVG0TQIxxEgkXbPsyDbk3DbNbQkHf/pV5+PsMrp0iSo7oaglsS9Y
NYTRA/DQCldzhv68YRoMBh5gD4oE5iK3e3c4nLm80vd7zj8YsuXnc4+55a8PrHfs
oVg0PE5fVlP3AVRJW09ikdf03U7m0AFX/fFKHrAwWylT1+Z1KSJhM4ZaXGgdvuOV
asFUenzF3WF6Nsx+smL/vLzr/AvvYeq80Q9OdLWQl4056HurkrpL/E2HVj4MYaoW
WKKRdfzX
=mga+
-----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 few more fixes for v4.17:
- a fix for a crash in scm_call_atomic on qcom platforms
- display fix for Allwinner A10
- a fix that re-enables ethernet on Allwinner H3 (C.H.I.P et al)
- a fix for eMMC corruption on hikey
- i2c-gpio descriptor tables for ixp4xx
... plus a small typo fix"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: Fix i2c-gpio GPIO descriptor tables
arm64: dts: hikey: Fix eMMC corruption regression
firmware: qcom: scm: Fix crash in qcom_scm_call_atomic1()
ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled"
ARM: dts: sun4i: Fix incorrect clocks for displays
ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One
Pull x86 store buffer fixes from Thomas Gleixner:
"Two fixes for the SSBD mitigation code:
- expose SSBD properly to guests. This got broken when the CPU
feature flags got reshuffled.
- simplify the CPU detection logic to avoid duplicate entries in the
tables"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/speculation: Simplify the CPU bug detection logic
KVM/VMX: Expose SSBD properly to guests
Pull scheduler fixes from Thomas Gleixner:
"Three fixes for scheduler and kthread code:
- allow calling kthread_park() on an already parked thread
- restore the sched_pi_setprio() tracepoint behaviour
- clarify the unclear string for the scheduling domain debug output"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched, tracing: Fix trace_sched_pi_setprio() for deboosting
kthread: Allow kthread_park() on a parked kthread
sched/topology: Clarify root domain(s) debug string
I used bad names in my clumsiness when rewriting many board
files to use GPIO descriptors instead of platform data. A few
had the platform_device ID set to -1 which would indeed give
the device name "i2c-gpio".
But several had it set to >=0 which gives the names
"i2c-gpio.0", "i2c-gpio.1" ...
Fix the offending instances in the ARM tree. Sorry for the
mess.
Fixes: b2e6355559 ("i2c: gpio: Convert to use descriptors")
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Reported-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
PPC:
- Close a hole which could possibly lead to the host timebase getting
out of sync.
- Three fixes relating to PTEs and TLB entries for radix guests.
- Fix a bug which could lead to an interrupt never getting delivered
to the guest, if it is pending for a guest vCPU when the vCPU gets
offlined.
s390:
- Fix false negatives in VSIE validity check (Cc stable)
x86:
- Fix time drift of VMX preemption timer when a guest uses LAPIC timer
in periodic mode (Cc stable)
- Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow
migration from hosts that don't need retpoline mitigation (Cc stable)
- Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and
CPUID.OSXSAVE (Cc stable)
- Report correct RIP after Hyper-V hypercall #UD (introduced in -rc6)
-----BEGIN PGP SIGNATURE-----
iQEcBAABCAAGBQJbCXxHAAoJEED/6hsPKofon5oIAKTwpbpBi0UKIyYcHQ2pwIoP
+qITTZUGGhEaIfe+aDkzE4vxVIA2ywYCbaC2+OSy4gNVThnytRL8WuhLyV8WLmlC
sDVSQ87RWaN8mW6hEJ95qXMS7FS0TsDJdytaw+c8OpODrsykw1XMSyV2rMLb0sMT
SmfioO2kuDx5JQGyiAPKFFXKHjAnnkH+OtffNemAEHGoPpenJ4qLRuXvrjQU8XT6
tVARIBZsutee5ITIsBKVDmI2n98mUoIe9na21M7N2QaJ98IF+qRz5CxZyL1CgvFk
tHqG8PZ/bqhnmuIIR5Di919UmhamOC3MODsKUVeciBLDS6LHlhado+HEpj6B8mI=
=ygB7
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Radim Krčmář:
"PPC:
- Close a hole which could possibly lead to the host timebase getting
out of sync.
- Three fixes relating to PTEs and TLB entries for radix guests.
- Fix a bug which could lead to an interrupt never getting delivered
to the guest, if it is pending for a guest vCPU when the vCPU gets
offlined.
s390:
- Fix false negatives in VSIE validity check (Cc stable)
x86:
- Fix time drift of VMX preemption timer when a guest uses LAPIC
timer in periodic mode (Cc stable)
- Unconditionally expose CPUID.IA32_ARCH_CAPABILITIES to allow
migration from hosts that don't need retpoline mitigation (Cc
stable)
- Fix guest crashes on reboot by properly coupling CR4.OSXSAVE and
CPUID.OSXSAVE (Cc stable)
- Report correct RIP after Hyper-V hypercall #UD (introduced in
-rc6)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: fix #UD address of failed Hyper-V hypercalls
kvm: x86: IA32_ARCH_CAPABILITIES is always supported
KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed
x86/kvm: fix LAPIC timer drift when guest uses periodic mode
KVM: s390: vsie: fix < 8k check for the itdba
KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path
KVM: PPC: Book3S HV: XIVE: Resend re-routed interrupts on CPU priority change
KVM: PPC: Book3S HV: Make radix clear pte when unmapping
KVM: PPC: Book3S HV: Make radix use correct tlbie sequence in kvmppc_radix_tlbie_page
KVM: PPC: Book3S HV: Snapshot timebase offset on guest entry
This patch is a partial revert of
commit abd7d0972a ("arm64: dts: hikey: Enable HS200 mode on eMMC")
which has been causing eMMC corruption on my HiKey board.
Symptoms usually looked like:
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
...
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc0: new HS200 MMC card at address 0001
...
dwmmc_k3 f723d000.dwmmc0: Unexpected command timeout, state 3
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
print_req_error: I/O error, dev mmcblk0, sector 8810504
Aborting journal on device mmcblk0p10-8.
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
mmc_host mmc0: Bus speed (slot 0) = 24800000Hz (slot req 400000Hz, actual 400000HZ div = 31)
mmc_host mmc0: Bus speed (slot 0) = 148800000Hz (slot req 150000000Hz, actual 148800000HZ div = 0)
EXT4-fs error (device mmcblk0p10): ext4_journal_check_start:61: Detected aborted journal
EXT4-fs (mmcblk0p10): Remounting filesystem read-only
And quite often this would result in a disk that wouldn't properly
boot even with older kernels.
It seems the max-frequency property added by the above patch is
causing the problem, so remove it.
Cc: Ryan Grachek <ryan@edited.us>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: YongQin Liu <yongqin.liu@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Wei Xu <xuwei04@gmail.com>
Merge misc fixes from Andrew Morton:
"16 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
kasan: fix memory hotplug during boot
kasan: free allocated shadow memory on MEM_CANCEL_ONLINE
checkpatch: fix macro argument precedence test
init/main.c: include <linux/mem_encrypt.h>
kernel/sys.c: fix potential Spectre v1 issue
mm/memory_hotplug: fix leftover use of struct page during hotplug
proc: fix smaps and meminfo alignment
mm: do not warn on offline nodes unless the specific node is explicitly requested
mm, memory_hotplug: make has_unmovable_pages more robust
mm/kasan: don't vfree() nonexistent vm_area
MAINTAINERS: change hugetlbfs maintainer and update files
ipc/shm: fix shmat() nil address after round-down when remapping
Revert "ipc/shm: Fix shmat mmap nil-page protection"
idr: fix invalid ptr dereference on item delete
ocfs2: revert "ocfs2/o2hb: check len for bio_add_page() to avoid getting incorrect bio"
mm: fix nr_rotate_swap leak in swapon() error case
Pull networking fixes from David Miller:
"Let's begin the holiday weekend with some networking fixes:
1) Whoops need to restrict cfg80211 wiphy names even more to 64
bytes. From Eric Biggers.
2) Fix flags being ignored when using kernel_connect() with SCTP,
from Xin Long.
3) Use after free in DCCP, from Alexey Kodanev.
4) Need to check rhltable_init() return value in ipmr code, from Eric
Dumazet.
5) XDP handling fixes in virtio_net from Jason Wang.
6) Missing RTA_TABLE in rtm_ipv4_policy[], from Roopa Prabhu.
7) Need to use IRQ disabling spinlocks in mlx4_qp_lookup(), from Jack
Morgenstein.
8) Prevent out-of-bounds speculation using indexes in BPF, from
Daniel Borkmann.
9) Fix regression added by AF_PACKET link layer cure, from Willem de
Bruijn.
10) Correct ENIC dma mask, from Govindarajulu Varadarajan.
11) Missing config options for PMTU tests, from Stefano Brivio"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (48 commits)
ibmvnic: Fix partial success login retries
selftests/net: Add missing config options for PMTU tests
mlx4_core: allocate ICM memory in page size chunks
enic: set DMA mask to 47 bit
ppp: remove the PPPIOCDETACH ioctl
ipv4: remove warning in ip_recv_error
net : sched: cls_api: deal with egdev path only if needed
vhost: synchronize IOTLB message with dev cleanup
packet: fix reserve calculation
net/mlx5: IPSec, Fix a race between concurrent sandbox QP commands
net/mlx5e: When RXFCS is set, add FCS data into checksum calculation
bpf: properly enforce index mask to prevent out-of-bounds speculation
net/mlx4: Fix irq-unsafe spinlock usage
net: phy: broadcom: Fix bcm_write_exp()
net: phy: broadcom: Fix auxiliary control register reads
net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy
net/mlx4: fix spelling mistake: "Inrerface" -> "Interface" and rephrase message
ibmvnic: Only do H_EOI for mobility events
tuntap: correctly set SOCKWQ_ASYNC_NOSPACE
virtio-net: fix leaking page for gso packet during mergeable XDP
...
Using module_init() is wrong. E.g. ACPI adds and onlines memory before
our memory notifier gets registered.
This makes sure that ACPI memory detected during boot up will not result
in a kernel crash.
Easily reproducible with QEMU, just specify a DIMM when starting up.
Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com
Fixes: 786a895991 ("kasan: disable memory hotplug")
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have to free memory again when we cancel onlining, otherwise a later
onlining attempt will fail.
Link: http://lkml.kernel.org/r/20180522100756.18478-2-david@redhat.com
Fixes: fa69b5989b ("mm/kasan: add support for memory hotplug")
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit c7753208a9 ("x86, swiotlb: Add memory encryption support") a
call to function `mem_encrypt_init' was added. Include prototype
defined in header <linux/mem_encrypt.h> to prevent a warning reported
during compilation with W=1:
init/main.c:494:20: warning: no previous prototype for `mem_encrypt_init' [-Wmissing-prototypes]
Link: http://lkml.kernel.org/r/20180522195533.31415-1-malat@debian.org
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Gargi Sharma <gs051095@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
`resource' can be controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
Fix this by sanitizing *resource* before using it to index
current->signal->rlim
Notice that given that speculation windows are large, the policy is to
kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The case of a new numa node got missed in avoiding using the node info
from page_struct during hotplug. In this path we have a call to
register_mem_sect_under_node (which allows us to specify it is hotplug
so don't change the node), via link_mem_sections which unfortunately
does not.
Fix is to pass check_nid through link_mem_sections as well and disable
it in the new numa node path.
Note the bug only 'sometimes' manifests depending on what happens to be
in the struct page structures - there are lots of them and it only needs
to match one of them.
The result of the bug is that (with a new memory only node) we never
successfully call register_mem_sect_under_node so don't get the memory
associated with the node in sysfs and meminfo for the node doesn't
report it.
It came up whilst testing some arm64 hotplug patches, but appears to be
universal. Whilst I'm triggering it by removing then reinserting memory
to a node with no other elements (thus making the node disappear then
appear again), it appears it would happen on hotplugging memory where
there was none before and it doesn't seem to be related the arm64
patches.
These patches call __add_pages (where most of the issue was fixed by
Pavel's patch). If there is a node at the time of the __add_pages call
then all is well as it calls register_mem_sect_under_node from there
with check_nid set to false. Without a node that function returns
having not done the sysfs related stuff as there is no node to use.
This is expected but it is the resulting path that fails...
Exact path to the problem is as follows:
mm/memory_hotplug.c: add_memory_resource()
The node is not online so we enter the 'if (new_node)' twice, on the
second such block there is a call to link_mem_sections which calls
into
drivers/node.c: link_mem_sections() which calls
drivers/node.c: register_mem_sect_under_node() which calls
get_nid_for_pfn and keeps trying until the output of that matches
the expected node (passed all the way down from
add_memory_resource)
It is effectively the same fix as the one referred to in the fixes tag
just in the code path for a new node where the comments point out we
have to rerun the link creation because it will have failed in
register_new_memory (as there was no node at the time). (actually that
comment is wrong now as we don't have register_new_memory any more it
got renamed to hotplug_memory_register in Pavel's patch).
Link: http://lkml.kernel.org/r/20180504085311.1240-1-Jonathan.Cameron@huawei.com
Fixes: fc44f7f923 ("mm/memory_hotplug: don't read nid from struct page during hotplug")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The 4.17-rc /proc/meminfo and /proc/<pid>/smaps look ugly: single-digit
numbers (commonly 0) are misaligned.
Remove seq_put_decimal_ull_width()'s leftover optimization for single
digits: it's wrong now that num_to_str() takes care of the width.
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805241554210.1326@eggly.anvils
Fixes: d1be35cb6f ("proc: add seq_put_decimal_ull_width to speed up /proc/pid/smaps")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Andrei Vagin <avagin@openvz.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oscar has noticed that we splat
WARNING: CPU: 0 PID: 64 at ./include/linux/gfp.h:467 vmemmap_alloc_block+0x4e/0xc9
[...]
CPU: 0 PID: 64 Comm: kworker/u4:1 Tainted: G W E 4.17.0-rc5-next-20180517-1-default+ #66
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
Call Trace:
vmemmap_populate+0xf2/0x2ae
sparse_mem_map_populate+0x28/0x35
sparse_add_one_section+0x4c/0x187
__add_pages+0xe7/0x1a0
add_pages+0x16/0x70
add_memory_resource+0xa3/0x1d0
add_memory+0xe4/0x110
acpi_memory_device_add+0x134/0x2e0
acpi_bus_attach+0xd9/0x190
acpi_bus_scan+0x37/0x70
acpi_device_hotplug+0x389/0x4e0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x146/0x340
worker_thread+0x47/0x3e0
kthread+0xf5/0x130
ret_from_fork+0x35/0x40
when adding memory to a node that is currently offline.
The VM_WARN_ON is just too loud without a good reason. In this
particular case we are doing
alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, order)
so we do not insist on allocating from the given node (it is more a
hint) so we can fall back to any other populated node and moreover we
explicitly ask to not warn for the allocation failure.
Soften the warning only to cases when somebody asks for the given node
explicitly by __GFP_THISNODE.
Link: http://lkml.kernel.org/r/20180523125555.30039-3-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Oscar Salvador <osalvador@techadventures.net>
Tested-by: Oscar Salvador <osalvador@techadventures.net>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oscar has reported:
: Due to an unfortunate setting with movablecore, memblocks containing bootmem
: memory (pages marked by get_page_bootmem()) ended up marked in zone_movable.
: So while trying to remove that memory, the system failed in do_migrate_range
: and __offline_pages never returned.
:
: This can be reproduced by running
: qemu-system-x86_64 -m 6G,slots=8,maxmem=8G -numa node,mem=4096M -numa node,mem=2048M
: and movablecore=4G kernel command line
:
: linux kernel: BIOS-provided physical RAM map:
: linux kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
: linux kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
: linux kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
: linux kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bffdffff] usable
: linux kernel: BIOS-e820: [mem 0x00000000bffe0000-0x00000000bfffffff] reserved
: linux kernel: BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
: linux kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
: linux kernel: BIOS-e820: [mem 0x0000000100000000-0x00000001bfffffff] usable
: linux kernel: NX (Execute Disable) protection: active
: linux kernel: SMBIOS 2.8 present.
: linux kernel: DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org
: linux kernel: Hypervisor detected: KVM
: linux kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
: linux kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
: linux kernel: last_pfn = 0x1c0000 max_arch_pfn = 0x400000000
:
: linux kernel: SRAT: PXM 0 -> APIC 0x00 -> Node 0
: linux kernel: SRAT: PXM 1 -> APIC 0x01 -> Node 1
: linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0009ffff]
: linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x00100000-0xbfffffff]
: linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0x13fffffff]
: linux kernel: ACPI: SRAT: Node 1 PXM 1 [mem 0x140000000-0x1bfffffff]
: linux kernel: ACPI: SRAT: Node 0 PXM 0 [mem 0x1c0000000-0x43fffffff] hotplug
: linux kernel: NUMA: Node 0 [mem 0x00000000-0x0009ffff] + [mem 0x00100000-0xbfffffff] -> [mem 0x0
: linux kernel: NUMA: Node 0 [mem 0x00000000-0xbfffffff] + [mem 0x100000000-0x13fffffff] -> [mem 0
: linux kernel: NODE_DATA(0) allocated [mem 0x13ffd6000-0x13fffffff]
: linux kernel: NODE_DATA(1) allocated [mem 0x1bffd3000-0x1bfffcfff]
:
: zoneinfo shows that the zone movable is placed into both numa nodes:
: Node 0, zone Movable
: pages free 160140
: min 1823
: low 2278
: high 2733
: spanned 262144
: present 262144
: managed 245670
: Node 1, zone Movable
: pages free 448427
: min 3827
: low 4783
: high 5739
: spanned 524288
: present 524288
: managed 515766
Note how only Node 0 has a hutplugable memory region which would rule it
out from the early memblock allocations (most likely memmap). Node1
will surely contain memmaps on the same node and those would prevent
offlining to succeed. So this is arguably a configuration issue.
Although one could argue that we should be more clever and rule early
allocations from the zone movable. This would be correct but probably
not worth the effort considering what a hack movablecore is.
Anyway, We could do better for those cases though. We rely on
start_isolate_page_range resp. has_unmovable_pages to do their job.
The first one isolates the whole range to be offlined so that we do not
allocate from it anymore and the later makes sure we are not stumbling
over non-migrateable pages.
has_unmovable_pages is overly optimistic, however. It doesn't check all
the pages if we are withing zone_movable because we rely that those
pages will be always migrateable. As it turns out we are still not
perfect there. While bootmem pages in zonemovable sound like a clear
bug which should be fixed let's remove the optimization for now and warn
if we encounter unmovable pages in zone_movable in the meantime. That
should help for now at least.
Btw. this wasn't a real problem until commit 72b39cfc4d ("mm,
memory_hotplug: do not fail offlining too early") because we used to
have a small number of retries and then failed. This turned out to be
too fragile though.
Link: http://lkml.kernel.org/r/20180523125555.30039-2-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Oscar Salvador <osalvador@techadventures.net>
Tested-by: Oscar Salvador <osalvador@techadventures.net>
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
KASAN uses different routines to map shadow for hot added memory and
memory obtained in boot process. Attempt to offline memory onlined by
normal boot process leads to this:
Trying to vfree() nonexistent vm area (000000005d3b34b9)
WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
Call Trace:
kasan_mem_notifier+0xad/0xb9
notifier_call_chain+0x166/0x260
__blocking_notifier_call_chain+0xdb/0x140
__offline_pages+0x96a/0xb10
memory_subsys_offline+0x76/0xc0
device_offline+0xb8/0x120
store_mem_state+0xfa/0x120
kernfs_fop_write+0x1d5/0x320
__vfs_write+0xd4/0x530
vfs_write+0x105/0x340
SyS_write+0xb0/0x140
Obviously we can't call vfree() to free memory that wasn't allocated via
vmalloc(). Use find_vm_area() to see if we can call vfree().
Unfortunately it's a bit tricky to properly unmap and free shadow
allocated during boot, so we'll have to keep it. If memory will come
online again that shadow will be reused.
Matthew asked: how can you call vfree() on something that isn't a
vmalloc address?
vfree() is able to free any address returned by
__vmalloc_node_range(). And __vmalloc_node_range() gives you any
address you ask. It doesn't have to be an address in [VMALLOC_START,
VMALLOC_END] range.
That's also how the module_alloc()/module_memfree() works on
architectures that have designated area for modules.
[aryabinin@virtuozzo.com: improve comments]
Link: http://lkml.kernel.org/r/dabee6ab-3a7a-51cd-3b86-5468718e0390@virtuozzo.com
[akpm@linux-foundation.org: fix typos, reflow comment]
Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com
Fixes: fa69b5989b ("mm/kasan: add support for memory hotplug")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The current hugetlbfs maintainer has not been active for more than a few
years. I have been been active in this area for more than two years and
plan to remain active in the foreseeable future.
Also, update the hugetlbfs entry to include linux-mm mail list and
additional hugetlbfs related files. hugetlb.c and hugetlb.h are not
100% hugetlbfs, but a majority of their content is hugetlbfs related.
Link: http://lkml.kernel.org/r/20180518225236.19079-1-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
fact the very first thing we check for. Andrea reported that for
SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
but we need to check again if the address was rounded down to nil. As
of this patch, such cases will return -EINVAL.
Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patch series "ipc/shm: shmat() fixes around nil-page".
These patches fix two issues reported[1] a while back by Joe and Andrea
around how shmat(2) behaves with nil-page.
The first reverts a commit that it was incorrectly thought that mapping
nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
with the exception of SHM_REMAP; which is address in the second patch.
I chose two patches because it is easier to backport and it explicitly
reverts bogus behaviour. Both patches ought to be in -stable and ltp
testcases need updated (the added testcase around the cve can be
modified to just test for SHM_RND|SHM_REMAP).
[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
This patch (of 2):
Commit 95e91b831f ("ipc/shm: Fix shmat mmap nil-page protection")
worked on the idea that we should not be mapping as root addr=0 and
MAP_FIXED. However, it was reported that this scenario is in fact
valid, thus making the patch both bogus and breaks userspace as well.
For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
initialization[1].
[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
Fixes: 95e91b831f ("ipc/shm: Fix shmat mmap nil-page protection")
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the radix tree underlying the IDR happens to be full and we attempt
to remove an id which is larger than any id in the IDR, we will call
__radix_tree_delete() with an uninitialised 'slot' pointer, at which
point anything could happen. This was easiest to hit with a single
entry at id 0 and attempting to remove a non-0 id, but it could have
happened with 64 entries and attempting to remove an id >= 64.
Roman said:
The syzcaller test boils down to opening /dev/kvm, creating an
eventfd, and calling a couple of KVM ioctls. None of this requires
superuser. And the result is dereferencing an uninitialized pointer
which is likely a crash. The specific path caught by syzbot is via
KVM_HYPERV_EVENTD ioctl which is new in 4.17. But I guess there are
other user-triggerable paths, so cc:stable is probably justified.
Matthew added:
We have around 250 calls to idr_remove() in the kernel today. Many of
them pass an ID which is embedded in the object they're removing, so
they're safe. Picking a few likely candidates:
drivers/firewire/core-cdev.c looks unsafe; the ID comes from an ioctl.
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c is similar
drivers/atm/nicstar.c could be taken down by a handcrafted packet
Link: http://lkml.kernel.org/r/20180518175025.GD6361@bombadil.infradead.org
Fixes: 0a835c4f09 ("Reimplement IDR and IDA using the radix tree")
Reported-by: <syzbot+35666cba7f0a337e2e79@syzkaller.appspotmail.com>
Debugged-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If swapon() fails after incrementing nr_rotate_swap, we don't decrement
it and thus effectively leak it. Make sure we decrement it if we
incremented it.
Link: http://lkml.kernel.org/r/b6fe6b879f17fa68eee6cbd876f459f6e5e33495.1526491581.git.osandov@fb.com
Fixes: 81a0298bdf ("mm, swap: don't use VMA based swap readahead if HDD is used as swap")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Rik van Riel <riel@surriel.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Allwinner fixes for 4.17
Here is a bunch of fixes for merge issues, typos and wrong clocks being
described for simplefb, resulting in non-working displays.
* tag 'sunxi-fixes-for-4.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
ARM: sun8i: v3s: fix spelling mistake: "disbaled" -> "disabled"
ARM: dts: sun4i: Fix incorrect clocks for displays
ARM: dts: sun8i: h3: Re-enable EMAC on Orange Pi One
Signed-off-by: Olof Johansson <olof@lixom.net>
In its current state, the driver will handle backing device
login in a loop for a certain number of retries while the
device returns a partial success, indicating that the driver
may need to try again using a smaller number of resources.
The variable it checks to continue retrying may change
over the course of operations, resulting in reallocation
of resources but exits without sending the login attempt.
Guard against this by introducing a boolean variable that
will retain the state indicating that the driver needs to
reattempt login with backing device firmware.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Daniel Borkmann says:
====================
pull-request: bpf 2018-05-24
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix a bug in the original fix to prevent out of bounds speculation when
multiple tail call maps from different branches or calls end up at the
same tail call helper invocation, from Daniel.
2) Two selftest fixes, one in reuseport_bpf_numa where test is skipped in
case of missing numa support and another one to update kernel config to
properly support xdp_meta.sh test, from Anders.
...
Would be great if you have a chance to merge net into net-next after that.
The verifier fix would be needed later as a dependency in bpf-next for
upcomig work there. When you do the merge there's a trivial conflict on
BPF side with 849fa50662 ("bpf/verifier: refine retval R0 state for
bpf_get_stack helper"): Resolution is to keep both functions, the
do_refine_retval_range() and record_func_map().
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
If the hypercall was called from userspace or real mode, KVM injects #UD
and then advances RIP, so it looks like #UD was caused by the following
instruction. This probably won't cause more than confusion, but could
give an unexpected access to guest OS' instruction emulator.
Also, refactor the code to count hv hypercalls that were handled by the
virt userspace.
Fixes: 6356ee0c96 ("x86: Delay skip of emulated hypercall instruction")
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
PMTU tests in pmtu.sh need support for VTI, VTI6 and dummy
interfaces: add them to config file.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: d1f1b9cbf3 ("selftests: net: Introduce first PMTU test")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- prevent hardif_put call with NULL parameter, by Colin Ian King
- Avoid race in Translation Table allocator, by Sven Eckelmann
- Fix Translation Table sync flags for intermediate Responses,
by Linus Luessing
- prevent sending inconsistent Translation Table TVLVs,
by Marek Lindner
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAlsGpzQWHHN3QHNpbW9u
d3VuZGVybGljaC5kZQAKCRChK+OYQpKeocg6D/420GIZ7fJf5xadOzw9XYDbU+tc
nSz/N7V40BGit5i+bTo1fvQ9KRw4amUgx5nrTGi+nFmm0Au3cvwtFQe/c9JWZjFj
/7LWsc/HJPjhS045qwbnwBNBrlEM0KbEwqibmKgfrwVf1uIlUueMuILOFrQtAMhE
WokWK0mffxwPhwFlLxcByzqJSIUPB7BIoYnobU6orqjECdUVpUs3u4AF4Hbk28Y1
P3HS2WCK+Xgf1My7yjahh1pf1gM/AD0y+Xf+1k7dfM+n3qZrhdAPx30JmAIbcNWG
T4uSarxXjio9RRV9Fy1DIggpi1oCCCGAlayTg6RwyYIv5qYB6L7dPrBlRx+gOtox
QpLWIczvdMvloYFV5QykviErZRutFVBF2LKOEOI0GAGU/mCal2GNd+K1V504z+Gq
PM/5SmuAPOmCXe1rf/72zpkFSspZ2h4xvPjYpdNRyBRg/QWHqz+JWMGeENtKoRYV
v+3wYJTEa1bdeoc5NH7Fnc2iudeNlmISDuMxon1ikkgh5jHbaaC8Jvc6inp8y/JW
hhvYd6A406H/N6WOn0FbbSuZc1DQFO/92Fib4N2zdOwBFY2adLTpjAayv/ePpMji
SnGUdxoinWOUWpQo4S4SX4PXdE6F6ylNU4/Z2k9ixyQxNWO3T9wbKPaQGfLl8iSn
P9wPkGr84R2tlXi21Q==
=KY0V
-----END PGP SIGNATURE-----
Merge tag 'batadv-net-for-davem-20180524' of git://git.open-mesh.org/linux-merge
Simon Wunderlich says:
====================
Here are some batman-adv bugfixes:
- prevent hardif_put call with NULL parameter, by Colin Ian King
- Avoid race in Translation Table allocator, by Sven Eckelmann
- Fix Translation Table sync flags for intermediate Responses,
by Linus Luessing
- prevent sending inconsistent Translation Table TVLVs,
by Marek Lindner
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix application of read-only permissions to kernel section mappings
- Sanitise reported ESR values for signals delivered on a kernel address
- Ensure tishift GCC helpers are exported to modules
- Fix inline asm constraints for some LSE atomics
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJbB/1rAAoJELescNyEwWM03oIIAKVMZ6jBQFq41H+VUw7lDBMc
USEzqa0hEUsaWiZW8N9penAhY2a5saYQX5srVTXy9C2JzjQ0Tc5d7BCKfc+NSjO3
OBlBNVPqwbyYwfMrNWjOVxkOHrk04gF9b6j8hwUa2g7ioWdjyP37fsh+T0pDsazM
yKJt9bkjEdDDFAFqYIohEBF0LR6zXpWpCMxzZ8lcl4KcDfd85y8YBhOu211QXQoC
9PMDF9V9GzPBweAGiiET8Z0EPb5j0sCFTjNIIUiZLiP5SC7VTVJz2BqTIvolJE3o
zLCPfJOCd34KbVx0S8lhPiJo652njlm2ahN5vLtVaLHQCMTAimaeYjTD7ye8jKc=
=Um8e
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull more arm64 fixes from Will Deacon:
- fix application of read-only permissions to kernel section mappings
- sanitise reported ESR values for signals delivered on a kernel
address
- ensure tishift GCC helpers are exported to modules
- fix inline asm constraints for some LSE atomics
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Make sure permission updates happen for pmd/pud
arm64: fault: Don't leak data in ESR context for user fault on kernel VA
arm64: export tishift functions to modules
arm64: lse: Add early clobbers to some input/output asm operands
Just one fix, to make sure the PCR (Processor Compatibility Register) is reset
on boot. Otherwise if we're running in compat mode in a guest (eg. pretending a
Power9 is a Power8) and the host kernel oopses and kdumps then the kdump
kernel's userspace will be running in Power8 mode, and will SIGILL if it uses
Power9-only instructions.
Thanks to:
Michael Neuling.
-----BEGIN PGP SIGNATURE-----
iQIwBAABCAAaBQJbB/PjExxtcGVAZWxsZXJtYW4uaWQuYXUACgkQUevqPMjhpYCK
rhAAh2zSxZfpvDkjvWwqD26yDiDRcVV+rU2CtDiFQk+tAWVFhFqEMJvPWaUU4Ub9
EQStTS4gLiYsY282M+TyFGoUX76aAlMJenaCak8YQmYA4DQ8Sv2LB/jTJBhvbVnC
5ig9aNhSef5aDS7i5r5XzITf+SQ+1U2wddMxzy5Oklku+ypFX3cj9MtNvcD+fJIK
D35vvv5kI2a3wZsE/R7TB91MmfLgWY/4fb4da+dXMVTm+E1gHgOOU7JcnmzEJ/fH
Ds3d8JiIvsFXPCSwCruLiTXtmzQjZUYK3p81ffD7f3qCLBb54PbNBvsFgMYq4h8k
JGNeTqo+gGq3rqqbsftSudHVfG9jleKiJk7Xng3m5iqADHioroq0WTxulZczFd7t
DIl3NcmPnl7kFG/OjO39EDg50+Y/o0+uurjiy3EB9xTtivnOQ0Os+7tvmeqnzL8y
RpXVtZ0Uvf1aBrfXaobz/uNGy4Zy0ZamzdyxfLup7gqtPdAnDVnRak2Cn5bKuqK0
Xsi7/liq6Y7mwtys+iFuCMthh4/wza43VyH+ZYleEXOe6c0hfnuAvQdGcRSDtLMh
arSXYKbJCzwaQXKiTL5VRf/ta51MVi22ghV9/72Cf0wYUMJe0SNDYkhn34C8KlxB
Z5xYHljqRZE/uD8lYeeSdZKMvNEcinEJSpaC645uJVcvkKA=
=lmT9
-----END PGP SIGNATURE-----
Merge tag 'powerpc-4.17-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fix from Michael Ellerman:
"Just one fix, to make sure the PCR (Processor Compatibility Register)
is reset on boot.
Otherwise if we're running in compat mode in a guest (eg. pretending a
Power9 is a Power8) and the host kernel oopses and kdumps then the
kdump kernel's userspace will be running in Power8 mode, and will
SIGILL if it uses Power9-only instructions.
Thanks to Michael Neuling"
* tag 'powerpc-4.17-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/64s: Clear PCR on boot
- Propagate correct error code for RPMB requests
MMC host:
- sdhci-iproc: Drop hard coded cap for 1.8v
- sdhci-iproc: Fix 32bit writes for transfer mode
- sdhci-iproc: Enable SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbB8VxAAoJEP4mhCVzWIwp6EAQAIq9PeUa6l2ywWfOzqc2WdMA
idRdSa1r7TwvoAP8Ou/izJ3RqAAYD0TOp/FUauDu83r+rMBKhSWXOeGdz+dhSFzg
7vIfcYw3JsCqRHBw2rW8Q2PnrtWH+uUMNWeSlUAOW+szXdD2AiPewERHy6QrtS6d
eK5vd2sTB1SGz7cNsnG/rexxdlVaiJvkBwz6+SIU8x1E+UMqLzs5zweVPY1yIbzo
NfpO5uNP4CRslTgI7u8/XLgvnzrsZTSvcJforRbbiHOCa/BRPpPD/QanxQf+3ubg
N1Fi//U0hhNsyAQkdu21VAmJKM8ALGq1rGltjC3k8bJVX3+sZkbQBlrmfczYiOH3
HOEKprwTnE0rWh0eaZQ6fGRTksFoWQ3qjlXoY9qLRzmskmmK1fnhGiulo3p1RuRV
pBC6No0TPhfRQMsDbRucJmfNzpbmVR/NSbf89FvTZJXep7sNGvogjsMyggqMT5gX
Vs8N34ztUHjJqoBuAxnbeFzxove+dDGSIKwqSdVIfoS70V+NCbMz9PjaXwkQic32
dlZh6lyRBrAj+9G7t7jNKqNd6evbGST4Zds3n5OuEaHgXhhvYAXlviNdql3bfvmD
F3vvlnarRw7EKm5ABpab5ti+8ZOvDQI5ZtZe7iESu/hTxMhutQzVzBe0FY/CLJ0Z
13Nyn55oibLRoNDtihbJ
=4RTH
-----END PGP SIGNATURE-----
Merge tag 'mmc-v4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"MMC core:
- Propagate correct error code for RPMB requests
MMC host:
- sdhci-iproc: Drop hard coded cap for 1.8v
- sdhci-iproc: Fix 32bit writes for transfer mode
- sdhci-iproc: Enable SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus"
* tag 'mmc-v4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
mmc: block: propagate correct returned value in mmc_rpmb_ioctl
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbB6JmAAoJEAx081l5xIa+Ut8P/247Q0a0ohiLIuwrIt5ESfjr
EDG/khUQi8QuoDBtEh061SpgaB5rCgRU1rUVan24pij8j50EnMl0Nltn2yNTNnKG
SvMl9JfvpVJxXeCXdP0/71JHOCVYwkTUYa2asEZD5OGPbUxUf2S1caBxt9Z4lsyG
gnVpa2UhwHXdwQAgxksDCHwfyLEPCexpl2s4ghRc1xD9paiNPBriE2vEMnXYCwQg
gNDowaZLC190k51MwhK0OrUIQDH7h7pTmd460CTRZt4dwbmODEdsQLwFHIWrRX7U
+rXb9S/Yuz5cAWDoPlWrnUnrqpls1Cz6E8GBdw3mskkEgLW6ZiYDj1hysoB3ASzQ
OJvGkhxkFr/wdCD4si/rpSDY6hFGpVe9WOHg3v4e1whcMRx3DxHcWCivS3o/wws/
ZqZZAzPhCO7WEIDEZN4EGj4jI23qxchUr1RWJyuiV6AzaTksElsXYDsljY3OBXzD
VX20kL/b+VuUf8ZmF/GPfY0OuzQvg0Iojim5SHqQC0JH0BgRUNagjQKZq+DCMVYK
vR17JLjFYnrY5AE8bpZBmp/eYriWc5sftoiTsCs+v2R6caSN/0DxekrBuJruc2Nq
URFdo2hwfsT5PKSB7lWxQ8Uhnr7iGAfbqSeZI53SG09r2Y2iCsmQd517GfqbbrMW
OlMYKFXzMkSg/Vh20mW5
=YUH9
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.17-rc7' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Only two sets of drivers fixes: one rcar-du lvds regression fix, and a
group of fixes for vmwgfx"
* tag 'drm-fixes-for-v4.17-rc7' of git://people.freedesktop.org/~airlied/linux:
drm/vmwgfx: Schedule an fb dirty update after resume
drm/vmwgfx: Fix host logging / guestinfo reading error paths
drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector
Two fixes:
- A timer pause event notification was garbled upon the recent
hardening work; corrected now
- HD-audio runtime PM regression fix due to the incorrect return
type
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAlsHEzYOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9OPg//WxG811LOLI8xu7HkwgeZ2x6Uy0UUm11G7g1d
YQMUf7GZIUKO3CxAQQIvJqbeYd6v6yIykMPQp6vCkeJ2BlQWpjtF8icSW9jqp/tG
CAiIoI2oDMPha3VzZXjM2VGtQMaS3mFECkv3IqGAl6UDTb6ttXUi0yyxuGQL5b7G
7zJs9yfCEMhmfxc6Vz4AaJIDbuzIfBAai9qeQ1y6ZJbfjndS+7awG9QIxY3h6Sow
rEg7/xPY3HrCxmhpbaNxSorLYzd/BT40pyI/GDRMTFDDLv3JUH/1+GdG9aE3ZKtV
BFfFkb7MxwaJyymc6z+Qys81pfKuYaYFn3vi0XDJSCq4IrRev73uHzICh/CnoZwq
px8TiOauogb1Ru3Wvx+T2h0y7X5BGNUIaN8qp/Z01BhDryNw0fzyie8VMGVpWMEP
tL9eVahlbw4iuV1QYACZWJc4qlYmJr+E9HzQbY4aCJElE1q3jafkRw0cRNdj0HLV
VNVzG9SS2qJxTh43Y66E3zAT45pBHNcu0z+307n5oKqPql4UFH/rCy8BkeC0Hk7w
/eVwHM/jaTtYMHpsO2U8OHbdIBr23sTYc7YGAFow5FTlKEe6gpLQgQXIEfBG8k2S
dT5S1ag3kkQ2gLMYr96OKJ6xkf0kHZbaqjZSiFOC9lkWkq+ArNVgQ7Tucp6IUj9O
8kUM66U=
=gHjw
-----END PGP SIGNATURE-----
Merge tag 'sound-4.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Two fixes:
- a timer pause event notification was garbled upon the recent
hardening work; corrected now
- HD-audio runtime PM regression fix due to the incorrect return
type"
* tag 'sound-4.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix runtime PM
ALSA: timer: Fix pause event notification
When a system is under memory presure (high usage with fragments),
the original 256KB ICM chunk allocations will likely trigger kernel
memory management to enter slow path doing memory compact/migration
ops in order to complete high order memory allocations.
When that happens, user processes calling uverb APIs may get stuck
for more than 120s easily even though there are a lot of free pages
in smaller chunks available in the system.
Syslog:
...
Dec 10 09:04:51 slcc03db02 kernel: [397078.572732] INFO: task
oracle_205573_e:205573 blocked for more than 120 seconds.
...
With 4KB ICM chunk size on x86_64 arch, the above issue is fixed.
However in order to support smaller ICM chunk size, we need to fix
another issue in large size kcalloc allocations.
E.g.
Setting log_num_mtt=30 requires 1G mtt entries. With the 4KB ICM chunk
size, each ICM chunk can only hold 512 mtt entries (8 bytes for each mtt
entry). So we need a 16MB allocation for a table->icm pointer array to
hold 2M pointers which can easily cause kcalloc to fail.
The solution is to use kvzalloc to replace kcalloc which will fall back
to vmalloc automatically if kmalloc fails.
Signed-off-by: Qing Huang <qing.huang@oracle.com>
Acked-by: Daniel Jurgens <danielj@mellanox.com>
Reviewed-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the following commit:
b91473ff6e ("sched,tracing: Update trace_sched_pi_setprio()")
the sched_pi_setprio trace point shows the "newprio" during a deboost:
|futex sched_pi_setprio: comm=futex_requeue_p pid"34 oldprio newprio=3D98
|futex sched_switch: prev_comm=futex_requeue_p prev_pid"34 prev_prio=120
This patch open codes __rt_effective_prio() in the tracepoint as the
'newprio' to get the old behaviour back / the correct priority:
|futex sched_pi_setprio: comm=futex_requeue_p pid"20 oldprio newprio=3D120
|futex sched_switch: prev_comm=futex_requeue_p prev_pid"20 prev_prio=120
Peter suggested to open code the new priority so people using tracehook
could get the deadline data out.
Reported-by: Mansky Christian <man@keba.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: b91473ff6e ("sched,tracing: Update trace_sched_pi_setprio()")
Link: http://lkml.kernel.org/r/20180524132647.gg6ziuogczdmjjzu@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The following commit:
85f1abe001 ("kthread, sched/wait: Fix kthread_parkme() completion issue")
added a WARN() in the case where we call kthread_park() on an already
parked thread, because the old code wasn't doing the right thing there
and it wasn't at all clear that would happen.
It turns out, this does in fact happen, so we have to deal with it.
Instead of potentially returning early, also wait for the completion.
This does however mean we have to use complete_all() and re-initialize
the completion on re-use.
Reported-by: LKP <lkp@01.org>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: kernel test robot <lkp@intel.com>
Cc: wfg@linux.intel.com
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 85f1abe001 ("kthread, sched/wait: Fix kthread_parkme() completion issue")
Link: http://lkml.kernel.org/r/20180504091142.GI12235@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
