linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Benno Lossin" <lossin@kernel.org>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	rust-for-linux@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] rust: Update PCI binding safety comments and add inline compiler hint
Date: Tue, 22 Jul 2025 14:49:33 +0200	[thread overview]
Message-ID: <DBILHBVA0NKJ.3R2QIVE9QIMM3@kernel.org> (raw)
In-Reply-To: <DBIKM7U4TSB8.17MTNSR81W8F3@kernel.org>

On Tue Jul 22, 2025 at 2:08 PM CEST, Benno Lossin wrote:
> On Tue Jul 22, 2025 at 1:35 PM CEST, Alice Ryhl wrote:
>> On Tue, Jul 22, 2025 at 12:57 PM Benno Lossin <lossin@kernel.org> wrote:
>>>
>>> On Tue Jul 22, 2025 at 11:51 AM CEST, Danilo Krummrich wrote:
>>> > I think they're good, but we're pretty late in the cycle now. That should be
>>> > fine though, we can probably take them through the nova tree, or in the worst
>>> > case share a tag, if needed.
>>> >
>>> > Given that, it would probably be good to add the Guarantee section on as_raw(),
>>> > as proposed by Benno, right away.
>>> >
>>> > @Benno: Any proposal on what this section should say?
>>>
>>> At a minimum I'd say "The returned pointer is valid.", but that doesn't
>>> really say for what it's valid... AFAIK you're mostly using this pointer
>>> to pass it to the C side, in that case, how about:
>>>
>>>     /// # Guarantees
>>>     ///
>>>     /// The returned pointer is valid for reads and writes from the C side for as long as `self` exists.
>>>
>>> Maybe we need to change it a bit more, but let's just start with this.
>>>
>>> (If you're also using the pointer from Rust, then we need to make
>>> changes)
>>
>> Honestly I think this is a bit over the top. I wouldn't bother adding
>> a section like that to every single as_raw() method out there.
>
> Hmm. And then just assume that these kinds of functions return valid
> pointers? I get that this is annoying to put on every function...
>
> Another option would be to have a `Ptr<'a, T>` type that is a valid
> pointer, but doesn't allow writing/reading safely (you need to justify
> why it's not a data race). And for FFI there could be an `as_ptr`
> function.

I don't understand where's the difference between the two. For FFI calls we'd
also have to justify it's not a data race, no?

The only guarantee we take as granted from as_raw() is that it returns a raw
pointer to the wrapped FFI type in Self, i.e. it points to valid memory. Any
additional guarantees may come from the context where the pointer is used and
which specific fields it is used to access.

  reply	other threads:[~2025-07-22 12:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-10  2:24 [PATCH v2 1/2] rust: Update PCI binding safety comments and add inline compiler hint Alistair Popple
2025-07-10  2:24 ` [PATCH v2 2/2] rust: Add several miscellaneous PCI helpers Alistair Popple
2025-07-10  8:01 ` [PATCH v2 1/2] rust: Update PCI binding safety comments and add inline compiler hint Benno Lossin
2025-07-10 23:22   ` Alistair Popple
2025-07-11  8:11     ` Benno Lossin
2025-07-11 15:03     ` Danilo Krummrich
2025-07-11 15:02   ` Danilo Krummrich
2025-07-11 18:30     ` Benno Lossin
2025-07-11 19:33       ` Danilo Krummrich
2025-07-11 20:46         ` Benno Lossin
2025-07-22  5:17           ` Alistair Popple
2025-07-22  9:51             ` Danilo Krummrich
2025-07-22 10:57               ` Benno Lossin
2025-07-22 11:02                 ` Danilo Krummrich
2025-07-22 11:21                   ` Benno Lossin
2025-07-22 11:36                     ` Danilo Krummrich
2025-07-22 11:35                 ` Alice Ryhl
2025-07-22 12:08                   ` Benno Lossin
2025-07-22 12:49                     ` Danilo Krummrich [this message]
2025-07-23 14:25                       ` Benno Lossin
2025-07-28  0:09               ` Alistair Popple
2025-07-22 10:49             ` Benno Lossin

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=DBILHBVA0NKJ.3R2QIVE9QIMM3@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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;
as well as URLs for NNTP newsgroup(s).