In 19be0eaff ("mm: remove gup_flags FOLL_WRITE games from __get_user_pages()"),
the mm code was changed from unsetting FOLL_WRITE after a COW was resolved to
setting the (newly introduced) FOLL_COW instead. Simultaneously, the check in
gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had
also been set. However, a similar check in huge_memory.c was forgotten. As a
result, remote memory writes to ro regions of memory backed by transparent huge
pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW and
returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately
because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is true. While in this
state the process is stil SIGKILLable, but little else works (e.g. no ptrace
attach, no other signals). This is easily reproduced with the following
code (assuming thp are set to always):
Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously to
the update in gup.c in the original commit. The same pattern exists in
follow_devmap_pmd. However, we should not be able to reach that check
with FOLL_COW set, so add WARN_ONCE to make sure we notice if we ever
do.
Signed-off-by: Keno Fischer <email address hidden>
Acked-by: Kirill A. Shutemov <email address hidden>
Acked-by: Michal Hocko <email address hidden>
Tested-by: David Rientjes <email address hidden>
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
It may happen that secondary CPUs are still alive and resetting
hv_context.tsc_page will cause a consequent crash in read_hv_clock_tsc()
as we don't check for it being not NULL there. It is safe as we're not
freeing this page anyways.
Signed-off-by: Vitaly Kuznetsov <email address hidden>
Signed-off-by: K. Y. Srinivasan <email address hidden>
Cc: <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 56ef6718a1d8d77745033c5291e025ce18504159)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt')
which injects NMI to the guest. We may want to crash the guest and do kdump
on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to
allow the kdump kernel to re-establish VMBus connection so it will see
VMBus devices (storage, network,..).
To properly unload VMBus making it possible to start over during kdump we
need to do the following:
- Send an 'unload' message to the hypervisor. This can be done on any CPU
so we do this the crashing CPU.
- Receive the 'unload finished' reply message. WS2012R2 delivers this
message to the CPU which was used to establish VMBus connection during
module load and this CPU may differ from the CPU sending 'unload'.
Receiving a VMBus message means the following:
- There is a per-CPU slot in memory for one message. This slot can in
theory be accessed by any CPU.
- We get an interrupt on the CPU when a message was placed into the slot.
- When we read the message we need to clear the slot and signal the fact
to the hypervisor. In case there are more messages to this CPU pending
the hypervisor will deliver the next message. The signaling is done by
writing to an MSR so this can only be done on the appropriate CPU.
To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload()
function which checks message slots for all CPUs in a loop waiting for the
'unload finished' messages. However, there is an issue which arises when
these conditions are met:
- We're crashing on a CPU which is different from the one which was used
to initially contact the hypervisor.
- The CPU which was used for the initial contact is blocked with interrupts
disabled and there is a message pending in the message slot.
In this case we won't be able to read the 'unload finished' message on the
crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs
simultaneously: the first CPU entering panic() will proceed to crash and
all other CPUs will stop themselves with interrupts disabled.
The suggested solution is to handle unknown NMIs for Hyper-V guests on the
first CPU which gets them only. This will allow us to rely on VMBus
interrupt handler being able to receive the 'unload finish' message in
case it is delivered to a different CPU.
The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the
boot CPU only, WS2012R2 and earlier Hyper-V versions are affected.
Signed-off-by: Vitaly Kuznetsov <email address hidden>
Acked-by: K. Y. Srinivasan <email address hidden>
Cc: <email address hidden>
Cc: Haiyang Zhang <email address hidden>
Link: http://<email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
(cherry picked from commit 59107e2f48831daedc46973ce4988605ab066de3)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Quirking the following AMI USB device with ALWAYS_POLL fixes an AMI
virtual keyboard and mouse from not responding and timing out when
it is attached to a ppc64el Power 8 system and when we have some
rapid open/closes on the mouse device.
usb 1-3: new high-speed USB device number 2 using xhci_hcd
usb 1-3: New USB device found, idVendor=046b, idProduct=ff01
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: Virtual Hub
usb 1-3: Manufacturer: American Megatrends Inc.
usb 1-3: SerialNumber: serial
usb 1-3.3: new high-speed USB device number 3 using xhci_hcd
usb 1-3.3: New USB device found, idVendor=046b, idProduct=ff31
usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3.3: Product: Virtual HardDisk Device
usb 1-3.3: Manufacturer: American Megatrends Inc.
usb 1-3.4: new low-speed USB device number 4 using xhci_hcd
usb 1-3.4: New USB device found, idVendor=046b, idProduct=ff10
usb 1-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-3.4: Product: Virtual Keyboard and Mouse
usb 1-3.4: Manufacturer: American Megatrends Inc.
With the quirk I have not been able to trigger the issue with
half an hour of saturation soak testing.
Signed-off-by: Colin Ian King <email address hidden>
Signed-off-by: Jiri Kosina <email address hidden>
(backported from ed9ab4287f96e66340e0390e2c583f2f9110cba0)
Signed-off-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
generic syscalls: kill cruft from removed pkey syscalls
pkey_set() and pkey_get() were syscalls present in older versions
of the protection keys patches. They were fully excised from the
x86 code, but some cruft was left in the generic syscall code. The
C++ comments were intended to help to make it more glaring to me to
fix them before actually submitting them. That technique worked,
but later than I would have liked.
(cherry-picked from commit 71757904efadefdf5505712f675218ce59483c5d upstream)
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
CONFIG_PINCTRL_CHERRYVIEW=y (must be y, not m) in addition to CONFIG_TOUCHSCREEN_ELAN to get the touchscreen working on CYAN.
The change of Intel related PINCTRLs (specifically the CHERRYVIEW one) to m instead of y causes at least the touchscreen regression.
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
UBUNTU: [debian] derive indep_hdrs_pkg_name from src_pkg_name
This long-standing oversight in our debian rules hardcodes the string "linux"
instead of using the $(src_pkg_name) for just one of the generated .deb package
names: linux-headers-x.x.x-x. Lets fix it in the generic branches
(T,X,Y,Z,unstable) so that we won't have to keep applying this patch to each of
the derivative/custom kernels.
-----8<-----
Ignore: yes
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Ben Romer <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
