On Fri, 2023-11-10 at 20:40 +, Anton Ivanov wrote:
> os_munmap already exists as os_munmap_memory
>
Hah, oops. Thanks :)
johannes
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
On 10/11/2023 18:52, Johannes Berg wrote:
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 | 3 +++
arch/
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 memory
So I've been mentioning the shared memory part, but because it
(mechanically, not semantically) depends on the broadcast
messages we use to separate tests, I've included those patches
here as well.
As for the shared memory part, the calendar/controller we have
already implements that protocol, see
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 ++--
ar
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 | 3 +++
arch/um/os-Linux/file.c | 28 ++
From: Mordechay Goodstein
Add a message type to the time-travel protocol to broadcast
a small (64-bit) value to all participants in a simulation.
The main use case is to have an identical message come to
all participants in a simulation, e.g. to separate out logs
for different tests running in a
So I guess now you reminded me of this thread ...
> The Timetravel socket can be read from the SIGIO handler, which may
> catch a RUN message that was expected to be received in the wait loop.
>
> It can happen that the device simulation only "created" one interrupt,
> but an uncertain (i.e., har
On Fri, 2023-11-10 at 16:54 +0100, Benjamin Beichler wrote:
> Am 06.11.2023 um 21:51 schrieb Johannes Berg:
> > On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> > > This slows down external TT-mode as more simulation roundtrips are
> > > required, and it unnecessarily affects the deter
On Fri, 2023-11-10 at 17:23 +0100, Benjamin Beichler wrote:
> Am 06.11.2023 um 21:33 schrieb Johannes Berg:
> >
> >
> > On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
> > > Allow the so called Calendar (or simulation master) to request the
> > > latest
On Fri, 2023-11-10 at 17:53 +0100, Benjamin Beichler wrote:
> >
> > At least in my mental model this is broken because the sender of the
> > event basically has to prepare the calendar for it happening, which
> > feels ... odd.
> Actually, for me, this would make kind of sense.
I'm not sure I ag
Am 06.11.2023 um 21:26 schrieb Johannes Berg:
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
This change permits interrupts on serial lines in time travel mode,
especially in external mode. However, these interrupts are processed
with the simple han
On Fri, 2023-11-10 at 16:54 +0100, Benjamin Beichler wrote:
> At the moment, we haven't patched the random device that fetches random
> bytes from the host (do you already have a patch for this?),
> so complete repeatability isn't guaranteed at the moment. However, that
> could be a logical next
Am 06.11.2023 um 21:33 schrieb Johannes Berg:
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
Allow the so called Calendar (or simulation master) to request the
latest timetravel event. This can be used in situations, where the
former request message
Am 06.11.2023 um 21:51 schrieb Johannes Berg:
On Fri, 2023-11-03 at 16:41 +, Benjamin Beichler wrote:
This slows down external TT-mode as more simulation roundtrips are
required, and it unnecessarily affects the determinism and accuracy of
the simulation.
I still don't think this is really
On Fri, 2023-11-10 at 11:12 +, Anton Ivanov wrote:
>
>
> On 10/11/2023 11:10, Benjamin Berg wrote:
> > Hi,
> >
> > On Fri, 2023-11-10 at 10:56 +, Anton Ivanov wrote:
> > > On 10/11/2023 10:42, Anton Ivanov wrote:
> > > > [SNIP]
> > > >
> > > > If we are going to use this definition of C
On 10/11/2023 11:10, Benjamin Berg wrote:
Hi,
On Fri, 2023-11-10 at 10:56 +, Anton Ivanov wrote:
On 10/11/2023 10:42, Anton Ivanov wrote:
[SNIP]
If we are going to use this definition of CATCH_EINTR throughout we
might as well remove the partial read/write code in UBD and other
places.
Hi,
On Fri, 2023-11-10 at 10:56 +, Anton Ivanov wrote:
> On 10/11/2023 10:42, Anton Ivanov wrote:
> > [SNIP]
> >
> > If we are going to use this definition of CATCH_EINTR throughout we
> > might as well remove the partial read/write code in UBD and other
> > places.
>
> Actually - some of it
From: Benjamin Berg
These registers are saved/restored together with the other general
registers using ptrace. In arch_set_tls we then just need to set the
register and it will be synced back normally.
Most of this logic was introduced in commit f39cf7845 ("[PATCH] uml:
x86_64 thread fixes")
From: Benjamin Berg
These features have existed since Linux 2.6.14 and can be considered
widely available at this point. Also drop the backward compatibility
code for PTRACE_SETOPTIONS.
Signed-off-by: Benjamin Berg
v2:
* Continue to define PTRACE_SYSEMU_SINGLESTEP as glibc only added it
From: Benjamin Berg
The 64bit helper are marked to clobber the memory, but the 32bit ones
are not. Add the appropriate clobber to the 32bit helper routines so
that the compiler cannot do invalid optimizations.
Signed-off-by: Benjamin Berg
---
arch/x86/um/shared/sysdep/stub_32.h | 18 ++
From: Benjamin Berg
The trampoline is running in a cloned process. It is not safe to use
printk for error printing there.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/skas/process.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/um/os-Linux/skas/proc
From: Benjamin Berg
For the detection code to check whether SYSEMU_SINGLESTEP works
correctly we needed some error cases while stopping to be non-fatal.
However, at this point stop_ptraced_child must always succeed, and we
can therefore simplify it slightly to exit immediately on error.
Signed-o
From: Benjamin Berg
When the winch thread runs into an error condition, it would exit(1) and
never be reaped until shutdown time. Change this to write a command byte
which causes the driver to kill it, therefore reaping the child.
Signed-off-by: Benjamin Berg
---
arch/um/drivers/chan_user.c |
From: Benjamin Berg
These functions were only used when calling PTRACE_ARCH_PRCTL, but this
code has been removed.
Signed-off-by: Benjamin Berg
---
arch/um/include/shared/registers.h | 2 --
arch/um/os-Linux/registers.c | 20
2 files changed, 22 deletions(-)
diff -
From: Benjamin Berg
start_userspace is only called from exactly one location, and the passed
pointer for the userspace process stack cannot be NULL.
Remove the check, without changing the control flow.
Signed-off-by: Benjamin Berg
---
arch/um/os-Linux/skas/process.c | 53 +++--
From: Benjamin Berg
The stub executable page is remapped to a different location in the
userland process. As these functions may be used by the stub, they
really need to be always inlined rather than permitting the compiler to
emit a function.
Signed-off-by: Benjamin Berg
---
arch/x86/um/share
From: Benjamin Berg
The threads allocated inside the kernel have only a single page of
stack. Unfortunately, the vfprintf function in standard glibc may use
too much stack-space, overflowing it.
To make os_info safe to be used by helper threads, use the kernel
vscnprintf function into a smallish
From: Benjamin Berg
The thread is running outside of the UML kernel scope and is a helper.
As such, printk cannot work and os_info must be used instead.
Signed-off-by: Benjamin Berg
---
arch/um/drivers/chan_user.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(
From: Benjamin Berg
Hi,
the SECCOMP patchset is not ready yet as I need to change it quite a bit
for the FD passing based security model that was proposed.
Until then, the cleanups and small fixes from the start of the patchset
are still relevant and it could be nice to pull them in anyway. So
On 10/11/2023 10:42, Anton Ivanov wrote:
On 10/11/2023 09:44, benja...@sipsolutions.net wrote:
From: Benjamin Berg
The UM kernel uses signals for various purposes (SIGALRM for scheduling
for example). These signals are interrupts for the UM kernel, which
should not affect file system opera
On 10/11/2023 09:44, benja...@sipsolutions.net wrote:
From: Benjamin Berg
The UM kernel uses signals for various purposes (SIGALRM for scheduling
for example). These signals are interrupts for the UM kernel, which
should not affect file system operations from userspace processes.
Said diffe
From: Benjamin Berg
The UM kernel uses signals for various purposes (SIGALRM for scheduling
for example). These signals are interrupts for the UM kernel, which
should not affect file system operations from userspace processes.
Said differently, in hostfs all operations are directly forwarded to
33 matches
Mail list logo
