All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Alice Ryhl" <alice@ryhl.io>,
	"Filipe Xavier" <felipeaggger@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	rust-for-linux@vger.kernel.org,
	"Filipe Xavier" <felipe_life@live.com>
Subject: Re: [PATCH] rust: generalize userSliceReader to support any Vec
Date: Mon, 6 Jan 2025 07:31:26 -0800	[thread overview]
Message-ID: <Z3v3TjMfG1CHd05C@tardis.local> (raw)
In-Reply-To: <CAH5fLggzi4-ccTTpbwjC9RaJo-GFne27L8_f68sKsR-c3knY1g@mail.gmail.com>

On Mon, Jan 06, 2025 at 02:34:13PM +0100, Alice Ryhl wrote:
[...]
> > > > ... what if the copy hit a page fault because the target memory (e.g. a
> > > > VVec) is not mapped? Would copy_from_user() handle this? Or would it
> > > > return a different error code than `EFAULT`?
> > > How could the memory not be mapped? A vector lets us obtain a &[u8] to the
> > > memory, which isn't valid if it's not mapped.
> > >
> >
> > I mistakenly thought that vmalloc()'d memory can be swapped out, which
> > is not the case. So you're right the memory must be mapped.
> >
> > But the usage question still exists: do you have an usage case for
> > reading userspace memory into a `VVec`?
> 
> I believe there's a use-case for a KVVec in Binder to avoid maximum
> sizes for a certain array.
> 

I see, thank you. `KVVec` makes a lot of senses here. I would still
suggest putting the details about the potential usage in the commit
message. Besides, Filipe, could you Cc memory management people next
time? Thanks!

Regards,
Boqun

> Alice

      reply	other threads:[~2025-01-06 15:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-22 16:37 [PATCH] rust: generalize userSliceReader to support any Vec Filipe Xavier
2024-12-22 17:20 ` Boqun Feng
2024-12-30 13:21   ` Alice Ryhl
2024-12-30 16:23     ` Boqun Feng
2025-01-06 13:34       ` Alice Ryhl
2025-01-06 15:31         ` Boqun Feng [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=Z3v3TjMfG1CHd05C@tardis.local \
    --to=boqun.feng@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=alice@ryhl.io \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=felipe_life@live.com \
    --cc=felipeaggger@gmail.com \
    --cc=gary@garyguo.net \
    --cc=ojeda@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 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.