kernel/linux.git/arch/um/include/shared/os.h, branch v6.6.131

um: remove copy_from_kernel_nofault_allowed

2025-04-10T12:37:34+00:00

[ Upstream commit 84a6fc378471fbeaf48f8604566a5a33a3d63c18 ] There is no need to override the default version of this function anymore as UML now has proper _nofault memory access functions. Doing this also fixes the fact that the implementation was incorrect as using mincore() will incorrectly flag pages as inaccessible if they were swapped out by the host. Fixes: f75b1b1bedfb ("um: Implement probe_kernel_read()") Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250210160926.420133-3-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

um: seed rng using host OS rng

2022-07-18T13:04:04+00:00

UML generally does not provide access to special CPU instructions like RDRAND, and execution tends to be rather deterministic, with no real hardware interrupts, making good randomness really very hard, if not all together impossible. Not only is this a security eyebrow raiser, but it's also quite annoying when trying to do various pieces of UML-based automation that takes a long time to boot, if ever. Fix this by trivially calling getrandom() in the host and using that seed as "bootloader randomness", which initializes the rng immediately at UML boot. The old behavior can be restored the same way as on any other arch, by way of CONFIG_TRUST_BOOTLOADER_RANDOMNESS=n or random.trust_bootloader=0. So seen from that perspective, this just makes UML act like other archs, which is positive in its own right. Additionally, wire up arch_get_random_{int,long}() in the same way, so that reseeds can also make use of the host RNG, controllable by CONFIG_TRUST_CPU_RANDOMNESS and random.trust_cpu, per usual. Cc: stable@vger.kernel.org Acked-by: Johannes Berg Acked-By: Anton Ivanov Signed-off-by: Jason A. Donenfeld

um: Fix WRITE_ZEROES in the UBD Driver

2022-03-11T09:46:34+00:00

Call to fallocate with FALLOC_FL_PUNCH_HOLE on a device backed by a sparse file can end up by missing data, zeroes data range, if the underlying file is used with a tool like bmaptool which will referenced only used spaces. Signed-off-by: Frédéric Danis Acked-by: Anton Ivanov Signed-off-by: Richard Weinberger

um: header debriding - os.h

2021-12-21T20:31:36+00:00

Signed-off-by: Al Viro Signed-off-by: Richard Weinberger

um: rename set_signals() to um_set_signals()

2021-12-21T20:13:44+00:00

Rename set_signals() as there's at least one driver that uses the same name and can now be built on UM due to PCI support, and thus we can get symbol conflicts. Also rename set_signals_trace() to be consistent. Reported-by: kernel test robot Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger

isystem: trim/fixup stdarg.h and other headers

2021-08-19T00:02:55+00:00

Delete/fixup few includes in anticipation of global -isystem compile option removal. Note: crypto/aegis128-neon-inner.c keeps due to redefinition of uintptr_t error (one definition comes from , another from ). Signed-off-by: Alexey Dobriyan Signed-off-by: Masahiro Yamada

um: Remove the repeated declaration

2021-06-17T20:11:52+00:00

Function 'os_flush_stdout' is declared twice, so remove the repeated declaration. Cc: Jeff Dike Cc: Richard Weinberger Signed-off-by: Shaokun Zhang Signed-off-by: Richard Weinberger

um: Add support for host CPU flags and alignment

2021-06-17T20:01:26+00:00

1. Reflect host cpu flags into the UML instance so they can be used to select the correct implementations for xor, crypto, etc. 2. Reflect host cache alignment into UML instance. This is important when running 32 bit on a 64 bit host as 32 bit by default aligns to 32 while the actual alignment should be 64. Ditto for some Xeons which align at 128. Signed-off-by: Anton Ivanov Signed-off-by: Richard Weinberger

um: time-travel/signals: fix ndelay() in interrupt

2021-06-17T19:44:52+00:00

We should be able to ndelay() from any context, even from an interrupt context! However, this is broken (not functionally, but locking-wise) in time-travel because we'll get into the time-travel code and enable interrupts to handle messages on other time-travel aware subsystems (only virtio for now). Luckily, I've already reworked the time-travel aware signal (interrupt) delivery for suspend/resume to have a time travel handler, which runs directly in the context of the signal and not from the Linux interrupt. In order to fix this time-travel issue then, we need to do a few things: 1) rework the signal handling code to call time-travel handlers (only) if interrupts are disabled but signals aren't blocked, instead of marking it only pending there. This is needed to not deadlock other communication. 2) rework time-travel to not enable interrupts while it's waiting for a message; 3) rework time-travel to not (just) disable interrupts but rather block signals at a lower level while it needs them disabled for communicating with the controller. Finally, since now we can actually spend even virtual time in interrupts-disabled sections, the delay warning when we deliver a time-travel delayed interrupt is no longer valid, things can (and should) now get delayed. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger

um: export signals_enabled directly

2021-06-17T19:44:51+00:00

Use signals_enabled instead of always jumping through a function call to read it, there's not much point in that. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger