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
On Thu, 2024-07-04 at 07:58 +0100, Anton Ivanov wrote:
>
> > +__initcall(register_power_off);
>
> Anton Ivanov
Heh, I thought I saw an Acked-by from you but then patchwork didn't seem
to pick it up, I guess I'll treat it as one anyway? :)
johannes
Hi Anton,
Thanks for taking a look! Also thanks for the other explanation.
On Thu, 2024-07-04 at 08:21 +0100, anton.iva...@cambridgegreys.com
wrote:
> From: Anton Ivanov
>
> UML vector drivers use ring buffer structures which map
> preallocated skbs onto mmsg vectors for use with sendmmsg
> and
From: Johannes Berg
If open fails, we have already set vp->opened, but it's
not reset so that any further attempts will just return
-ENXIO. Reset vp->opened even if close has nothing to do.
This helps e.g. with slirp4netns handling only a single
connection, you can then restart it a
From: Johannes Berg
This lock is useless, all the places that are using
it for some locking will already hold the RTNL. Just
remove it.
Signed-off-by: Johannes Berg
---
v2: remove unused flags variables
---
arch/um/drivers/vector_kern.c | 16 +---
arch/um/drivers/vector_kern.h
From: Johannes Berg
This lock is useless, all the places that are using
it for some locking will already hold the RTNL. Just
remove it.
Signed-off-by: Johannes Berg
---
arch/um/drivers/vector_kern.c | 14 +-
arch/um/drivers/vector_kern.h | 1 -
2 files changed, 1 insertion(+), 14
Lockdep reports a spinlock ordering problem: sometimes we take head_lock
first, sometimes tail_lock, so there's a classic ABBA deadlock possible.
It may not happen now because of UML being single-CPU and all that, but
perhaps with preempt?
Report:
=
From: Johannes Berg
Otherwise we always get
reboot: Power off not available: System halted instead
which is really quite pointless.
Signed-off-by: Johannes Berg
---
arch/um/kernel/reboot.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/um/kernel/reboot.c b/arch
From: Johannes Berg
The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line().
Signed-off-by: Johannes Berg
---
arch/um/drivers/line.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Johannes Berg
We just removed the driver, but forgot the row in the
documentation table mentioning it. Remove that.
Signed-off-by: Johannes Berg
---
Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/virt/uml
On Wed, 2024-07-03 at 11:45 +0200, Johannes Berg wrote:
> On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> > From: Benjamin Berg
> >
> > There should be no need for this.
>
> "should" ;-)
>
> This breaks things if glibc enables r
On Wed, 2024-06-26 at 15:53 +0200, Benjamin Berg wrote:
>
> +choice
> + prompt "Pagetable levels"
> + default 2_LEVEL_PGTABLES if !64BIT
> + default 4_LEVEL_PGTABLES if 64BIT
> +
> + config 2_LEVEL_PGTABLES
> + bool "Two-level pagetables" if !64BIT
> + depen
From: Johannes Berg
When signals are hard-blocked in order to do time-travel
socket processing, we set signals_blocked and then handle
SIGIO signals by setting the SIGIO bit in signals_pending.
When unblocking, we first set signals_blocked to 0, and
then handle all pending signals. We have to
From: Johannes Berg
This function is unused and unneeded, remove it.
Signed-off-by: Johannes Berg
---
arch/um/kernel/time.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index d44eaad53d9d..47b9f5e63566 100644
--- a/arch/um/kernel
On Wed, 2024-07-03 at 12:08 +0200, Benjamin Berg wrote:
> On Wed, 2024-07-03 at 11:45 +0200, Johannes Berg wrote:
> > On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> > > From: Benjamin Berg
> > >
> > > There should be no need for thi
On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> From: Benjamin Berg
>
> There should be no need for this.
"should" ;-)
This breaks things if glibc enables rseq. That might even be already
broken in the sense that it might corrupt memory that's put at the same
place the rse
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c | 23
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
v3: fix print format
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
On Tue, 2024-07-02 at 10:25 +0200, Johannes Berg wrote:
> From: Anton Ivanov
>
> Since userspace state is saved in the MM process, kernel using
> FPU still doesn't really need to do anything, so this really
> is as simple as enabling preemption. The irq critical sectio
On Tue, 2024-07-02 at 12:18 +0200, Johannes Berg wrote:
>
> We have 40 patches in patchwork now, including the 7 64-bit address
> space ones from Benjamin where I think some rework is needed. I've
> rebased/applied the other 33, I've just pushed that to the 'pe
On Tue, 2024-07-02 at 11:07 +0100, Anton Ivanov wrote:
>
>
> Is that all we have left?
I think so, yes.
> I lost track of your mm patches and they do not apply cleanly to master at
> present.
Mine actually mostly went away, in favour of Benjamin's, but his also
didn't apply cleanly due to th
vanov
[vastly simplify, fix x86/um Makefile, rewrite commit message]
Signed-off-by: Johannes Berg
---
v10:
- rebase on top of various other patchsets, including Benjamin's
page table updates:
https://patchwork.ozlabs.org/project/linux-um/list/?series=408104
- fix x86/um Makefile
- remov
On Tue, 2024-07-02 at 09:24 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> dev_t is a kernel type and may have different definitions
> in kernel and userspace. On 32-bit x86 this currently makes
> the stat structure being 4 bytes longer in the user code,
> causin
From: Johannes Berg
dev_t is a kernel type and may have different definitions
in kernel and userspace. On 32-bit x86 this currently makes
the stat structure being 4 bytes longer in the user code,
causing stack corruption.
However, this is (potentially) not the only problem, since
dev_t is a
From: Johannes Berg
dev_t is a kernel type and may have different definitions
in kernel and userspace. On 32-bit x86 this currently makes
the stat structure being 4 bytes longer in the user code,
causing stack corruption. Just use 'unsigned int' so the
same size is used.
Signed-off-by
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c | 23
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
v3: fix print format
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
--
v2: drop os_munmap()
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers/xterm_kern.c | 13
From: Johannes Berg
When signals are hard-blocked in order to do time-travel
socket processing, we set signals_blocked and then handle
SIGIO signals by setting the SIGIO bit in signals_pending.
When unblocking, we first set signals_blocked to 0, and
then handle all pending signals. We have to
On Wed, 2024-06-26 at 15:53 +0200, Benjamin Berg wrote:
>
> +static int __init init_stub_exec_fd(void)
> +{
> + size_t len = 0;
> + int res;
> + char tmpfile[] = "/tmp/uml-userspace-XX";
That seems awkward, perhaps it should use make_tempfile() from mem.c?
> + stub_e
From: Johannes Berg
We can select ARCH_HAS_UBSAN, it works just fine. It had been
enabled and we even used it, but then commit 890a64810d59
("ubsan: Restore dependency on ARCH_HAS_UBSAN") (correctly)
disabled it again, enable ARCH_HAS_UBSAN to get it.
Signed-off-by: Johannes Berg
--
On Mon, 2024-07-01 at 19:55 +0100, Anton Ivanov wrote:
> >
> As Benjamin pointed out we no longer need this, so we can junk this
> patch at this point. If there will be any need to save/restore FPU in
> kernel context, I will revisit it.
I think we still want/need the parts with the preempt_dis
On Mon, 2024-07-01 at 17:56 +0200, Johannes Berg wrote:
> Hmm. I also see a ton of this:
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rwsem.c:1525
> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 538, name:
> chan-switch.sh
> preempt_
Hmm. I also see a ton of this:
BUG: sleeping function called from invalid context at
kernel/locking/rwsem.c:1525
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 538, name: chan-switch.sh
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
no locks held by chan-switch.sh/538.
irq e
> arch/um/Kconfig | 2 +-
> arch/um/include/asm/fpu/api.h | 9 ++--
> arch/um/include/asm/thread_info.h | 4 +-
> arch/um/kernel/Makefile | 4 ++
> arch/um/kernel/fpu.c | 71 +++
> arch/um/kernel/irq.c | 2
On Wed, 2024-06-05 at 19:59 +0200, Ard Biesheuvel wrote:
>
> > > -ifdef CONFIG_X86_64
> > > +ifneq ($(or $(CONFIG_X86_64),$(CONFIG_X86_32)),)
> >
> > These configurations are mutually exclusive, so would it look more
> > readable to have it be:
> >
> >
> > ifeq ($(CONFIG_X86_32)$(CONFIG_X86_64)
On Tue, 2024-05-28 at 18:16 +0800, Tiwei Bie wrote:
> On 5/28/24 4:54 PM, benja...@sipsolutions.net wrote:
> > From: Benjamin Berg
> >
> > Newer glibc versions are enabling rseq support by default. This remains
> > enabled in the cloned child process, potentially causing the host kernel
> > to wr
On Mon, 2024-05-13 at 14:58 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > > > On Mon, 2024-05-13 at 14
On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > Disable UBSAN sanitization o
On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Disable UBSAN sanitization on UML, since UML does not support it.
>
Luckily, that isn't actually true, nor does it actually do this at all.
Please fix the commit message.
johannes
1 - 100 of 285 matches
Mail list logo
