On Fri, 2025-05-09 at 11:50 +0200, Christian Lamparter wrote:
>
> What's interessting/very strange strange about this time-travel stuff:
> > commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not
> > yield")
>
> $ git describe 0b8b2668f998
> => v6.12-rc2-43-g0b8b2668f998
>
C
On Fri, 2025-05-09 at 11:50 +0200, Christian Lamparter wrote:
>
> What's interessting/very strange strange about this time-travel stuff:
> > commit 0b8b2668f998 ("um: insert scheduler ticks when userspace does not
> > yield")
>
> $ git describe 0b8b2668f998
> => v6.12-rc2-43-g0b8b2668f998
> (fr
Patch attached, does this look good to you?
Yeah looks good to me. Common gotcha really.
Reviewed-by: Johannes Berg
If anyone _really_ needs to have this driver built on UML (say for
simulations/testing, we do build iwlwifi for all the time), then they'd
probably want to replace the rdtsc
On Wed, 2025-05-07 at 15:38 -0600, Shuah Khan wrote:
> My workflow:
>
> - Build kernel on x86_64 with CONFIG_AMD_MEM_ENCRYPT enabled
>
> - Check for arch/x86/realmode/rm/pasyms.h
>ls arch/x86/realmode/rm/pasyms.h
> arch/x86/realmode/rm/pasyms.h
>
> - make ARCH=um O=/linux/build
>
>
+linux-um
On Wed, 2025-05-07 at 18:40 +, tip-bot2 for Ingo Molnar wrote:
>
> To resolve these kinds of problems and to allow to be included on
> UML,
> add a simplified version of , which only adds the rdtsc()
> definition.
OK, weird, why would that be needed - UM isn't really X86.
> ar
e SUBARCH directory.
Do you want to take that through your tree? I'm not sure we'd get it
into 6.15 at this point via uml, if you have some other material feel
free to take it:
Acked-by: Johannes Berg
Otherwise we can take it via uml tree for 6.16 too, let us know.
johannes
Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202505070045.vwc04ygs-...@intel.com/
> Signed-off-by: Herbert Xu
Acked-by: Johannes Berg
johannes
From: Johannes Berg
Since this is called deep in the ARCH=um IRQ infrastructure
it must use a raw spinlock. It's not really part of the
driver, but rather the core UML IRQ code.
Signed-off-by: Johannes Berg
---
arch/um/drivers/chan_kern.c | 10 +-
1 file changed, 5 insertions(
h changes up to 68025adfc13e6cd15eebe2293f77659f47daf13b:
um: fix _nofault accesses (2025-05-05 10:06:51 +0200)
A single fix for _nofault infrastructure.
----
Johannes Berg (1)
On Fri, 2025-05-02 at 10:08 +0100, Anton Ivanov wrote:
>
> On 02/05/2025 09:35, Thomas Meyer wrote:
> > Hi,
> >
> > Aren't those drivers under exactly this folder because those drivers will
> > work only with when the host OS is Linux? I mean this is all hypothetical
> > but when somebody is go
On Tue, 2025-04-29 at 14:23 +0100, Lorenzo Stoakes wrote:
> Thanks, appreciate the response. I would say send a v8 that's rebased to
> make life easier for maintainers :) if you already have it ready to go that
> is!
There probably haven't been that many patches since, but I guess why not
:)
I wa
David Gow (1):
um: Pass the correct Rust target and options with gcc
Ethan Carter Edwards (1):
um: use str_yes_no() to remove hardcoded "yes" and "no"
Hajime Tazaki (1):
um: x86: clean up elf specific definitions
Johannes Berg (1):
um: mark rodata rea
;
Hajime Tazaki (1):
um: x86: clean up elf specific definitions
Johannes Berg (1):
um: mark rodata read-only and implement _nofault accesses
Tiwei Bie (8):
um: Allocate vdso page pointer statically
um: Update min_low_pfn to match changes in uml_reserved
um: virt-pc
On Thu, 2025-03-06 at 23:07 +0800, Tiwei Bie wrote:
> Introduce a new set of utility functions that can be used to create
> pthread-based helpers. Helper threads created in this way will ensure
> thread safety for errno while sharing the same memory space.
I'm not sure at the moment exactly what t
From: Johannes Berg
Nathan reported [1] that when built with clang, the um kernel
crashes pretty much immediately. This turned out to be an issue
with the inline assembly I had added, when clang used %rax/%eax
for both operands. Reorder it so current->thread.segv_continue
is written first,
On Thu, 2025-04-03 at 12:19 -0700, Nathan Chancellor wrote:
>
> Thanks, I applied that change, which shows a slightly different crash
> message now:
Pretty sure it's all just a bug in my inline assembly, and clang
allocates registers differently:
#define ___backtrack_faulted(_faulted)
On Wed, 2025-03-19 at 21:55 +0800, Tiwei Bie wrote:
> Directly creating helper threads with VM_CLONE using clone can
> compromise the thread safety of errno. Since all these helper
> threads have been converted to use os_run_helper_thread(), let's
> prevent using this flag in run_helper_thread().
>
On Wed, 2025-03-26 at 14:54 +0800, Tiwei Bie wrote:
> On 2025/3/20 16:32, Johannes Berg wrote:
> > On Wed, 2025-03-19 at 21:55 +0800, Tiwei Bie wrote:
> > > Directly creating helper threads with VM_CLONE using clone can
> > > compromise the thread safety of er
On Sun, 2025-03-16 at 00:19 +0800, Tiwei Bie wrote:
> Implement a new virtual PCI driver based on the VFIO framework.
> This driver allows users to pass through PCI devices to UML via
> VFIO. Currently, only MSI-X capable devices are supported, and
> it is assumed that drivers will use MSI-X.
Seem
On Mon, 2025-02-24 at 19:18 +0100, Benjamin Berg wrote:
>
> -static void handle_segv(int pid, struct uml_pt_regs *regs)
> -{
> - get_skas_faultinfo(pid, ®s->faultinfo);
> - segv(regs->faultinfo, 0, 1, NULL);
> -}
>
This, and below, no longer applies due to the other segv() changes. Easy
On Tue, 2025-03-18 at 14:06 +0100, Johannes Berg wrote:
> On Thu, 2025-03-06 at 23:07 +0800, Tiwei Bie wrote:
> > Introduce a new set of utility functions that can be used to create
> > pthread-based helpers. Helper threads created in this way will ensure
> > thread safety fo
On Thu, 2025-03-06 at 23:07 +0800, Tiwei Bie wrote:
> Introduce a new set of utility functions that can be used to create
> pthread-based helpers. Helper threads created in this way will ensure
> thread safety for errno while sharing the same memory space.
Using pthreads seemed odd, but Benjamin a
em, which would
> be nice.
I was just picking up um patches, but given that it was a series, and
changes rust/ rather than arch/um/, I think it's probably better if you
do it, so:
Acked-by: Johannes Berg
johannes
On Fri, 2025-03-14 at 08:10 +0100, Thomas Huth wrote:
> While the GCC and Clang compilers already define __ASSEMBLER__
> automatically when compiling assembly code, __ASSEMBLY__ is a
> macro that only gets defined by the Makefiles in the kernel.
> This can be very confusing when switching between u
On Tue, 2025-02-18 at 15:27 -0500, Sasha Levin wrote:
> From: Johannes Berg
>
> [ Upstream commit 5b166b782d327f4b66190cc43afd3be36f2b3b7a ]
>
> This code can be called deep in the IRQ handling, for
> example, and then cannot normally use kmalloc(). Have
> its own pre-all
From: Johannes Berg
This is needed because at least in time-travel the code
can be called directly from the deep architecture and
IRQ handling code.
Signed-off-by: Johannes Berg
---
arch/um/drivers/virtio_uml.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch
From: Johannes Berg
This code can be called deep in the IRQ handling, for
example, and then cannot normally use kmalloc(). Have
its own pre-allocated memory and use from there instead
so this doesn't occur. Only in the (very rare) case of
memcpy_toio() we'd still need to allocate memor
From: Johannes Berg
Since this is deep in the architecture, and the code is
called nested into other deep management code, this really
needs to be a raw spinlock. Convert it.
Signed-off-by: Johannes Berg
---
arch/um/kernel/irq.c | 79 ++--
1 file
Some locks changed to be raw, and we now need to also
do that across UML.
johannes
On Thu, 2024-12-05 at 22:56 +0900, Hajime Tazaki wrote:
>
> > > +++ b/arch/x86/um/asm/processor.h
> > > @@ -38,6 +38,18 @@ static __always_inline void cpu_relax(void)
> > >
> > > #define task_pt_regs(t) (&(t)->thread.regs)
> > >
> > > +#ifndef CONFIG_MMU
> > > +#define task_top_of_stack(task)
On Thu, 2024-12-05 at 22:51 +0900, Hajime Tazaki wrote:
> >
> > I don't understand why this behaves differently with and without
> > zpoline, it seems it shouldn't need to. Anyway, still think zpoline is
> > future work.
>
> I will remove the zpoline part.
> When zpoline is used, SIGSYS signal is
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +static int os_x86_arch_prctl(int pid, int option, unsigned long *arg2)
> +{
> + if (host_has_fsgsbase) {
> + switch (option) {
> + case ARCH_SET_FS:
> + wrfsbase(*arg2);
> +
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/um/kernel/process.c
> @@ -117,13 +117,17 @@ void new_thread_handler(void)
>* callback returns only if the kernel thread execs a process
>*/
> fn(arg);
> +#ifndef CONFIG_MMU
> + arch_switch_to(current);
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +#ifndef CONFIG_MMU
> +extern int um_zpoline_enabled;
> +#endif
That doesn't make sense, there's no good reason these two mechanisms
need to be mutually exclusive.
I think you should leave out zpoline initially, get all the other stuff
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
> This commit adds a mechanism to hook syscalls for unmodified userspace
> programs used under UML in !MMU mode. The mechanism, called zpoline,
>
I think you should just leave this out of the first version entirely.
johannes
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
> This commit introduces an entry point of syscall interface for !MMU
> mode. It uses an entry function, __kernel_vsyscall, a kernel-wide global
> symbol accessible from any locations.
>
> Although it isn't in the scope of this commit, it can
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/um/include/asm/futex.h
> @@ -8,7 +8,11 @@
>
>
> int arch_futex_atomic_op_inuser(int op, u32 oparg, int *oval, u32 __user
> *uaddr);
> +#ifdef CONFIG_MMU
> int futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
>
On Tue, 2024-12-03 at 13:23 +0900, Hajime Tazaki wrote:
>
> arch/um/include/asm/Kbuild | 1 +
>
> arch/x86/um/asm/module.h | 24
>
These changes could be a separate cleanup?
johannes
On Tue, 2024-12-03 at 13:22 +0900, Hajime Tazaki wrote:
> This is a series of patches of nommu arch addition to UML.
Please next time you resend this, don't hide it in the old thread :)
johannes
Hi,
> > I'd argue though that this doesn't count as fixing the regression, since
> > the kernel was fine before the changes there (even before porting hostfs
> > to the new API) with _any_ version of userspace. Except perhaps for when
> > there's a comma in the path, which I suppose would've broke
Let me try to unify the threads, and perhaps further my understanding -
you seem to already have much more of that than me :)
> > > But this is still a regression, so we need to figure out what to do
> > > short term?
> > >
> > So for short term, even long term, can we consider handling the hostf
On Mon, 2024-11-25 at 18:43 +0100, Karel Zak wrote:
>
> The long-term solution would be to clean up hostfs and use named
> variables, such as "mount -t hostfs none -o 'path="/home/hostfs"'.
That's what Hongbo's commit *did*, afaict, but it is a regression.
Now most of the regression is that with
On Fri, 2024-11-22 at 09:33 +, Lorenzo Stoakes wrote:
>
> In general, while I appreciate your work and don't mean to be negative, we
> in mm consistently have problems with nommu as it is a rarely-tested
> more-or-less hack used for very few very old architectures and a constant
> source of pr
On Mon, 2024-11-11 at 15:27 +0900, Hajime Tazaki wrote:
> This is a series of patches of nommu arch addition to UML. It would
> be nice to ask comments/opinions on this.
So I've been thinking about this for a while now...
To be clear, I'm not really _against_ it. With around 1200 lines of
code,
On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
>
> > > > - depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > + depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA)
> > > > && !MMU)
> > >
> > > s/UML/X86/?
> >
> > I guess the fdpic loader
(sorry, fat-fingered that)
On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> >
> > > > > - depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) &&
> > > > > !MMU)
>
k it up? Or should we
pick it up via um, but then likely only for 6.13?
If you could pick it up:
Acked-by: Johannes Berg
johannes
On Sun, 2024-11-03 at 22:28 +0100, Benjamin Berg wrote:
> From: Benjamin Berg
>
> It appears that the different vhost device implementations use different
> sizes of the virtual queues. Add device specific limitations (for now,
> only for sound), to ensure that we do not get disconnected unexpect
On Thu, 2024-11-07 at 22:17 +0800, Hongbo Li wrote:
> > There's only one option anyway, so I'd think we just need to fix this
> > and not require the hostfs= key. Perhaps if and only if it starts with
> > hostfs= we can treat it as a key, otherwise treat it all as a dir? But I
>
> May be we can do
Hi,
So took me a while to grok the context, and to understand why it was
working for me, and broken on another machine...
> I have read the context in [1]. It seems your tool has already used new
> mount api to mount the hostfs.
Yes, however, that's a default that's entirely transparent to the
On Wed, 2024-10-30 at 15:26 +0800, Shaojie Dong wrote:
> free_pages() performs a parameter null check inside
> therefore remove double zero check here.
>
Ok, so, I get it, you want to make some cleanup - but you've just send
pretty much the same patch *six* times (although most of them were
incor
On Sat, 2024-10-26 at 16:36 +0900, Hajime Tazaki wrote:
>
> Originally our patchset had a whitelist-based seccomp filter (w/
> SCMP_ACT_ALLOW), but dropped from this RFC as I found that 1) this is
> not the !MMU specific feature (it can be generally applied to all UML
> use cases), and 2) we canno
On Sat, 2024-10-26 at 13:04 +0200, Benjamin Berg wrote:
> > >
> > > +#include
> >
> > Hmm. If this works, why do we have UML_CONFIG_64BIT? For ASM stuff?
>
> So, I just had a quick look. It seems that before commit a95b37e20db9
> ("kbuild: get out of ") doing
> this would have caused compilat
On Sat, 2024-10-26 at 20:59 +1300, Paulo Miguel Almeida wrote:
>
> when I said that "umid is already generated during make_umid_init
> __initcall", from my humble point of view, I was explaining the 'why'
> using UMID_LEN for calculation buffer sizes was redundant. Then again,
> once we know the s
On Sat, 2024-10-26 at 16:46 +1300, Paulo Miguel Almeida wrote:
> umid is already generated during make_umid_init __initcall so there is
> no need to allocate UMID_LEN bytes to accommodate the max possible name
> for the umid segment of the filepath
>
> This patch replaces UMID_LEN occurences in wh
On Fri, 2024-10-25 at 22:05 +0900, Hajime Tazaki wrote:
> On Fri, 25 Oct 2024 18:33:06 +0900,
> Johannes Berg wrote:
> >
> > On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > >
> > > config MMU
> > > - bool
> > > + bool "M
On Fri, 2024-10-25 at 22:27 +0900, Hajime Tazaki wrote:
>
> On Fri, 25 Oct 2024 18:28:01 +0900,
> Johannes Berg wrote:
> >
> > On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > >
> > > +static void sigill(int sig, siginfo_t *si, void *ctx_v
On Fri, 2024-10-25 at 21:58 +0900, Hajime Tazaki wrote:
>
> > > + if (down_write_killable(&mm->mmap_lock)) {
> > > + err = -EINTR;
> > > + return err;
> >
> > ?
>
> the lock isn't needed actually so, will remove it.
Oh, I was just looking at the weird handling of the err variabl
On Fri, 2024-10-25 at 21:55 +0900, Hajime Tazaki wrote:
> >
> > Should that really do _nothing_? Perhaps it's not called at all in no-
> > MMU, but then you don't need it, but otherwise it seems it should do
> > something even if it's just panic()?
>
> it is called also in !MMU. I'll think to fi
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> This commit adds a mechanism to hook syscalls for unmodified userspace
> programs used under UML in !MMU mode. The mechanism, called zpoline,
> translates syscall/sysenter instructions with `call *%rax`, which can be
> processed by a trampol
On Thu, 2024-10-24 at 22:28 +0800, Tiwei Bie wrote:
> The ubd io and write_sigio threads/processes may leak e.g. when
> the main process is killed by "kill -9". Fix it by setting the
> parent-death signal for them.
>
I always used killall, but yeah, good idea, thanks!
johannes
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> config MMU
> - bool
> + bool "MMU-based Paged Memory Management Support"
> default y
"if !64bit" or something
> config UML_DMA_EMULATION
> @@ -187,8 +190,14 @@ config MAGIC_SYSRQ
> The keys are documented in
>
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> This commit updates the behavior of signal handling under !MMU
> environment. 1) the stack preparation for the signal handlers and
> 2) retoration of stack after rt_sigreturn(2) syscall. Those are
typo: restoration
> @@ -562,6 +574,20 @@
> oom:
> - printk(KERN_ERR "Cannot allocate vdso\n");
> + pr_err("Cannot allocate vdso");
kind of unrelated change
johannes
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +static void sigill(int sig, siginfo_t *si, void *ctx_void)
> +{
> + longjmp(jmpbuf, 1);
> +}
Should this code use sigsetjmp/siglongjmp?
> +int os_has_fsgsbase(void)
> +{
> + return has_fsgsbase;
> +}
Why should this be a funct
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> Since ptrace facility isn't used under !MMU of UML, there is different
> code path to invoke proceeses/threads; on an entry to the syscall
typo: processes
> /* Called magically, see new_thread_handler above */
> static void fork_handler(
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/x86/um/do_syscall_64.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifndef CONFIG_MMU
This seems unnecessary, you don't build the file w
(I should say, I'm still reading through this, and haven't formed an
overall opinion. Just nitpicking on the details as I see them for now)
> +#endif
> +
>
> #include
extra newline
> /* tlb.c */
> +#ifdef CONFIG_MMU
> extern void report_enomem(void);
> +#else
> +static inline void report_e
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +#ifndef CONFIG_MMU
> +#include
Not sure that makes so much sense in the middle of the file, no harm
always having it?
>
> +static inline const struct user_regset_view *task_user_regset_view(
> + struct task_struct *task)
What hap
From: Johannes Berg
CONFIG_GCOV is special and only in UML since it builds the
kernel with a "userspace" option. This is fine, but the stub
is even more special and not really a full userspace process,
so it then fails to link as reported.
For good measure, also remove the GPROF opt
permit userspace to
> decode the frame.
>
> As a side effect, this will permit UML to run on hosts with newer CPU
> extensions (such as AMX) that need even more register state.
>
> Signed-off-by: Benjamin Berg
>
> ---
>
> v3:
> * Fix FP register initializatio
From: Johannes Berg
Since __attribute__((naked)) cannot be used with functions
containing C statements, just generate the few instructions
it needs in assembly directly.
While at it, fix the stack usage ("1 + 2*x - 1" is odd) and
document what it must do, and why it must adjust
ce it.
However I was just playing with the below - was just looking at the size
though, but what do you think?
johannes
>From 57c5a80a4db2de33a11a5a20fcbea8f3643844f5 Mon Sep 17 00:00:00 2001
From: Johannes Berg
Date: Tue, 22 Oct 2024 11:48:21 +0200
Subject: [PATCH] um: make stub_exe _start
On Sat, 2024-10-19 at 13:54 +0800, David Gow wrote:
>
> Okay, it turns out this breaks clang:
> arch/um/kernel/skas/stub_exe.c:84:2: error: non-ASM statement in naked
> function is not supported
Fun :)
Interesting too, I've _definitely_ got some code elsewhere, that's
usually compiled with clang
On Thu, 2024-10-17 at 15:17 +0800, David Gow wrote:
> It turns out that this breaks the KUnit user alloc helpers on x86_64,
> at least on my machine.
Yay, second bug from this ;-)
> This can be reproduced with:
> ./tools/testing/kunit/kunit.py run usercopy
>
> Though the 32-bit version works:
>
Hi Tiwei,
So kind of a nit, but if the resulting code looks like this:
> @@ -184,17 +172,14 @@ static inline pte_t pte_wrprotect(pte_t pte)
> {
> if (likely(pte_get_bits(pte, _PAGE_RW)))
> pte_clear_bits(pte, _PAGE_RW);
> return pte;
> }
then the if really isn't neede
From: Johannes Berg
Mark read-only data actually read-only (simple mprotect), and
to be able to test it also implement _nofault accesses. This
works by setting up a new "segv_continue" pointer in current,
and then when we hit a segfault we change the signal return
context so that we c
From: Johannes Berg
This was perhaps intended to do _nofault copies, but the
real reason is lost to history. Remove this, it's not
needed, and using longjmp() out of the middle of the
signal handler with all the state it has modified is
not going to be a good idea anyway.
Signed-o
From: Johannes Berg
After the execve() to disable ASLR, comm is now "exe",
which is a bit confusing. Use readlink() to get this
to the right name again.
Disable stack frame size warnings on main.o since it's
part of the initial userspace and can use larger stack.
Fixes: 68
On Wed, 2024-09-25 at 22:32 +0200, Benjamin Berg wrote:
>
> --- /dev/null
> +++ b/arch/x86/um/shared/sysdep/stub-data.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
That new file should possibly have double-include guards as common.
Can we use #pragma once yet? ;)
> +static __al
On Wed, 2024-09-25 at 22:32 +0200, Benjamin Berg wrote:
>
> + /*
> + * If in seccomp mode, install the SECCOMP filter and trigger a syscall.
> + * Otherwise set PTRACE_TRACEME and do a SIGSTOP.
> + */
> + if (init_data.seccomp) {
> + struct sock_filter filter[] =
On Wed, 2024-09-25 at 22:32 +0200, Benjamin Berg wrote:
>
> Fix this issue using a new IRQ that is fired after a SIGCHLD and keeping
> an (internal) list of all MMs.
Maybe that would be nicer with an xarray indexed by pid?
The list could get quite long I suppose?
johannes
On Wed, 2024-09-25 at 22:32 +0200, Benjamin Berg wrote:
> Add the UML_SECCOMP configuration options. The next commits will add the
> support itself in smaller chunks.
>
> Only x86_64 will be supported for now.
>
> Signed-off-by: Benjamin Berg
> Signed-off-by: Benjamin Berg
> ---
> arch/um/Kcon
On Mon, 2024-10-07 at 09:49 +0200, Julian Vetter wrote:
>
> > > The um arch is the only architecture that sets the config 'NO_IOMEM',
(you did note this, for the comment below)
> No, I think you're understanding the series correctly. It doesn't work.
> I will revert this.
OK.
> > You're addin
On Mon, 2024-09-30 at 15:23 +0200, Julian Vetter wrote:
> The um arch is the only architecture that sets the config 'NO_IOMEM',
> yet drivers that use IO memory can be selected. In order to make these
> drivers happy we add a dummy implementation for memcpy_{from,to}io and
> memset_io functions.
M
On Wed, 2024-09-18 at 14:17 +0800, Tiwei Bie wrote:
> The highmem support has been removed by commit a98a6d864d3b ("um:
> Remove broken highmem support"). The 2-level page table is sufficient
> on UML/i386 now. Remove the 3-level page table support on UML/i386
> which is still marked as experimenta
On Wed, 2024-09-04 at 15:50 +0200, Gabriele Monaco wrote:
> While building for KUnit with default settings, the build is generating
> the following compilation warnings.
>
> ```
> $ make ARCH=um O=.kunit --jobs=16
> ../lib/iomap.c:156:5: warning: no previous prototype for
> ‘ioread64_lo_hi’ [-Wmis
On Tue, 2024-09-03 at 18:14 +0100, Jiaxun Yang wrote:
>
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -32,6 +32,7 @@ config UML
> select TTY # Needed for line.c
> select HAVE_ARCH_VMAP_STACK
> select HAVE_RUST
> + select HAVE_GENERATE_RUST_TARGET if X86_32 || X86_64
>
On Mon, 2024-08-19 at 11:46 -0700, Maciej Żenczykowski wrote:
> On Mon, Aug 19, 2024 at 5:23 AM Johannes Berg
> wrote:
> >
> > On Tue, 2024-08-13 at 16:47 -0700, Maciej Żenczykowski wrote:
> > > Without this patch:
> > > #!/usr/bin/python3
>
From: Johannes Berg
The schedule() call there really never did anything at
least since the introduction of the EEVDF scheduler,
but now I found a case where we permanently hang in a
loop of -ERESTARTNOINTR (due to locking.) Work around
it by making any syscalls with error return take time
(and
On Tue, 2024-08-13 at 16:47 -0700, Maciej Żenczykowski wrote:
> Without this patch:
> #!/usr/bin/python3
> import ctypes
> import os
> personality = ctypes.CDLL(None).personality
> personality.restype = ctypes.c_int
> personality.argtypes = [ctypes.c_ulong]
> PER_LINUX32=8
> persona
From: Johannes Berg
There's no such symbol and we currently don't have any of the
mechanisms to make boot-time selection cheap enough, so we can't
have HAVE_PREEMPT_DYNAMIC_CALL or HAVE_PREEMPT_DYNAMIC_KEY.
Remove the select statement.
Reported-by: Lukas Bulwahn
Fixes: cd
On Thu, 2024-07-04 at 21:16 +0100, Anton Ivanov wrote:
> > > - qi->queue_depth = 0;
> > > + wmb(); /* Ensure that RX processing elsewhere sees the changes */
> > > + atomic_set(&qi->queue_depth, 0);
> > > }
> > I don't understand this.
> >
> > prep_queue_for_rx() is called by vector_mmsg_rx(),
On Thu, 2024-07-04 at 18:27 +0200, Benjamin Berg wrote:
> From: Benjamin Berg
>
> With the change to use execve() we can now safely clear the memory up to
> STUB_START as rseq will not be trying to use memory in that region. Also,
> on 64 bit the previous changes should mean that there is no usab
On Thu, 2024-07-04 at 18:27 +0200, Benjamin Berg wrote:
>
> + /* set a nice name */
> + stub_syscall2(__NR_prctl, PR_SET_NAME, (unsigned long)"uml-userspace");
Is that even needed when you're passing it as argv[0] in execve()? But
whatever, it's fine, just wondering.
> + /* setup sig
On Thu, 2024-07-04 at 13:22 +0100, anton.iva...@cambridgegreys.com
wrote:
>
> @@ -675,11 +657,20 @@ static void prep_queue_for_rx(struct vector_queue *qi)
> struct vector_private *vp = netdev_priv(qi->dev);
> struct mmsghdr *mmsg_vector = qi->mmsg_vector;
> void **skbuff_vector =
From: Johannes Berg
When generalizing this, I was in the mindset of this being
"userspace" code, but even there we should not use variable
arrays as the kernel is moving away from allowing that.
Simply reserve (but not use) enough space for the maximum
two descriptors we might nee
On Thu, 2024-07-04 at 11:55 +0200, Johannes Berg wrote:
> On Thu, 2024-07-04 at 10:52 +0100, Anton Ivanov wrote:
> > >
> > > There is an extra issue there - stats. I need to double-check the locking
> > > when
> > > they are being fetched.
> >
>
On Thu, 2024-07-04 at 10:52 +0100, Anton Ivanov wrote:
> >
> > There is an extra issue there - stats. I need to double-check the locking
> > when
> > they are being fetched.
>
> Same story - these need atomics. Otherwise we can potentially get the same
> ABBA
> lock issue when they are being fe
On Thu, 2024-07-04 at 10:45 +0100, Anton Ivanov wrote:
> > (it probably also never even executes twice unless you actually have SMP
> > or preemption?)
>
> It does. If half of the vector is at the end of the array which is used to
> imitate a ring buffer and the other half is at the beginning. Qu
1 - 100 of 331 matches
Mail list logo
