~vicamo/+git/ubuntu-kernel:bug-1866734/fix-selftest-retry-v2/focal

Last commit made on 2020-03-16
Get this branch:
git clone -b bug-1866734/fix-selftest-retry-v2/focal https://git.launchpad.net/~vicamo/+git/ubuntu-kernel
Only You-Sheng Yang can upload to this branch. If you are You-Sheng Yang please log in for upload directions.

Branch merges

Branch information

Name:
bug-1866734/fix-selftest-retry-v2/focal
Repository:
lp:~vicamo/+git/ubuntu-kernel

Recent commits

d45468b... by You-Sheng Yang

Bug 1866734: Input: i8042 - fix the selftest retry logic

b6256d9... by You-Sheng Yang

Input: i8042 - fix the selftest retry logic

It returns -NODEV at the first selftest timeout, so the retry logic
doesn't work. Move the return outside of the while loop to make it real
retry 5 times before returns -ENODEV.

BTW, the origin loop will retry 6 times, also fix this.

Signed-off-by: You-Sheng Yang <email address hidden>
(backported from
https://<email address hidden>/)

1b33ff9... by Greg Kroah-Hartman <email address hidden>

Linux 5.4.25

BugLink: https://bugs.launchpad.net/bugs/1867178

Signed-off-by: Paolo Pisati <email address hidden>

a91124c... by Stephen Rothwell <email address hidden>

drm/virtio: module_param_named() requires linux/moduleparam.h

BugLink: https://bugs.launchpad.net/bugs/1867178

commit b0138364da17617db052c4a738b58bf45e42f500 upstream.

Fixes: 3e93bc2a58aa ("drm/virtio: make resource id workaround runtime switchable.")
Signed-off-by: Stephen Rothwell <email address hidden>
Link: http://<email address hidden>
Signed-off-by: Gerd Hoffmann <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

3187c54... by Guo Ren <email address hidden>

csky: Implement copy_thread_tls

BugLink: https://bugs.launchpad.net/bugs/1867178

commit 0b9f386c4be6493d282aab0af6f9b70c62142777 upstream.

This is required for clone3 which passes the TLS value through a
struct rather than a register.

Cc: Amanieu d'Antras <email address hidden>
Signed-off-by: Guo Ren <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

05e9327... by Paolo Valente <email address hidden>

block, bfq: remove ifdefs from around gets/puts of bfq groups

BugLink: https://bugs.launchpad.net/bugs/1867178

commit 4d8340d0d4d90e7ca367d18ec16c2fefa89a339c upstream.

ifdefs around gets and puts of bfq groups reduce readability, remove them.

Tested-by: Oleksandr Natalenko <email address hidden>
Reported-by: Jens Axboe <email address hidden>
Signed-off-by: Paolo Valente <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

0990e59... by Paolo Valente <email address hidden>

block, bfq: get a ref to a group when adding it to a service tree

BugLink: https://bugs.launchpad.net/bugs/1867178

commit db37a34c563bf4692b36990ae89005c031385e52 upstream.

BFQ schedules generic entities, which may represent either bfq_queues
or groups of bfq_queues. When an entity is inserted into a service
tree, a reference must be taken, to make sure that the entity does not
disappear while still referred in the tree. Unfortunately, such a
reference is mistakenly taken only if the entity represents a
bfq_queue. This commit takes a reference also in case the entity
represents a group.

Tested-by: Oleksandr Natalenko <email address hidden>
Tested-by: Chris Evich <email address hidden>
Signed-off-by: Paolo Valente <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

48201df... by Jason A. Donenfeld

efi: READ_ONCE rng seed size before munmap

BugLink: https://bugs.launchpad.net/bugs/1867178

commit be36f9e7517e17810ec369626a128d7948942259 upstream.

This function is consistent with using size instead of seed->size
(except for one place that this patch fixes), but it reads seed->size
without using READ_ONCE, which means the compiler might still do
something unwanted. So, this commit simply adds the READ_ONCE
wrapper.

Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...")
Signed-off-by: Jason A. Donenfeld <email address hidden>
Signed-off-by: Ard Biesheuvel <email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Cc: <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Link: https://<email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

fb2a1de... by Ard Biesheuvel <email address hidden>

efi/x86: Handle by-ref arguments covering multiple pages in mixed mode

BugLink: https://bugs.launchpad.net/bugs/1867178

commit 8319e9d5ad98ffccd19f35664382c73cea216193 upstream.

The mixed mode runtime wrappers are fragile when it comes to how the
memory referred to by its pointer arguments are laid out in memory, due
to the fact that it translates these addresses to physical addresses that
the runtime services can dereference when running in 1:1 mode. Since
vmalloc'ed pages (including the vmap'ed stack) are not contiguous in the
physical address space, this scheme only works if the referenced memory
objects do not cross page boundaries.

Currently, the mixed mode runtime service wrappers require that all by-ref
arguments that live in the vmalloc space have a size that is a power of 2,
and are aligned to that same value. While this is a sensible way to
construct an object that is guaranteed not to cross a page boundary, it is
overly strict when it comes to checking whether a given object violates
this requirement, as we can simply take the physical address of the first
and the last byte, and verify that they point into the same physical page.

When this check fails, we emit a WARN(), but then simply proceed with the
call, which could cause data corruption if the next physical page belongs
to a mapping that is entirely unrelated.

Given that with vmap'ed stacks, this condition is much more likely to
trigger, let's relax the condition a bit, but fail the runtime service
call if it does trigger.

Fixes: f6697df36bdf0bf7 ("x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y")
Signed-off-by: Ard Biesheuvel <email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Cc: <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>

aec62c4... by Ard Biesheuvel <email address hidden>

efi/x86: Align GUIDs to their size in the mixed mode runtime wrapper

BugLink: https://bugs.launchpad.net/bugs/1867178

commit 63056e8b5ebf41d52170e9f5ba1fc83d1855278c upstream.

Hans reports that his mixed mode systems running v5.6-rc1 kernels hit
the WARN_ON() in virt_to_phys_or_null_size(), caused by the fact that
efi_guid_t objects on the vmap'ed stack happen to be misaligned with
respect to their sizes. As a quick (i.e., backportable) fix, copy GUID
pointer arguments to the local stack into a buffer that is naturally
aligned to its size, so that it is guaranteed to cover only one
physical page.

Note that on x86, we cannot rely on the stack pointer being aligned
the way the compiler expects, so we need to allocate an 8-byte aligned
buffer of sufficient size, and copy the GUID into that buffer at an
offset that is aligned to 16 bytes.

Fixes: f6697df36bdf0bf7 ("x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y")
Reported-by: Hans de Goede <email address hidden>
Signed-off-by: Ard Biesheuvel <email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Tested-by: Hans de Goede <email address hidden>
Cc: <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

Signed-off-by: Paolo Pisati <email address hidden>