From: "Benno Lossin" <lossin@kernel.org>
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: "Marcelo Moreira" <marcelomoreira1905@gmail.com>,
<benno.lossin@proton.me>, <ojeda@kernel.org>,
<rust-for-linux@vger.kernel.org>, <skhan@linuxfoundation.org>,
<linux-kernel-mentees@lists.linuxfoundation.org>,
<~lkcamp/patches@lists.sr.ht>
Subject: Re: [PATCH v2] rust: doc: Clarify safety invariants for Revocable type
Date: Fri, 23 May 2025 10:31:14 +0200 [thread overview]
Message-ID: <DA3EEUYQET6K.2MXO7RY206FOL@kernel.org> (raw)
In-Reply-To: <2390300b-49d0-4fe5-81b5-5a9f3fd9e300@kernel.org>
On Fri May 23, 2025 at 9:19 AM CEST, Danilo Krummrich wrote:
> On 5/19/25 2:26 PM, Benno Lossin wrote:
>> I'm not happy with the sentence structure, so how about:
>>
>> * `data` is valid for reads in two cases:
>> * while `is_available` is true, or
>> * while the RCU read-side lock is taken and it was acquired while `is_available` was `true`.
>
> That sounds good!
>
>> * `data` is valid for writes when `is_available` was atomically changed from `true` to `false`.
>>
>> The last one is needed in order to call `drop_in_place`.
>
> If think for this you have the same conditional, in the RCU case you can't call
> drop_in_place() immediately after is_available was altered, but have to wait for
> synchronize_rcu() to return.
Oh yeah, how about:
* `data` is valid for writes when `is_available` was atomically changed from `true to `false`
and no thread is holding an RCU read-side lock that was acquired prior to the change in
`is_available`.
---
Cheers,
Benno
prev parent reply other threads:[~2025-05-23 8:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-03 14:53 [PATCH v2] rust: doc: Clarify safety invariants for Revocable type Marcelo Moreira
2025-05-09 10:10 ` Benno Lossin
2025-05-17 0:03 ` Marcelo Moreira
2025-05-17 8:19 ` Benno Lossin
2025-05-17 9:54 ` Danilo Krummrich
2025-05-17 19:09 ` Benno Lossin
2025-05-19 8:50 ` Danilo Krummrich
2025-05-19 9:18 ` Benno Lossin
2025-05-19 9:55 ` Danilo Krummrich
2025-05-19 11:10 ` Benno Lossin
2025-05-19 11:37 ` Danilo Krummrich
2025-05-19 12:26 ` Benno Lossin
2025-05-23 0:13 ` Marcelo Moreira
2025-05-23 8:42 ` Benno Lossin
2025-05-23 8:55 ` Danilo Krummrich
2025-05-23 11:53 ` Benno Lossin
2025-05-26 2:10 ` Marcelo Moreira
2025-05-23 7:19 ` Danilo Krummrich
2025-05-23 8:31 ` Benno Lossin [this message]
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=DA3EEUYQET6K.2MXO7RY206FOL@kernel.org \
--to=lossin@kernel.org \
--cc=benno.lossin@proton.me \
--cc=dakr@kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=marcelomoreira1905@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=~lkcamp/patches@lists.sr.ht \
/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.