Hurray, Houston we have ignition.
We now have working userspace timers.
It is still schizophrenic - userspace is HZ, kernel is NOHZ because the
userpace has to keep checking did the kernel timer fire yet at a HZ
interval. However, even that is a major progress compared to having
userspace timer
Hi Thomas, hi Richard,
It is now possible to reproducibly hang it. I have not been able to
concoct a synthetic test (yet), but a non-synthetic one, namely
installing an update to base-files on Debian is a guaranteed hang. So IO
on itself does not hang it, CPU on itself does not, a mix of two
The likely suspect is arch/um/os-Linux/skas/process.c
It is spinning in the while(1) loop.
However, the current code looks correct and the original code does not
make any sense at least to me:
Original code gets the _VALUE_ of the current userspace itimer() and it
ensures that the signal is
On 11/05/15 18:00, Thomas Meyer wrote:
Hi,
maybe there is a bug in how the timers are created for all user space
processes.
In the latest patch I use os__timer_remain for the initial interval.
The idea was to launch all timers at the same time. But I now think this can
never work using
Hi,
maybe there is a bug in how the timers are created for all user space processes.
In the latest patch I use os__timer_remain for the initial interval.
The idea was to launch all timers at the same time. But I now think this can
never work using relative times, especially when os__timer_remain
On 11/05/15 18:41, Thomas Meyer wrote:
Am 11.05.2015 7:31 nachm. schrieb Anton Ivanov
anton.iva...@kot-begemot.co.uk:
On 11/05/15 18:20, Anton Ivanov wrote:
On 11/05/15 18:00, Thomas Meyer wrote:
Hi,
maybe there is a bug in how the timers are created for all user space
processes.
In the
Am 11.05.2015 9:42 nachm. schrieb Anton Ivanov anton.iva...@kot-begemot.co.uk:
On 11/05/15 18:41, Thomas Meyer wrote:
Am 11.05.2015 7:31 nachm. schrieb Anton Ivanov
anton.iva...@kot-begemot.co.uk:
On 11/05/15 18:20, Anton Ivanov wrote:
On 11/05/15 18:00, Thomas Meyer wrote:
Hi,
Am 10.05.2015 um 16:34 schrieb Thomas Meyer:
Am 10.05.2015 um 14:35 schrieb Richard Weinberger
richard.weinber...@gmail.com:
On Sun, May 10, 2015 at 1:14 AM, Thomas Meyer tho...@m3y3r.de wrote:
Hi,
Changes:
- also create posix timer in stub_clone_handler()
- incorporated antons remarks
Rework UML's uaccess code to reuse as much as possible
from asm-generic/uaccess.c.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/include/asm/thread_info.h | 2 +-
arch/um/include/asm/uaccess.h | 176 ++
arch/um/kernel/skas/uaccess.c |
um_vdso_addr is defined in asm/elf.h.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/x86/um/vdso/vma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/um/vdso/vma.c b/arch/x86/um/vdso/vma.c
index 916cda4..237c683 100644
--- a/arch/x86/um/vdso/vma.c
+++
...for userspace memory access.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/x86/um/ldt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/um/ldt.c b/arch/x86/um/ldt.c
index 5c0b711..9701a4f 100644
--- a/arch/x86/um/ldt.c
+++ b/arch/x86/um/ldt.c
@@ -6,6 +6,7 @@
#include
It's using put_user() and needs this header.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/x86/um/syscalls_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
index adb08eb..e655227 100644
--- a/arch/x86/um/syscalls_64.c
+++
By reusing asm-generic/uaccess.h we can drop a lot of UML's
ad-hoc uaccess code and make it much more straightforward.
It uncovered also some header issues which got resolved.
[PATCH 1/5] um: Cleanup mem_32/64.c headers
[PATCH 2/5] um: Add asm/elf.h to vma.c
[PATCH 3/5] um: Add uaccess.h to
Include only headers we really need.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/x86/um/mem_32.c | 3 +--
arch/x86/um/mem_64.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/x86/um/mem_32.c b/arch/x86/um/mem_32.c
index f40281e..744afdc 100644
---
On 11/05/15 18:20, Anton Ivanov wrote:
On 11/05/15 18:00, Thomas Meyer wrote:
Hi,
maybe there is a bug in how the timers are created for all user space
processes.
In the latest patch I use os__timer_remain for the initial interval.
The idea was to launch all timers at the same time. But I
Am 11.05.2015 7:31 nachm. schrieb Anton Ivanov anton.iva...@kot-begemot.co.uk:
On 11/05/15 18:20, Anton Ivanov wrote:
On 11/05/15 18:00, Thomas Meyer wrote:
Hi,
maybe there is a bug in how the timers are created for all user space
processes.
In the latest patch I use
16 matches
Mail list logo