From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D08ADC3DA49 for ; Tue, 30 Jul 2024 14:32:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6944C6B009B; Tue, 30 Jul 2024 10:32:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 644266B009C; Tue, 30 Jul 2024 10:32:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50B696B009D; Tue, 30 Jul 2024 10:32:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 334356B009B for ; Tue, 30 Jul 2024 10:32:31 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C1CCC1202F7 for ; Tue, 30 Jul 2024 14:32:30 +0000 (UTC) X-FDA: 82396659660.05.AD6476E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 08CEF4002F for ; Tue, 30 Jul 2024 14:32:28 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=APhoxjyX; spf=pass (imf01.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722349894; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=y0OqFpEW/LDALC/kx7R+Xa89XiiMG2r64AxNfOe0Q4k=; b=5inIs2W8rIGGDWJf5YNpOtDzDvnzaOGklbYtjQghbFgPJsQOtQC/v/kMaC9iqnH2i+Oy75 eUya9jDA1oB900ifxkxFhQ5eo2FqlaZPT1CnCFbuO/apziDfReQKiKoURUkFQ810XQASop 18hLrCMWOWvtqayhOcBKkRygBl755HQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722349894; a=rsa-sha256; cv=none; b=qEYRU5wNfoNOCSJv0E4n5ZSQSFpX9ucTEKdMD022tnufNS7ZRcNi1v7bevKvYiP1HlrJrQ LFpuVquFWqM+i9XGXUUWgmgItotgzDOf3CVByxA4xjOU/deJ/lRNy2etvcMTr4tu0oeh5t fttQwIO08RVjYrCnShEJIBAfqCaVtu8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=APhoxjyX; spf=pass (imf01.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E462E61F38; Tue, 30 Jul 2024 14:32:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E04DBC32782; Tue, 30 Jul 2024 14:32:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722349947; bh=+j4R5RoszZQrj25E4WFcSoCqS39W7IfpQDj+BrchEnI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=APhoxjyXBcQaSHoDLpSBG95xMCA8HtFHOS/tMTPaW8kEhRrD9GiLM6/G3ZP4zlDVc 5mL25FjCiET/oFIcsvSubRCN1HTeMVB9RtO9XvF9XhbhhLGDB78bwwz2KstOeATE2I zOqdUgcsPeP+E7NSs1KPTXZmh7b6FhXjfGxTPniTC5M9q/YRHx7hg2fV6fsw8yk3Qh d/FGM9S7x/iROKN26sK3St5itFXVIhRCCiWUe3wMQCLhIJwiBb9C5JDyIgVVu2fXH5 uYBU/VdInqGpfU1CoAVaXcZGLkRmT59XD8Qvv//yJcvimDPmGSw4PbJLpuWPQ1Cigi QRki53DuJDYIg== Date: Tue, 30 Jul 2024 16:32:19 +0200 From: Danilo Krummrich To: Vlastimil Babka Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, urezki@gmail.com, hch@infradead.org, kees@kernel.org, ojeda@kernel.org, wedsonaf@gmail.com, mhocko@kernel.org, mpe@ellerman.id.au, chandan.babu@oracle.com, christian.koenig@amd.com, maz@kernel.org, oliver.upton@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org, Feng Tang , kasan-dev Subject: Re: [PATCH v2 1/2] mm: vmalloc: implement vrealloc() Message-ID: References: <20240722163111.4766-1-dakr@kernel.org> <20240722163111.4766-2-dakr@kernel.org> <07491799-9753-4fc9-b642-6d7d7d9575aa@suse.cz> <44fa564b-9c8f-4ac2-bce3-f6d2c99b73b7@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: botqot1q3cipb7xnzszztch3oomqodi7 X-Rspamd-Queue-Id: 08CEF4002F X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1722349948-144441 X-HE-Meta: U2FsdGVkX19vW9PCWi5Ce1/dI2W5qNKEy5oJkCr2SuI+DhlDtgxiU0gRhOv57cVWIIohM1Gwvpu5+7TBSgB6uTuZh1npOv5HeI44Ki9YX1m0+9dCzCaICVjMYpEnLr4FI8rr/4eKWs0ah9df12YZJnd3KweaTg6+JvNOtymZvE3lvVdF5plYtdqD7PFFRbJXxFwX3WpuGc6yoa1fqRHk66hQFCLmGzzyiZG0dNnpuiXHuzt/7b+dPf7ou1prEgTDOGqNO0RpSMoTgC2z2pMqiKERW9hOPQZ6n9iXCt1OqMbdKlYwfcCcVadA+vbfxFX5T+l6PXFG2YySA1dQtLatAj9rOjlRkfyTt4eciyUTsQnEEEF1nDmX+rRKbjOSFyaXyv0naQXGCeLCiTCRG+uRKmfV93+AZf8WC/WauuuoCDlRb1NvjlmfZD8+8V7T7clYNUPooBgNXqyJe/YOb3zkg5jHb2ahrl6iFHwPaX4tizxVjmKW+vwFZIzkp8huqae1XBQVorrvebwLVKvxAtvG3yw3OW7ZcBAav6yJ1+TSiqYX5YTCkdtRrfywQhtkFYwvbuVBm/1j9Zk+NpE/t7eLtR8kRwYhyqyGs1/stFJYLI8HVizdwnqb0SErLb/39toQTj1Ye9XPxEkG/bfo0QHxMUY5SSgWwH0H+9wo0gB95z9tRNXMtrr188FpkZhmhwLmGduIBqaRZKvwQwnwc+d3Vo3Pt3fV558e3rW8NCIyCYr4qK9Xi/Itfx6DQtm9rgj6tN7K/PpYOpNizONTa5HucsS2hZHEvCxa2lKA/j/mHjcWI+bHEJHqg72y4uyWpnrOx4PHwzIb0gIWSkKfYy/lbR7NLo40wXDO45eYXJY7hAua/fzydpAy8ZjMGP3zDrRy02hoQWs3rGfxq5gDfXUNjCXqF1X/13D6HT4WJGh85ji8nic7ydyKL2WWisRInETMgvNsF0V+vDVZk3/Y8SF 1dGIzd+x AEgkIUTpt9ScCjIgx/hshyFSBc/8poGUdkIh37SBAu8WUbhbrZsyU0pj0dc4cv+EM6N4vh04GKAPuNThkpHukOtEWlXkS5btQ9C23nxc81EzjPViIZNfbQOHjPP0L9HRITiiqz2h7pVMI7xAur17T3PM8etXxCb5oKoqFFfG8iON36InHpsIuz39s3YAHxrUGUKbTcU7d0ZlO2+rXsPmd8iHeoSobLXItKOLcfjFQkNZ26tOxqm2E7JSwMv/vJM6/a2fQuC6VEH7TH5to/jcrhqOowoM+s8pVyXNzw58bOdKmVROcxmlctQyprnYIK2uNQq7Mv+7oZ5cfJ+5YYt/2zrjaytFgFccFYu1y X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 > >>>>>> > >>>>>> Acked-by: Vlastimil Babka > >>>>>> > >>>>>>> --- 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.