Re: rust_binder: use KVVec for files_to_translate
From: Alice Ryhl
Date: Thu Aug 27 2026 - 03:11:07 EST
On Tue, Aug 25, 2026 at 07:17:12PM +0300, scadastrangelove wrote:
> From: Sergey Gordeychik <scadastrangelove@xxxxxxxxx>
>
> 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@xxxxxxxxx>
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@xxxxxxxxxx>
Alice