Re: [RFC PATCH] sched/proxy_exec: Extend PE blocked_on chain to rwsem write-side

[John Stultz]

On Wed, Mar 4, 2026 at 12:23 AM <soolaug...@gmail.com> wrote:
>
> From: zhidao su <suzhi...@xiaomi.com>
>
> Proxy Execution currently tracks blocked_on chains only through
> struct mutex. This patch extends the infrastructure to support
> rw_semaphore write-side blocking, allowing PE to eliminate priority
> inversion where a high-priority writer waits for a low-priority
> write lock holder.

I'm confused. I've already mentioned Suleiman has implemented rwsem
support for proxy back in September:
  https://lore.kernel.org/lkml/20250926032931.27663-1-jstu...@google.com/

Which the latest version can be found here (though I do have fixes
pending for v25):
  https://github.com/johnstultz-work/linux-dev/commits/proxy-exec-v24-6.18/


> diff --git a/tools/testing/selftests/sched/proxy_exec_test.c 
> b/tools/testing/selftests/sched/proxy_exec_test.c
> new file mode 100644
> index 00000000000..30fc58b9738
> --- /dev/null
> +++ b/tools/testing/selftests/sched/proxy_exec_test.c
> @@ -0,0 +1,763 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Proxy Execution (PE) selftest
> + *
> + * Tests for the sched_proxy_exec feature. Verifies that the kernel
> + * correctly handles RT priority inheritance through proxy execution.
> + *
> + * TC-1: Basic PE activation — low-prio holder releases lock for high-prio
> + *        waiter within expected time bound.
> + * TC-2: Three-level blocked_on chain — PE chains through B->C so that
> + *        A eventually acquires its mutex.
> + * TC-3: PE deactivate path — SIGSTOP/SIGCONT on holder; high-prio thread
> + *        must still acquire the lock within a generous timeout.
> + */
> +
> +#define _GNU_SOURCE
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <pthread.h>
> +#include <sched.h>
> +#include <errno.h>
> +#include <signal.h>
> +#include <time.h>
> +#include <sys/syscall.h>
> +#include <sys/types.h>
> +
> +static int test_count;
> +
> +/* ------------------------------------------------------------------ */
> +/* Helpers                                                              */
> +/* ------------------------------------------------------------------ */
> +
> +/*
> + * is_proxy_exec_enabled - check whether CONFIG_SCHED_PROXY_EXEC is active
> + *
> + * Try to read /proc/sys/kernel/sched_proxy_exec. If the file exists and
> + * contains a non-zero value the feature is considered enabled. Returns 1
> + * when enabled, 0 otherwise.
> + */
> +static int is_proxy_exec_enabled(void)
> +{
> +       FILE *f;
> +       int val = 0;
> +
> +       f = fopen("/proc/sys/kernel/sched_proxy_exec", "r");
> +       if (!f)
> +               return 0;

? There is no /proc/sys/kernel/sched_proxy_exec file.

This seems a bit like its AI generated, and wasn't tested. I'd avoid
sending stuff like that out to the list.

thanks
-john