mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "André Almeida" <andrealmeid@igalia.com>,
	"Florian Weimer" <fweimer@redhat.com>
Cc: linux-kernel@vger.kernel.org, Carlos O'Donell <carlos@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Rich Felker <dalias@aerifal.cx>,
	Torvald Riegel <triegel@redhat.com>,
	Darren Hart <dvhart@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Arnd Bergmann <arnd@arndb.de>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock
Date: Thu, 12 Mar 2026 12:09:01 -0400	[thread overview]
Message-ID: <2e9b6192-ffd3-4d8e-9430-763bbcf49e21@efficios.com> (raw)
In-Reply-To: <f3eb5c08-1ec7-4131-8e2a-b4f4ca38cbb0@igalia.com>

On 2026-03-12 10:14, André Almeida wrote:
> 
> 
> Em 12/03/2026 11:12, Florian Weimer escreveu:
>> * Mathieu Desnoyers:
>>
>>> On 2026-03-12 04:49, Florian Weimer wrote:
>>>> * Mathieu Desnoyers:
>>>>
>>>>> + * This vDSO unlocks the robust futex by exchanging the content of
>>>>> + * *uaddr with 0 with a store-release semantic. If the futex has
>>>>> + * waiters, it sets bit 1 of *op_pending_addr, else it clears
>>>>> + * *op_pending_addr. Those operations are within a code region
>>>>> + * known by the kernel, making them safe with respect to asynchronous
>>>>> + * program termination either from thread context or from a nested
>>>>> + * signal handler.
>>>>> + *
>>>>> + * Expected use of this vDSO:
>>>>> + *
>>>>> + * if ((__vdso_robust_futex_unlock((u32 *) &mutex->__data.__lock, 
>>>>> &pd->robust_head.list_op_pending)
>>>>> + *     & FUTEX_WAITERS) != 0)
>>>>> + *         futex_wake((u32 *) &mutex->__data.__lock, 1, private);
>>>>> + * WRITE_ONCE(pd->robust_head.list_op_pending, 0);
>>>> The comment could perhaps say that pd->robust_head is the
>>>> thread-specific robust list that has been registered with
>>>> set_robust_list.
>>
>>> Good point. Considering that "robust_head" is the thread-specific
>>> robust list registered with set_robust_list, I wonder if passing
>>> &robust_head->list_op_pending is the right ABI choice there,
>>> or if we should rather pass the robust_head pointer and offset it
>>> within the vDSO.
>>
>> I think set_robust_list has pointer and size arguments, so we should
>> pass those two at least.
>>
> 
> The size argument for set_robust_list() has never been useful it seems, 
> it just checks if (size == sizeof(*head)). I believe it was added in 
> case the struct would ever be expanded, but that never happened and with 
> set_robust_list2() in the horizon this is even less likely to ever happen.

I'd prefer not passing an extra parameter which would require the caller
to perform error validation unless it's really necessary.

The field we need to access (list_op_pending) is part of the original
structure, so it would be there even of this structure is extended in
the future.

Thanks,

Mathieu

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

  reply	other threads:[~2026-03-12 16:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 18:54 Mathieu Desnoyers
2026-03-11 20:11 ` Mathieu Desnoyers
2026-03-12  8:49 ` Florian Weimer
2026-03-12 13:13   ` Mathieu Desnoyers
2026-03-12 14:12     ` Florian Weimer
2026-03-12 14:14       ` André Almeida
2026-03-12 16:09         ` Mathieu Desnoyers [this message]
2026-03-12 13:46 ` André Almeida
2026-03-12 14:04   ` Mathieu Desnoyers
2026-03-12 18:40     ` Mathieu Desnoyers
2026-03-12 18:58       ` André Almeida
2026-03-12 19:10     ` Thomas Gleixner
2026-03-12 19:16       ` Mathieu Desnoyers
2026-03-13  8:20         ` Florian Weimer
2026-03-12 20:19   ` Thomas Gleixner
2026-03-12 21:28     ` Mathieu Desnoyers
2026-03-12 22:23 ` Thomas Gleixner
2026-03-12 22:52   ` Mathieu Desnoyers
2026-03-13 12:12     ` Sebastian Andrzej Siewior
2026-03-13 12:17       ` Mathieu Desnoyers
2026-03-13 13:29         ` Sebastian Andrzej Siewior
2026-03-13 13:35           ` Mathieu Desnoyers
2026-03-16 17:12     ` Thomas Gleixner
2026-03-16 19:36       ` Mathieu Desnoyers
2026-03-16 20:27         ` Thomas Gleixner
2026-03-16 21:01           ` Mathieu Desnoyers
2026-03-16 22:19             ` Thomas Gleixner
2026-03-16 22:30               ` Mathieu Desnoyers
2026-03-16 23:29                 ` Thomas Gleixner
2026-03-20 18:13                   ` Mathieu Desnoyers
2026-03-24 21:35                     ` Thomas Gleixner
2026-03-25 14:12                       ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e9b6192-ffd3-4d8e-9430-763bbcf49e21@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=andrealmeid@igalia.com \
    --cc=arnd@arndb.de \
    --cc=bigeasy@linutronix.de \
    --cc=carlos@redhat.com \
    --cc=dalias@aerifal.cx \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=fweimer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=triegel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome