uot;User-Mode Linux Host filesystem");
MODULE_LICENSE("GPL");
---
base-commit: 1dfe225e9af5bd3399a1dbc6a4df6a6041ff9c23
change-id: 20240702-md-um-fs-hostfs-fa6ebcf75249
@@ -49,6 +49,7 @@
#include "mconsole.h"
#include "harddog.h"
+MODULE_DESCRIPTION("UML hardware watchdog");
MODULE_LICENSE("GPL");
static DEFINE_MUTEX(harddog_mutex);
---
base-commit: 1dfe225e9af5bd3399a1dbc6a4df6a6041ff9c23
change-id: 20240702-md-um-arch-um-drivers-a84a42d077b5
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: 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
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/xterm
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
Maybe a bit pedantic, but this dot should be part of the other patch ;-)
Am 01.07.2024 um 23:31 schrieb Johannes Berg:
@@ -124,7 +145,8 @@ enum um_timetravel_ops {
*/
UM_TIMETRAVEL_GET_TOD = 8,
- /** @UM_TIMETRAVEL_BROADCAST: Send/Receive a broadcast messge
+
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 section
> in sigio_handler() needs
On 02/07/2024 11:18, Johannes Berg wrote:
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
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 'pending'
> branch:
>
> https://git.ker
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
On 02/07/2024 09:25, 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 section
in sigio_handler() needs preempt_disable()/pr
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 section
in sigio_handler() needs preempt_disable()/preempt_enable().
Signed-off-by: Anton Ivanov
[
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,
> causing stack corruption.
>
> Ho
On Mon, Jul 01, 2024 at 04:22:19PM +0800, Oliver Sang wrote:
> from below, it seems the patchset doesn't introduce any performance
> improvement
> but a regression now. is this expected?
Not having the improvement at least alleviate my concerns about data
integrity. I'm still curious where it co
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 diff
16 matches
Mail list logo
