talos-op-linux/arch/x86/um, branch master

um: Implement copy_thread_tls

2020-01-07T12:31:29+00:00

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

Merge tag 'y2038-cleanups-5.5' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground

2019-12-01T22:00:59+00:00

Pull y2038 cleanups from Arnd Bergmann: "y2038 syscall implementation cleanups This is a series of cleanups for the y2038 work, mostly intended for namespace cleaning: the kernel defines the traditional time_t, timeval and timespec types that often lead to y2038-unsafe code. Even though the unsafe usage is mostly gone from the kernel, having the types and associated functions around means that we can still grow new users, and that we may be missing conversions to safe types that actually matter. There are still a number of driver specific patches needed to get the last users of these types removed, those have been submitted to the respective maintainers" Link: https://lore.kernel.org/lkml/20191108210236.1296047-1-arnd@arndb.de/ * tag 'y2038-cleanups-5.5' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground: (26 commits) y2038: alarm: fix half-second cut-off y2038: ipc: fix x32 ABI breakage y2038: fix typo in powerpc vdso "LOPART" y2038: allow disabling time32 system calls y2038: itimer: change implementation to timespec64 y2038: move itimer reset into itimer.c y2038: use compat_{get,set}_itimer on alpha y2038: itimer: compat handling to itimer.c y2038: time: avoid timespec usage in settimeofday() y2038: timerfd: Use timespec64 internally y2038: elfcore: Use __kernel_old_timeval for process times y2038: make ns_to_compat_timeval use __kernel_old_timeval y2038: socket: use __kernel_old_timespec instead of timespec y2038: socket: remove timespec reference in timestamping y2038: syscalls: change remaining timeval to __kernel_old_timeval y2038: rusage: use __kernel_old_timeval y2038: uapi: change __kernel_time_t to __kernel_old_time_t y2038: stat: avoid 'time_t' in 'struct stat' y2038: ipc: remove __kernel_time_t reference from headers y2038: vdso: powerpc: avoid timespec references ...

y2038: vdso: change time_t to __kernel_old_time_t

2019-11-15T13:38:28+00:00

Only x86 uses the 'time' syscall in vdso, so change that to __kernel_old_time_t as a preparation for removing 'time_t' and '__kernel_time_t' later. Reviewed-by: Thomas Gleixner Signed-off-by: Arnd Bergmann

y2038: vdso: change timespec to __kernel_old_timespec

2019-11-15T13:38:28+00:00

In order to remove 'timespec' completely from the kernel, all internal uses should be converted to a y2038-safe type, while those that are only for compatibity with existing user space should be marked appropriately. Change vdso to use __kernel_old_timespec in order to avoid the deprecated type and mark these interfaces as outdated. Signed-off-by: Arnd Bergmann

y2038: vdso: change timeval to __kernel_old_timeval

2019-11-15T13:38:27+00:00

The gettimeofday() function in vdso uses the traditional 'timeval' structure layout, which will be incompatible with future versions of glibc on 32-bit architectures that use a 64-bit time_t. This interface is problematic for y2038, when time_t overflows on 32-bit architectures, but the plan so far is that a libc with 64-bit time_t will not call into the gettimeofday() vdso helper at all, and only have a method for entering clock_gettime(). This means we don't have to fix it here, though we probably want to add a new clock_gettime() entry point using a 64-bit version of 'struct timespec' at some point. Changing the vdso code to use __kernel_old_timeval helps isolate this usage from the other ones that still need to be fixed properly, and it gets us closer to removing the 'timeval' definition from the kernel sources. Reviewed-by: Thomas Gleixner Signed-off-by: Arnd Bergmann

x86/um: Annotate data appropriately

2019-10-18T08:45:03+00:00

Use the new SYM_DATA_START and SYM_DATA_END_LABEL macros for vdso_start. Result is: 0000 2376 OBJECT GLOBAL DEFAULT 4 vdso_start 0948 0 OBJECT GLOBAL DEFAULT 4 vdso_end Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Acked-by: Richard Weinberger Cc: Anton Ivanov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jeff Dike Cc: linux-arch@vger.kernel.org Cc: linux-um@lists.infradead.org Cc: Thomas Gleixner Cc: user-mode-linux-devel@lists.sourceforge.net Cc: user-mode-linux-user@lists.sourceforge.net Cc: x86-ml Link: https://lkml.kernel.org/r/20191011115108.12392-14-jslaby@suse.cz

um: Use real DMA barriers

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

When we have virtio enabled, we must have real barriers since we may be running on an SMP machine (quite likely are, in fact), so the other process can be on another CPU. Since in any other case we don't really use DMA barriers, remove their override completely so real barriers will get used. In the future we might need them for other cases as well. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger

um: Don't use generic barrier.h

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

UML has its own platform-specific barrier.h under arch/x86/um/, which should get used. Fix the build system to use it, and then fix the barrier.h to actually compile. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger

um: Fix VDSO compiler warning

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

Fix a warning about the function type being wrong. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger

Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2019-07-09T04:48:15+00:00

Pull force_sig() argument change from Eric Biederman: "A source of error over the years has been that force_sig has taken a task parameter when it is only safe to use force_sig with the current task. The force_sig function is built for delivering synchronous signals such as SIGSEGV where the userspace application caused a synchronous fault (such as a page fault) and the kernel responded with a signal. Because the name force_sig does not make this clear, and because the force_sig takes a task parameter the function force_sig has been abused for sending other kinds of signals over the years. Slowly those have been fixed when the oopses have been tracked down. This set of changes fixes the remaining abusers of force_sig and carefully rips out the task parameter from force_sig and friends making this kind of error almost impossible in the future" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (27 commits) signal/x86: Move tsk inside of CONFIG_MEMORY_FAILURE in do_sigbus signal: Remove the signal number and task parameters from force_sig_info signal: Factor force_sig_info_to_task out of force_sig_info signal: Generate the siginfo in force_sig signal: Move the computation of force into send_signal and correct it. signal: Properly set TRACE_SIGNAL_LOSE_INFO in __send_signal signal: Remove the task parameter from force_sig_fault signal: Use force_sig_fault_to_task for the two calls that don't deliver to current signal: Explicitly call force_sig_fault on current signal/unicore32: Remove tsk parameter from __do_user_fault signal/arm: Remove tsk parameter from __do_user_fault signal/arm: Remove tsk parameter from ptrace_break signal/nds32: Remove tsk parameter from send_sigtrap signal/riscv: Remove tsk parameter from do_trap signal/sh: Remove tsk parameter from force_sig_info_fault signal/um: Remove task parameter from send_sigtrap signal/x86: Remove task parameter from send_sigtrap signal: Remove task parameter from force_sig_mceerr signal: Remove task parameter from force_sig signal: Remove task parameter from force_sigsegv ...