Re: rust_binder: use KVVec for files_to_translate

[Alice Ryhl <aliceryhl@google.com>]

On Tue, Aug 25, 2026 at 07:17:12PM +0300, scadastrangelove wrote:
> From: Sergey Gordeychik <scadastrangelove@gmail.com>
> 
> The num_fds value in a binder_fd_array_object is bounded by the
> transaction buffer. However, its in-kernel metadata is larger than the
> u32 array on the wire.
> 
> On 64-bit systems, FileEntry occupies 24 bytes. About 900,000 entries
> therefore make files_to_translate request roughly 20.6 MiB of
> physically contiguous memory, triggering a warning in
> __alloc_frozen_pages_noprof.
> 
> translate_fds() later allocates Reservation entries from the same
> count. At 16 bytes per entry, this requires another 13.7 MiB contiguous
> allocation.
> 
> Neither vector requires physical contiguity. Use KVVec for both so
> large allocations can fall back to vmalloc.
> 
> Keep close_on_free as KVec because its u32 storage matches the wire
> representation and does not reach the allocation sizes above.
> 
> Tested under QEMU/KVM. The 900,000-entry reproducer no longer triggers
> a page allocator warning, and a 300,000-entry transaction that repeats
> one valid fd reaches translate_fds() without WARN or BUG.
> 
> Suggested-by: rust-in-peace agentic pipeline
> Signed-off-by: Sergey Gordeychik <scadastrangelove@gmail.com>

A few things. One it looks like you're missing [PATCH] in the email
title. Also, as checkpatch points out, Suggested-by must be an email
address.

Also, should the close_on_free vector also be a KVVec?

Otherwise this looks good to me.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Alice