s390 updates for 6.3 merge window part 2

- Add empty command line parameter handling stubs to kernel for all command
  line parameters which are handled in the decompressor. This avoids
  invalid "Unknown kernel command line parameters" messages from the
  kernel, and also avoids that these will be incorrectly passed to user
  space. This caused already confusion, therefore add the empty stubs

- Add missing phys_to_virt() handling to machine check handler

- Introduce and use a union to be used for zcrypt inline assemblies. This
  makes sure that only a register wide member of the union is passed as
  input and output parameter to inline assemblies, while usual C code uses
  other members of the union to access bit fields of it

- Add and use a READ_ONCE_ALIGNED_128() macro, which can be used to
  atomically read a 128-bit value from memory. This replaces the (mis-)use
  of the 128-bit cmpxchg operation to do the same in cpum_sf code.
  Currently gcc does not generate the used lpq instruction if __READ_ONCE()
  is used for aligned 128-bit accesses, therefore use this s390 specific
  helper

- Simplify machine check handler code if a task needs to be killed because
  of e.g. register corruption due to a machine malfunction

- Perform CPU reset to clear pending interrupts and TLB entries on an
  already stopped target CPU before delegating work to it

- Generate arch/s390/boot/vmlinux.map link map for the decompressor, when
  CONFIG_VMLINUX_MAP is enabled for debugging purposes

- Fix segment type handling for dcssblk devices. It incorrectly always
  returned type "READ/WRITE" even for read-only segements, which can result
  in a kernel panic if somebody tries to write to a read-only device

- Sort config S390 select list again

- Fix two kprobe reenter bugs revealed by a recently added kprobe kunit
  test
s390/kprobes: fix current_kprobe never cleared after kprobes reenter

Recent test_kprobe_missed kprobes kunit test uncovers the following
problem. Once kprobe is triggered from another kprobe (kprobe reenter),
all future kprobes on this cpu are considered as kprobe reenter, thus
pre_handler and post_handler are not being called and kprobes are counted
as "missed".

Commit b9599798f953 ("[S390] kprobes: activation and deactivation")
introduced a simpler scheme for kprobes (de)activation and status
tracking by using push_kprobe/pop_kprobe, which supposed to work for
both initial kprobe entry as well as kprobe reentry and helps to avoid
handling those two cases differently. The problem is that a sequence of
calls in case of kprobes reenter:
push_kprobe() <- NULL (current_kprobe)
push_kprobe() <- kprobe1 (current_kprobe)
pop_kprobe() -> kprobe1 (current_kprobe)
pop_kprobe() -> kprobe1 (current_kprobe)
leaves "kprobe1" as "current_kprobe" on this cpu, instead of setting it
to NULL. In fact push_kprobe/pop_kprobe can only store a single state
(there is just one prev_kprobe in kprobe_ctlblk). Which is a hack but
sufficient, there is no need to have another prev_kprobe just to store
NULL. To make a simple and backportable fix simply reset "prev_kprobe"
when kprobe is poped from this "stack". No need to worry about
"kprobe_status" in this case, because its value is only checked when
current_kprobe != NULL.

Cc: stable@vger.kernel.org
Fixes: b9599798f953 ("[S390] kprobes: activation and deactivation")
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
1 file changed