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 69A4AC3DA49 for ; Tue, 23 Jul 2024 11:28:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7FA36B0085; Tue, 23 Jul 2024 07:28:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2F746B0088; Tue, 23 Jul 2024 07:28:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF8086B0089; Tue, 23 Jul 2024 07:28:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8DEC96B0085 for ; Tue, 23 Jul 2024 07:28:40 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2A3D2A1E10 for ; Tue, 23 Jul 2024 11:28:40 +0000 (UTC) X-FDA: 82370794800.11.C9C45DD Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf11.hostedemail.com (Postfix) with ESMTP id 331FD4000E for ; Tue, 23 Jul 2024 11:28:37 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="cJX/8lns"; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721734095; 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=abrqLpr2mYE+mftzGkLINKPIi/aoImy+3XxL7lJcnew=; b=UKY3taBfvBwl9+rD8qfaDiCWfMoexuV1TvxCSx9SSMY5wcpFAPN1+TaH5m/SuOh516zubk 1LEQsseVonjiWftGKZfk8meYpAxQMBRLUypYJGxmMeE5D9vWtECVwb+H5Ft2yYj7FfENPv lJwr+oCPII9NzcPgqibbp7eT76rXD3M= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="cJX/8lns"; spf=pass (imf11.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721734095; a=rsa-sha256; cv=none; b=r6NJO4nPb7sdQ7G0WuqS4tZEgJ5EC69eQdUdotovasrA/KHVk5dUmaHwZW3wPQGUdEguiz js1NWEQAkFRxOQ1hSEoqNn/HMffLHhSso9FbsdqbNzLPiGzzVRxtlO4pN2XdlTAXuWg6p9 hLHXK4cvkIvQvUii/XYpTeDIM6ir/TA= Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-52f025bc147so3216893e87.3 for ; Tue, 23 Jul 2024 04:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721734116; x=1722338916; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=abrqLpr2mYE+mftzGkLINKPIi/aoImy+3XxL7lJcnew=; b=cJX/8lnskmHoDqcCCZZhg22CU9kB0GMRFLgGMAg+vlTRUvX9M87r3WBFDF5TKLFocA Wbt/L6HRZiIBQAKYi0vRNpCrBLTt7NnJK4hfdkyij/PuM3/fvugBuNVgb2VpX5djWng6 DbBzBLgj2ZlEyayTiqjItKEa2ci5yYVogEFqFNtZoN0fkJ2d9IP8EAqGsXnODCKBTvw1 8CNPxnlzzRUclsMS+/tSoH7eer2YRph/mmxCevvNL3lqZdD2V9pEwgrhgiA4PgOjCeVa 0v3pHWzo8y51ZKuQ2Q+3euWL1T8gcz5jnMmKGQhJKdwVW2N6lSxjkSJN3jdU1Fv+dmSa aI+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721734116; x=1722338916; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=abrqLpr2mYE+mftzGkLINKPIi/aoImy+3XxL7lJcnew=; b=CulYph8Bg5oYGcmUHAUZxxigXuTfNDXk2PO782mPxYNoAV8mWxaxPKCa0sSEgz/ftU ua9frafDlSqOI4ppi5veZwPj6qi/pIg9yocb3RSFiKMfkyg/EJXBTTgpzCQrfEZZRZuu HYSB1d+Cjx4ydpddkvHRt3QnMpVgi8wp9cJ4p8QO0bowkgFMFA9mXeh6PudDdgZRO8e3 mFFQ27yd4tjxzJXWOcBcquWbPhYRQnqWA33+Mv+VmkJ+g5xk/J1GnvbY9gtSB97SUUUE TMVAQ0VjaaqpYiIDY3yuFTS8A+4/reqSkTF0vSiZc1ZaCl3rbwgW7syJSkbD1If+Km8p Dh8g== X-Forwarded-Encrypted: i=1; AJvYcCVK8YBr0VVeM6qpYtw4b/xy9kkdSkXuoaz8iG1Tmyo5Gctod4RoMWauQ2B6WhbX5zojEhTHVjFOQp5WpsYNLgbRv8Q= X-Gm-Message-State: AOJu0YypE6vs5NrHp5jKpWd//CWLD6mhNFRieQ/Tn74Yu75maOKzPKAG ZPFUZUNNzxiIU8JlHxnUgzGVLCj7wl6iSUCChqn7Z9C++K/ADu25 X-Google-Smtp-Source: AGHT+IE6SmKJeYRCd6J8eMwqSuZsAeG1RkElKxi9pM8+aTJA2/sss1iQnaWtymJXnMTtbLebBahEYg== X-Received: by 2002:a05:6512:3d1a:b0:52e:7684:a385 with SMTP id 2adb3069b0e04-52efb7e8f75mr6226245e87.52.1721734116088; Tue, 23 Jul 2024 04:28:36 -0700 (PDT) Received: from pc636 (host-90-233-197-231.mobileonline.telia.com. [90.233.197.231]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52efa73423csm1235399e87.102.2024.07.23.04.28.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jul 2024 04:28:35 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 23 Jul 2024 13:28:32 +0200 To: Danilo Krummrich Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, 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, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH 1/2] mm: vmalloc: implement vrealloc() Message-ID: References: <20240717222427.2211-1-dakr@kernel.org> <20240717222427.2211-2-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240717222427.2211-2-dakr@kernel.org> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 331FD4000E X-Stat-Signature: oifybfd4bzxdfoqqh7tmkpdji9tb6wuw X-HE-Tag: 1721734117-509927 X-HE-Meta: U2FsdGVkX1+sGtAn699ahloQEEjWDWVH3ZW4R48Y7zPKYUvQmPDFrFpOifbMH1os+Hs08TMpk11uFXS2nCQ7UGzPj+ui5/8nXnwiFI1z7XlWkS/1akrGRk37ZxH/v2HWx0Q4BDX12surqHBR7cJEtGvzQ5TyWulEFVy/olhhm5Z2oFujSXdC/UdPmLm2jPME+zzA5OBWcwZmPa8vyLoB8peX00xkJD8DBKgOhu8xeUWpYaEBazp7g30ENt53JEnVc2OhgeINJpw+4MACd38ZGOf80F7baaZwwnIffuA78rx7Lv92rMMXcuZ5Fhvp2HVX1Jk23FUOGUmJgS89Ri3aINu6dq9IiXCByhKbaycJ88PQzpM91pjrn6EzfnsNoejxQA2OLfKg1Fo7hodd9rfU04dqVTsxfKMDpcQgqJCaNHSIuJtqOrzJeunzV53B/DT1HRVu+LEj/8iSIOi68ZNBnIBYv1RJVIDjipPZHlfUm3xa7puQuKYj/l1ma2/moGLZhsLxlZGNNl8r0fw9URje85jGx38VP6c9wCQuoesbvy7OFl2sks6CANj+PmjtTUJM1em53OIJnYJTYqFO2MdesLYqXcVS7nU5MWuAu56WCFHOqLqP7+i6XL2I06CSkT8pYnt6lDJcHYA7/agLxud8FlzFo1znhZPuNSuhNbw9FyNFaxoMGfa+zHQJyRO26j3FnLwjebbGuBemqzXuv7VYMj57LU1qW5qfYcmu1joQVjREie2nv66ps+4wAw9zjliznEoLmeN7Oz9WnhLTt/4kRu7FCmZZvp7y5PtTJUiJ5/JZOIqo/9W50aTZvcBHt2Y/OyEmte31/xfOjztAPtDqcG0UTmkg9P8v4I+SKTlGLwPw0LyS15pdWzriPYAZW92QBZVMyOQ3vZFD+lraiuOV00RJ7g7zz3uGyx5MoVfDK98Bkq/qKWgPiozvxf6MvPs4vkjjeL+G5rbQHjPp4ew 7fXnaynO KjKXBM/qRDFxQC4vV4NUkGMcoQMu/iWcYVo6J+zbD1DuZDMJhGoxSXK8LFFrjZ7xLM6lOHyQelNdssiY3PFXuWQi6BP/1UcAvgQ0VR6CJtvTKgj1Pqbm3RlDcFW/E8WT9F0qNJjZkSRSy16cuHOGZYPaSVaA+TX4HijoqQhK//TnZ7h5C3fBpGZs+O33UR3BlhZSlXFtPsjVt09ucd5y7xlkro7MfLvsJmvu6vpBAaeT1deYjhDqmSc6S/aAbCtGgaN6l5DzB8Xi9BrFjmCh+Wa4u0PHIO7FxRBO9IxetSyiDkcRLrxvDHT+OQzu5672y7qVb64rg+zimKjsOQv1pjSmOr7oNF8/J5D/PXQ+0U8UnwXnya87QLRsB7jydR6bg0DKJ+0SA7Pk6ua8ZgQSkOGHKZhen7uCV3ZW53iDR7PTCFetG05Norpk5kHdH2qsJnLlBPM3XrAm7uyFSVvNsqFLMjA== 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 Thu, Jul 18, 2024 at 12:24:01AM +0200, 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 > --- > include/linux/vmalloc.h | 4 +++ > mm/vmalloc.c | 58 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 62 insertions(+) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index e4a631ec430b..9ff0a8e5c323 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -189,6 +189,10 @@ extern void *__vcalloc_noprof(size_t n, size_t size, gfp_t flags) __alloc_size(1 > extern void *vcalloc_noprof(size_t n, size_t size) __alloc_size(1, 2); > #define vcalloc(...) alloc_hooks(vcalloc_noprof(__VA_ARGS__)) > > +extern void * __must_check vrealloc_noprof(const void *p, size_t size, > + gfp_t flags) __realloc_size(2); > +#define vrealloc(...) alloc_hooks(vrealloc_noprof(__VA_ARGS__)) > + > extern void vfree(const void *addr); > extern void vfree_atomic(const void *addr); > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index e34ea860153f..4ec949ac9d9d 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4036,6 +4036,64 @@ 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). > + * > + * If @p is %NULL, vrealloc() behaves exactly like vmalloc(). If @size is 0 and > + * @p is not a %NULL pointer, the object pointed to is freed. > + * > + * Return: pointer to the allocated memory; %NULL if @size is zero or in case of > + * failure > + */ > +void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > +{ > + size_t old_size = 0; > + void *n; > + > + if (!size) { > + vfree(p); > + return NULL; > + } > + > + if (p) { > + struct vm_struct *vm; > + > + vm = find_vm_area(p); > Concurrent vfree() will lead to use-after-free. Either add a comment that a user is responsible for not using vrealloc()/vfree() on the same pointer concurrently or use find_unlink_vmap_area() which might be more complex when it comes to design of the vrealloc(). -- Uladzislau Rezki