On Tue, Jul 30, 2024 at 03:58:25PM +0200, Vlastimil Babka wrote: > On 7/30/24 3:14 PM, Danilo Krummrich wrote: > > On Tue, Jul 30, 2024 at 02:15:34PM +0200, Vlastimil Babka wrote: > >> On 7/30/24 3:35 AM, Danilo Krummrich wrote: > >>> On Mon, Jul 29, 2024 at 09:08:16PM +0200, Danilo Krummrich wrote: > >>>> On Fri, Jul 26, 2024 at 10:05:47PM +0200, Danilo Krummrich wrote: > >>>>> On Fri, Jul 26, 2024 at 04:37:43PM +0200, Vlastimil Babka wrote: > >>>>>> On 7/22/24 6:29 PM, Danilo Krummrich wrote: > >>>>>>> Implement vrealloc() analogous to krealloc(). > >>>>>>> > >>>>>>> Currently, krealloc() requires the caller to pass the size of the > >>>>>>> previous memory allocation, which, instead, should be self-contained. > >>>>>>> > >>>>>>> We attempt to fix this in a subsequent patch which, in order to do so, > >>>>>>> requires vrealloc(). > >>>>>>> > >>>>>>> Besides that, we need realloc() functions for kernel allocators in Rust > >>>>>>> too. With `Vec` or `KVec` respectively, potentially growing (and > >>>>>>> shrinking) data structures are rather common. > >>>>>>> > >>>>>>> Signed-off-by: Danilo Krummrich <dakr@xxxxxxxxxx> > >>>>>> > >>>>>> Acked-by: Vlastimil Babka <vbabka@xxxxxxx> > >>>>>> > >>>>>>> --- a/mm/vmalloc.c > >>>>>>> +++ b/mm/vmalloc.c > >>>>>>> @@ -4037,6 +4037,65 @@ void *vzalloc_node_noprof(unsigned long size, int node) > >>>>>>> } > >>>>>>> EXPORT_SYMBOL(vzalloc_node_noprof); > >>>>>>> > >>>>>>> +/** > >>>>>>> + * vrealloc - reallocate virtually contiguous memory; contents remain unchanged > >>>>>>> + * @p: object to reallocate memory for > >>>>>>> + * @size: the size to reallocate > >>>>>>> + * @flags: the flags for the page level allocator > >>>>>>> + * > >>>>>>> + * The contents of the object pointed to are preserved up to the lesser of the > >>>>>>> + * new and old size (__GFP_ZERO flag is effectively ignored). > >>>>>> > >>>>>> Well, technically not correct as we don't shrink. Get 8 pages, kvrealloc to > >>>>>> 4 pages, kvrealloc back to 8 and the last 4 are not zeroed. But it's not > >>>>>> new, kvrealloc() did the same before patch 2/2. > >>>>> > >>>>> Taking it (too) literal, it's not wrong. The contents of the object pointed to > >>>>> are indeed preserved up to the lesser of the new and old size. It's just that > >>>>> the rest may be "preserved" as well. > >>>>> > >>>>> I work on implementing shrink and grow for vrealloc(). In the meantime I think > >>>>> we could probably just memset() spare memory to zero. > >>>> > >>>> Probably, this was a bad idea. Even with shrinking implemented we'd need to > >>>> memset() potential spare memory of the last page to zero, when new_size < > >>>> old_size. > >>>> > >>>> Analogously, the same would be true for krealloc() buckets. That's probably not > >>>> worth it. > >> > >> I think it could remove unexpected bad surprises with the API so why not > >> do it. > > > > We'd either need to do it *every* time we shrink an allocation on spec, or we > > only do it when shrinking with __GFP_ZERO flag set, which might be a bit > > counter-intuitive. > > I don't think it is that much counterintuitive. > > > If we do it, I'd probably vote for the latter semantics. While it sounds more > > error prone, it's less wasteful and enough to cover the most common case where > > the actual *realloc() call is always with the same parameters, but a changing > > size. > > Yeah. Or with hardening enabled (init_on_alloc) it could be done always. > Ok, sounds good. Will go with that then.
