From: Benno Lossin <benno.lossin@proton.me>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@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@samsung.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Kees Cook" <keescook@chromium.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Daniel Xu" <dxu@dxuuu.xyz>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 6/7] rust: file: add `DeferredFdCloser`
Date: Fri, 08 Dec 2023 17:39:01 +0000 [thread overview]
Message-ID: <MjDmZBGV04fVI1qzhceEjQgcmoBuo3YoVuiQdANKj9F1Ux5JFKud8hQpfeyLXI0O5HG6qicKFaYYzM7JAgR_kVQfMCeVdN6t7PjbPaz0D0U=@proton.me> (raw)
In-Reply-To: <20231206-alice-file-v2-6-af617c0d9d94@google.com>
On 12/6/23 12:59, Alice Ryhl wrote:
> + /// Schedule a task work that closes the file descriptor when this task returns to userspace.
> + ///
> + /// Fails if this is called from a context where we cannot run work when returning to
> + /// userspace. (E.g., from a kthread.)
> + pub fn close_fd(self, fd: u32) -> Result<(), DeferredFdCloseError> {
> + use bindings::task_work_notify_mode_TWA_RESUME as TWA_RESUME;
> +
> + // In this method, we schedule the task work before closing the file. This is because
> + // scheduling a task work is fallible, and we need to know whether it will fail before we
> + // attempt to close the file.
> +
> + // SAFETY: Getting a pointer to current is always safe.
> + let current = unsafe { bindings::get_current() };
> +
> + // SAFETY: Accessing the `flags` field of `current` is always safe.
> + let is_kthread = (unsafe { (*current).flags } & bindings::PF_KTHREAD) != 0;
Since Boqun brought to my attention that we already have a wrapper for
`get_current()`, how about you use it here as well?
> + if is_kthread {
> + return Err(DeferredFdCloseError::TaskWorkUnavailable);
> + }
> +
> + // This disables the destructor of the box, so the allocation is not cleaned up
> + // automatically below.
> + let inner = Box::into_raw(self.inner);
Importantly this also lifts the uniqueness requirement (maybe add this
to the comment?).
> +
> + // The `callback_head` field is first in the struct, so this cast correctly gives us a
> + // pointer to the field.
> + let callback_head = inner.cast::<bindings::callback_head>();
> + // SAFETY: This pointer offset operation does not go out-of-bounds.
> + let file_field = unsafe { core::ptr::addr_of_mut!((*inner).file) };
> +
> + // SAFETY: The `callback_head` pointer is compatible with the `do_close_fd` method.
Also, `callback_head` is valid, since it is derived from...
> + unsafe { bindings::init_task_work(callback_head, Some(Self::do_close_fd)) };
> + // SAFETY: The `callback_head` pointer points at a valid and fully initialized task work
> + // that is ready to be scheduled.
> + //
> + // If the task work gets scheduled as-is, then it will be a no-op. However, we will update
> + // the file pointer below to tell it which file to fput.
> + let res = unsafe { bindings::task_work_add(current, callback_head, TWA_RESUME) };
> +
> + if res != 0 {
> + // SAFETY: Scheduling the task work failed, so we still have ownership of the box, so
> + // we may destroy it.
> + unsafe { drop(Box::from_raw(inner)) };
> +
> + return Err(DeferredFdCloseError::TaskWorkUnavailable);
Just curious, what could make the `task_work_add` call fail? I imagine
an OOM situation, but is that all?
> + }
> +
> + // SAFETY: Just an FFI call. This is safe no matter what `fd` is.
I took a look at the C code and there I found this comment:
/*
* variant of close_fd that gets a ref on the file for later fput.
* The caller must ensure that filp_close() called on the file.
*/
And while you do call `filp_close` later, this seems like a safety
requirement to me.
Also, you do not call it when `file` is null, which I imagine to be
fine, but I do not know that since the C comment does not cover that
case.
> + let file = unsafe { bindings::close_fd_get_file(fd) };
> + if file.is_null() {
> + // We don't clean up the task work since that might be expensive if the task work queue
> + // is long. Just let it execute and let it clean up for itself.
> + return Err(DeferredFdCloseError::BadFd);
> + }
> +
> + // SAFETY: The `file` pointer points at a valid file.
> + unsafe { bindings::get_file(file) };
> +
> + // SAFETY: Due to the above `get_file`, even if the current task holds an `fdget` to
> + // this file right now, the refcount will not drop to zero until after it is released
> + // with `fdput`. This is because when using `fdget`, you must always use `fdput` before
Shouldn't this be "the refcount will not drop to zero until after it is
released with `fput`."?
Why is this the SAFETY comment for `filp_close`? I am not understanding
the requirement on that function that needs this. This seems more a
justification for accessing `file` inside `do_close_fd`. In which case I
think it would be better to make it a type invariant of
`DeferredFdCloserInner`.
> + // returning to userspace, and our task work runs after any `fdget` users have returned
> + // to userspace.
> + //
> + // Note: fl_owner_t is currently a void pointer.
> + unsafe { bindings::filp_close(file, (*current).files as bindings::fl_owner_t) };
> +
> + // We update the file pointer that the task work is supposed to fput.
> + //
> + // SAFETY: Task works are executed on the current thread once we return to userspace, so
> + // this write is guaranteed to happen before `do_close_fd` is called, which means that a
> + // race is not possible here.
> + //
> + // It's okay to pass this pointer to the task work, since we just acquired a refcount with
> + // the previous call to `get_file`. Furthermore, the refcount will not drop to zero during
> + // an `fdget` call, since we defer the `fput` until after returning to userspace.
> + unsafe { *file_field = file };
A synchronization question: who guarantees that this write is actually
available to the cpu that executes `do_close_fd`? Is there some
synchronization run when returning to userspace?
> +
> + Ok(())
> + }
> +
> + // SAFETY: This function is an implementation detail of `close_fd`, so its safety comments
> + // should be read in extension of that method.
Why not use this?:
- `inner` is a valid pointer to the `callback_head` field of a valid
`DeferredFdCloserInner`.
- `inner` has exclusive access to the pointee and owns the allocation.
- `inner` originates from a call to `Box::into_raw`.
> + unsafe extern "C" fn do_close_fd(inner: *mut bindings::callback_head) {
> + // SAFETY: In `close_fd` we use this method together with a pointer that originates from a
> + // `Box<DeferredFdCloserInner>`, and we have just been given ownership of that allocation.
> + let inner = unsafe { Box::from_raw(inner as *mut DeferredFdCloserInner) };
Use `.cast()`.
> + if !inner.file.is_null() {
> + // SAFETY: This drops a refcount we acquired in `close_fd`. Since this callback runs in
> + // a task work after we return to userspace, it is guaranteed that the current thread
> + // doesn't hold this file with `fdget`, as `fdget` must be released before returning to
> + // userspace.
> + unsafe { bindings::fput(inner.file) };
> + }
> + // Free the allocation.
> + drop(inner);
> + }
> +}
> +
> +/// Represents a failure to close an fd in a deferred manner.
> +#[derive(Copy, Clone, Eq, PartialEq)]
> +pub enum DeferredFdCloseError {
> + /// Closing the fd failed because we were unable to schedule a task work.
> + TaskWorkUnavailable,
> + /// Closing the fd failed because the fd does not exist.
> + BadFd,
> +}
> +
> +impl From<DeferredFdCloseError> for Error {
> + fn from(err: DeferredFdCloseError) -> Error {
> + match err {
> + DeferredFdCloseError::TaskWorkUnavailable => ESRCH,
This error reads "No such process", I am not sure if that is the best
way to express the problem in that situation. I took a quick look at the
other error codes, but could not find a better fit. Do you have any
better ideas? Or is this the error that C binder uses?
--
Cheers,
Benno
> + DeferredFdCloseError::BadFd => EBADF,
> + }
> + }
> +}
next prev parent reply other threads:[~2023-12-08 17:39 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 11:59 [PATCH v2 0/7] File abstractions needed by Rust Binder Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 1/7] rust: file: add Rust abstraction for `struct file` Alice Ryhl
2023-12-08 9:48 ` Benno Lossin
2023-12-11 15:34 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 2/7] rust: cred: add Rust abstraction for `struct cred` Alice Ryhl
2023-12-08 16:13 ` Benno Lossin
2023-12-11 15:34 ` Alice Ryhl
2023-12-11 1:19 ` Boqun Feng
2023-12-11 15:34 ` Alice Ryhl
2023-12-11 17:35 ` Boqun Feng
2023-12-11 19:30 ` Benno Lossin
2023-12-12 9:40 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 3/7] rust: security: add abstraction for secctx Alice Ryhl
2023-12-08 16:22 ` Benno Lossin
2023-12-11 15:34 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 4/7] rust: file: add `FileDescriptorReservation` Alice Ryhl
2023-12-08 7:37 ` Benno Lossin
2023-12-08 7:43 ` Alice Ryhl
2023-12-11 15:34 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 5/7] rust: file: add `Kuid` wrapper Alice Ryhl
2023-12-06 12:34 ` Peter Zijlstra
2023-12-06 12:57 ` Alice Ryhl
2023-12-06 13:40 ` Peter Zijlstra
2023-12-06 13:50 ` Alice Ryhl
2023-12-06 16:49 ` Nick Desaulniers
2023-12-08 16:31 ` Miguel Ojeda
2023-12-08 16:57 ` Peter Zijlstra
2023-12-08 18:18 ` Kees Cook
2023-12-08 20:45 ` Peter Zijlstra
2023-12-08 20:57 ` Kees Cook
2023-12-11 21:13 ` Kent Overstreet
2023-12-08 16:40 ` Benno Lossin
2023-12-08 16:43 ` Boqun Feng
2023-12-11 15:58 ` Kent Overstreet
2023-12-11 17:04 ` Benno Lossin
2023-12-11 15:34 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 6/7] rust: file: add `DeferredFdCloser` Alice Ryhl
2023-12-08 17:39 ` Benno Lossin [this message]
2023-12-11 15:34 ` Alice Ryhl
2023-12-11 17:23 ` Benno Lossin
2023-12-12 9:35 ` Alice Ryhl
2023-12-12 16:50 ` Benno Lossin
2023-12-11 17:41 ` Boqun Feng
2023-12-12 1:25 ` Boqun Feng
2023-12-12 20:57 ` Boqun Feng
2023-12-13 11:04 ` Alice Ryhl
2023-12-06 11:59 ` [PATCH v2 7/7] rust: file: add abstraction for `poll_table` Alice Ryhl
2023-12-08 17:53 ` Benno Lossin
2023-12-12 9:59 ` Alice Ryhl
2023-12-12 17:01 ` Benno Lossin
2023-12-13 1:35 ` Boqun Feng
2023-12-13 9:12 ` Benno Lossin
2023-12-13 10:09 ` Alice Ryhl
2023-12-13 17:05 ` Boqun Feng
2023-12-13 11:02 ` Alice Ryhl
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='MjDmZBGV04fVI1qzhceEjQgcmoBuo3YoVuiQdANKj9F1Ux5JFKud8hQpfeyLXI0O5HG6qicKFaYYzM7JAgR_kVQfMCeVdN6t7PjbPaz0D0U=@proton.me' \
--to=benno.lossin@proton.me \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=cmllamas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dxu@dxuuu.xyz \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tkjos@android.com \
--cc=viro@zeniv.linux.org.uk \
--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;
as well as URLs for NNTP newsgroup(s).