On Tue, Apr 02 2024 at 10:23, John Stultz wrote:
> On Tue, Apr 2, 2024 at 7:57 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> This test in particular exercises new functionality/behaviour, which
>> really has no business to be backported into stable just to make the
>> relevant test usable on older kernels.
>
> That's fair. I didn't have all the context around what motivated the
> change and the follow-on test, which is why I'm asking here.
It's a performance enhancement to avoid waking up idle threads for
signal delivery instead of just delivering it to the current running
thread which made the CPU timer fire. So it does not qualify for fix.
>> Why would testing with latest tests against an older kernel be valid per
>> se?
>
> So yeah, it definitely can get fuzzy trying to split hairs between
> when a change in behavior is a "new feature" or a "fix".
>
> Greg could probably articulate it better, but my understanding is the
> main point for running newer tests on older kernels is that newer
> tests will have more coverage of what is expected of the kernel. For
> features that older kernels don't support, ideally the tests will
> check for that functionality like userland applications would, and
> skip that portion of the test if it's unsupported. This way, we're
> able to find issues (important enough to warrant tests having been
> created) that have not yet been patched in the -stable trees.
>
> In this case, there is a behavioral change combined with a compliance
> test, which makes it look a bit more like a fix, rather than a feature
> (additionally the lack of a way for userland to probe for this new
> "feature" makes it seem fix-like). But the intended result of this is
> just spurring this discussion to see if it makes sense to backport or
> not. Disabling/ignoring the test (maybe after Thomas' fix to avoid it
> from hanging :) is a fine solution too, but not one I'd want folks to
> do until they've synced with maintainers and had full context.
I was staring at this test because it hangs even on upstream on a
regular base, at least in a VM. The timeout change I posted prevents the
hang, but still the posixtimer test will not have 0 fails.
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.
So I came up with a modified variant of that, which can deduce pretty
reliably that the test runs on an older kernel.
Thanks,
tglx
---
Subject: selftests/timers/posix_timers: Make signal distribution test less fragile
From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Date: Mon, 15 May 2023 00:40:10 +0200
The signal distribution test has a tendency to hang for a long time as the
signal delivery is not really evenly distributed. In fact it might never be
distributed across all threads ever in the way it is written.
Address this by:
1) Adding a timeout which aborts the test
2) Letting the test threads do a usleep() once they got a signal instead
of running continuously. That ensures that the other threads will expire
the timer and get the signal
3) Adding a detection whether all signals arrvied at the main thread,
which allows to run the test on older kernels.
While at it get rid of the pointless atomic operation on a the thread local
variable in the signal handler.
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
---
tools/testing/selftests/timers/posix_timers.c | 48 +++++++++++++++++---------
1 file changed, 32 insertions(+), 16 deletions(-)
--- a/tools/testing/selftests/timers/posix_timers.c
+++ b/tools/testing/selftests/timers/posix_timers.c
@@ -184,18 +184,22 @@ static int check_timer_create(int which)
return 0;
}
-int remain;
-__thread int got_signal;
+static int remain;
+static __thread int got_signal;
static void *distribution_thread(void *arg)
{
- while (__atomic_load_n(&remain, __ATOMIC_RELAXED));
- return NULL;
+ while (__atomic_load_n(&remain, __ATOMIC_RELAXED) && !done) {
+ if (got_signal)
+ usleep(10);
+ }
+
+ return (void *)got_signal;
}
static void distribution_handler(int nr)
{
- if (!__atomic_exchange_n(&got_signal, 1, __ATOMIC_RELAXED))
+ if (++got_signal == 1)
__atomic_fetch_sub(&remain, 1, __ATOMIC_RELAXED);
}
@@ -205,8 +209,6 @@ static void distribution_handler(int nr)
*/
static int check_timer_distribution(void)
{
- int err, i;
- timer_t id;
const int nthreads = 10;
pthread_t threads[nthreads];
struct itimerspec val = {
@@ -215,7 +217,11 @@ static int check_timer_distribution(void
.it_interval.tv_sec = 0,
.it_interval.tv_nsec = 1000 * 1000,
};
+ int err, i, nsigs;
+ time_t start, now;
+ timer_t id;
+ done = 0;
remain = nthreads + 1; /* worker threads + this thread */
signal(SIGALRM, distribution_handler);
err = timer_create(CLOCK_PROCESS_CPUTIME_ID, NULL, &id);
@@ -231,7 +237,7 @@ static int check_timer_distribution(void
for (i = 0; i < nthreads; i++) {
err = pthread_create(&threads[i], NULL, distribution_thread,
- NULL);
+ thread_sigs + i);
if (err) {
ksft_print_msg("Can't create thread: %s (%d)\n",
strerror(errno), errno);
@@ -240,23 +246,33 @@ static int check_timer_distribution(void
}
/* Wait for all threads to receive the signal. */
- while (__atomic_load_n(&remain, __ATOMIC_RELAXED));
+ now = start = time(NULL);
+ while (__atomic_load_n(&remain, __ATOMIC_RELAXED)) {
+ now = time(NULL);
+ if (now - start > 5)
+ break;
+ }
+ done = 1;
- for (i = 0; i < nthreads; i++) {
+ if (timer_delete(id)) {
+ ksft_perror("Can't delete timer\n");
+ return -1;
+ }
+
+ for (i = 0, nsigs = 0; i < nthreads; i++) {
err = pthread_join(threads[i], NULL);
if (err) {
ksft_print_msg("Can't join thread: %s (%d)\n",
strerror(errno), errno);
return -1;
}
+ nsigs += thread_sigs[i];
}
- if (timer_delete(id)) {
- ksft_perror("Can't delete timer");
- return -1;
- }
-
- ksft_test_result_pass("check_timer_distribution\n");
+ if (!nsigs)
+ ksft_test_result_skip("No signal distribution. Assuming old kernel\n");
+ else
+ ksft_test_result(now - start < 5, "check_timer_distribution\n");
return 0;
}
