From: Andreas Hindborg <nmi@metaspace.dk>
To: Benno Lossin <benno.lossin@proton.me>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Christoph Hellwig" <hch@lst.de>,
"Keith Busch" <kbusch@kernel.org>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Bart Van Assche" <bvanassche@acm.org>,
"Hannes Reinecke" <hare@suse.de>,
"Ming Lei" <ming.lei@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Matthew Wilcox" <willy@infradead.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>,
"Alice Ryhl" <aliceryhl@google.com>,
"Chaitanya Kulkarni" <chaitanyak@nvidia.com>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Yexuan Yang" <1182282462@bupt.edu.cn>,
"Sergio González Collado" <sergio.collado@gmail.com>,
"Joel Granados" <j.granados@samsung.com>,
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
"Niklas Cassel" <Niklas.Cassel@wdc.com>,
"Philipp Stanner" <pstanner@redhat.com>,
"Conor Dooley" <conor@kernel.org>,
"Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>,
"Matias Bjørling" <m@bjorling.me>,
"open list" <linux-kernel@vger.kernel.org>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"gost.dev@samsung.com" <gost.dev@samsung.com>
Subject: Re: [PATCH v4 1/3] rust: block: introduce `kernel::block::mq` module
Date: Tue, 04 Jun 2024 11:59:49 +0200 [thread overview]
Message-ID: <87y17lqb8q.fsf@metaspace.dk> (raw)
In-Reply-To: <925fe0fe-9303-4f49-b473-c3a3ecc5e2e6@proton.me> (Benno Lossin's message of "Mon, 03 Jun 2024 18:26:08 +0000")
Benno Lossin <benno.lossin@proton.me> writes:
[...]
>>>> +impl<T: Operations> OperationsVTable<T> {
>>>> + /// This function is called by the C kernel. A pointer to this function is
>>>> + /// installed in the `blk_mq_ops` vtable for the driver.
>>>> + ///
>>>> + /// # Safety
>>>> + ///
>>>> + /// - The caller of this function must ensure `bd` is valid
>>>> + /// and initialized. The pointees must outlive this function.
>>>
>>> Until when do the pointees have to be alive? "must outlive this
>>> function" could also be the case if the pointees die immediately after
>>> this function returns.
>>
>> It should not be plural. What I intended to communicate is that what
>> `bd` points to must be valid for read for the duration of the function
>> call. I think that is what "The pointee must outlive this function"
>> states? Although when we talk about lifetime of an object pointed to by
>> a pointer, I am not sure about the correct way to word this. Do we talk
>> about the lifetime of the pointer or the lifetime of the pointed to
>> object (the pointee). We should not use the same wording for the pointer
>> and the pointee.
>>
>> How about:
>>
>> /// - The caller of this function must ensure that the pointee of `bd` is
>> /// valid for read for the duration of this function.
>
> But this is not enough for it to be sound, right? You create an `ARef`
> from `bd.rq`, which potentially lives forever. You somehow need to
> require that the pointer `bd` stays valid for reads and (synchronized)
> writes until the request is ended (probably via `blk_mq_end_request`).
The statement does not say anything about `*((*bd).rq)`. `*bd` needs to
be valid only for the duration of the function. It carries a pointer to
a `struct request` in the `rq` field. The pointee of that pointer must
be exclusively owned by the driver until the request is done.
Maybe like this:
# Safety
- The caller of this function must ensure that the pointee of `bd` is
valid for read for the duration of this function.
- This function must be called for an initialized and live `hctx`. That
is, `Self::init_hctx_callback` was called and
`Self::exit_hctx_callback()` was not yet called.
- `(*bd).rq` must point to an initialized and live `bindings:request`.
That is, `Self::init_request_callback` was called but
`Self::exit_request_callback` was not yet called for the request.
- `(*bd).rq` must be owned by the driver. That is, the block layer must
promise to not access the request until the driver calls
`bindings::blk_mq_end_request` for the request.
[...]
>>>> + /// This function is called by the C kernel. A pointer to this function is
>>>> + /// installed in the `blk_mq_ops` vtable for the driver.
>>>> + ///
>>>> + /// # Safety
>>>> + ///
>>>> + /// This function may only be called by blk-mq C infrastructure. `set` must
>
> `set` doesn't exist (`_set` does), you are also not using this
> requirement.
Would be nice if there was a way in `rustdoc` no name arguments
explicitly.
>
>>>> + /// point to an initialized `TagSet<T>`.
>>>> + unsafe extern "C" fn init_request_callback(
>>>> + _set: *mut bindings::blk_mq_tag_set,
>>>> + rq: *mut bindings::request,
>>>> + _hctx_idx: core::ffi::c_uint,
>>>> + _numa_node: core::ffi::c_uint,
>>>> + ) -> core::ffi::c_int {
>>>> + from_result(|| {
>>>> + // SAFETY: The `blk_mq_tag_set` invariants guarantee that all
>>>> + // requests are allocated with extra memory for the request data.
>>>
>>> What guarantees that the right amount of memory has been allocated?
>>> AFAIU that is guaranteed by the `TagSet` (but there is no invariant).
>>
>> It is by C API contract. `TagSet`::try_new` (now `new`) writes
>> `cmd_size` into the `struct blk_mq_tag_set`. That is picked up by
>> `blk_mq_alloc_tag_set` to allocate the right amount of space for each request.
>>
>> The invariant here is on the C type. Perhaps the wording is wrong. I am
>> not exactly sure how to express this. How about this:
>>
>> // SAFETY: We instructed `blk_mq_alloc_tag_set` to allocate requests
>> // with extra memory for the request data when we called it in
>> // `TagSet::new`.
>
> I think you need a safety requirement on the function: `rq` points to a
> valid `Request`. Then you could just use `Request::wrapper_ptr` instead
> of the line below.
I cannot require `rq` to point to a valid `Request`, because that would
require the private data area to already be initialized as a valid
`RequestDataWrapper`. Using the `wrapper_ptr` is good 👍. How is this:
/// # Safety
///
/// - This function may only be called by blk-mq C infrastructure.
/// - `_set` must point to an initialized `TagSet<T>`.
/// - `rq` must point to an initialized `bindings::request`.
/// - The allocation pointed to by `rq` must be at the size of `Request`
/// plus the size of `RequestDataWrapper`.
BR Andreas
next prev parent reply other threads:[~2024-06-04 9:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-01 13:40 [PATCH v4 0/3] Rust block device driver API and null block driver Andreas Hindborg
2024-06-01 13:40 ` [PATCH v4 1/3] rust: block: introduce `kernel::block::mq` module Andreas Hindborg
2024-06-02 20:08 ` Benno Lossin
2024-06-03 12:01 ` Andreas Hindborg
2024-06-03 18:26 ` Benno Lossin
2024-06-04 9:59 ` Andreas Hindborg [this message]
2024-06-10 20:07 ` Benno Lossin
2024-06-01 13:40 ` [PATCH v4 2/3] rust: block: add rnull, Rust null_blk implementation Andreas Hindborg
2024-06-01 14:24 ` Keith Busch
2024-06-01 15:36 ` Andreas Hindborg
2024-06-01 16:01 ` Keith Busch
2024-06-01 16:59 ` Andreas Hindborg
2024-06-01 19:53 ` Andreas Hindborg
2024-06-02 3:49 ` Matthew Wilcox
2024-06-02 9:27 ` Andreas Hindborg
2024-06-03 9:05 ` Hannes Reinecke
2024-06-03 9:06 ` Alice Ryhl
2024-06-03 12:05 ` Andreas Hindborg
2024-06-03 12:07 ` Andreas Hindborg
2024-06-01 13:40 ` [PATCH v4 3/3] MAINTAINERS: add entry for Rust block device driver API Andreas Hindborg
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=87y17lqb8q.fsf@metaspace.dk \
--to=nmi@metaspace.dk \
--cc=1182282462@bupt.edu.cn \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Niklas.Cassel@wdc.com \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=conor@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dlemoal@kernel.org \
--cc=gary@garyguo.net \
--cc=gost.dev@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=j.granados@samsung.com \
--cc=kbusch@kernel.org \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=m@bjorling.me \
--cc=mcgrof@kernel.org \
--cc=ming.lei@redhat.com \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=sergio.collado@gmail.com \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.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