Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we c
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new introd
Hi all,
this is the backport of the previously published FPU testing cleanup
series to the stable/3.0.x branch.
Patch 1 has been updated to match the supported architectures in the
3.0.x stable branch, Patch 2 is unmodified.
Best regards,
Florian
Florian Bezdeka (2):
x86: cobalt/switchtest:
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we c
Hi all,
this is the backport of the previously published FPU testing cleanup
series to the stable/3.1.x branch.
Patch 1 has been updated to match the supported architectures in the
3.1.x stable branch, Patch 2 is unmodified.
Best regards,
Florian
Florian Bezdeka (2):
x86: cobalt/switchtest: F
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new introd
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running the tests in kernel space
in task context there is no guarantee that the FPU was initialized so
under heavy load / scheduling the test might fail and report a FPU
register corruption.
Th
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we c
Hi all,
this is the backport of the previously pulished FPU testing cleanup. As
3.2 stable branch still supports ipipe and ipipe allows us to use the
FPU in kernel space (in user task context) we have to deal with the
problem differently.
The x86 fpu test relied on getting a clean fpu state (crea
FPU usage in kernel space was allowed / enabled with ipipe, but is no
longer available for dovetail based kernels. That allows us to clean
up the FPU related tests of the switchtest utility.
fp_kernel_supported() can be removed as all supported architectures
returned 0 already. That allows us to r
Hi all,
some minor comments, see below:
On 22.04.22 20:58, Mauro S. via Xenomai wrote:
> Some cards are slow to get the connection link up after the
> "rtifconfig rteth0 up" command, e.g. on an Atom-x5 with an Intel I210
> (rt_igb driver) I detected approximately 3 seconds to get the link up.
>
Hi all,
On 03.04.22 19:49, Philippe Gerum via Xenomai wrote:
>
> Richard Weinberger writes:
>
>> - Ursprüngliche Mail -
>>> Von: "Philippe Gerum"
>>> An: "xenomai"
>>> CC: "Philippe Gerum" , "Richard Weinberger"
>>>
>>> Gesendet: Sonntag, 3. April 2022 16:43:48
>>> Betreff: [PATCH v
On 01.03.22 21:21, Jan Kiszka wrote:
> On 01.03.22 13:52, Florian Bezdeka wrote:
>> The CPU hotplugging code might re-trigger a vector. In that case the
>> vector is in the VECTOR_RETRIGGERED state. With this patch applied ipipe
>> does no longer call BUG() for such vectors.
>>
>
> Doesn't this al
On 01.03.22 19:28, Jan Kiszka wrote:
> On 21.02.22 14:25, Florian Bezdeka wrote:
>> The compat syscall was previously routed to the native entrypoint.
>> While the timeout is always based on time64_t the siginfo has to be
>> handled different in compat mode.
>>
>> Signed-off-by: Florian Bezdeka
>>
IRQ migrations did not work. Writing a new IRQ SMP affinity into
/proc/irq//smp_affinity had no effect.
It turned out that the pending migration was never handled. With
commit d4637fc8663b ("x86/ipipe: fix chained irq handling") do_IRQ() is
bypassed because it is not able to deal with chained IRQs
IRQ migrations did not work. Writing a new IRQ SMP affinity into
/proc/irq//smp_affinity had no effect.
It turned out that the pending migration was never handled. With
commit 2ecf1d517b02 ("x86/ipipe: fix chained irq handling") do_IRQ() is
bypassed because it is not able to deal with chained IRQs
The CPU hotplugging code might re-trigger a vector. In that case the
vector is in the VECTOR_RETRIGGERED state. With this patch applied ipipe
does no longer call BUG() for such vectors.
This is a backport from the 4.19 and 5.4 ipipe branches handling the
VECTOR_SHUTDOWN state. The VECTOR_SHUTDOWN
It might happen that the APIC vector in flight has already been shut
down by the device driver. In such a race it's still an unexpected
trap, but nothing we should warn about. Checking the vector error
state upfront avoids confusion.
This is what do_IRQ() would do as well, in a slightly simplified
Hi,
this are the results from an internal debugging session. We we're facing
some problems related to system tunings and some confusing kernel
messages related to spurious IRQs.
The most important part:
IRQ migrations were broken in 4.19 and 5.4 based branches
Patch 1 is compile tested only.
It might happen that the APIC vector in flight has already been shut
down by the device driver. In such a race it's still an unexpected
trap, but nothing we should warn about. Checking the vector error
state upfront avoids confusion.
This is what do_IRQ() would do as well, in a slightly simplified
The compat syscall was previously routed to the native entrypoint
which triggered a failure during mmsghdr validation.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cobalt/arch/x86/includ
The compat syscall was previously routed to the native entrypoint.
While the timeout is always based on time64_t the siginfo has to be
handled different in compat mode.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/x86/include/asm/xenomai/syscall32-table.h | 1 +
1 file changed, 1 insert
There is a pointer to ssize_t part of the ABI. The pointer itself is
autocorrected by the syscall enter machinery, but when reading/writing
we have to care about different sizes between compat and native case.
Signed-off-by: Florian Bezdeka
---
.../x86/include/asm/xenomai/syscall32-table.h | 1
I started testing the compat mode on a Ubuntu based system with glibc
2.34 which supports switching to 64 bit based time_t. These are the fixes
for problems observed while testing the kernel / cobalt part.
More tests, especially for the libcobalt part will be necessary,
especially because the way
We have a test within the smokey testsuite which actually does
something like
cobalt_monitor_init()
cobalt_monitor_wait()
cobalt_monitor_enter()
-> timeout
cobalt_monitor_exit()
cobalt_monitor_destroy()
If the posix_mutex tests were run right after this scenario th
Detected when trying to compile Xenomai on a 32bit system using latest
glibc release (2.34) without running autoreconf to regenerate
xeno_config.h.
The signature of _setrobust was mixed with the signature of _getrobust.
Updates https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/31
Signed-o
Initialization of the mutex used for mutex_timedlock64 tests could fail.
We have to abort the test in this case.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/y2038/syscall-tests.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/testsuite/smokey/y2038/syscall-tests.c
Like all other pointers in the cond_wait_prologue interface the error
pointer is user-provided and should be annotated accordingly.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/posix/cond.c | 8
kernel/cobalt/posix/cond.h | 8
kernel/cobalt/posix/syscall32.c | 4 +
It libc reports time64_t support, cond_wait_prologue is now dispatched
to the time64_t based syscall.
Signed-off-by: Florian Bezdeka
---
lib/cobalt/cond.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/lib/cobalt/cond.c b/lib/cobalt/cond.c
index 1bf5c7
According to the doctype provided by __get_user (which is used by the
__xn_get_user() macro) each call should be protected by access_ok().
We missed such a protection at some places.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/posix/internal.h | 4
kernel/cobalt/posix/nsem.c | 3
Extending the smokey testsuite to do some tests for the recently added
cond_wait_prologue64 syscall.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/y2038/syscall-tests.c | 97 ++
1 file changed, 97 insertions(+)
diff --git a/testsuite/smokey/y2038/syscall-tests.c
b
The following validation issues have been addressed:
- __cobalt_cond_wait_prologue() missed validating the supplied
pointers after the registry lookup which could fail. That triggered
the kernel OOPS dumped below
- The check removed from cobalt_cond_timedwait_prologue() is now
alr
Add a syscall specific for cond_wait_prologue64 with 64bit time_t.
Signed-off-by: Florian Bezdeka
---
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/cond.c | 26 ++
kernel/cobalt/posix/cond.h | 13 +
kernel/cobalt/posix/syscall3
Hi all,
this is the last missing POSIX related y2038 affected syscall in
Xenomai. With this applied we have two Xenomai specific syscalls
missing:
- sc_cobalt_thread_setschedparam_ex
- sc_cobalt_thread_getschedparam_ex
While adding tests for the introduced cond_wait_prologue64 I hit a
kernel
On 13.10.21 13:55, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> VM_DENYWRITE was removed in 5.15, so we need a different criteria.
> Absence of a file-backing seems to be a good one.
Bringing this one up, because we recently had a "report" on the ML
regarding VM_DENYWRITE.
I scanned the
On 27.12.21 19:50, G.Strobbe via Xenomai wrote:
> Hi all,
>
> The compilation of file xenomai/kernel/cobalt/debug.c
> in branch v5.15-dovetail-rebase failed.
> The problem is that since kernel vanilla v15.5
> include/linux/mm.h no longer defines VM_DENYWRITE
>
> It is still used in xndebug_trac
On 03.12.21 12:12, Jan Kiszka via Xenomai wrote:
> On 01.12.21 20:04, Jan Kiszka via Xenomai wrote:
>> On 26.11.21 09:02, Jean-Baptiste Trédez via Xenomai wrote:
>>> Current fec driver does not build on xenomai 3 and on recent kernel (ex :
>>> 5.10). Fec driver was completely rewritten on mainline
It can happen that the LAVA job submission fails. If so, the CI job
should be marked as failed. Previously we had something like the
following in the log, but the job was still marked as "OK".
Log:
connect to lava server: https://lava.xenomai.org
Deploy artifacts from
'https://xenomai-images-arti
To minimize CI build time, the ssh-regen part will be skipped on all
ci / test targets.
Signed-off-by: Florian Bezdeka
---
opt-ci.yml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/opt-ci.yml b/opt-ci.yml
index 4d1ab60..f90277a 100644
--- a/opt-ci.yml
+++ b/opt-ci.yml
@@ -27,6 +27,8 @@ re
Updating to the latest ISAR next revision to avoid carrying ISAR
patches. Some adjustments to CI scripts and machine configs were
necessary to follow ISAR upstream.
- The ssh key generation had some problems on Debian 11.
The key generation was started in parallel to the entropy feeding,
From: Jan Kiszka
No reason to turn this off, in fact, we have to turn it on with
bullseye's gcc-10 and debug options enabled to avoid relocation
range problems when loading modules.
Reported-by: Florian Bezdeka
Signed-off-by: Jan Kiszka
Signed-off-by: Florian Bezdeka
---
recipes-kernel/linux
Switching from Debian buster to Debian bullseye as base for or xenomai-demo
distribution.
Signed-off-by: Florian Bezdeka
---
conf/distro/xenomai-demo.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/conf/distro/xenomai-demo.conf b/conf/distro/xenomai-demo.conf
index 1
Integrate opt-lava-test.yml and opt-ext4-gz.yml into opt-ci.yml.
opt-ci.yml now holds all CI specific options:
- IMAGE_TYPE adjustments to fulfill LAVA needs
- COMPRESS for virtual qemu targets
CI configuration has been cleaned up. We only need opt-ci.yml,
all board related BUILD_OPTIONS have
Trying to expand the partition during first boot doesn't make sense
as we use NFS for deployment. Removing it helps to reduce the first boot
time a bit.
Signed-off-by: Florian Bezdeka
---
opt-ci.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/opt-ci.yml b/opt-ci.yml
index 9df02d0..4d1ab6
Whenever the kas option file opt-ci.yml is used we want the same build
options as the CI uses, which includes setting the debug options.
Signed-off-by: Florian Bezdeka
---
ci/gitlab-ci-base.yml | 4 ++--
opt-ci.yml| 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a
Hi all,
with this series the Xenomai demo image will be based on Debian 11.
All Debian 11 related topics that had to be adressed are now merged to
all Xenomai branches, stable branches included. CI runs were successfully
tested against all branches.
Patch 7 made it to the list but has not been a
Whenever an IRQ was handled for a vector being NULL or in one of the
error states the interrupt was not acknowledged at the APIC. That can
happen if a vector is cleaned up by one of the device drivers while
there is still one IRQ in flight.
This has two effects:
- If the affected vector is re-as
Extend the struct and make sure all members are initialized / cleaned
up properly. All new members will be used by the following patches.
Signed-off-by: Florian Bezdeka
---
include/linux/irqdesc.h | 11 +++
kernel/irq/irqdesc.c| 24 ++--
2 files changed, 33 insert
Signed-off-by: Florian Bezdeka
---
The output looks like that:
[36452.934159] dev_watchdog: cpu(6) jiffies(4331120128) jd(5072)
ct(36452934152782) ctd(511)
[36458.054164] dev_watchdog: cpu(6) jiffies(4331125248) jd(5120)
ct(36458054156389) ctd(5120003)
[36464.198155] dev_watchdog: cpu(6) j
For each CPU the following IRQ information will be shown:
- inband post counter
- inband pull counter
- inband merge counter
- Linux accounting (unmodified)
- out of band post counter
- out of band pull counter
- out of band merge counter
Signed-off-by: Florian Bezdeka
---
The cove
- Remember how often an IRQ was posted into and pulled from the IRQ log
- Measure the time between push and pull
- Count how often we merge IRQs
(multiple post events before pulling again)
Signed-off-by: Florian Bezdeka
---
kernel/irq/pipeline.c | 34 ++
1 f
Show the maximum time an interrupt stayed in the IRQ log on each CPU.
Heavily inspired by show_interrupts().
Both logs (inband as well as out of band) are taken into account and
are visible now.
Signed-off-by: Florian Bezdeka
---
The coverletter has an example of how this file looks like on the
We stop systemd-timesyncd before running the smokey testsuite and start
it again once the smokey tests are complete. As xeno-test has a "set -e"
we will stop the execution on the first error. So if smokey reports an
error systemd-timesyncd is not started again. We don't properly restore
the system
It might happen that the kernel does not support the combination of
address family and protocol we use for this test. Skip the test and
simulate success in such cases.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/y2038/syscall-tests.c | 4
1 file changed, 4 insertions(+)
diff --git
It can happen that the LAVA job submission fails. If so, the CI job
should be marked as failed. Previously we had something like the
following in the log, but the job was still marked as "OK".
Log:
connect to lava server: https://lava.xenomai.org
Deploy artifacts from
'https://xenomai-images-arti
Switching from Debian buster to Debian bullseye as base for or xenomai-demo
distribution.
Signed-off-by: Florian Bezdeka
---
conf/distro/xenomai-demo.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/conf/distro/xenomai-demo.conf b/conf/distro/xenomai-demo.conf
index 1
From: Jan Kiszka
No reason to turn this off, in fact, we have to turn it on with
bullseye's gcc-10 and debug options enabled to avoid relocation
range problems when loading modules.
Reported-by: Florian Bezdeka
Signed-off-by: Jan Kiszka
---
recipes-kernel/linux/files/armhf_defconfig | 1 -
1
Whenever the kas option file opt-ci.yml is used we want the same build
options as the CI does, which includes setting the debug options.
Signed-off-by: Florian Bezdeka
---
ci/gitlab-ci-base.yml | 4 ++--
opt-ci.yml| 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a
This kas option file is used for real test / ci boards only. The
previous name indicated that it is used for all ci tests including
virtual devices like (qemu).
Signed-off-by: Florian Bezdeka
---
ci/gitlab-ci-base.yml | 6 +++---
opt-lava-test.yml => opt-ci-board.yml | 0
2 files
For now the difference between the demo and the "ci image" is the
removed sshd-regen-keys. That reduces the (first) boot time especially
on low end CI hardware. Helps to stay within LAVA timeouts.
CI builds will now use that file.
Signed-off-by: Florian Bezdeka
---
ci/gitlab-ci-base.yml | 4 ++
Trying to expand the partition during first boot doesn't make sense
as we use NFS for deployment. Removing it helps to reduce the first boot
time a bit.
It is disabled on all qemu machines in the machine config, as we can
handle all qemu machines at once there. For real boards we want it to
stay,
See patch descriptions for details. The main problem was that the key
generation took extremly long and several other services (like the
serial consoles) were not started because the configured timeout was
reached.
Signed-off-by: Florian Bezdeka
---
...Start-key-generation-after-entropy-s.patch
Hi all,
with this series the Xenomai demo image will be based on Debian 11.
All Debian 11 related topics that had to be adressed are now merged to
the Xenomai next branch. The stable branches have not yet been updated
so CI will report some failures for such branches.
Patch 4 made it to the list
On 13.10.21 10:08, Jan Kiszka wrote:
> On 13.10.21 09:50, Florian Bezdeka wrote:
>> On 13.10.21 09:26, Jan Kiszka wrote:
>>> On 13.10.21 09:18, Florian Bezdeka via Xenomai wrote:
>>>> For now the difference between the demo and the "ci image" is:
>>>
On 13.10.21 09:50, Florian Bezdeka via Xenomai wrote:
> On 13.10.21 09:26, Jan Kiszka wrote:
>> On 13.10.21 09:18, Florian Bezdeka via Xenomai wrote:
>>> For now the difference between the demo and the "ci image" is:
>>> - Removed sshd-regen-keys: Reduce
On 13.10.21 09:50, Florian Bezdeka via Xenomai wrote:
> On 13.10.21 09:26, Jan Kiszka wrote:
>> On 13.10.21 09:18, Florian Bezdeka via Xenomai wrote:
>>> For now the difference between the demo and the "ci image" is:
>>> - Removed sshd-regen-keys: Reduce
On 13.10.21 09:28, Jan Kiszka wrote:
> On 13.10.21 09:18, Florian Bezdeka via Xenomai wrote:
>> It can happen that the LAVA job submission fails. If so, the CI job
>> should be marked as failed. Previously we had something like the
>> following in the log, but the job wa
On 13.10.21 09:26, Jan Kiszka wrote:
> On 13.10.21 09:18, Florian Bezdeka via Xenomai wrote:
>> For now the difference between the demo and the "ci image" is:
>> - Removed sshd-regen-keys: Reduces the (first) boot time especially on
>>low end CI hardware. Hel
See patch descriptions for details. The main problem was that the key
generation took extremly long and several other services (like the
serial consoles) were not started because the configured timeout was
reached.
Signed-off-by: Florian Bezdeka
---
...Start-key-generation-after-entropy-s.patch
It can happen that the LAVA job submission fails. If so, the CI job
should be marked as failed. Previously we had something like the
following in the log, but the job was still marked as "OK".
Log:
connect to lava server: https://lava.xenomai.org
Deploy artifacts from
'https://xenomai-images-arti
Whenever the kas option file opt-ci.yml is used we want the same build
options as the CI does, which includes setting the debug options.
Signed-off-by: Florian Bezdeka
---
ci/gitlab-ci-base.yml | 4 ++--
opt-ci.yml| 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a
Switching from Debian buster to Debian bullseye as base for or xenomai-demo
distribution.
Signed-off-by: Florian Bezdeka
---
conf/distro/xenomai-demo.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/conf/distro/xenomai-demo.conf b/conf/distro/xenomai-demo.conf
index 1
From: Jan Kiszka
No reason to turn this off, in fact, we have to turn it on with
bullseye's gcc-10 and debug options enabled to avoid relocation
range problems when loading modules.
Reported-by: Florian Bezdeka
Signed-off-by: Jan Kiszka
---
recipes-kernel/linux/files/armhf_defconfig | 1 -
1
For now the difference between the demo and the "ci image" is:
- Removed sshd-regen-keys: Reduces the (first) boot time especially on
low end CI hardware. Helps to stay within LAVA timeouts.
- Removed expand-on-first-boot: Doesn't make much sense on CI runs as
we don't really use the files
Hi all,
with this series the Xenomai demo image will be based on Debian 11.
All Debian 11 related topics that had to be adressed are now merged to
the Xenomai next branch. The stable branches have not yet been updated
so CI will report some failures for such branches.
Patch 4 made it to the list
From: Song Chen
If libc reports time64_t support, recvmmsg is dispatched to the
time64_t based syscall.
Signed-off-by: Song Chen
Signed-off-by: Florian Bezdeka
---
lib/cobalt/rtdm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index f3fb5d411.
From: Song Chen
Add a syscall specific for recvmmsg64 with 64bit time_t.
Signed-off-by: Song Chen
[Florian: Fixed some style issues]
[Florian: Added Song's Signed-off back (malformed patch received)]
[Florian: Fixed tracing infrastructure]
Signed-off-by: Florian Bezdeka
---
include/cobalt/ker
From: Song Chen
Extending the test suite for recvmmsg64 test.
Signed-off-by: Song Chen
[Florian: Rebased the patch on top of next]
[Florian: switched to CLOCK_MONOTONIC]
[Florian: Fixed error handling of the socket() call]
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/y2038/syscall-test
Hi,
Just another y2038 related syscall, once again based on v4 sent out by
Song with the following changes (squashed into the affected patches):
- rebased to current next (especially patch 3)
- minor code cleanups / reformattings
- Added the syscall name to the tracing infrastructure
- Switched t
Especially 4.19 is not 2038 safe and 32 bit kernels do not have
CONFIG_64BIT_TIME set, which ends up in __kernel_timespec being defined
in a non y2038 safe way.
cobalt_get_timespec64 will copy the upper bytes of the sec field into
the nsec field, which is always zero.
Testing y2038 syscalls on a
Hi all,
first issue:
maybe someone can explain what's going on here. I'm running autotune
inside qemu (ARM) on an x86_64 host and get the error below. The
kernel in use is 4.19 (ipipe) build with current "next" branch.
root@demo:~# autotune2
== auto-tuning started, period=100 ns (may take
The refcnt field was never initialized and triggered a BUG() in
vfile_regular_release (vfile.c) when closing / releasing such a virtual
file.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/registry.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/r
Exporting named semaphores to /proc/xenomai/registry/posix/sem helps
to identify resource leaks by making registered semaphores visible. The
content of all created virtual files is empty. Removal of such files is
not possible and reports "operation not supported".
Signed-off-by: Florian Bezdeka
-
Will be used later for exporting registry entries, namely named
semaphores as well as mqueues to
/proc/xenomai/registry/posix/{mqueue,sem}
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/posix/internal.h | 2 ++
kernel/cobalt/posix/process.c | 2 ++
2 files changed, 4 insertions(+)
diff --git
Make sure that named semaphores as well as mqueues are exported to the
procfs.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/leaks/leaks.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/testsuite/smokey/leaks/leaks.c b/testsuite/smokey/leaks/leaks.c
index
Allows re-using xnregistry_vfreg_ops. All other file options were
already available.
Signed-off-by: Florian Bezdeka
---
include/cobalt/kernel/registry.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/cobalt/kernel/registry.h b/include/cobalt/kernel/registry.h
index 624db5a78..a459
Hi all,
with this series I'm trying to care about all the feedback I got for
RFCs I sent out some days ago. Exporting mqueues and named semaphores to
the procfs helps to debug and identify resource leaks.
mqueues will be exported to
/proc/xenomai/registry/posix/mqueue/
named semaphores
The exit code of the child process was never correctly reported to the
parent process. Hence, the status code check was wrong at all. The
variable previously named subprocess_status was not shared between both
processes.
Signed-off-by: Florian Bezdeka
---
testsuite/smokey/leaks/leaks.c | 41
Exporting created mqueues to /proc/xenomai/registry/posix/mqueue helps
to identify resource leaks by making mqueues visible. The content of all
created virtual files is empty. Removal of such files is not possible
and reports "operation not supported".
Signed-off-by: Florian Bezdeka
---
kernel/c
Will be used later for exporting named semaphores as well as mqueues
to /proc/xenomai/registry/posix/{mqueue,sem}
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/registry.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
index 211e0f76f.
Make sure mqueues and named semaphores are exported to the procfs if
the kernel has procfs support activated.
While at it: The exit code of the child process was never correctly
reported to the parent process. Hence, the status code check was wrong
at all. The variable previously named subprocess_
Exporting named semaphores to /proc/xenomai/registry/posix/sem helps
to identify resource leaks by making registered semaphores visible. The
content of all created virtual files is empty. Removal of such files is
not possible and reports "operation not supported".
Signed-off-by: Florian Bezdeka
-
Exporting created mqueues to /proc/xenomai/registry/posix/mqueue helps
to identify resource leaks by making mqueues visible. The content of all
created virtual files is empty. Removal of such files is not possible
and reports "operation not supported".
Signed-off-by: Florian Bezdeka
---
kernel/c
The refcnt field was never initialized and triggered a BUG() in
vfile_regular_release (vfile.c) when closing / releasing such a virtual
file.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/registry.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/r
Allows re-using xnregistry_vfreg_ops. All other file options were
already available.
Signed-off-by: Florian Bezdeka
---
include/cobalt/kernel/registry.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/cobalt/kernel/registry.h b/include/cobalt/kernel/registry.h
index 624db5a78..a459
Hi all,
with this series I'm trying to care about all the feedback I got for
RFCs I sent out some days ago. Exporting mqueues and named semaphores to
the procfs helps to debug and identify resource leaks.
mqueues will be exported to
/proc/xenomai/registry/posix/mqueue/
named semaphores
Allows re-using xnregistry_vfreg_ops. All other file options were
already available.
Signed-off-by: Florian Bezdeka
---
include/cobalt/kernel/registry.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/cobalt/kernel/registry.h b/include/cobalt/kernel/registry.h
index 624db5a78..a459
Previously the root directory was mandatory, which means that exports
to the proc file system were forced to be located in
/proc/xenomai/registry///.
The virtual directory is now optional. If not supplied the
root node of is set to registry_vfroot, which represents
/proc/xenomai/registry.
Signe
Exporting created mqueues to /proc/xenomai/registry/mqueue helps to
identify resource leaks by making mqueues visible. The content of all
created virtual files is empty. Removal of such files is not possible
and reports "operation not supported".
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/
Hi,
this is another try to make registered mqueues visible. This time by
exporting them to the procfs, namely to
/proc/xenomai/registry/mqueue/
Let me know what you think...
I had to rework the existing export machinery a bit to get rid of the so
called "root" directory which is normally create
1 - 100 of 256 matches
Mail list logo
