From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
paulmck <paulmck@linux.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>, Paul Turner <pjt@google.com>,
linux-api <linux-api@vger.kernel.org>,
stable <stable@vger.kernel.org>,
Florian Weimer <fw@deneb.enyo.de>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH for 5.5 2/2] rseq/selftests: Clarify rseq_prepare_unload() helper requirements
Date: Fri, 20 Dec 2019 15:32:06 -0500 (EST) [thread overview]
Message-ID: <190540378.14355.1576873926104.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <2ad7d561-2cbc-09c2-2806-97c3be3727e2@linuxfoundation.org>
----- On Dec 20, 2019, at 3:27 PM, Shuah Khan skhan@linuxfoundation.org wrote:
> Hi Mathieu,
>
> On 12/20/19 1:12 PM, Mathieu Desnoyers wrote:
>> The rseq.h UAPI now documents that the rseq_cs field must be cleared
>> before reclaiming memory that contains the targeted struct rseq_cs, but
>> also that the rseq_cs field must be cleared before reclaiming memory of
>> the code pointed to by the rseq_cs start_ip and post_commit_offset
>> fields.
>>
>> While we can expect that use of dlclose(3) will typically unmap
>> both struct rseq_cs and its associated code at once, nothing would
>> theoretically prevent a JIT from reclaiming the code without
>> reclaiming the struct rseq_cs, which would erroneously allow the
>> kernel to consider new code which is not a rseq critical section
>> as a rseq critical section following a code reclaim.
>>
>> Suggested-by: Florian Weimer <fw@deneb.enyo.de>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>
>> Cc: Florian Weimer <fw@deneb.enyo.de>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Cc: "Paul E. McKenney" <paulmck@linux.ibm.com>
>> Cc: Boqun Feng <boqun.feng@gmail.com>
>> Cc: "H . Peter Anvin" <hpa@zytor.com>
>> Cc: Paul Turner <pjt@google.com>
>> Cc: Dmitry Vyukov <dvyukov@google.com>
>> ---
>> tools/testing/selftests/rseq/rseq.h | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/testing/selftests/rseq/rseq.h
>> b/tools/testing/selftests/rseq/rseq.h
>> index d40d60e7499e..15cbd51d0818 100644
>> --- a/tools/testing/selftests/rseq/rseq.h
>> +++ b/tools/testing/selftests/rseq/rseq.h
>> @@ -149,11 +149,13 @@ static inline void rseq_clear_rseq_cs(void)
>> /*
>> * rseq_prepare_unload() should be invoked by each thread executing a rseq
>> * critical section at least once between their last critical section and
>> - * library unload of the library defining the rseq critical section
>> - * (struct rseq_cs). This also applies to use of rseq in code generated by
>> - * JIT: rseq_prepare_unload() should be invoked at least once by each
>> - * thread executing a rseq critical section before reclaim of the memory
>> - * holding the struct rseq_cs.
>> + * library unload of the library defining the rseq critical section (struct
>> + * rseq_cs) or the code refered to by the struct rseq_cs start_ip and
>
> Nit: referred instead of refered
Good catch. I've done the same error in patch 1/2. I'll update both and
resend.
Thanks!
Mathieu
>
>> + * post_commit_offset fields. This also applies to use of rseq in code
>> + * generated by JIT: rseq_prepare_unload() should be invoked at least once by
>> + * each thread executing a rseq critical section before reclaim of the memory
>> + * holding the struct rseq_cs or reclaim of the code pointed to by struct
>> + * rseq_cs start_ip and post_commit_offset fields.
>> */
>> static inline void rseq_prepare_unload(void)
>> {
>>
>
> thanks,
> -- Shuah
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2019-12-20 20:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 20:12 [PATCH for 5.5 1/2] rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements Mathieu Desnoyers
2019-12-20 20:12 ` [PATCH for 5.5 2/2] rseq/selftests: Clarify rseq_prepare_unload() helper requirements Mathieu Desnoyers
2019-12-20 20:27 ` Shuah Khan
2019-12-20 20:32 ` Mathieu Desnoyers [this message]
2019-12-20 20:37 ` [PATCH for 5.5 1/2] rseq: Fix: Clarify rseq.h UAPI rseq_cs memory reclaim requirements Florian Weimer
2019-12-20 20:54 ` Mathieu Desnoyers
2019-12-20 20:57 ` Florian Weimer
2019-12-20 21:15 ` Mathieu Desnoyers
2020-01-06 19:08 ` Mathieu Desnoyers
2020-01-06 19:30 ` Florian Weimer
2020-01-06 20:25 ` 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=190540378.14355.1576873926104.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=dvyukov@google.com \
--cc=fw@deneb.enyo.de \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.