linux.git/arch/um/kernel, branch v5.4.64

Revert "um: Enable CONFIG_CONSTRUCTORS"

2020-02-01T09:34:53+00:00

commit 87c9366e17259040a9118e06b6dc8de986e5d3d1 upstream.

This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS").

There are two issues with this commit, uncovered by Anton in tests
on some (Debian) systems:

1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS
   isn't set. Don't recall now if it just wasn't needed on my system, or
   if I never tested this case.

2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I
   set CONFIG_CONSTRUCTORS, it fails again, which isn't totally
   unexpected since whatever wanted to run is likely to have to run
   before the kernel init etc. that calls the constructors in this case.

Basically, some constructors that gcc emits (libc has?) need to run
very early during init; the failure mode otherwise was that the ptrace
fork test already failed:

----------------------
$ ./linux mem=512M
Core dump limits :
	soft - 0
	hard - NONE
Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f
Aborted
----------------------

Thinking more about this, it's clear that we simply cannot support
CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan)
involve not use of the __attribute__((constructor)), but instead
some constructor code/entry generated by gcc. Therefore, we cannot
distinguish between kernel constructors and system constructors.

Thus, revert this commit.

Cc: stable@vger.kernel.org [5.4+]
Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS")
Reported-by: Anton Ivanov 
Signed-off-by: Johannes Berg 
Acked-by: Anton Ivanov 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Richard Weinberger

um: Implement copy_thread_tls

2020-01-14T19:08:35+00:00

commit 457677c70c7672a4586b0b8abc396cc1ecdd376d upstream.

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

Signed-off-by: Amanieu d'Antras 
Cc: linux-um@lists.infradead.org
Cc:  # 5.3.x
Link: https://lore.kernel.org/r/20200104123928.1048822-1-amanieu@gmail.com
Signed-off-by: Christian Brauner 
Signed-off-by: Greg Kroah-Hartman

um: irq: Fix LAST_IRQ usage in init_IRQ()

2019-09-16T06:38:58+00:00

LAST_IRQ was used incorrectly in init_IRQ.
Commit 09ccf0364ca3 forgot to update the for loop.
Fix this.

Fixes: 49da7e64f33e ("High Performance UML Vector Network Driver")
Fixes: 09ccf0364ca3 ("um: Fix off by one error in IRQ enumeration")
Signed-off-by: Erel Geron 
Signed-off-by: Johannes Berg 
Acked-by: Anton Ivanov 
Signed-off-by: Richard Weinberger

um: Add SPDX headers to files in arch/um/kernel/

2019-09-15T19:37:17+00:00

Convert files to use SPDX header. All files are licensed under the
GPLv2.

Signed-off-by: Alex Dewar 
Signed-off-by: Richard Weinberger

um: drivers: Add virtio vhost-user driver

2019-09-15T19:37:15+00:00

This module allows virtio devices to be used over a vhost-user socket.

Signed-off-by: Erel Geron 
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: time-travel: Restrict time update in IRQ handler

2019-09-15T19:37:13+00:00

We currently do the time updates in the timer handler, even if
we just call the timer handler ourselves. In basic mode we must
in fact do it there since otherwise the OS timer signal won't
move time forward, but in inf-cpu mode we don't need to, and
it's harder to understand.

Restrict the update there to basic mode, adding a comment, and
do it before calling the timer_handler() in inf-cpu mode.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: time-travel: Fix periodic timers

2019-09-15T19:37:13+00:00

Periodic timers are broken, because the also only fire once.
As it happens, Linux doesn't care because it only sets the
timer to periodic very briefly during boot, and then switches
it only between one-shot and off later.

Nevertheless, fix the logic (we shouldn't even be looking at
time_travel_timer_expiry unless the timer is enabled) and
change the code to fire the timer periodically in periodic
mode, in case it ever gets used in the future.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: Enable CONFIG_CONSTRUCTORS

2019-09-15T19:37:13+00:00

We do need to call the constructors for *modules*, and
at least for KASAN in the future, we must call even the
kernel constructors only later when the kernel has been
initialized.

Instead of relying on libc to call them, emit an empty
section for libc and let the kernel's CONSTRUCTORS code
do the rest of the job.

Tested that it indeed doesn't work in modules, and does
work after the fixes in both, with a few functions with
__attribute__((constructor)) in both dynamic and static
builds.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: Place (soft)irq text with macros

2019-09-15T19:37:12+00:00

Otherwise it gets placed without the start/end markers.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger

um: Implement TRACE_IRQFLAGS_SUPPORT

2019-09-15T19:37:11+00:00

UML enables TRACE_IRQFLAGS_SUPPORT but doesn't actually implement
it. It seems to have been added for lockdep support, but that can't
actually really work well without IRQ flags tracing, as is also
very noisily reported when enabling CONFIG_DEBUG_LOCKDEP.

Implement it now.

Fixes: 711553efa5b8 ("[PATCH] uml: declare in Kconfig our partial LOCKDEP support")
Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger