From nobody Fri Oct 3 02:16:57 2025 Received: from mail-ed1-f74.google.com (mail-ed1-f74.google.com [209.85.208.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CF8A2E718B for ; Mon, 8 Sep 2025 07:22:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316124; cv=none; b=kZgw5ZiDVgMERPLKNTETXhm8eyu+K2cODOeqXvAqSrMBnFRwXNQGwHJnUHeUbU5LsFS0lJ+qqm6Q8ys2KMdRPlS1acairCeVpA6mXfwID6NqMcK1/D7sdv92+GwlhYKb9Dw+05O3nLu+PGCiTpGKZlE7kVF8z0vhttQT8Gk9PP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316124; c=relaxed/simple; bh=iv0V5sjDmP+G0IfYZFx/KWMcUh6euYWecr6+mvlV4QE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Mx9m/CJ537/rXfNlW3CM0imY9M1J3NRr3L2gkxIAW7iCRBF9QcJdByBGj5+57Z8dxnIznMGjKxc/o+ZxXIdxPvspYT4XoYeeUriAsDaSduUtnV0PyghhXtXo38PorgleyaZeDcAVy3w90wAee1ZCKwb93cPLaMRdJWRjjUQrYbk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KdJK25Sy; arc=none smtp.client-ip=209.85.208.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KdJK25Sy" Received: by mail-ed1-f74.google.com with SMTP id 4fb4d7f45d1cf-6241bcb4dc5so1874438a12.0 for ; Mon, 08 Sep 2025 00:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1757316121; x=1757920921; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ysoQKff0sxHrJKhSrzzYE1E0RWSujnefH1ZX7oEQ0w8=; b=KdJK25SysnGxyaRHUn9WG4zsc/gDPVtFj/V0AawE5Uk8AUsrEKxNWSL1PP6SHGYk9C vf2835qYRb8LpCjqmYRmfu2rtOdIVgoDGjei838BbebOIvoxNn4XCHOL/9RwzmBTMI/M nwC9lS+mscJAnlz1RyYyhmVQt4ShZ0am89XC6vmhW+udUJuc+Gkupsd31olbOBA8RoiD SgZG6isWlZXXHdoOTPslTKa6mIyTB1vmECPmP37bGjRuJxbGtppeLIUfuiZvTM0w/oEk 78EOBtVqvIH+ddZxBwzF6RohLwQZVN8jIE2pg0pX5o+7HOp6GO7vQcolcZMaXfjh8DaT L3nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757316121; x=1757920921; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ysoQKff0sxHrJKhSrzzYE1E0RWSujnefH1ZX7oEQ0w8=; b=t2W7KORSUVGT0YLl+sfbhmZ+aaDt9iblqmYQqitwyzHBr6r6rEt83KR7fbeNleTYCX /+9m/8pp+3c25bXLeDpf4RZiDmV1d7TbAcpa9MhRhhzhSHvx0e6Glf3iKK19v1Rg1OyW rmNrW1ncfEoNAiAgZ3ckd/ES5LSj7XEfW9Qlqk66dPU4Xst1FDqANxokBNAyw8TbW0wV NWRPwDNawDPZs6cfEBBfLb6mRi5eJlO1DyFEefAPM0TbLyEXuqxqA0qqRjahS399K9yw I8J1sN+iDJwoYQIrtHFUQwIpcmYExHwkrVVRA2bInNnDq5Rhr2IwW69UFEreG1jaSbzL vuiQ== X-Forwarded-Encrypted: i=1; AJvYcCWruT0f2XI6txoxiVHEKBqL76H1Udk9G925MPEOHaqcFJGKSQTJ6ywRGvV2eoQKynuAv3qAvmrrMu1lvAs=@vger.kernel.org X-Gm-Message-State: AOJu0YwUixCifRaJop+AQKCHu34nfIwRIJwzCXfvRv2gAsjA41nOX5S7 VirVhu6lmeJw6/eX4BAP6vIWEzyUrSGV27vR6xmy78NjqqyNEXajMHbJwfNUD6mNZQS6ew== X-Google-Smtp-Source: AGHT+IG3O7KQTMkteqE6QaLliSIWj3W9rn30EeC9lqpPanaLx1WwtPnQKWWx4eZFplTweL/AeLsHHkM= X-Received: from edaa13.prod.google.com ([2002:a05:6402:24cd:b0:61a:366c:d1ba]) (user=bqe job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:52cb:b0:61a:967f:55f9 with SMTP id 4fb4d7f45d1cf-6237b972390mr5963632a12.10.1757316120834; Mon, 08 Sep 2025 00:22:00 -0700 (PDT) Date: Mon, 8 Sep 2025 07:21:51 +0000 In-Reply-To: <20250908072158.1041611-1-bqe@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250908072158.1041611-1-bqe@google.com> X-Mailer: git-send-email 2.51.0.355.g5224444f11-goog Message-ID: <20250908072158.1041611-2-bqe@google.com> Subject: [PATCH v16 1/5] rust: add bindings for bitmap.h From: Burak Emir To: Yury Norov , Kees Cook Cc: Burak Emir , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , Carlos LLama , Pekka Ristola , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Makes the bitmap_copy_and_extend inline function available to Rust. Adds F: to existing MAINTAINERS section BITMAP API BINDINGS [RUST]. Suggested-by: Alice Ryhl Suggested-by: Yury Norov Signed-off-by: Burak Emir Reviewed-by: Alice Ryhl Acked-by: Yury Norov [NVIDIA] - --- MAINTAINERS | 1 + rust/bindings/bindings_helper.h | 1 + rust/helpers/bitmap.c | 9 +++++++++ rust/helpers/helpers.c | 1 + 4 files changed, 12 insertions(+) create mode 100644 rust/helpers/bitmap.c diff --git a/MAINTAINERS b/MAINTAINERS index cd7ff55b5d32..0b2d800d8ae5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4299,6 +4299,7 @@ F: tools/lib/find_bit.c BITMAP API BINDINGS [RUST] M: Yury Norov S: Maintained +F: rust/helpers/bitmap.c F: rust/helpers/cpumask.c =20 BITOPS API diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helpe= r.h index 84d60635e8a9..7bb575043c86 100644 --- a/rust/bindings/bindings_helper.h +++ b/rust/bindings/bindings_helper.h @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include diff --git a/rust/helpers/bitmap.c b/rust/helpers/bitmap.c new file mode 100644 index 000000000000..a50e2f082e47 --- /dev/null +++ b/rust/helpers/bitmap.c @@ -0,0 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include + +void rust_helper_bitmap_copy_and_extend(unsigned long *to, const unsigned = long *from, + unsigned int count, unsigned int size) +{ + bitmap_copy_and_extend(to, from, count, size); +} diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c index 7cf7fe95e41d..8437736fdf28 100644 --- a/rust/helpers/helpers.c +++ b/rust/helpers/helpers.c @@ -8,6 +8,7 @@ */ =20 #include "auxiliary.c" +#include "bitmap.c" #include "blk.c" #include "bug.c" #include "build_assert.c" --=20 2.51.0.355.g5224444f11-goog From nobody Fri Oct 3 02:16:57 2025 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F4DE2E7199 for ; Mon, 8 Sep 2025 07:22:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316125; cv=none; b=SaEeoSI+hr5UIAVCR8rY43EnBt7MPjdg5w/WkfgPMbwsRoodPlxuhSNvlTF5j+9Sm4uC0j8iEqbNEIvsFjw315qTosZI+j0nZKOL1xwGT2ZrMSWbYD8zSJJjg8O9dP71UpGi0WaxkVL5vYIKIAWKpjJto2lcHx2bopxC1qSqe7g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316125; c=relaxed/simple; bh=OOacAJVa68AaxUpHDVNtzS9UHSKeHeKC1dw93YZO7sk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=JPYkGvWNKSr/DlQxPDp8YK11oqTK7eKaH8Vx2eaP/7gA2j0NhISCksvylC1lJCVjRbEj26JsDau02g5A5Dps3wgK9nvt4xqYPnt5dl+GmwsKZaQkx4oE7DK2UQWoT3ONeKO1CzAigHBZBmtP+ohrSB2gP7MfqhQlQBEC7a8oiic= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=XF9A7yds; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="XF9A7yds" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-45cb604427fso20364175e9.1 for ; Mon, 08 Sep 2025 00:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1757316122; x=1757920922; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=UqKOdD5po84tcrN8SKOhshxoNPwLNVkwMMwYt2v//JI=; b=XF9A7ydsF6bNlIsEBUMJ935TtEZMPbiXih+mh8uoaYZRWijvNKwC9hQC/i1/6vmbzm mfvnWVw2SlVEsXWOlNxCzP0+wfOuBtXgSw92IRWJf89TS/mVNOutd91M5ONwka8yixdu sngEONu+lQ6Sr/rH75stynS9QaCLEOnn+sqGyB25Brj7R08JB1cGhTPQFR/F1a9pLJjJ wfVbLF/JwH+k0h/Mk8U/ElTjybysWWsVr6McorAdUziDq6+mzl9FffQcY6UK50SR6NKs 1frR/WPjxWanFJQK0HpJWWwzkUeFdPfGcn69HxGkuKcC41BzkC8f5zE28Jw945NWyTA1 xajg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757316122; x=1757920922; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UqKOdD5po84tcrN8SKOhshxoNPwLNVkwMMwYt2v//JI=; b=R8pF/BNJTSJDIt65FIFVo4JPEuAaycz4/oZegJw/64qFKNpSIlZIrs8NVCsQjcpeow P12fQbmZmN+Q7w90JENgvVyHRTHtftSUqP9UY2VLpV0DGuIxbbz/o4xLgBlc1oH9Xuw7 3vPxjWm38kpYID3/u6K8+LzBtJyahVoNm88ZuRC3vbFIGcxc/nMB5DYfe40A8M6fOzfC zXrmrmHPikL4QuxTdnr1p6NE4+hzSVd5ZCvB0yeE4lC9Dfz4+fHWf+mPkb3JjNudZHdO oZEMPJo0KG3BZ80bOugCiYxKFJx75fu68z67Qjfd+cqt1+QFPJxLmj/XdCH+/sWjNrPZ 7cjA== X-Forwarded-Encrypted: i=1; AJvYcCWUko1UrX484V72VbbAEQ1vxwIxgvl6126cC2qjNSNEoJ73UAUwJw61Ft7Qa4qo5697GOhAcfhv7aoDP5A=@vger.kernel.org X-Gm-Message-State: AOJu0YwOAgkpan3Fp1qEQbn43i2U91LxlxcPnPhrm1n1+PLY7Yg25tB3 83jQeIDBdM/ZUSWB681rmEbF8hrBzhgLmwlri4TVSSE2XqaS+CdNTnir6Epe5pUsaOKiwQ== X-Google-Smtp-Source: AGHT+IEtnsRyHcoGTt+JZUtAP0WZUcirkzCVRs4Uj7nWACizvc97iPwwuy4TtxNpq1Hqrq5u4pWViRE= X-Received: from wmbdv20.prod.google.com ([2002:a05:600c:6214:b0:45b:66f9:1aa1]) (user=bqe job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:45cf:b0:45d:cfc7:a16a with SMTP id 5b1f17b1804b1-45ddde9222amr40573845e9.9.1757316121795; Mon, 08 Sep 2025 00:22:01 -0700 (PDT) Date: Mon, 8 Sep 2025 07:21:52 +0000 In-Reply-To: <20250908072158.1041611-1-bqe@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250908072158.1041611-1-bqe@google.com> X-Mailer: git-send-email 2.51.0.355.g5224444f11-goog Message-ID: <20250908072158.1041611-3-bqe@google.com> Subject: [PATCH v16 2/5] rust: add bindings for bitops.h From: Burak Emir To: Yury Norov , Kees Cook Cc: Burak Emir , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , Carlos LLama , Pekka Ristola , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Makes atomic set_bit and clear_bit inline functions as well as the non-atomic variants __set_bit and __clear_bit available to Rust. Adds a new MAINTAINERS section BITOPS API BINDINGS [RUST]. Suggested-by: Alice Ryhl Suggested-by: Yury Norov Signed-off-by: Burak Emir Reviewed-by: Alice Ryhl Acked-by: Yury Norov [NVIDIA] --- MAINTAINERS | 5 +++++ rust/helpers/bitops.c | 23 +++++++++++++++++++++++ rust/helpers/helpers.c | 1 + 3 files changed, 29 insertions(+) create mode 100644 rust/helpers/bitops.c diff --git a/MAINTAINERS b/MAINTAINERS index 0b2d800d8ae5..5654a5277df0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4316,6 +4316,11 @@ F: include/linux/bitops.h F: lib/test_bitops.c F: tools/*/bitops* =20 +BITOPS API BINDINGS [RUST] +M: Yury Norov +S: Maintained +F: rust/helpers/bitops.c + BLINKM RGB LED DRIVER M: Jan-Simon Moeller S: Maintained diff --git a/rust/helpers/bitops.c b/rust/helpers/bitops.c new file mode 100644 index 000000000000..5d0861d29d3f --- /dev/null +++ b/rust/helpers/bitops.c @@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include + +void rust_helper___set_bit(unsigned long nr, unsigned long *addr) +{ + __set_bit(nr, addr); +} + +void rust_helper___clear_bit(unsigned long nr, unsigned long *addr) +{ + __clear_bit(nr, addr); +} + +void rust_helper_set_bit(unsigned long nr, volatile unsigned long *addr) +{ + set_bit(nr, addr); +} + +void rust_helper_clear_bit(unsigned long nr, volatile unsigned long *addr) +{ + clear_bit(nr, addr); +} diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c index 8437736fdf28..abff1ef14d81 100644 --- a/rust/helpers/helpers.c +++ b/rust/helpers/helpers.c @@ -9,6 +9,7 @@ =20 #include "auxiliary.c" #include "bitmap.c" +#include "bitops.c" #include "blk.c" #include "bug.c" #include "build_assert.c" --=20 2.51.0.355.g5224444f11-goog From nobody Fri Oct 3 02:16:57 2025 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 908BA2E7F08 for ; Mon, 8 Sep 2025 07:22:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316128; cv=none; b=NelwPf8Ilrx4h2ZKijlqYogto09jlUzUWyUDSu//udvO1jgylomKlgtA/No/bN1jc0/QMHipBTk1irp0ZEFGG+LffVju8AkYsHwBOeGruJ0kxUgPZoqPmuIyyiiVymA0N2cxc/UYcZei0aPQPPggfqjQ6t1rg/JJLeUEeWOcmtg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316128; c=relaxed/simple; bh=xWFUyzOlnBXZNl/ZXrqxTQ11OUpupcGUF2/KgPHBWAM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=WRCPNHpaiGv7zOqcTDyZcFhxKDN5vfmfx824XobcL4tXzjZHS8Hj+hLQ8Guf9dU/CjadSY4oI4qRQW196X9p7r8y1B/dMwdJWiVlOsNZ71ON5YNZwC5zySDsdn8B/ATiMcYFcS8OS1+eukPoTnAi3Cog5V0/0efGbHsiS/TJX8k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MJUdA6nX; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MJUdA6nX" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-45de13167aaso11024775e9.1 for ; Mon, 08 Sep 2025 00:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1757316123; x=1757920923; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=DB6CXWCvzBB+/6D7BABwCFRGvOlrjHpm6gDOgtkLBq4=; b=MJUdA6nXM0h5MFhyM3WvgZQZZYREvzPc+57QHEXE6csy8tgjByMzXYHzrMQu7S8t+Z H7gtNNbc0GTezSEAncJbB3T34Leo3NF3FcFIR4KHGZQ9vZKwkfn6sDcOMJx7hWUIAUmx O7lDKQM+uUthBAKlDDPKYz0Nlq9ZbsQ6ggnHS/7Qdl/D8ROkJDhnMJ/YYF4K7VzJyc6m NZZipSXlfb/vGB4gIG6A5CKuWR804V9QlqYCwUyYhL9eh0J4fZwC8yG9XRntUT03rm/D qux+nlLVClzh53UagGYD+4hxZ3fW3/qeU013z7Tz1UtH34PhWczn5YbD2yHCalmsG6op 5zIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757316123; x=1757920923; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DB6CXWCvzBB+/6D7BABwCFRGvOlrjHpm6gDOgtkLBq4=; b=WOLZ18lUoH8xHGpWHyF//mLuOFLKNd0U12JPcwRznIL0hMhJRmeTzAW7yJPYthogJW iqzclkQz6V+eOP6xFCuJwCOnE6OJt9paKrVZM6Qn5pzLHdCcpQ8VF0pJXR2HSf1gy3mH bYCHIFWOkBon7VzZXFImLl2Mg5hCEKfp4whbtxFwIEly69St7twbN5GMcU51qfAzIPhF CVsr30tf9spQ0ZqVFU522wcY1NVViXpShaGjGeIYjUSb+RqWrIBUHf3+MFCib0fn1otb WCY8u1S5zGuQmNROSL1aVaQT5A8mOtRQNhqdD8LcQJKj6/+dquGjJAsxvYP7ePuDYPtX /JVg== X-Forwarded-Encrypted: i=1; AJvYcCVgxJkw7xACyOUv23tE1VkcVMNudnkO7NzTh/fet7AuHHj6jcyTsUz3frj3oz2TKM7xqrgdnhWVIb9Gm60=@vger.kernel.org X-Gm-Message-State: AOJu0YwWEtXSQLUjvJ73aU9bUFWrjO/5BQs9sfsL45PMWeIRWBB0+uJX nUUv1MxXXjjiXvgNtvn56Bg9yIjHImIgbg7P9MR4py2YhqnnL8g69bmDuvhkzuwxSjHRlw== X-Google-Smtp-Source: AGHT+IFyY/FpYMuxESl8qHdd0v3JMwEUVG539JdFb9+xql3hbpuf1fb64Vqj2n0TfpDT3aNBJUrUv/Q= X-Received: from wre15.prod.google.com ([2002:a05:6000:4b0f:b0:3e7:4198:a826]) (user=bqe job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:4211:b0:3d8:1f1b:9c9f with SMTP id ffacd0b85a97d-3e64cd57764mr4853050f8f.55.1757316122896; Mon, 08 Sep 2025 00:22:02 -0700 (PDT) Date: Mon, 8 Sep 2025 07:21:53 +0000 In-Reply-To: <20250908072158.1041611-1-bqe@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250908072158.1041611-1-bqe@google.com> X-Mailer: git-send-email 2.51.0.355.g5224444f11-goog Message-ID: <20250908072158.1041611-4-bqe@google.com> Subject: [PATCH v16 3/5] rust: add bitmap API. From: Burak Emir To: Yury Norov , Kees Cook Cc: Burak Emir , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , Carlos LLama , Pekka Ristola , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Provides an abstraction for C bitmap API and bitops operations. This commit enables a Rust implementation of an Android Binder data structure from commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup"), which can be found in drivers/android/dbitmap.h. It is a step towards upstreaming the Rust port of Android Binder driver. We follow the C Bitmap API closely in naming and semantics, with a few differences that take advantage of Rust language facilities and idioms. The main types are `BitmapVec` for owned bitmaps and `Bitmap` for references to C bitmaps. * We leverage Rust type system guarantees as follows: * all (non-atomic) mutating operations require a &mut reference which amounts to exclusive access. * the `BitmapVec` type implements Send. This enables transferring ownership between threads and is needed for Binder. * the `BitmapVec` type implements Sync, which enables passing shared references &Bitmap between threads. Atomic operations can be used to safely modify from multiple threads (interior mutability), though without ordering guarantees. * The Rust API uses `{set,clear}_bit` vs `{set,clear}_bit_atomic` as names for clarity, which differs from the C naming convention `set_bit` for atomic vs `__set_bit` for non-atomic. * we include enough operations for the API to be useful. Not all operations are exposed yet in order to avoid dead code. The missing ones can be added later. * We take a fine-grained approach to safety: * Low-level bit-ops get a safe API with bounds checks. Calling with an out-of-bounds arguments to {set,clear}_bit becomes a no-op and get logged as errors. * We also introduce a RUST_BITMAP_HARDENED config, which causes invocations with out-of-bounds arguments to panic. * methods correspond to find_* C methods tolerate out-of-bounds since the C implementation does. Also here, out-of-bounds arguments are logged as errors, or panic in RUST_BITMAP_HARDENED mode. * We add a way to "borrow" bitmaps from C in Rust, to make C bitmaps that were allocated in C directly usable in Rust code (`Bitmap`). * the Rust API is optimized to represent the bitmap inline if it would fit into a pointer. This saves allocations which is relevant in the Binder use case. The underlying C bitmap is *not* exposed for raw access in Rust. Doing so would permit bypassing the Rust API and lose static guarantees. An alternative route of vendoring an existing Rust bitmap package was considered but suboptimal overall. Reusing the C implementation is preferable for a basic data structure like bitmaps. It enables Rust code to be a lot more similar and predictable with respect to C code that uses the same data structures and enables the use of code that has been tried-and-tested in the kernel, with the same performance characteristics whenever possible. We use the `usize` type for sizes and indices into the bitmap, because Rust generally always uses that type for indices and lengths and it will be more convenient if the API accepts that type. This means that we need to perform some casts to/from u32 and usize, since the C headers use unsigned int instead of size_t/unsigned long for these numbers in some places. Adds new MAINTAINERS section BITMAP API [RUST]. Suggested-by: Alice Ryhl Suggested-by: Yury Norov Signed-off-by: Burak Emir Reviewed-by: Alice Ryhl --- MAINTAINERS | 7 + rust/kernel/bitmap.rs | 585 +++++++++++++++++++++++++++++++++++++ rust/kernel/lib.rs | 1 + security/Kconfig.hardening | 10 + 4 files changed, 603 insertions(+) create mode 100644 rust/kernel/bitmap.rs diff --git a/MAINTAINERS b/MAINTAINERS index 5654a5277df0..98c290d246cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4302,6 +4302,13 @@ S: Maintained F: rust/helpers/bitmap.c F: rust/helpers/cpumask.c =20 +BITMAP API [RUST] +M: Alice Ryhl +M: Burak Emir +R: Yury Norov +S: Maintained +F: rust/kernel/bitmap.rs + BITOPS API M: Yury Norov R: Rasmus Villemoes diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs new file mode 100644 index 000000000000..f349b1eb59f9 --- /dev/null +++ b/rust/kernel/bitmap.rs @@ -0,0 +1,585 @@ +// SPDX-License-Identifier: GPL-2.0 + +// Copyright (C) 2025 Google LLC. + +//! Rust API for bitmap. +//! +//! C headers: [`include/linux/bitmap.h`](srctree/include/linux/bitmap.h). + +use crate::alloc::{AllocError, Flags}; +use crate::bindings; +#[cfg(not(CONFIG_RUST_BITMAP_HARDENED))] +use crate::pr_err; +use core::ptr::NonNull; + +const BITS_PER_LONG: usize =3D bindings::BITS_PER_LONG as usize; + +/// Represents a C bitmap. Wraps underlying C bitmap API. +/// +/// # Invariants +/// +/// Must reference a `[c_ulong]` long enough to fit `data.len()` bits. +#[cfg_attr(CONFIG_64BIT, repr(align(8)))] +#[cfg_attr(not(CONFIG_64BIT), repr(align(4)))] +pub struct Bitmap { + data: [()], +} + +impl Bitmap { + /// Borrows a C bitmap. + /// + /// # Safety + /// + /// * `ptr` holds a non-null address of an initialized array of `unsig= ned long` + /// that is large enough to hold `nbits` bits. + /// * the array must not be freed for the lifetime of this [`Bitmap`] + /// * concurrent access only happens through atomic operations + pub unsafe fn from_raw<'a>(ptr: *const usize, nbits: usize) -> &'a Bit= map { + let data: *const [()] =3D core::ptr::slice_from_raw_parts(ptr.cast= (), nbits); + // INVARIANT: `data` references an initialized array that can hold= `nbits` bits. + // SAFETY: + // The caller guarantees that `data` (derived from `ptr` and `nbit= s`) + // points to a valid, initialized, and appropriately sized memory = region + // that will not be freed for the lifetime 'a. + // We are casting `*const [()]` to `*const Bitmap`. The `Bitmap` + // struct is a ZST with a `data: [()]` field. This means its layout + // is compatible with a slice of `()`, and effectively it's a "thi= n pointer" + // (its size is 0 and alignment is 1). The `slice_from_raw_parts` + // function correctly encodes the length (number of bits, not elem= ents) + // into the metadata of the fat pointer. Therefore, dereferencing = this + // pointer as `&Bitmap` is safe given the caller's guarantees. + unsafe { &*(data as *const Bitmap) } + } + + /// Borrows a C bitmap exclusively. + /// + /// # Safety + /// + /// * `ptr` holds a non-null address of an initialized array of `unsig= ned long` + /// that is large enough to hold `nbits` bits. + /// * the array must not be freed for the lifetime of this [`Bitmap`] + /// * no concurrent access may happen. + pub unsafe fn from_raw_mut<'a>(ptr: *mut usize, nbits: usize) -> &'a m= ut Bitmap { + let data: *mut [()] =3D core::ptr::slice_from_raw_parts_mut(ptr.ca= st(), nbits); + // INVARIANT: `data` references an initialized array that can hold= `nbits` bits. + // SAFETY: + // The caller guarantees that `data` (derived from `ptr` and `nbit= s`) + // points to a valid, initialized, and appropriately sized memory = region + // that will not be freed for the lifetime 'a. + // Furthermore, the caller guarantees no concurrent access will ha= ppen, + // which upholds the exclusivity requirement for a mutable referen= ce. + // Similar to `from_raw`, casting `*mut [()]` to `*mut Bitmap` is + // safe because `Bitmap` is a ZST with a `data: [()]` field, + // making its layout compatible with a slice of `()`. + unsafe { &mut *(data as *mut Bitmap) } + } + + /// Returns a raw pointer to the backing [`Bitmap`]. + pub fn as_ptr(&self) -> *const usize { + core::ptr::from_ref::(self).cast::() + } + + /// Returns a mutable raw pointer to the backing [`Bitmap`]. + pub fn as_mut_ptr(&mut self) -> *mut usize { + core::ptr::from_mut::(self).cast::() + } + + /// Returns length of this [`Bitmap`]. + #[expect(clippy::len_without_is_empty)] + pub fn len(&self) -> usize { + self.data.len() + } +} + +/// Holds either a pointer to array of `unsigned long` or a small bitmap. +#[repr(C)] +union BitmapRepr { + bitmap: usize, + ptr: NonNull, +} + +macro_rules! bitmap_assert { + ($cond:expr, $($arg:tt)+) =3D> { + #[cfg(CONFIG_RUST_BITMAP_HARDENED)] + assert!($cond, $($arg)*); + } +} + +macro_rules! bitmap_assert_return { + ($cond:expr, $($arg:tt)+) =3D> { + #[cfg(CONFIG_RUST_BITMAP_HARDENED)] + assert!($cond, $($arg)*); + + #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))] + if !($cond) { + pr_err!($($arg)*); + return + } + } +} + +/// Represents an owned bitmap. +/// +/// Wraps underlying C bitmap API. See [`Bitmap`] for available +/// methods. +/// +/// # Examples +/// +/// Basic usage +/// +/// ``` +/// use kernel::alloc::flags::GFP_KERNEL; +/// use kernel::bitmap::BitmapVec; +/// +/// let mut b =3D BitmapVec::new(16, GFP_KERNEL)?; +/// +/// assert_eq!(16, b.len()); +/// for i in 0..16 { +/// if i % 4 =3D=3D 0 { +/// b.set_bit(i); +/// } +/// } +/// assert_eq!(Some(0), b.next_bit(0)); +/// assert_eq!(Some(1), b.next_zero_bit(0)); +/// assert_eq!(Some(4), b.next_bit(1)); +/// assert_eq!(Some(5), b.next_zero_bit(4)); +/// assert_eq!(Some(12), b.last_bit()); +/// # Ok::<(), Error>(()) +/// ``` +/// +/// # Invariants +/// +/// * `nbits` is `<=3D i32::MAX` and never changes. +/// * if `nbits <=3D bindings::BITS_PER_LONG`, then `repr` is a `usize`. +/// * otherwise, `repr` holds a non-null pointer to an initialized +/// array of `unsigned long` that is large enough to hold `nbits` bits. +pub struct BitmapVec { + /// Representation of bitmap. + repr: BitmapRepr, + /// Length of this bitmap. Must be `<=3D i32::MAX`. + nbits: usize, +} + +impl core::ops::Deref for BitmapVec { + type Target =3D Bitmap; + + fn deref(&self) -> &Bitmap { + let ptr =3D if self.nbits <=3D BITS_PER_LONG { + // SAFETY: Bitmap is represented inline. + unsafe { core::ptr::addr_of!(self.repr.bitmap) } + } else { + // SAFETY: Bitmap is represented as array of `unsigned long`. + unsafe { self.repr.ptr.as_ptr() } + }; + + // SAFETY: We got the right pointer and invariants of [`Bitmap`] h= old. + // An inline bitmap is treated like an array with single element. + unsafe { Bitmap::from_raw(ptr, self.nbits) } + } +} + +impl core::ops::DerefMut for BitmapVec { + fn deref_mut(&mut self) -> &mut Bitmap { + let ptr =3D if self.nbits <=3D BITS_PER_LONG { + // SAFETY: Bitmap is represented inline. + unsafe { core::ptr::addr_of_mut!(self.repr.bitmap) } + } else { + // SAFETY: Bitmap is represented as array of `unsigned long`. + unsafe { self.repr.ptr.as_ptr() } + }; + + // SAFETY: We got the right pointer and invariants of [`BitmapVec`= ] hold. + // An inline bitmap is treated like an array with single element. + unsafe { Bitmap::from_raw_mut(ptr, self.nbits) } + } +} + +/// Enable ownership transfer to other threads. +/// +/// SAFETY: We own the underlying bitmap representation. +unsafe impl Send for BitmapVec {} + +/// Enable unsynchronized concurrent access to [`BitmapVec`] through share= d references. +/// +/// SAFETY: `deref()` will return a reference to a [`Bitmap`]. Its methods +/// take immutable references are either atomic or read-only. +unsafe impl Sync for BitmapVec {} + +impl Drop for BitmapVec { + fn drop(&mut self) { + if self.nbits <=3D BITS_PER_LONG { + return; + } + // SAFETY: `self.ptr` was returned by the C `bitmap_zalloc`. + // + // INVARIANT: there is no other use of the `self.ptr` after this + // call and the value is being dropped so the broken invariant is + // not observable on function exit. + unsafe { bindings::bitmap_free(self.repr.ptr.as_ptr()) }; + } +} + +impl BitmapVec { + /// Constructs a new [`BitmapVec`]. + /// + /// Fails with [`AllocError`] when the [`BitmapVec`] could not be allo= cated. This + /// includes the case when `nbits` is greater than `i32::MAX`. + #[inline] + pub fn new(nbits: usize, flags: Flags) -> Result { + if nbits <=3D BITS_PER_LONG { + return Ok(BitmapVec { + repr: BitmapRepr { bitmap: 0 }, + nbits, + }); + } + if nbits > i32::MAX.try_into().unwrap() { + return Err(AllocError); + } + let nbits_u32 =3D u32::try_from(nbits).unwrap(); + // SAFETY: `BITS_PER_LONG < nbits` and `nbits <=3D i32::MAX`. + let ptr =3D unsafe { bindings::bitmap_zalloc(nbits_u32, flags.as_r= aw()) }; + let ptr =3D NonNull::new(ptr).ok_or(AllocError)?; + // INVARIANT: `ptr` returned by C `bitmap_zalloc` and `nbits` chec= ked. + Ok(BitmapVec { + repr: BitmapRepr { ptr }, + nbits, + }) + } + + /// Returns length of this [`Bitmap`]. + #[allow(clippy::len_without_is_empty)] + #[inline] + pub fn len(&self) -> usize { + self.nbits + } +} + +impl Bitmap { + /// Set bit with index `index`. + /// + /// ATTENTION: `set_bit` is non-atomic, which differs from the naming + /// convention in C code. The corresponding C function is `__set_bit`. + /// + /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and `index` is great= er than + /// or equal to `self.nbits`, does nothing. + /// + /// # Panics + /// + /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `index` is gr= eater than + /// or equal to `self.nbits`. + #[inline] + pub fn set_bit(&mut self, index: usize) { + bitmap_assert_return!( + index < self.len(), + "Bit `index` must be < {}, was {}", + self.len(), + index + ); + // SAFETY: Bit `index` is within bounds. + unsafe { bindings::__set_bit(index, self.as_mut_ptr()) }; + } + + /// Set bit with index `index`, atomically. + /// + /// This is a relaxed atomic operation (no implied memory barriers). + /// + /// ATTENTION: The naming convention differs from C, where the corresp= onding + /// function is called `set_bit`. + /// + /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and `index` is great= er than + /// or equal to `self.len()`, does nothing. + /// + /// # Panics + /// + /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `index` is gr= eater than + /// or equal to `self.len()`. + #[inline] + pub fn set_bit_atomic(&self, index: usize) { + bitmap_assert_return!( + index < self.len(), + "Bit `index` must be < {}, was {}", + self.len(), + index + ); + // SAFETY: `index` is within bounds and the caller has ensured that + // there is no mix of non-atomic and atomic operations. + unsafe { bindings::set_bit(index, self.as_ptr().cast_mut()) }; + } + + /// Clear `index` bit. + /// + /// ATTENTION: `clear_bit` is non-atomic, which differs from the naming + /// convention in C code. The corresponding C function is `__clear_bit= `. + /// + /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and `index` is great= er than + /// or equal to `self.len()`, does nothing. + /// + /// # Panics + /// + /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `index` is gr= eater than + /// or equal to `self.len()`. + #[inline] + pub fn clear_bit(&mut self, index: usize) { + bitmap_assert_return!( + index < self.len(), + "Bit `index` must be < {}, was {}", + self.len(), + index + ); + // SAFETY: `index` is within bounds. + unsafe { bindings::__clear_bit(index, self.as_mut_ptr()) }; + } + + /// Clear `index` bit, atomically. + /// + /// This is a relaxed atomic operation (no implied memory barriers). + /// + /// ATTENTION: The naming convention differs from C, where the corresp= onding + /// function is called `clear_bit`. + /// + /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and `index` is great= er than + /// or equal to `self.len()`, does nothing. + /// + /// # Panics + /// + /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `index` is gr= eater than + /// or equal to `self.len()`. + #[inline] + pub fn clear_bit_atomic(&self, index: usize) { + bitmap_assert_return!( + index < self.len(), + "Bit `index` must be < {}, was {}", + self.len(), + index + ); + // SAFETY: `index` is within bounds and the caller has ensured that + // there is no mix of non-atomic and atomic operations. + unsafe { bindings::clear_bit(index, self.as_ptr().cast_mut()) }; + } + + /// Copy `src` into this [`Bitmap`] and set any remaining bits to zero. + /// + /// # Examples + /// + /// ``` + /// use kernel::alloc::{AllocError, flags::GFP_KERNEL}; + /// use kernel::bitmap::BitmapVec; + /// + /// let mut long_bitmap =3D BitmapVec::new(256, GFP_KERNEL)?; + /// + /// assert_eq!(None, long_bitmap.last_bit()); + /// + /// let mut short_bitmap =3D BitmapVec::new(16, GFP_KERNEL)?; + /// + /// short_bitmap.set_bit(7); + /// long_bitmap.copy_and_extend(&short_bitmap); + /// assert_eq!(Some(7), long_bitmap.last_bit()); + /// + /// # Ok::<(), AllocError>(()) + /// ``` + #[inline] + pub fn copy_and_extend(&mut self, src: &Bitmap) { + let len =3D core::cmp::min(src.len(), self.len()); + // SAFETY: access to `self` and `src` is within bounds. + unsafe { + bindings::bitmap_copy_and_extend( + self.as_mut_ptr(), + src.as_ptr(), + len as u32, + self.len() as u32, + ) + }; + } + + /// Finds last set bit. + /// + /// # Examples + /// + /// ``` + /// use kernel::alloc::{AllocError, flags::GFP_KERNEL}; + /// use kernel::bitmap::BitmapVec; + /// + /// let bitmap =3D BitmapVec::new(64, GFP_KERNEL)?; + /// + /// match bitmap.last_bit() { + /// Some(idx) =3D> { + /// pr_info!("The last bit has index {idx}.\n"); + /// } + /// None =3D> { + /// pr_info!("All bits in this bitmap are 0.\n"); + /// } + /// } + /// # Ok::<(), AllocError>(()) + /// ``` + #[inline] + pub fn last_bit(&self) -> Option { + // SAFETY: `_find_next_bit` access is within bounds due to invaria= nt. + let index =3D unsafe { bindings::_find_last_bit(self.as_ptr(), sel= f.len()) }; + if index >=3D self.len() { + None + } else { + Some(index) + } + } + + /// Finds next set bit, starting from `start`. + /// + /// Returns `None` if `start` is greater or equal to `self.nbits`. + #[inline] + pub fn next_bit(&self, start: usize) -> Option { + bitmap_assert!( + start < self.len(), + "`start` must be < {} was {}", + self.len(), + start + ); + // SAFETY: `_find_next_bit` tolerates out-of-bounds arguments and = returns a + // value larger than or equal to `self.len()` in that case. + let index =3D unsafe { bindings::_find_next_bit(self.as_ptr(), sel= f.len(), start) }; + if index >=3D self.len() { + None + } else { + Some(index) + } + } + + /// Finds next zero bit, starting from `start`. + /// Returns `None` if `start` is greater than or equal to `self.len()`. + #[inline] + pub fn next_zero_bit(&self, start: usize) -> Option { + bitmap_assert!( + start < self.len(), + "`start` must be < {} was {}", + self.len(), + start + ); + // SAFETY: `_find_next_zero_bit` tolerates out-of-bounds arguments= and returns a + // value larger than or equal to `self.len()` in that case. + let index =3D unsafe { bindings::_find_next_zero_bit(self.as_ptr()= , self.len(), start) }; + if index >=3D self.len() { + None + } else { + Some(index) + } + } +} + +use macros::kunit_tests; + +#[kunit_tests(rust_kernel_bitmap)] +mod tests { + use super::*; + use kernel::alloc::flags::GFP_KERNEL; + + #[test] + fn bitmap_borrow() { + let fake_bitmap: [usize; 2] =3D [0, 0]; + // SAFETY: `fake_c_bitmap` is an array of expected length. + let b =3D unsafe { Bitmap::from_raw(fake_bitmap.as_ptr(), 2 * BITS= _PER_LONG) }; + assert_eq!(2 * BITS_PER_LONG, b.len()); + assert_eq!(None, b.next_bit(0)); + } + + #[test] + fn bitmap_copy() { + let fake_bitmap: usize =3D 0xFF; + // SAFETY: `fake_c_bitmap` can be used as one-element array of exp= ected length. + let b =3D unsafe { Bitmap::from_raw(core::ptr::addr_of!(fake_bitma= p), 8) }; + assert_eq!(8, b.len()); + assert_eq!(None, b.next_zero_bit(0)); + } + + #[test] + fn bitmap_vec_new() -> Result<(), AllocError> { + let b =3D BitmapVec::new(0, GFP_KERNEL)?; + assert_eq!(0, b.len()); + + let b =3D BitmapVec::new(3, GFP_KERNEL)?; + assert_eq!(3, b.len()); + + let b =3D BitmapVec::new(1024, GFP_KERNEL)?; + assert_eq!(1024, b.len()); + + // Requesting too large values results in [`AllocError`]. + let res =3D BitmapVec::new(1 << 31, GFP_KERNEL); + assert!(res.is_err()); + Ok(()) + } + + #[test] + fn bitmap_set_clear_find() -> Result<(), AllocError> { + let mut b =3D BitmapVec::new(128, GFP_KERNEL)?; + + // Zero-initialized + assert_eq!(None, b.next_bit(0)); + assert_eq!(Some(0), b.next_zero_bit(0)); + assert_eq!(None, b.last_bit()); + + b.set_bit(17); + + assert_eq!(Some(17), b.next_bit(0)); + assert_eq!(Some(17), b.next_bit(17)); + assert_eq!(None, b.next_bit(18)); + assert_eq!(Some(17), b.last_bit()); + + b.set_bit(107); + + assert_eq!(Some(17), b.next_bit(0)); + assert_eq!(Some(17), b.next_bit(17)); + assert_eq!(Some(107), b.next_bit(18)); + assert_eq!(Some(107), b.last_bit()); + + b.clear_bit(17); + + assert_eq!(Some(107), b.next_bit(0)); + assert_eq!(Some(107), b.last_bit()); + Ok(()) + } + + #[test] + fn owned_bitmap_out_of_bounds() -> Result<(), AllocError> { + // TODO: Kunit #[test]s do not support `cfg` yet, + // so we add it here in the body. + #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))] + { + let mut b =3D BitmapVec::new(128, GFP_KERNEL)?; + b.set_bit(2048); + b.set_bit_atomic(2048); + b.clear_bit(2048); + b.clear_bit_atomic(2048); + assert_eq!(None, b.next_bit(2048)); + assert_eq!(None, b.next_zero_bit(2048)); + assert_eq!(None, b.last_bit()); + } + Ok(()) + } + + // TODO: uncomment once kunit supports [should_panic] and `cfg`. + // #[cfg(CONFIG_RUST_BITMAP_HARDENED)] + // #[test] + // #[should_panic] + // fn owned_bitmap_out_of_bounds() -> Result<(), AllocError> { + // let mut b =3D BitmapVec::new(128, GFP_KERNEL)?; + // + // b.set_bit(2048); + // } + + #[test] + fn bitmap_copy_and_extend() -> Result<(), AllocError> { + let mut long_bitmap =3D BitmapVec::new(256, GFP_KERNEL)?; + + long_bitmap.set_bit(3); + long_bitmap.set_bit(200); + + let mut short_bitmap =3D BitmapVec::new(32, GFP_KERNEL)?; + + short_bitmap.set_bit(17); + + long_bitmap.copy_and_extend(&short_bitmap); + + // Previous bits have been cleared. + assert_eq!(Some(17), long_bitmap.next_bit(0)); + assert_eq!(Some(17), long_bitmap.last_bit()); + Ok(()) + } +} diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index fef97f2a5098..03eb6b34ddd2 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -62,6 +62,7 @@ pub mod alloc; #[cfg(CONFIG_AUXILIARY_BUS)] pub mod auxiliary; +pub mod bitmap; pub mod bits; #[cfg(CONFIG_BLOCK)] pub mod block; diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening index b9a5bc3430aa..86f8768c63d4 100644 --- a/security/Kconfig.hardening +++ b/security/Kconfig.hardening @@ -255,6 +255,16 @@ config LIST_HARDENED =20 If unsure, say N. =20 +config RUST_BITMAP_HARDENED + bool "Check integrity of bitmap Rust API" + depends on RUST + help + Enables additional assertions in the Rust Bitmap API to catch + arguments that are not guaranteed to result in an immediate access + fault. + + If unsure, say N. + config BUG_ON_DATA_CORRUPTION bool "Trigger a BUG when data corruption is detected" select LIST_HARDENED --=20 2.51.0.355.g5224444f11-goog From nobody Fri Oct 3 02:16:57 2025 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FDBE2E5D32 for ; Mon, 8 Sep 2025 07:22:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316127; cv=none; b=gwhThkQpTumPOTQwEAelKURau46PyeGWeHUE0e7ZOGiLZQNTgPuMoe1xUjCmSlgv92hhMdv642HlZRLQVIsZwzW97nJ60S77DZQL9eVESIu1/MU8p9MnV1YnNRiI7VQYdfqfs7BOPm97Aj6nAdudd397RpN/fEd995XTkOUgN08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316127; c=relaxed/simple; bh=zWaFv6wIQnDxO16NsTQ3HvYYxUl2HsKNEBdHmvlvdb0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=sCcQ8N1IKrqYBhys5cIyifBqKBwlWOTmmZpHcRWinfAP7bn1jHOYPaZ//Pkl0Kbqu1X8fyQrWxxJPRoRPPAitz3GuPCBcPxtQsPEDPJcSvbazEm9Bejfclp+185JFQzvUkwRyxb3DbPpigj+P1u8xy41Xh1z+0vYrZFj18iDs2A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fY01RCE3; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fY01RCE3" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-45de18e7eccso7609755e9.0 for ; Mon, 08 Sep 2025 00:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1757316123; x=1757920923; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=1ePxjvctTOLE3eciJG001eb53Phz0dQCJ3ObaVFMaXw=; b=fY01RCE36a/Xd4eXp/zeuLQme5LkP75ia6otsuvm+5J2+ll6t84wIOryxEwcYhkYoa lrADWpQ0MxOApdftvAvu2VtTCacEiHK098U3Zgj3zLqrFScS8WfG2Hjxkc1YY/5My3fm 80caX1n/mFapJUsbGtwhJirwLxGc0Hk+jPw2ZJHYStk0SVmQZfGZpel9y+b7GQlqnGpC mNy3jK1zzwzoOAlsLCMYEKMYXu9JQrV8rkFcz6bj5SsvznSaMrSjmtsMT5vWpke965nX qugTTfJnyaeCQZIFt/ewAHrAwGAaB7PCXok9/aqdZ5eAPnGMFKvaqa5c9BDP6Mrmfnu4 jTeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757316123; x=1757920923; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1ePxjvctTOLE3eciJG001eb53Phz0dQCJ3ObaVFMaXw=; b=QRf142iwBXhTd6gq3w9bm4NiBIRmdY7spQNJhVeuVmqLPOaMuZGq5AuMUp2/Vwceb3 p6Lm2BS7ktkRBILyezWQNjO4q8TLK9M0GW+zNtDjR1DUrc3Dp1159kDPzPzfX8eKufeE PAJ3nQuv2b3NeWS1s+w+YUHyCxQw8nHSSxFnQXQma0dMLikDhQ2dUimSf0ULK7QkoXvf 24l7LR6VY9owERrakFyqzF1uDJKei54oLtisqxp5zMmFkEVuXL/pfSzKoibSjAu6pEiA nCtT5NxU7TPtmcrmsgtqleTq7uscjmgJnDgPhTfxWSZJyD7O+PkU1cdE5ywNvGu0z9QH kaPQ== X-Forwarded-Encrypted: i=1; AJvYcCXpW36JRP0vVqqBGs1AF/78owUbrZ4fIMe615Z0Y3F3bvAefxve8/LAuzo2UTUfs7M1fr1T5o3JM6reZrk=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7Sd3ToTVjNb/+m529/Ygz6R2JOM0+qxxD8OcdIxgQZJ11n71q QmE0u4hLetNIXMoU3r/i9L+7dLlljd/XxGZLwJCvlaY5xtkiqMZHclsqFSaUxJN8bijpjw== X-Google-Smtp-Source: AGHT+IGIXTaPc6PZiNuhCsxD+oYfeTZRnrbJqWHRjPqkO1xAkej7baOcajV+35iWea/IKw7zsBNR8JU= X-Received: from wrbee14.prod.google.com ([2002:a05:6000:210e:b0:3e7:4935:6261]) (user=bqe job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:647:b0:3e7:1f63:6e81 with SMTP id ffacd0b85a97d-3e71f6373c5mr5095031f8f.16.1757316123609; Mon, 08 Sep 2025 00:22:03 -0700 (PDT) Date: Mon, 8 Sep 2025 07:21:54 +0000 In-Reply-To: <20250908072158.1041611-1-bqe@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250908072158.1041611-1-bqe@google.com> X-Mailer: git-send-email 2.51.0.355.g5224444f11-goog Message-ID: <20250908072158.1041611-5-bqe@google.com> Subject: [PATCH v16 4/5] rust: add find_bit_benchmark_rust module. From: Burak Emir To: Yury Norov , Kees Cook Cc: Burak Emir , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , Carlos LLama , Pekka Ristola , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Microbenchmark protected by a config FIND_BIT_BENCHMARK_RUST, following `find_bit_benchmark.c` but testing the Rust Bitmap API. We add a fill_random() method protected by the config in order to maintain the abstraction. The sample output from the benchmark, both C and Rust version: find_bit_benchmark.c output: ``` Start testing find_bit() with random-filled bitmap [ 438.101937] find_next_bit: 860188 ns, 163419 iterations [ 438.109471] find_next_zero_bit: 912342 ns, 164262 iterations [ 438.116820] find_last_bit: 726003 ns, 163419 iterations [ 438.130509] find_nth_bit: 7056993 ns, 16269 iterations [ 438.139099] find_first_bit: 1963272 ns, 16270 iterations [ 438.173043] find_first_and_bit: 27314224 ns, 32654 iterations [ 438.180065] find_next_and_bit: 398752 ns, 73705 iterations [ 438.186689] Start testing find_bit() with sparse bitmap [ 438.193375] find_next_bit: 9675 ns, 656 iterations [ 438.201765] find_next_zero_bit: 1766136 ns, 327025 iterations [ 438.208429] find_last_bit: 9017 ns, 656 iterations [ 438.217816] find_nth_bit: 2749742 ns, 655 iterations [ 438.225168] find_first_bit: 721799 ns, 656 iterations [ 438.231797] find_first_and_bit: 2819 ns, 1 iterations [ 438.238441] find_next_and_bit: 3159 ns, 1 iterations ``` find_bit_benchmark_rust.rs output: ``` [ 451.182459] find_bit_benchmark_rust: [ 451.186688] Start testing find_bit() Rust with random-filled bitmap [ 451.194450] next_bit: 777950 ns, 163644 iterations [ 451.201997] next_zero_bit: 918889 ns, 164036 iterations [ 451.208642] Start testing find_bit() Rust with sparse bitmap [ 451.214300] next_bit: 9181 ns, 654 iterations [ 451.222806] next_zero_bit: 1855504 ns, 327026 iterations ``` Here are the results from 32 samples, with 95% confidence interval. The microbenchmark was built with RUST_BITMAP_HARDENED=3Dn and run on a machine that did not execute other processes. Random-filled bitmap: +-----------+-------+-----------+--------------+-----------+-----------+ | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi | +-----------+-------+-----------+--------------+-----------+-----------+ | find_bit/ | C | 825.07 | 53.89 | 806.40 | 843.74 | | next_bit | Rust | 870.91 | 46.29 | 854.88 | 886.95 | +-----------+-------+-----------+--------------+-----------+-----------+ | find_zero/| C | 933.56 | 56.34 | 914.04 | 953.08 | | next_zero | Rust | 945.85 | 60.44 | 924.91 | 966.79 | +-----------+-------+-----------+--------------+-----------+-----------+ Rust appears 5.5% slower for next_bit, 1.3% slower for next_zero. Sparse bitmap: +-----------+-------+-----------+--------------+-----------+-----------+ | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi | +-----------+-------+-----------+--------------+-----------+-----------+ | find_bit/ | C | 13.17 | 6.21 | 11.01 | 15.32 | | next_bit | Rust | 14.30 | 8.27 | 11.43 | 17.17 | +-----------+-------+-----------+--------------+-----------+-----------+ | find_zero/| C | 1859.31 | 82.30 | 1830.80 | 1887.83 | | next_zero | Rust | 1908.09 | 139.82 | 1859.65 | 1956.54 | +-----------+-------+-----------+--------------+-----------+-----------+ Rust appears 8.5% slower for next_bit, 2.6% slower for next_zero. In summary, taking the arithmetic mean of all slow-downs, we can say the Rust API has a 4.5% slowdown. Suggested-by: Alice Ryhl Suggested-by: Yury Norov [NVIDIA] Reviewed-by: Yury Norov [NVIDIA] Reviewed-by: Alice Ryhl Signed-off-by: Burak Emir --- MAINTAINERS | 1 + lib/Kconfig.debug | 13 ++++ lib/Makefile | 1 + lib/find_bit_benchmark_rust.rs | 104 ++++++++++++++++++++++++++++++++ rust/bindings/bindings_helper.h | 1 + rust/kernel/bitmap.rs | 15 +++++ 6 files changed, 135 insertions(+) create mode 100644 lib/find_bit_benchmark_rust.rs diff --git a/MAINTAINERS b/MAINTAINERS index 98c290d246cc..a720ebab334c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4307,6 +4307,7 @@ M: Alice Ryhl M: Burak Emir R: Yury Norov S: Maintained +F: lib/find_bit_benchmark_rust.rs F: rust/kernel/bitmap.rs =20 BITOPS API diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index dc0e0c6ed075..386232d81a0e 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2607,6 +2607,19 @@ config FIND_BIT_BENCHMARK =20 If unsure, say N. =20 +config FIND_BIT_BENCHMARK_RUST + tristate "Test find_bit functions in Rust" + depends on RUST + help + This builds the "find_bit_benchmark_rust" module. It is a micro + benchmark that measures the performance of Rust functions that + correspond to the find_*_bit() operations in C. It follows the + FIND_BIT_BENCHMARK closely but will in general not yield same + numbers due to extra bounds checks and overhead of foreign + function calls. + + If unsure, say N. + config TEST_FIRMWARE tristate "Test firmware loading via userspace interface" depends on FW_LOADER diff --git a/lib/Makefile b/lib/Makefile index 392ff808c9b9..96a83b937a60 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -62,6 +62,7 @@ obj-y +=3D hexdump.o obj-$(CONFIG_TEST_HEXDUMP) +=3D test_hexdump.o obj-y +=3D kstrtox.o obj-$(CONFIG_FIND_BIT_BENCHMARK) +=3D find_bit_benchmark.o +obj-$(CONFIG_FIND_BIT_BENCHMARK_RUST) +=3D find_bit_benchmark_rust.o obj-$(CONFIG_TEST_BPF) +=3D test_bpf.o test_dhry-objs :=3D dhry_1.o dhry_2.o dhry_run.o obj-$(CONFIG_TEST_DHRY) +=3D test_dhry.o diff --git a/lib/find_bit_benchmark_rust.rs b/lib/find_bit_benchmark_rust.rs new file mode 100644 index 000000000000..6bdc51de2f30 --- /dev/null +++ b/lib/find_bit_benchmark_rust.rs @@ -0,0 +1,104 @@ +// SPDX-License-Identifier: GPL-2.0 +//! Benchmark for find_bit-like methods in Bitmap Rust API. + +use kernel::alloc::flags::GFP_KERNEL; +use kernel::bindings; +use kernel::bitmap::BitmapVec; +use kernel::error::{code, Result}; +use kernel::prelude::module; +use kernel::time::{Instant, Monotonic}; +use kernel::ThisModule; +use kernel::{pr_cont, pr_err}; + +const BITMAP_LEN: usize =3D 4096 * 8 * 10; +// Reciprocal of the fraction of bits that are set in sparse bitmap. +const SPARSENESS: usize =3D 500; + +/// Test module that benchmarks performance of traversing bitmaps. +struct Benchmark(); + +fn test_next_bit(bitmap: &BitmapVec) { + let time =3D Instant::::now(); + let mut cnt =3D 0; + let mut i =3D 0; + + while let Some(index) =3D bitmap.next_bit(i) { + cnt +=3D 1; + i =3D index + 1; + // CONFIG_RUST_BITMAP_HARDENED enforces strict bounds. + if i =3D=3D BITMAP_LEN { + break; + } + } + + let delta =3D time.elapsed(); + pr_cont!( + "\nnext_bit: {:18} ns, {:6} iterations", + delta.as_nanos(), + cnt + ); +} + +fn test_next_zero_bit(bitmap: &BitmapVec) { + let time =3D Instant::::now(); + let mut cnt =3D 0; + let mut i =3D 0; + + while let Some(index) =3D bitmap.next_zero_bit(i) { + cnt +=3D 1; + i =3D index + 1; + // CONFIG_RUST_BITMAP_HARDENED enforces strict bounds. + if i =3D=3D BITMAP_LEN { + break; + } + } + + let delta =3D time.elapsed(); + pr_cont!( + "\nnext_zero_bit: {:18} ns, {:6} iterations", + delta.as_nanos(), + cnt + ); +} + +fn find_bit_test() { + pr_err!("Benchmark"); + pr_cont!("\nStart testing find_bit() Rust with random-filled bitmap"); + + let mut bitmap =3D BitmapVec::new(BITMAP_LEN, GFP_KERNEL).expect("allo= c bitmap failed"); + bitmap.fill_random(); + + test_next_bit(&bitmap); + test_next_zero_bit(&bitmap); + + pr_cont!("\nStart testing find_bit() Rust with sparse bitmap"); + + let mut bitmap =3D BitmapVec::new(BITMAP_LEN, GFP_KERNEL).expect("allo= c sparse bitmap failed"); + let nbits =3D BITMAP_LEN / SPARSENESS; + for _i in 0..nbits { + // SAFETY: __get_random_u32_below is safe to call with any u32 arg= ument. + let bit =3D + unsafe { bindings::__get_random_u32_below(BITMAP_LEN.try_into(= ).unwrap()) as usize }; + bitmap.set_bit(bit); + } + + test_next_bit(&bitmap); + test_next_zero_bit(&bitmap); + pr_cont!("\n"); +} + +impl kernel::Module for Benchmark { + fn init(_module: &'static ThisModule) -> Result { + find_bit_test(); + // Return error so test module can be inserted again without rmmod. + Err(code::EINVAL) + } +} + +module! { + type: Benchmark, + name: "find_bit_benchmark_rust", + authors: ["Burak Emir "], + description: "Module with benchmark for bitmap Rust API", + license: "GPL v2", +} diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helpe= r.h index 7bb575043c86..5d58316f871e 100644 --- a/rust/bindings/bindings_helper.h +++ b/rust/bindings/bindings_helper.h @@ -67,6 +67,7 @@ #include #include #include +#include #include #include #include diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs index f349b1eb59f9..f45915694454 100644 --- a/rust/kernel/bitmap.rs +++ b/rust/kernel/bitmap.rs @@ -252,6 +252,21 @@ pub fn new(nbits: usize, flags: Flags) -> Result { pub fn len(&self) -> usize { self.nbits } + + /// Fills this `Bitmap` with random bits. + #[cfg(CONFIG_FIND_BIT_BENCHMARK_RUST)] + pub fn fill_random(&mut self) { + // SAFETY: `self.as_mut_ptr` points to either an array of the + // appropriate length or one usize. + unsafe { + bindings::get_random_bytes( + self.as_mut_ptr().cast::(), + usize::div_ceil(self.nbits, bindings::BITS_PER_LONG as usi= ze) + * bindings::BITS_PER_LONG as usize + / 8, + ); + } + } } =20 impl Bitmap { --=20 2.51.0.355.g5224444f11-goog From nobody Fri Oct 3 02:16:57 2025 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8113E2E8B9A for ; Mon, 8 Sep 2025 07:22:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316129; cv=none; b=imNZ8Jrkv2fo+0llzW0GR8AInVykXp08UnaRCaZvOy8RA3NzGmr1J/b/1tSxjK3ie9SgcbKW6TqFBtXHZ2Ofb1N3B/R9n5jyA3+Ri8NNPFZmvFS6Ixy4Dm8QBhXtxUtD6lLpB83mLiBh9LPhzZxmG0TlFBU2yj/lZZLo3TrNyqM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757316129; c=relaxed/simple; bh=pmqS3evNc5oxoiYApVyvCuJZfNi/fP6gQHZHJm2XXkc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=BgMlC9xw6ySy2Xjd/CXekmqMVsk7A9KK8Q7RopDsIO2MB2cHSGEIykXqxOgpwlfrWnN07mRWT6AR9YqF/IVjeuaJnIU2aSPPjLxKOkMWiNjOHqF+cmZ/bar614IQrZLtGxJY6vkCucHW85N5F72uU2b5OuwohSSZ75B1A8ZWyKQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=1lCsDpyq; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--bqe.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="1lCsDpyq" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-3dc0f2fd4acso2649867f8f.2 for ; Mon, 08 Sep 2025 00:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1757316125; x=1757920925; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=PwOBttLcfP3y909J4CXHqY+uMaR7wzzUE7W3TRjyS/Q=; b=1lCsDpyqtDOudhn07Zp3mYaQBNP531gP2tb2cVwO46VJFB+KfHP3xdw/bNvfN00ydP iWaFj6z1UQnf7aaFjYFkkAJpO6bul+34kRw/M2BL24sjVBy1RC54ki1eccccIXoooInq G22T513+TbDegh6YuR253hSwhrvCEk6K7TbKARFIzf6ICaDGJovgp/UACipGi6/olCqr 8uV5aq9kSBWiHnFnVW5fT1/JxHDgfLTr9bU2dQf6/Lk1Ynywv324k2BlbA2RFOLZuE+a LHb/y0CwlZx19//RIDep80MLXb/lnk+7XNNoiqpmZDNyckxqVSyVWPBysuk5Wyc3Nt1X o5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757316125; x=1757920925; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PwOBttLcfP3y909J4CXHqY+uMaR7wzzUE7W3TRjyS/Q=; b=iOnD/QqHU3IoZGQOCcNe5+WuaDS8DXYmQ2CxAiiHkrc/G4HbWu0G/iydmWyXH6tVoT WvmMrNNimjECaLsoS0mfsmyrUd5WpIZma3H83SfIIVOKtJJuWmEpgHPTFhpJGuxXOaXt IwnFaTVrAUAZF58yC6/suaqXX3PgXwdihsE2T3byt/jIS+0LyKY+H4glgnvT8TSqunx7 MgOrXdBnNYX9oFTtne46KABm/tSIZJPtTG4ShmfroY94PQ3IAROJBUSFfc7C2QLJ1FLa a8paCsci8PzdXr0ubPT6YplBImwZdoH990ahxQuqqQMauMj9ZEnW09++CVtkZxBp6ic0 X7ww== X-Forwarded-Encrypted: i=1; AJvYcCUksNGh11PDFCATuobotiDCCmO0Sl89x15GaekC8zemDo5VB2Z1yrKkF46XycnsTlj3tIPYon9F7PrBVDA=@vger.kernel.org X-Gm-Message-State: AOJu0YwAbv+t36fMLnAouaqzaS3PENSPdJ2Hj+0mqGCVL/MrXlTD7+SG JXfXgCEAkQkxMbKYHkzsBfSXLnefu26s4mFj1vdjuPbwh3B2tlgETN//be989t/Chjc8Uw== X-Google-Smtp-Source: AGHT+IH7qGezYAQxCu5HJIfGQ38GlEMYOXtx+3BqAEho8c7/diV+LhX1oBeAhCEjb2YLeNyh32GKXw8= X-Received: from wrpk18.prod.google.com ([2002:adf:f5d2:0:b0:3d6:801b:c728]) (user=bqe job=prod-delivery.src-stubby-dispatcher) by 2002:a5d:64e3:0:b0:3e5:955d:a81b with SMTP id ffacd0b85a97d-3e64392d35bmr4582712f8f.34.1757316124583; Mon, 08 Sep 2025 00:22:04 -0700 (PDT) Date: Mon, 8 Sep 2025 07:21:55 +0000 In-Reply-To: <20250908072158.1041611-1-bqe@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250908072158.1041611-1-bqe@google.com> X-Mailer: git-send-email 2.51.0.355.g5224444f11-goog Message-ID: <20250908072158.1041611-6-bqe@google.com> Subject: [PATCH v16 5/5] rust: add dynamic ID pool abstraction for bitmap From: Burak Emir To: Yury Norov , Kees Cook Cc: Burak Emir , Rasmus Villemoes , Viresh Kumar , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , "Gustavo A . R . Silva" , Carlos LLama , Pekka Ristola , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is a port of the Binder data structure introduced in commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup") to Rust. Like drivers/android/dbitmap.h, the ID pool abstraction lets clients acquire and release IDs. The implementation uses a bitmap to know what IDs are in use, and gives clients fine-grained control over the time of allocation. This fine-grained control is needed in the Android Binder. We provide an example that release a spinlock for allocation and unit tests (rustdoc examples). The implementation does not permit shrinking below capacity below BITS_PER_LONG. Suggested-by: Alice Ryhl Suggested-by: Yury Norov Reviewed-by: Alice Ryhl Signed-off-by: Burak Emir --- MAINTAINERS | 1 + rust/kernel/id_pool.rs | 226 +++++++++++++++++++++++++++++++++++++++++ rust/kernel/lib.rs | 1 + 3 files changed, 228 insertions(+) create mode 100644 rust/kernel/id_pool.rs diff --git a/MAINTAINERS b/MAINTAINERS index a720ebab334c..6fb79d990e4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4309,6 +4309,7 @@ R: Yury Norov S: Maintained F: lib/find_bit_benchmark_rust.rs F: rust/kernel/bitmap.rs +F: rust/kernel/id_pool.rs =20 BITOPS API M: Yury Norov diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs new file mode 100644 index 000000000000..a41a3404213c --- /dev/null +++ b/rust/kernel/id_pool.rs @@ -0,0 +1,226 @@ +// SPDX-License-Identifier: GPL-2.0 + +// Copyright (C) 2025 Google LLC. + +//! Rust API for an ID pool backed by a [`BitmapVec`]. + +use crate::alloc::{AllocError, Flags}; +use crate::bitmap::BitmapVec; + +const BITS_PER_LONG: usize =3D bindings::BITS_PER_LONG as usize; + +/// Represents a dynamic ID pool backed by a [`BitmapVec`]. +/// +/// Clients acquire and release IDs from unset bits in a bitmap. +/// +/// The capacity of the ID pool may be adjusted by users as +/// needed. The API supports the scenario where users need precise control +/// over the time of allocation of a new backing bitmap, which may require +/// release of spinlock. +/// Due to concurrent updates, all operations are re-verified to determine +/// if the grow or shrink is sill valid. +/// +/// # Examples +/// +/// Basic usage +/// +/// ``` +/// use kernel::alloc::{AllocError, flags::GFP_KERNEL}; +/// use kernel::id_pool::IdPool; +/// +/// let mut pool =3D IdPool::new(64, GFP_KERNEL)?; +/// for i in 0..64 { +/// assert_eq!(i, pool.acquire_next_id(i).ok_or(ENOSPC)?); +/// } +/// +/// pool.release_id(23); +/// assert_eq!(23, pool.acquire_next_id(0).ok_or(ENOSPC)?); +/// +/// assert_eq!(None, pool.acquire_next_id(0)); // time to realloc. +/// let resizer =3D pool.grow_request().ok_or(ENOSPC)?.realloc(GFP_KERNEL)= ?; +/// pool.grow(resizer); +/// +/// assert_eq!(pool.acquire_next_id(0), Some(64)); +/// # Ok::<(), Error>(()) +/// ``` +/// +/// Releasing spinlock to grow the pool +/// +/// ```no_run +/// use kernel::alloc::{AllocError, flags::GFP_KERNEL}; +/// use kernel::sync::{new_spinlock, SpinLock}; +/// use kernel::id_pool::IdPool; +/// +/// fn get_id_maybe_realloc(guarded_pool: &SpinLock) -> Result { +/// let mut pool =3D guarded_pool.lock(); +/// loop { +/// match pool.acquire_next_id(0) { +/// Some(index) =3D> return Ok(index), +/// None =3D> { +/// let alloc_request =3D pool.grow_request(); +/// drop(pool); +/// let resizer =3D alloc_request.ok_or(AllocError)?.reall= oc(GFP_KERNEL)?; +/// pool =3D guarded_pool.lock(); +/// pool.grow(resizer) +/// } +/// } +/// } +/// } +/// ``` +pub struct IdPool { + map: BitmapVec, +} + +/// Indicates that an [`IdPool`] should change to a new target size. +pub struct ReallocRequest { + num_ids: usize, +} + +/// Contains a [`BitmapVec`] of a size suitable for reallocating [`IdPool`= ]. +pub struct PoolResizer { + new: BitmapVec, +} + +impl ReallocRequest { + /// Allocates a new backing [`BitmapVec`] for [`IdPool`]. + /// + /// This method only prepares reallocation and does not complete it. + /// Reallocation will complete after passing the [`PoolResizer`] to the + /// [`IdPool::grow`] or [`IdPool::shrink`] operation, which will check + /// that reallocation still makes sense. + pub fn realloc(&self, flags: Flags) -> Result= { + let new =3D BitmapVec::new(self.num_ids, flags)?; + Ok(PoolResizer { new }) + } +} + +impl IdPool { + /// Constructs a new [`IdPool`]. + /// + /// A capacity below [`BITS_PER_LONG`] is adjusted to + /// [`BITS_PER_LONG`]. + /// + /// [`BITS_PER_LONG`]: srctree/include/asm-generic/bitsperlong.h + #[inline] + pub fn new(num_ids: usize, flags: Flags) -> Result { + let num_ids =3D core::cmp::max(num_ids, BITS_PER_LONG); + let map =3D BitmapVec::new(num_ids, flags)?; + Ok(Self { map }) + } + + /// Returns how many IDs this pool can currently have. + #[inline] + pub fn capacity(&self) -> usize { + self.map.len() + } + + /// Returns a [`ReallocRequest`] if the [`IdPool`] can be shrunk, [`No= ne`] otherwise. + /// + /// The capacity of an [`IdPool`] cannot be shrunk below [`BITS_PER_LO= NG`]. + /// + /// [`BITS_PER_LONG`]: srctree/include/asm-generic/bitsperlong.h + /// + /// # Examples + /// + /// ``` + /// use kernel::alloc::{AllocError, flags::GFP_KERNEL}; + /// use kernel::id_pool::{ReallocRequest, IdPool}; + /// + /// let mut pool =3D IdPool::new(1024, GFP_KERNEL)?; + /// let alloc_request =3D pool.shrink_request().ok_or(AllocError)?; + /// let resizer =3D alloc_request.realloc(GFP_KERNEL)?; + /// pool.shrink(resizer); + /// assert_eq!(pool.capacity(), kernel::bindings::BITS_PER_LONG as usi= ze); + /// # Ok::<(), AllocError>(()) + /// ``` + #[inline] + pub fn shrink_request(&self) -> Option { + let cap =3D self.capacity(); + // Shrinking below [`BITS_PER_LONG`] is never possible. + if cap <=3D BITS_PER_LONG { + return None; + } + // Determine if the bitmap can shrink based on the position of + // its last set bit. If the bit is within the first quarter of + // the bitmap then shrinking is possible. In this case, the + // bitmap should shrink to half its current size. + let Some(bit) =3D self.map.last_bit() else { + return Some(ReallocRequest { + num_ids: BITS_PER_LONG, + }); + }; + if bit >=3D (cap / 4) { + return None; + } + let num_ids =3D usize::max(BITS_PER_LONG, cap / 2); + Some(ReallocRequest { num_ids }) + } + + /// Shrinks pool by using a new [`BitmapVec`], if still possible. + #[inline] + pub fn shrink(&mut self, mut resizer: PoolResizer) { + // Between request to shrink that led to allocation of `resizer` a= nd now, + // bits may have changed. + // Verify that shrinking is still possible. In case shrinking to + // the size of `resizer` is no longer possible, do nothing, + // drop `resizer` and move on. + let Some(updated) =3D self.shrink_request() else { + return; + }; + if updated.num_ids > resizer.new.len() { + return; + } + + resizer.new.copy_and_extend(&self.map); + self.map =3D resizer.new; + } + + /// Returns a [`ReallocRequest`] for growing this [`IdPool`], if possi= ble. + /// + /// The capacity of an [`IdPool`] cannot be grown above [`i32::MAX`]. + #[inline] + pub fn grow_request(&self) -> Option { + let num_ids =3D self.capacity() * 2; + if num_ids > i32::MAX.try_into().unwrap() { + return None; + } + Some(ReallocRequest { num_ids }) + } + + /// Grows pool by using a new [`BitmapVec`], if still necessary. + /// + /// The `resizer` arguments has to be obtained by calling [`Self::grow= _request`] + /// on this object and performing a [`ReallocRequest::realloc`]. + #[inline] + pub fn grow(&mut self, mut resizer: PoolResizer) { + // Between request to grow that led to allocation of `resizer` and= now, + // another thread may have already grown the capacity. + // In this case, do nothing, drop `resizer` and move on. + if resizer.new.len() <=3D self.capacity() { + return; + } + + resizer.new.copy_and_extend(&self.map); + self.map =3D resizer.new; + } + + /// Acquires a new ID by finding and setting the next zero bit in the + /// bitmap. + /// + /// Upon success, returns its index. Otherwise, returns [`None`] + /// to indicate that a [`Self::grow_request`] is needed. + #[inline] + pub fn acquire_next_id(&mut self, offset: usize) -> Option { + let next_zero_bit =3D self.map.next_zero_bit(offset); + if let Some(nr) =3D next_zero_bit { + self.map.set_bit(nr); + } + next_zero_bit + } + + /// Releases an ID. + #[inline] + pub fn release_id(&mut self, id: usize) { + self.map.clear_bit(id); + } +} diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 03eb6b34ddd2..b47442a01002 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -90,6 +90,7 @@ pub mod firmware; pub mod fmt; pub mod fs; +pub mod id_pool; pub mod init; pub mod io; pub mod ioctl; --=20 2.51.0.355.g5224444f11-goog