linux-kernel - Re: [PATCH v3 0/4] rust: alloc: add Vec shrinking methods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af90cbe5-dcfa-46da-83b3-e903134c7f93@zohomail.in>
Date: Wed, 11 Feb 2026 14:11:31 +0530
From: Shivam Kalra <shivamkalra98@...omail.in>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] rust: alloc: add Vec shrinking methods

On 11/02/26 12:21, Alice Ryhl wrote:
> On Wed, Feb 11, 2026 at 2:08 AM Shivam Kalra <shivamkalra98@...il.com> wrote:
>>
>> On 11/02/26 02:41, Danilo Krummrich wrote:
>>> On Tue Feb 10, 2026 at 9:58 PM CET, Alice Ryhl wrote:
>>>> On Tue, Feb 10, 2026 at 9:54 PM Danilo Krummrich <dakr@...nel.org> wrote:
>>>> Yes that's what I meant. Only provide shrink_to() for those. After
>>>> all, if Kmalloc never actually shrinks when you call realloc, what's
>>>> the point of having KVec::shrink_to()?
>>>
>>> Nothing, but eventually we want a generic impl of shrink_to() with A::realloc().
>>> But again, for now that's fine.
>> Thanks for the discussion. Just want to confirm my understanding
>> of the agreed approach:
>>
>> Since VVec and KVVec are type aliases for Vec<T, Vmalloc> and
>> Vec<T, KVmalloc>, implementing shrink_to() on "only VVec and KVVec"
>> means writing separate impl blocks:
>>
>>   impl<T> Vec<T, Vmalloc> { fn shrink_to() { ... } }
>>   impl<T> Vec<T, KVmalloc> { fn shrink_to() { ... } }
>>
>> Is that what you had in mind, with the shrink logic duplicated
>> in both? Or would you prefer a shared impl with a trait bound to
>> avoid duplication?
> 
> I would prefer either a single stand-alone function that both impls
> blocks call, or implementing it for KVmalloc only. Trait is overkill
> here.
> 
> Alice
Thanks Alice. I'll go with the standalone helper function approach
with separate impl blocks for Vec<T, Vmalloc> and Vec<T, KVmalloc>.

Will send v4 in a some time.

Shivam