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 23074D18145 for ; Mon, 14 Oct 2024 20:35:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A24A66B0085; Mon, 14 Oct 2024 16:35:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D53C6B0088; Mon, 14 Oct 2024 16:35:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89FB76B0089; Mon, 14 Oct 2024 16:35:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 670DA6B0085 for ; Mon, 14 Oct 2024 16:35:25 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 17F2BABF4F for ; Mon, 14 Oct 2024 20:35:09 +0000 (UTC) X-FDA: 82673362884.11.5068685 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 429D814001D for ; Mon, 14 Oct 2024 20:35:19 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Ect6gHv/"; spf=pass (imf23.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728937982; 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=ppi7+dgoi6Dcu/mxMR3vNRKUMuBcP1Y/URA6z3Ogy0s=; b=keLCoedrAgxsKWF2xnrX1WU7IjXss7c3uCRWuJTgGcnlTPKuBSaUgIu9SaCyWQT8mS+4rk hNjx8PQ/uXZHw9npD6ipzDQb53IwUwGrQWDsrUL6pVV1xmD+VdX10gUntxtlr5dL+6Cv5g Agt+ecgU8OgFrYnVy9OEgQ3l0SXI6Jg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728937982; a=rsa-sha256; cv=none; b=tWZ7pxBj9axsZ4kAYPrZ3lkWNJCokqeTbiAOPVOPkveNinPCKMH2otTJFB1aXy7wW72+4b PTsygR7xGMV7kzrn2bcsddVjRaHSSLJChmObFFp9uVLVjrCuqYazZPyIIB0KuCAYB6MiOG GyES2FpuaIn6SfaFFDkc/Tt8oMBIA0k= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Ect6gHv/"; spf=pass (imf23.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) 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 A76A85C5BFD; Mon, 14 Oct 2024 20:35:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B59E6C4CECE; Mon, 14 Oct 2024 20:35:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728938121; bh=wLhf3jR8M5Z8MMOJ1B8t6VL9zgSh30irh8dHs0m90j4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ect6gHv/bZie0Eolgfh8N6DRlAQnyFyCJplGNFbrR19cey3SPPXqQx2sIvoYxica1 MHzCSzEtHhkgLbo9RTbnPvVyNu/q7tFCmo7oqlKqdMs7r/OMMZ15Hf1RXed+hDI07a y6TL+Xa+h45NN+ls3czivjkjwX5Wg1ah4mNFN9ZeqH3cPRxjNknZ3h5b/cQJPiU+Df 9fv9/Hv/fdEZgpPoTRXnxx77K3lgP9M4/abqUsGVLw8sYlVX8nwBS2eQw03cbPIsDz mr5PXWZKapJr0TioKVO0GC/V6GoEp+5zhZOgaUkmn0k/GRqMND9+pWPiNzFzA8eQUr 2EXr1TCygBH9w== Date: Mon, 14 Oct 2024 13:35:17 -0700 From: Kees Cook To: Vlastimil Babka Cc: Feng Tang , Marco Elver , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Andrey Konovalov , Shuah Khan , David Gow , Danilo Krummrich , Alexander Potapenko , Andrey Ryabinin , Dmitry Vyukov , Vincenzo Frascino , "linux-mm@kvack.org" , "kasan-dev@googlegroups.com" , "linux-kernel@vger.kernel.org" , Eric Dumazet Subject: Re: [PATCH v2 0/5] mm/slub: Improve data handling of krealloc() when orig_size is enabled Message-ID: <202410141330.CAF56E3@keescook> References: <20240911064535.557650-1-feng.tang@intel.com> <49ef066d-d001-411e-8db7-f064bdc2104c@suse.cz> <2382d6e1-7719-4bf9-8a4a-1e2c32ee7c9f@suse.cz> <0e8d49d2-e89b-44df-9dff-29e8f24de105@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e8d49d2-e89b-44df-9dff-29e8f24de105@suse.cz> X-Rspamd-Queue-Id: 429D814001D X-Stat-Signature: brjktugtpquaitrn3z9o7gi7igdj7yra X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1728938119-196909 X-HE-Meta: U2FsdGVkX18JJX8rIot+Xwce7yXPe7t5FKzkLSFU0Mvf8x1pWECm8YkEQ7rfaBXhU+d/pQMUgBaeiFbCCSHq21dAQEjReUSXQDSHvNTzi0Y/Wwxp0cpwT0kougIy4/lWW6AY70Dl48pz8VJNX16XQLlI0Fvqa9XwkExdpC/Y62eJrNdm8/kdfWG+VJznkqb9zwEJ3R4n4PDyiR2lfxoSo4UELlVnet/fhNMu7sfLnjMea8pmhwWjyYrLgPGIW1xP61gwBYS1jcfaFn3jP5ektPZWzQEmmc1Fr3xXZNFnV9vfM4azc57NlYNu1z9W2KGGZIULht5JfUpMm1DHG2Ip5gtF2933ItCeYVz65uh2DA9Lm1Vg0MZzgnud+f+MTU6RWqk3i0UV8z8MvUeZvGQ85HSYrkisb7MNjoDiE4mRUZXtKkMv/BkzLNXDXWmQpSzol1d5PVOCBWs+1q8WHKFuCYOre050ACt4RbAOwZDoYjOT3+24VWzANvSwDFEBIEpxwvFILp3XIpiU91oJI+btYCjmr0VKKR6LPhdwhKA2KEfbUCQbTTBNxhAAwU5GX0LwiNVKN/02mW2aSqnO0Oeax8VZMotwme2gjqSNrz0IcJO4bQeLBBopesmAGNAti5lcO6IfH7SPJOII7dDpT//17Olby/+u2RNM62ttY6bE0XJjRVfgl+Bc3Txpq0ZPW3c1b0GOSikPtiny5Eobg27pwFKHD+LVHZL2sk3TpBsTc6WoWIeNjBk6qk54bRdFtBHjMWhpbjCG9y9457+goTCvBDujZVsjqnsaizW8NWAOAilWhA8GL4KTIxic7NxOoIZ26bcP8F0DnM1GyZqjywq9q3vKTHqxvg2NrlzK2YWT+y9f7QOndyNrAX3K2/R0IvOnlC3/1MjmsNjJ5iyzAd/QoFU2N3WSyvEPZxvOT0biZGiRZoBZdleDJXbIME6al/l82dPAcZ6Lw9kLqUsVVKa FdGF8sm4 E9S5jwFT42ldtuSRjq4bWztisIL+PEb/5uMKPI+JRasQaD/BfGIq2defP9Rt667jAm6xjjTlGheDiyt+E7JdVQTVZ6qKrmGtphQ7O12EZvhL9e1H74nZbb8J2P378hMbXghJd4FQ4u48NfCUAFvNfqgBUffq3T0DqqSkDGvp66L8xX3hqQc2SZsU/veLNCOonNpUH3cGJpA66P2xz/OGM+feuZeH67kLf3onxCTWrf6Fof7HYJsRfIXm9UHwN/Du8ovHBUeA67AE6C2hmndD9dbC7fLPJgbt7qZMDi/wF0jUqcoCpFZ3RDd+5XtRzmm9uwtTbIMOay9gNLlQWw+o9RYYSwvn1NNhlpWX0sIMki/+qxrnt7aRvjdJXTdQwD3kN8xO15iyBktp9j85f3a7HrvYCZDEfBYavZa5V 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 Mon, Oct 14, 2024 at 03:12:09PM +0200, Vlastimil Babka wrote: > On 10/14/24 14:52, Feng Tang wrote: > > On Mon, Oct 14, 2024 at 10:53:32AM +0200, Vlastimil Babka wrote: > >> On 10/14/24 09:52, Feng Tang wrote: > >> > On Fri, Oct 04, 2024 at 05:52:10PM +0800, Vlastimil Babka wrote: > >> > Thanks for the suggestion! > >> > > >> > As there were error report about the NULL slab for big kmalloc object, how > >> > about the following code for > >> > > >> > __do_krealloc(const void *p, size_t new_size, gfp_t flags) > >> > { > >> > void *ret; > >> > size_t ks = 0; > >> > int orig_size = 0; > >> > struct kmem_cache *s = NULL; > >> > > >> > /* Check for double-free. */ > >> > if (likely(!ZERO_OR_NULL_PTR(p))) { > >> > if (!kasan_check_byte(p)) > >> > return NULL; > >> > > >> > ks = ksize(p); > >> > >> I think this will result in __ksize() doing > >> skip_orig_size_check(folio_slab(folio)->slab_cache, object); > >> and we don't want that? > > > > I think that's fine. As later code will re-set the orig_size anyway. > > But you also read it first. > > >> > /* Some objects have no orig_size, like big kmalloc case */ > >> > if (is_kfence_address(p)) { > >> > orig_size = kfence_ksize(p); > >> > } else if (virt_to_slab(p)) { > >> > s = virt_to_cache(p); > >> > orig_size = get_orig_size(s, (void *)p); > > here. > > >> > } > > >> Also the checks below repeat some of the checks of ksize(). > > > > Yes, there is some redundancy, mostly the virt_to_slab() > > > >> So I think in __do_krealloc() we should do things manually to determine ks > >> and not call ksize(). Just not break any of the cases ksize() handles > >> (kfence, large kmalloc). > > > > OK, originally I tried not to expose internals of __ksize(). Let me > > try this way. > > ksize() makes assumptions that a user outside of slab itself is calling it. > > But we (well mostly Kees) also introduced kmalloc_size_roundup() to avoid > querying ksize() for the purposes of writing beyond the original > kmalloc(size) up to the bucket size. So maybe we can also investigate if the > skip_orig_size_check() mechanism can be removed now? > > Still I think __do_krealloc() should rather do its own thing and not call > ksize(). The goal was to avoid having users of the allocation APIs change the sizes of allocations without calling into realloc. This is because otherwise the "alloc_size" attribute used by compilers inform __builtin_dynamic_object_size() can get confused: ptr = alloc(less_than_bucket_size); ... size = ksize(ptr); /* larger size! */ memcpy(ptr, src, size); /* compiler instrumentation doesn't see that ptr "grows" */ So the callers use kmalloc_size_roundup() to just allocate the rounded up size immediately. Internally, the allocator can do what it wants. -- Kees Cook