From nobody Mon Feb 9 01:45:38 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 576F01BB6A2 for ; Thu, 4 Jul 2024 17:08:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720112922; cv=none; b=DyFMDpF3gBg1pWZ2lQTVJhFLe6nbNvh5Mrc6IvdNYgG+YJcRlCZs9S5X/JqZaAHGolp0cXhNoPLOHS804yJSrzHUGyaqYXo8fUQFHeVGsNnjNJRHkTix3I1eNopZ8nEC5i5SJ4xHoEG2oDkS3wB/2WS3kDAupDW4Y2uWLU+Rd40= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720112922; c=relaxed/simple; bh=YcnAH3SHZXROeNoMHnipvFfals1BnUzQ96nTlnvMQFo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MszTlQbOoA7Ivx9pX7VOUhbfqwskhu1F0bOAIGYstnJo3CcxSCayZ75nqc7ohB25Va9UlEL1qE631jbOpZpHE+wc9ZLX6WMI4EUIDQAU4TdHVibbJRMxuM7yfjpTIUYKkYxl6hip0AZ1z2xageD5XZ1EF0hGT4lSrcK3sqpFzWQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Jj4QXqQY; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Jj4QXqQY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720112920; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u0UMICwsMRzMsfA9s19JVB8HcVWOB39iLX8GByK/zHc=; b=Jj4QXqQYg9Db1teo87LBqhfTfKnhttYn7Mim+T+cFOcMIASjJ5UbvyQ96jkn92GWF/Znrg iq+bmKjX9Tl+pEz1UdMroOoDgpub8bcAB8P/Us5H36+wmffcZuwMjiVYEd9AaStyw7cTEB tSmdR0uOgya5hxxkkoMRYivPgHX8nWY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-659-BAUgnQgJPLmzE_HnGCcwMw-1; Thu, 04 Jul 2024 13:08:39 -0400 X-MC-Unique: BAUgnQgJPLmzE_HnGCcwMw-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-36792df120fso658730f8f.1 for ; Thu, 04 Jul 2024 10:08:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720112918; x=1720717718; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u0UMICwsMRzMsfA9s19JVB8HcVWOB39iLX8GByK/zHc=; b=LDhQEdc+XUbsNw6BIN9LU7XHy6CSusn6+Msklt/xekLepj8ymRZGecX/gn0DN7vbEF ulvfleGkXAQ0KuOGnSeFfIC1mQZ9Zgkufj62yuq4K5f4pDZaLyrciThtXgAwAkk3y0yz CvcC2s3gb82xK7AuohO5j4AnbYJP61oK7sfORlH+DIIxQOEEOERJPYjiALmNO2wHVLoB 2Lv1hOQ4btIFjhxVIklnl3qqPq8Ej6KNiCvRz3MWSt4Jn1EZG61/chQffYmnaNXIz39w ItcDzqKEjmzbHxJuOk/DR9PJ7H6jnMozAmZUzqPcCEUooG/ONEpwk1UqM3nJBXe+a8tO LFPw== X-Forwarded-Encrypted: i=1; AJvYcCVym65xGZhhiOmzhmugj5we18DjztCP4VllcL2ebcO6R2tLtRB/SfAdGbIaojh34xWgf8BQEhRG27RaUtoRUQSiuEVtNpuvtT/TrTby X-Gm-Message-State: AOJu0YyBX7ffoSayD5TZC1FA/oTavqA24h1wK11PEJRTAzqM13ntGX6Q rqPiKyTMCfzfbrHm+BXi1nxOeg8K8xMEpM2Zi1Z2tcOTVNsJ/uznJTSojF6UOQTrr8rOfURULcj nv9FXcb93rmnY2GzjfYo2tVSttXVcp+CjJsu+1ndpEmNRmWiXqmoX3IPBKKun9A== X-Received: by 2002:a05:6000:12c6:b0:367:91cf:e890 with SMTP id ffacd0b85a97d-3679dd10283mr1823258f8f.6.1720112917799; Thu, 04 Jul 2024 10:08:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF/XJEdVUhXEyatK6ngjqfp7NJ4Le1ciarBr+9Y1EF175deeq20/plyxZJPo3uVQ0XayyddFQ== X-Received: by 2002:a05:6000:12c6:b0:367:91cf:e890 with SMTP id ffacd0b85a97d-3679dd10283mr1823239f8f.6.1720112917535; Thu, 04 Jul 2024 10:08:37 -0700 (PDT) Received: from cassiopeiae.. ([2a02:810d:4b3f:ee94:642:1aff:fe31:a19f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-367a3016f8bsm877280f8f.46.2024.07.04.10.08.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jul 2024 10:08:36 -0700 (PDT) From: Danilo Krummrich To: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@samsung.com, aliceryhl@google.com Cc: daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, acurrid@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Danilo Krummrich Subject: [PATCH 06/20] rust: alloc: remove `krealloc_aligned` Date: Thu, 4 Jul 2024 19:06:34 +0200 Message-ID: <20240704170738.3621-7-dakr@redhat.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240704170738.3621-1-dakr@redhat.com> References: <20240704170738.3621-1-dakr@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Now that we have `Allocator` for `Kmalloc` in place, remove explicit calls to `krealloc_aligned` and get rid of `krealloc_aligned` itself. `bindings::krealloc` should only be called from `Kmalloc::realloc`. Signed-off-by: Danilo Krummrich --- rust/kernel/alloc/allocator.rs | 21 --------------------- rust/kernel/alloc/box_ext.rs | 13 ++++--------- rust/kernel/alloc/vec_ext.rs | 23 +++++++++++++---------- 3 files changed, 17 insertions(+), 40 deletions(-) diff --git a/rust/kernel/alloc/allocator.rs b/rust/kernel/alloc/allocator.rs index b7c0490f6415..1860cb79b875 100644 --- a/rust/kernel/alloc/allocator.rs +++ b/rust/kernel/alloc/allocator.rs @@ -36,27 +36,6 @@ fn aligned_size(new_layout: Layout) -> usize { size } =20 -/// Calls `krealloc` with a proper size to alloc a new object. -/// -/// # Safety -/// -/// - `ptr` can be either null or a pointer which has been allocated by th= is allocator. -/// - `new_layout` must have a non-zero size. -pub(crate) unsafe fn krealloc_aligned(ptr: *mut u8, new_layout: Layout, fl= ags: Flags) -> *mut u8 { - // SAFETY: - // - `ptr` is either null or a pointer returned from a previous `k{re}= alloc()` by the - // function safety requirement. - // - `size` is greater than 0 since it's either a `layout.size()` (whi= ch cannot be zero - // according to the function safety requirement) or a result from `n= ext_power_of_two()`. - unsafe { - bindings::krealloc( - ptr as *const core::ffi::c_void, - aligned_size(new_layout), - flags.0, - ) as *mut u8 - } -} - unsafe impl Allocator for Kmalloc { unsafe fn realloc( &self, diff --git a/rust/kernel/alloc/box_ext.rs b/rust/kernel/alloc/box_ext.rs index 829cb1c1cf9e..1aeae02c147e 100644 --- a/rust/kernel/alloc/box_ext.rs +++ b/rust/kernel/alloc/box_ext.rs @@ -33,24 +33,19 @@ fn new_uninit(_flags: Flags) -> Result>, AllocError> { #[cfg(not(any(test, testlib)))] fn new_uninit(flags: Flags) -> Result>, AllocError>= { let ptr =3D if core::mem::size_of::>() =3D=3D 0 { - core::ptr::NonNull::<_>::dangling().as_ptr() + core::ptr::NonNull::dangling() } else { + let alloc: &dyn super::Allocator =3D &super::allocator::Kmallo= c; let layout =3D core::alloc::Layout::new::>(); =20 // SAFETY: Memory is being allocated (first arg is null). The = only other source of // safety issues is sleeping on atomic context, which is addre= ssed by klint. Lastly, // the type is not a SZT (checked above). - let ptr =3D - unsafe { super::allocator::krealloc_aligned(core::ptr::nul= l_mut(), layout, flags) }; - if ptr.is_null() { - return Err(AllocError); - } - - ptr.cast::>() + alloc.alloc(layout, flags)?.cast() }; =20 // SAFETY: For non-zero-sized types, we allocate above using the g= lobal allocator. For // zero-sized types, we use `NonNull::dangling`. - Ok(unsafe { Box::from_raw(ptr) }) + Ok(unsafe { Box::from_raw(ptr.as_ptr()) }) } } diff --git a/rust/kernel/alloc/vec_ext.rs b/rust/kernel/alloc/vec_ext.rs index e9a81052728a..bf277976ed38 100644 --- a/rust/kernel/alloc/vec_ext.rs +++ b/rust/kernel/alloc/vec_ext.rs @@ -118,6 +118,7 @@ fn reserve(&mut self, additional: usize, _flags: Flags)= -> Result<(), AllocError =20 #[cfg(not(any(test, testlib)))] fn reserve(&mut self, additional: usize, flags: Flags) -> Result<(), A= llocError> { + let alloc: &dyn super::Allocator =3D &super::allocator::Kmalloc; let len =3D self.len(); let cap =3D self.capacity(); =20 @@ -145,16 +146,18 @@ fn reserve(&mut self, additional: usize, flags: Flags= ) -> Result<(), AllocError> =20 // SAFETY: `ptr` is valid because it's either NULL or comes from a= previous call to // `krealloc_aligned`. We also verified that the type is not a ZST. - let new_ptr =3D unsafe { super::allocator::krealloc_aligned(ptr.ca= st(), layout, flags) }; - if new_ptr.is_null() { - // SAFETY: We are just rebuilding the existing `Vec` with no c= hanges. - unsafe { rebuild(self, old_ptr, len, cap) }; - Err(AllocError) - } else { - // SAFETY: `ptr` has been reallocated with the layout for `new= _cap` elements. New cap - // is greater than `cap`, so it continues to be >=3D `len`. - unsafe { rebuild(self, new_ptr.cast::(), len, new_cap) }; - Ok(()) + match unsafe { alloc.realloc(ptr.cast(), cap, layout, flags) } { + Ok(ptr) =3D> { + // SAFETY: `ptr` has been reallocated with the layout for = `new_cap` elements. + // `new_cap` is greater than `cap`, so it continues to be = >=3D `len`. + unsafe { rebuild(self, ptr.as_ptr().cast(), len, new_cap) = }; + Ok(()) + } + Err(err) =3D> { + // SAFETY: We are just rebuilding the existing `Vec` with = no changes. + unsafe { rebuild(self, old_ptr, len, cap) }; + Err(err) + } } } } --=20 2.45.2