From: Matthew Wilcox <willy@infradead.org>
To: Wedson Almeida Filho <wedsonaf@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fsdevel@vger.kernel.org, rust-for-linux@vger.kernel.org,
Wedson Almeida Filho <walmeida@microsoft.com>
Subject: Re: [RFC PATCH 09/19] rust: folio: introduce basic support for folios
Date: Wed, 18 Oct 2023 18:17:22 +0100 [thread overview]
Message-ID: <ZTATIhi9U6ObAnN7@casper.infradead.org> (raw)
In-Reply-To: <20231018122518.128049-10-wedsonaf@gmail.com>
On Wed, Oct 18, 2023 at 09:25:08AM -0300, Wedson Almeida Filho wrote:
> +void *rust_helper_kmap(struct page *page)
> +{
> + return kmap(page);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_kmap);
> +
> +void rust_helper_kunmap(struct page *page)
> +{
> + kunmap(page);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_kunmap);
I'm not thrilled by exposing kmap()/kunmap() to Rust code. The vast
majority of code really only needs kmap_local_*() / kunmap_local().
Can you elaborate on why you need the old kmap() in new Rust code?
> +void rust_helper_folio_set_error(struct folio *folio)
> +{
> + folio_set_error(folio);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_folio_set_error);
I'm trying to get rid of the error flag. Can you share the situations
in which you've needed the error flag? Or is it just copying existing
practices?
> + /// Returns the byte position of this folio in its file.
> + pub fn pos(&self) -> i64 {
> + // SAFETY: The folio is valid because the shared reference implies a non-zero refcount.
> + unsafe { bindings::folio_pos(self.0.get()) }
> + }
I think it's a mistake to make file positions an i64. I estimate 64
bits will not be enough by 2035-2040. We should probably have a numeric
type which is i64 on 32-bit and isize on other CPUs (I also project
64-bit pointers will be insufficient by 2035-2040 and so we will have
128-bit pointers around the same time, so we're not going to need i128
file offsets with i64 pointers).
> +/// A [`Folio`] that has a single reference to it.
> +pub struct UniqueFolio(pub(crate) ARef<Folio>);
How do we know it only has a single reference? Do you mean "has at
least one reference"? Or am I confusing Rust's notion of a reference
with Linux's notion of a reference?
> +impl UniqueFolio {
> + /// Maps the contents of a folio page into a slice.
> + pub fn map_page(&self, page_index: usize) -> Result<MapGuard<'_>> {
> + if page_index >= self.0.size() / bindings::PAGE_SIZE {
> + return Err(EDOM);
> + }
> +
> + // SAFETY: We just checked that the index is within bounds of the folio.
> + let page = unsafe { bindings::folio_page(self.0 .0.get(), page_index) };
> +
> + // SAFETY: `page` is valid because it was returned by `folio_page` above.
> + let ptr = unsafe { bindings::kmap(page) };
Surely this can be:
let ptr = unsafe { bindings::kmap_local_folio(folio, page_index * PAGE_SIZE) };
> + // SAFETY: We just mapped `ptr`, so it's valid for read.
> + let data = unsafe { core::slice::from_raw_parts(ptr.cast::<u8>(), bindings::PAGE_SIZE) };
Can we hide away the "if this isn't a HIGHMEM system, this maps to the
end of the folio, but if it is, it only maps to the end of the page"
problem here?
next prev parent reply other threads:[~2023-10-18 17:17 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 12:24 [RFC PATCH 00/19] Rust abstractions for VFS Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 01/19] rust: fs: add registration/unregistration of file systems Wedson Almeida Filho
2023-10-18 15:38 ` Benno Lossin
2024-01-10 18:32 ` Wedson Almeida Filho
2024-01-25 9:15 ` Benno Lossin
2023-10-18 12:25 ` [RFC PATCH 02/19] rust: fs: introduce the `module_fs` macro Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 03/19] samples: rust: add initial ro file system sample Wedson Almeida Filho
2023-10-28 16:18 ` Alice Ryhl
2024-01-10 18:25 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 04/19] rust: fs: introduce `FileSystem::super_params` Wedson Almeida Filho
2023-10-18 16:34 ` Benno Lossin
2023-10-28 16:39 ` Alice Ryhl
2023-10-30 8:21 ` Benno Lossin
2023-10-30 21:36 ` Alice Ryhl
2023-10-20 15:04 ` Ariel Miculas (amiculas)
2024-01-03 12:25 ` Andreas Hindborg (Samsung)
2023-10-18 12:25 ` [RFC PATCH 05/19] rust: fs: introduce `INode<T>` Wedson Almeida Filho
2023-10-28 18:00 ` Alice Ryhl
2024-01-03 12:45 ` Andreas Hindborg (Samsung)
2024-01-03 12:54 ` Andreas Hindborg (Samsung)
2024-01-04 5:20 ` Darrick J. Wong
2024-01-04 9:57 ` Andreas Hindborg (Samsung)
2024-01-10 9:45 ` Benno Lossin
2024-01-04 5:14 ` Darrick J. Wong
2024-01-24 18:17 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 06/19] rust: fs: introduce `FileSystem::init_root` Wedson Almeida Filho
2023-10-19 14:30 ` Benno Lossin
2023-10-20 0:52 ` Boqun Feng
2023-10-21 13:48 ` Benno Lossin
2023-10-21 15:57 ` Boqun Feng
2023-10-21 17:01 ` Matthew Wilcox
2023-10-21 19:33 ` Boqun Feng
2023-10-23 5:29 ` Dave Chinner
2023-10-23 12:55 ` Wedson Almeida Filho
2023-10-30 2:29 ` Dave Chinner
2023-10-31 20:49 ` Wedson Almeida Filho
2023-11-08 4:54 ` Dave Chinner
2023-11-08 6:15 ` Wedson Almeida Filho
2023-10-20 0:30 ` Boqun Feng
2023-10-23 12:36 ` Wedson Almeida Filho
2024-01-03 13:29 ` Andreas Hindborg (Samsung)
2024-01-24 4:07 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 07/19] rust: fs: introduce `FileSystem::read_dir` Wedson Almeida Filho
2023-10-21 8:33 ` Benno Lossin
2024-01-03 14:09 ` Andreas Hindborg (Samsung)
2024-01-21 21:00 ` Askar Safin
2024-01-21 21:51 ` Dave Chinner
2023-10-18 12:25 ` [RFC PATCH 08/19] rust: fs: introduce `FileSystem::lookup` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 09/19] rust: folio: introduce basic support for folios Wedson Almeida Filho
2023-10-18 17:17 ` Matthew Wilcox [this message]
2023-10-18 18:32 ` Wedson Almeida Filho
2023-10-18 19:21 ` Matthew Wilcox
2023-10-19 13:25 ` Wedson Almeida Filho
2023-10-20 4:11 ` Matthew Wilcox
2023-10-20 15:17 ` Matthew Wilcox
2023-10-23 12:32 ` Wedson Almeida Filho
2023-10-23 10:48 ` Andreas Hindborg (Samsung)
2023-10-23 14:28 ` Matthew Wilcox
2023-10-24 15:04 ` Ariel Miculas (amiculas)
2023-10-23 12:29 ` Wedson Almeida Filho
2023-10-21 9:21 ` Benno Lossin
2023-10-18 12:25 ` [RFC PATCH 10/19] rust: fs: introduce `FileSystem::read_folio` Wedson Almeida Filho
2023-11-07 22:18 ` Matthew Wilcox
2023-11-07 22:22 ` Al Viro
2023-11-08 0:35 ` Wedson Almeida Filho
2023-11-08 0:56 ` Al Viro
2023-11-08 2:39 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 11/19] rust: fs: introduce `FileSystem::read_xattr` Wedson Almeida Filho
2023-10-18 13:06 ` Ariel Miculas (amiculas)
2023-10-19 13:35 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 12/19] rust: fs: introduce `FileSystem::statfs` Wedson Almeida Filho
2024-01-03 14:13 ` Andreas Hindborg (Samsung)
2024-01-04 5:33 ` Darrick J. Wong
2024-01-24 4:24 ` Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 13/19] rust: fs: introduce more inode types Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 14/19] rust: fs: add per-superblock data Wedson Almeida Filho
2023-10-25 15:51 ` Ariel Miculas (amiculas)
2023-10-26 13:46 ` Ariel Miculas (amiculas)
2024-01-03 14:16 ` Andreas Hindborg (Samsung)
2023-10-18 12:25 ` [RFC PATCH 15/19] rust: fs: add basic support for fs buffer heads Wedson Almeida Filho
2024-01-03 14:17 ` Andreas Hindborg (Samsung)
2023-10-18 12:25 ` [RFC PATCH 16/19] rust: fs: allow file systems backed by a block device Wedson Almeida Filho
2023-10-21 13:39 ` Benno Lossin
2024-01-24 4:14 ` Wedson Almeida Filho
2024-01-03 14:38 ` Andreas Hindborg (Samsung)
2023-10-18 12:25 ` [RFC PATCH 17/19] rust: fs: allow per-inode data Wedson Almeida Filho
2023-10-21 13:57 ` Benno Lossin
2024-01-03 14:39 ` Andreas Hindborg (Samsung)
2023-10-18 12:25 ` [RFC PATCH 18/19] rust: fs: export file type from mode constants Wedson Almeida Filho
2023-10-18 12:25 ` [RFC PATCH 19/19] tarfs: introduce tar fs Wedson Almeida Filho
2023-10-18 16:57 ` Matthew Wilcox
2023-10-18 17:05 ` Wedson Almeida Filho
2023-10-18 17:20 ` Matthew Wilcox
2023-10-18 18:07 ` Wedson Almeida Filho
2024-01-24 5:05 ` Matthew Wilcox
2024-01-24 5:23 ` Matthew Wilcox
2024-01-24 18:26 ` Wedson Almeida Filho
2024-01-24 21:05 ` Dave Chinner
2024-01-24 21:28 ` Matthew Wilcox
2024-01-24 5:34 ` Gao Xiang
2023-10-18 13:40 ` [RFC PATCH 00/19] Rust abstractions for VFS Ariel Miculas (amiculas)
2023-10-18 17:12 ` Wedson Almeida Filho
2023-10-29 20:31 ` Matthew Wilcox
2023-10-31 20:14 ` Wedson Almeida Filho
2024-01-03 18:02 ` Matthew Wilcox
2024-01-03 19:04 ` Wedson Almeida Filho
2024-01-03 19:53 ` Al Viro
2024-01-03 20:38 ` Kent Overstreet
2024-01-04 1:49 ` Matthew Wilcox
2024-01-09 18:25 ` Wedson Almeida Filho
2024-01-09 19:30 ` Matthew Wilcox
2024-01-03 19:14 ` Kent Overstreet
2024-01-03 20:41 ` Al Viro
2024-01-09 19:13 ` Wedson Almeida Filho
2024-01-09 19:25 ` Matthew Wilcox
2024-01-09 19:32 ` Greg Kroah-Hartman
2024-01-10 7:49 ` Wedson Almeida Filho
2024-01-10 7:57 ` Greg Kroah-Hartman
2024-01-10 12:56 ` Matthew Wilcox
2024-01-09 22:19 ` Dave Chinner
2024-01-10 19:19 ` Kent Overstreet
2024-01-24 13:08 ` FUJITA Tomonori
2024-01-24 19:49 ` Kent Overstreet
2024-01-05 0:04 ` David Howells
2024-01-05 15:54 ` Jarkko Sakkinen
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=ZTATIhi9U6ObAnN7@casper.infradead.org \
--to=willy@infradead.org \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kent.overstreet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=walmeida@microsoft.com \
--cc=wedsonaf@gmail.com \
/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).