Download URL:
https://xenomai.org/downloads/ipipe/v5.x/arm64/ipipe-core-5.4.135-arm64-3.patch
Repository: https://git.xenomai.org/ipipe-arm64
Release tag: ipipe-core-5.4.135-arm64-3
Download URL:
https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.198-cip54-arm64-11.patch
Repository: https://git.xenomai.org/ipipe-arm64
Release tag: ipipe-core-4.19.198-cip54-arm64-11
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
kernel/irq/pipeline.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/pipeline.c b/kernel/irq/pipeline.c
index 090fcc8bbb6a449..585bd3b6fae5ef4 100644
--- a/kernel/irq/pipeline.c
+++ b/kernel/irq/pi
From: Philippe Gerum
Conditional irq enabling/disabling helpers must inform the irq tracer
about the change, so that lockdep does not complain about inconsistent
irq state. Fixing up the stall bit using the common
local_irq_enable/disable() helpers ensures this.
CAUTION: we make sure to always h
From: Philippe Gerum
Hard irqs are off when start_kernel() is called from the head code, we
must set the stall accordingly. Failing to do so causes lockdep to
complain, such as:
[0.00] DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled())
[0.00] WARNING: CPU: 0 PID: 0 at kernel/lockin
From: Philippe Gerum
local_irq_save/restore() pairs should be replaced by
local_irq_save_full() calls when pipelining, not
hard_local_irq_save/restore(), so that lockdep does not complain about
inconsistent irq state (the hard_* form does not invoke the trace_irq*
API).
This fixes this kind of s
From: Philippe Gerum
The usual pain with synchronizing the virtual and real interrupt
states. These issues have been detected while porting to v5.14, some
are reported by CONFIG_DEBUG_LOCKDEP=y.
Philippe Gerum (4):
x86/ioapic: irq_pipeline: unbreak irqflags tracing
init: early sync the inban
From: Song Chen
Add a syscall specific for mq_timedsend with 64bit time_t.
Signed-off-by: Song Chen
[Florian: Reformat commit msg, relocate code, tracing, fix compat decl]
Signed-off-by: Florian Bezdeka
---
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/mqueue.c | 23 +++
Extending the test suite for mq_timedsend64() and mq_timedrecv64()
tests.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/y2038/syscall-tests.c | 177 -
1 file changed, 176 insertions(+), 1 deletion(-)
diff --git a/testsuite/smokey/y2038/syscall-tests.c
b/testsuite/
From: Song Chen
Add a syscall specific for mq_timedreceive64 with 64bit time_t.
Signed-off-by: Song Chen
[Florian: Reformat commit msg, relocate code, tracing, fix compat decl]
Signed-off-by: Florian Bezdeka
---
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/mqueue.c | 2
From: Song Chen
If libc reports time64_t support mq_timedreceive is dispatched to the
time64_t based syscall.
Signed-off-by: Song Chen
[Florian: Reformat commit message]
Signed-off-by: Florian Bezdeka
---
lib/cobalt/mq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cobalt/mq.c
From: Song Chen
Dispatch mq_timesend to the 64bit aware syscall if libc reports
time64_t support.
Signed-off-by: Song Chen
[Florian: Rephrase commit message]
Signed-off-by: Florian Bezdeka
---
lib/cobalt/mq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cobalt/mq.c b/lib/cobal
Hi all,
this is kind of a re-send of the patch series originall published by
Song. There were some things that had to be addressed:
- Code formattings
- Copy paste errors in the test suite
- Failing / incomplete tests, missing test cleanups
- Incorrect compat syscall declerations
@Song: Espe
This patch was based on the patch sent out by Song and reworked.
Especially
- switched from CLOCK_MONOTONIC to CLOCK_REALTIME
According to POSIX this service is based on CLOCK_REALTIME
- Fixed some mutex leaks / missing pthread_mutex_destroy()
- Removed some magic numbers used for makin
From: Song Chen
Add a syscall specific for mutex_timedlock with 64bit time_t.
Signed-off-by: Song Chen
[Florian: Rearranged code, coding style fixes, tracing]
Signed-off-by: Florian Bezdeka
---
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/mutex.c| 23
From: Song Chen
In case the libc in use reports a 64 bit time_t dispacht
mutex_timedlock to the kernel entry point that accepts it.
Signed-off-by: Song Chen
Signed-off-by: Florian Bezdeka
---
lib/cobalt/mutex.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/cobalt/mutex.c b/lib/c
The mutex of the smokey_barrier used inside protect_handover() was
never destroyed. This had side effects when trying to extend the test
suite with an additional function that had a mutex located on the same
address than the never cleaned up smokey_barrier lock.
Signed-off-by: Florian Bezdeka
---
According to the POSIX spec the value of the timeout parameter needs
not to be validated if the mutex/semaphore could be taken immediately.
While the implementation of the semaphore timedwait (sem_timedwait())
allowed an invalid timeout pthread_mutex_timedlock() was failing with
-EFAULT in case th
Hi!
This series is based on the series posted by Song some time ago. The
testing part has been heavily reworked. Details are mentioned in the
description of the last patch.
@Jan: Patch 1 and 2 are re-sends. They are not directly related to the
y2038 stuff but the testsuite might fail if they ar
19 matches
Mail list logo
