-5b504a2d3...@sirena.org.uk/
Signed-off-by: Oleg Nesterov
---
tools/testing/selftests/kselftest.h | 6 ++
tools/testing/selftests/timers/posix_timers.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kselftest.h
b/tools/testing/selftests/k
On 04/11, Thomas Gleixner wrote:
>
> On Thu, Apr 11 2024 at 13:44, Mark Brown wrote:
> >
> > Further to my previous mail it's also broken the arm64 selftest builds,
> > they use kselftest.h with nolibc in order to test low level
> > functionality mainly used by libc implementations and nolibc
On 04/10, John Stultz wrote:
>
> After commit 6d029c25b71f ("selftests/timers/posix_timers:
> Reimplement check_timer_distribution()") I started seeing the
> following warning building with an older gcc:
>
> posix_timers.c:250:2: warning: format not a string literal and no format
> arguments
on() fails on the older kernel.
Signed-off-by: Oleg Nesterov
---
tools/testing/selftests/kselftest.h | 14 +++
tools/testing/selftests/timers/posix_timers.c | 103 --
2 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/tools/testing/selftests/kselftest.
On 04/09, Thomas Gleixner wrote:
>
> The discussion started about running new tests on older kernels. As this
> is a feature and not a bug fix that obviously fails on older kernels.
OK, I see... please see below.
> So something like the uncompiled below should work.
Hmm... this patch doesn't
On 04/08, Oleg Nesterov wrote:
>
> On 04/08, Dmitry Vyukov wrote:
> >
> > >
> > > if (ctd_failed)
> > > ksft_test_result_skip("No signal distribution. Assuming
> > > old kernel\n");
> >
> > Shouldn't t
On 04/08, Dmitry Vyukov wrote:
>
> >
> > if (ctd_failed)
> > ksft_test_result_skip("No signal distribution. Assuming old
> > kernel\n");
>
> Shouldn't the test fail here? The goal of a test is to fail when
> things don't work.
I've copied this from the previous patch from
Muhammad,
I am sorry, but... are you aware that this patch was applied over a year ago,
and then this code was updated to use the ksft_API?
Oleg.
On 04/07, Muhammad Usama Anjum wrote:
>
> On 3/16/23 5:30 PM, Marco Elver wrote:
> > From: Dmitry Vyukov
> >
> > Test that POSIX timers using
Dmitry, Thomas,
To simplify the review I've attached the code with this patch applied below.
Yes, this changes the "semantics" of check_timer_distribution(), perhaps it
should be renamed.
But I do not see a better approach, and in fact I think that
Test that all running threads
always send the signal
to the thread which burns cpu.
Without the commit bcb7ee79029d ("posix-timers: Prefer delivery of signals
to the current thread") the test-case fails immediately, the very 1st tick
wakes the leader up. Otherwise it quickly succeeds after 100 ticks.
Signed-of
On 04/04, Thomas Gleixner wrote:
>
> On Thu, Apr 04 2024 at 15:43, Oleg Nesterov wrote:
>
> > And this will happen with
> > or without the commit bcb7ee79029dca ("posix-timers: Prefer delivery of
> > signals to the current thread"). Any thread can dequeue a s
On 04/04, Thomas Gleixner wrote:
>
> IOW, we cannot test this reliably at all with the current approach.
Agreed!
So how about a REALLY SIMPLE test-case below?
Lacks error checking, should be updated to match tools/testing/selftests.
Without commit bcb7ee79029dca assert(sig_cnt > SIG_CNT)
Perhaps I am totally confused, but.
On 04/04, Dmitry Vyukov wrote:
>
> On Wed, 3 Apr 2024 at 17:43, Thomas Gleixner wrote:
> >
> > > Why distribution_thread() can't simply exit if got_signal != 0 ?
> > >
> > > See https://lore.kernel.org/all/20230128195641.ga14...@redhat.com/
> >
> > Indeed.
On 04/03, Thomas Gleixner wrote:
>
> The test if fragile as hell as there is absolutely no guarantee that the
> signal target distribution is as expected. The expectation is based on a
> statistical assumption which does not really hold.
Agreed. I too never liked this test-case.
I forgot
I'll try to read your email later, just one note for now...
On 01/22, Bernd Edlinger wrote:
>
> > I didn't say that t is a group leader. I said it can be a zombie sub-thread
> > with ->exit_state != 0.
>
> the condition here is
>
> (t != tsk->group_leader || !t->exit_state)
>
> so in other words,
On 01/17, Bernd Edlinger wrote:
>
> >>
> >> The problem happens when a tracer tries to ptrace_attach
> >> to a multi-threaded process, that does an execve in one of
> >> the threads at the same time, without doing that in a forked
> >> sub-process. That means: There is a race condition, when one
I'll try to recall this problem and actually read the patch tommorrow...
Hmm. but it doesn't apply to Linus's tree, you need to rebase it.
In particular, please note the recent commit 5431fdd2c181dd2eac2
("ptrace: Convert ptrace_attach() to use lock guards")
On 01/15, Bernd Edlinger wrote:
>
>
17 matches
Mail list logo
