public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	Raghavendra Rao Ananta <rananta@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Carlos O'Donell <carlos@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	Michael Jeanson <mjeanson@efficios.com>,
	linux-kselftest@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] selftests/rseq: Fix handling of glibc without rseq support
Date: Tue, 14 Jan 2025 19:45:56 -0500	[thread overview]
Message-ID: <28c050bb-d844-4b85-a49b-39f2defc20ef@efficios.com> (raw)
In-Reply-To: <9b7228cf-29ed-4f35-8b8a-b4f8482c434e@linuxfoundation.org>

On 2025-01-14 19:14, Shuah Khan wrote:
> On 1/14/25 07:51, Mathieu Desnoyers wrote:
>> When porting librseq commit:
>>
>> commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
>>
>> from librseq to the kernel selftests, the following line was missed
>> at the end of rseq_init():
>>
>>    rseq_size = get_rseq_kernel_feature_size();
>>
>> which effectively leaves rseq_size initialized to -1U when glibc does not
>> have rseq support. glibc supports rseq from version 2.35 onwards.
>>
>> In a following librseq commit
>>
>> commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
>>
>> to mimic the libc behavior, a new approach is taken: don't set the
>> feature size in 'rseq_size' until at least one thread has successfully
>> registered. This allows using 'rseq_size' in fast-paths to test for both
>> registration status and available features. The caveat is that on libc
>> either all threads are registered or none are, while with bare librseq
>> it is the responsability of the user to register all threads using rseq.
>>
>> This combines the changes from the following librseq commits:
>>
>> commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
>> commit c67d198627c2 ("Only set 'rseq_size' on first thread registration")
>>
>> Fixes: 73a4f5a704a2 ("selftests/rseq: Fix mm_cid test failure")
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> 
> Hi Mathieu,
> 
> Can you double check these commits and make sure these are right
> ones in the mainline rc7?
> 
> I am seeing "Unknown commit id" warnings on all of these - my
> repo is at 6.13 rc7

This is because those are commits in the librseq project at
https://git.kernel.org/pub/scm/libs/librseq/librseq.git/
which is a different tree from the Linux kernel. I am not
sure what is the preferred approach when citing a
commit ID from a different project ?

I've been keeping both rseq selftests and librseq in
sync since 2018. I plan to eventually add a dependency
of the rseq selftests on librseq, but this cannot
happen until we freeze the API and cut a librseq
release.

This was premature before we reached the major milestone
of having extensible rseq support in glibc.

Now that it's merged into glibc (as of last week),
we can start looking forward to a librseq release,
which should eventually eliminate code duplication
with rseq selftests.

Perhaps we should add a Link: to the librseq
repository ?

> 
> Also would you like to add Reported-by for Raghavendra Rao Ananta?

Yes, please. Can you add it as you merge my patch ?

Thanks,

Mathieu

> 
> thanks,
> -- Shuah

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


  reply	other threads:[~2025-01-15  0:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-14 14:51 [PATCH] selftests/rseq: Fix handling of glibc without rseq support Mathieu Desnoyers
2025-01-15  0:14 ` Shuah Khan
2025-01-15  0:45   ` Mathieu Desnoyers [this message]
2025-01-15 17:57     ` Shuah Khan
2025-01-15 19:08       ` 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=28c050bb-d844-4b85-a49b-39f2defc20ef@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=boqun.feng@gmail.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mjeanson@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rananta@google.com \
    --cc=skhan@linuxfoundation.org \
    --cc=stable@vger.kernel.org \
    /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