No reason to not allow MEMBARRIER_CMD_FLAG_CPU on
MEMBARRIER_CMD_PRIVATE_EXPEDITED or
MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE.

If it is known specifically what cpu you want to interrupt then there
is a decent efficiency saving in not interrupting all the other ones.

Also - the code already works as is for them.

Signed-off-by: Dylan Yudaken <dyudaken@gmail.com>
---
 kernel/sched/membarrier.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 809194cd779f..def6d4094ad6 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -595,7 +595,9 @@ static int membarrier_get_registrations(void)
  *          contains the CPU on which to interrupt (= restart)
  *          the RSEQ critical section.
  * @cpu_id: if @flags == MEMBARRIER_CMD_FLAG_CPU, indicates the cpu on which
- *          RSEQ CS should be interrupted (@cmd must be
+ *          RSEQ CS should be interrupted (@cmd must be one of
+ *          MEMBARRIER_CMD_PRIVATE_EXPEDITED,
+ *          MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE,
  *          MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ).
  *
  * If this system call is not implemented, -ENOSYS is returned. If the
@@ -625,6 +627,8 @@ static int membarrier_get_registrations(void)
 SYSCALL_DEFINE3(membarrier, int, cmd, unsigned int, flags, int, cpu_id)
 {
 	switch (cmd) {
+	case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
+	case MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE:
 	case MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ:
 		if (unlikely(flags && flags != MEMBARRIER_CMD_FLAG_CPU))
 			return -EINVAL;
-- 
2.49.0

On 2025-06-26 11:52, Dylan Yudaken wrote:
> No reason to not allow MEMBARRIER_CMD_FLAG_CPU on
> MEMBARRIER_CMD_PRIVATE_EXPEDITED or
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE.
> 
> If it is known specifically what cpu you want to interrupt then there
> is a decent efficiency saving in not interrupting all the other ones.
> 
> Also - the code already works as is for them.

Can you elaborate on a concrete use-case justifying adding this ?

Thanks,

Mathieu

> 
> Signed-off-by: Dylan Yudaken <dyudaken@gmail.com>
> ---
>   kernel/sched/membarrier.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
> index 809194cd779f..def6d4094ad6 100644
> --- a/kernel/sched/membarrier.c
> +++ b/kernel/sched/membarrier.c
> @@ -595,7 +595,9 @@ static int membarrier_get_registrations(void)
>    *          contains the CPU on which to interrupt (= restart)
>    *          the RSEQ critical section.
>    * @cpu_id: if @flags == MEMBARRIER_CMD_FLAG_CPU, indicates the cpu on which
> - *          RSEQ CS should be interrupted (@cmd must be
> + *          RSEQ CS should be interrupted (@cmd must be one of
> + *          MEMBARRIER_CMD_PRIVATE_EXPEDITED,
> + *          MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE,
>    *          MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ).
>    *
>    * If this system call is not implemented, -ENOSYS is returned. If the
> @@ -625,6 +627,8 @@ static int membarrier_get_registrations(void)
>   SYSCALL_DEFINE3(membarrier, int, cmd, unsigned int, flags, int, cpu_id)
>   {
>   	switch (cmd) {
> +	case MEMBARRIER_CMD_PRIVATE_EXPEDITED:
> +	case MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE:
>   	case MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ:
>   		if (unlikely(flags && flags != MEMBARRIER_CMD_FLAG_CPU))
>   			return -EINVAL;


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

On Thu, Jun 26, 2025 at 5:07 PM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> On 2025-06-26 11:52, Dylan Yudaken wrote:
> > No reason to not allow MEMBARRIER_CMD_FLAG_CPU on
> > MEMBARRIER_CMD_PRIVATE_EXPEDITED or
> > MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE.
> >
> > If it is known specifically what cpu you want to interrupt then there
> > is a decent efficiency saving in not interrupting all the other ones.
> >
> > Also - the code already works as is for them.
>
> Can you elaborate on a concrete use-case justifying adding this ?
>
> Thanks,
>
> Mathieu
>

So my use case is for core-local data such as performance counters.

I have a library that allows a fast thread to  "lock" a core -> do
some work (probably incrementing some performance counters) -> unlock.
The "lock" uses restartable sequences (ie no serializing
instructions), and the unlock just writes a 0 to memory (again, no
serializing instructions).

A slow thread will occasionally (say every few minutes) try and read
data computed in the work section.
It does this by disabling locking and firing off a membarrier(RSEQ) on
that core to be sure that the core is either "locked" or "unlocked".
It then spins waiting for it to be unlocked.
At this point my understanding is a bit fuzzy - but I believe you need
that core to have a memory barrier since there is no serializing
instruction and the processor would happily reorder some "work" after
the "unlock" instruction.

That serializing instruction is what I want from this. But since I
know the cpu_id that I am working with I don't need to do a barrier on
_all_ the cores.

To be clear: (1) I don't have a current real world use case, and (2)
my library/design/understanding might be buggy.
(3) I don't have a use case for the SYNC_CORE part, but again it
seemed easy enough to add and I presume others might have a use case.