From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C57A72DCC08 for ; Mon, 9 Feb 2026 19:23:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770664980; cv=none; b=Jg/uMTd+J1XCtkli0jWS3o91SXupcjYGgCUUoMUhYcTdtwxE1NmKHPURpLW9x2PfH2KfWiHdRLSnHfUbO1eJKwegLELcx4njRp4sve5SNTm/053S6PhhR0gBClbyeSRwThDilf+KGpOti5N8M3FsLuFswCHj4jn2Lx1zhBmyzr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770664980; c=relaxed/simple; bh=x+w4vcNUGi96Yfu/kHRiLjQqc4hmrwi6fQkJYLD9ddI=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=KyOVjaJSyMNAGkXWfdax1yjqWByR7KbwHDAyW6ky3k+IiEuenJHyLd1Q0PHGVPURh2/2IDxJFU3ZZF7luRrl0zido4P8+9MXlxFXrkORxtoiax4t6wGOKXz/fNa7INShN+HgNvMYIP4F5RrzOB1oAC5Ty1vxX7OSyraJr11gcJc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XiBgqW9E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XiBgqW9E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F976C116C6; Mon, 9 Feb 2026 19:23:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770664980; bh=x+w4vcNUGi96Yfu/kHRiLjQqc4hmrwi6fQkJYLD9ddI=; h=Date:From:To:Cc:Subject:From; b=XiBgqW9Eakq955vCSVTj967UR9d26QqRRJvzxHXZ6+Bkura7oD7eTgff7qIuNH54j fFkTp/kgJN01pcZtBrk/89L9jyK5uNkDoYfL3va0YJVa3J5TVo6JNgYKnPNlGaeUB0 y0B057hkFo8mgt272hae81S6//gCwzUJTf8wdJO/ApDPm9WP9Sing2OQi7WXV3dAYe INESDWBzsGDhOAyj17quon7f/7Lz7gl2woRH+xHz6ciQTjXxB1vxf5bwZLn9XgufQ6 0djlos6ie7v9+ZJeKVlW58xUAX6Nh3prkmU+o+YD1smTqRxEE3slD9D/YQDcHFHnvC uvXdOYXw40Fyw== Date: Mon, 9 Feb 2026 11:22:59 -0800 From: Kees Cook To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, Kees Cook , Vlastimil Babka Subject: [GIT PULL] kmalloc_obj branch for v7.0-rc1 Message-ID: <202602091050.5089A54A@keescook> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Linus, Please pull the kmalloc_obj branch for v7.0-rc1. Vlastimil asked me to carry this tree as a distinct branch, so here it is. Introduces the kmalloc_obj* family of APIs for switching to type-based kmalloc allocations, away from purely size-based allocations. Discussed on lkml, with you, and at Linux Plumbers. It's been in -next for the entire dev cycle. Before you cut -rc1, I'd like to send you the treewide change (generated from the Coccinelle script in this PR), which mechanically converts almost 20k callsites from kmalloc* to kmalloc_obj*: 8007 files changed, 19980 insertions(+), 20838 deletions(-) This change needed fixes for mismatched types (since now the return type from allocations is a pointer to the requested type, not "void *"), and I've been fixing these over the last 4 releases. For those, see: $ git log --author Kees --grep "preparation for making the kmalloc" These fixes have mostly been trivial mismatches with const qualifiers or accidentally identical sizes (e.g. same object size: "struct kvec *" vs "struct iovec *", or differing pointer pointers: "struct vkms_plane_state **" vs "struct drm_plane **"), but I did catch one case of too-small allocation (the fix is in the works). While working through these fixes it became clear the integral type allocations needed to be excluded from the mechanical treewide change since many of those needed case-by-case examination for type correctness. Much of the Coccinelle script, therefore, is excluding those. I've had the treewide change getting scanned by 0-day for the entire dev cycle, and a few stragglers have popped up (recently introduced type mismatches). I've sent patches for these already, but if they don't get picked up for -rc1, I'll add them to my treewide change branch before I send you that PR. I've also been doing my own allmodconfig builds across architectures to see if I can catch anything 0-day hasn't found. Note that the Coccinelle script commit has a commit date from today since I added wchar_t to the exclusion list today after finding an instance of that in s390 over the weekend. If you'd rather handle the treewide change differently, please let me know what you'd like to see! :) Thanks! -Kees The following changes since commit 9448598b22c50c8a5bb77a9103e2d49f134c9578: Linux 6.19-rc2 (2025-12-21 15:52:04 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/kmalloc_obj-v7.0-rc1 for you to fetch changes up to bdc5071d7f7bb82589737741e9bf19820ceb7a6a: coccinelle: Add kmalloc_objs conversion script (2026-02-09 10:48:20 -0800) ---------------------------------------------------------------- kmalloc_obj branch for v7.0-rc1 - Introduce kmalloc_obj*() family of type-based allocator APIs - checkpatch: Suggest kmalloc_obj family for sizeof allocations - coccinelle: Add kmalloc_objs conversion script ---------------------------------------------------------------- Kees Cook (5): slab: Introduce kmalloc_obj() and family checkpatch: Suggest kmalloc_obj family for sizeof allocations compiler_types: Introduce __flex_counter() and family slab: Introduce kmalloc_flex() and family coccinelle: Add kmalloc_objs conversion script scripts/checkpatch.pl | 39 ++++++++-- scripts/coccinelle/api/kmalloc_objs.cocci | 124 ++++++++++++++++++++++++++++++ Documentation/process/deprecated.rst | 31 ++++++++ include/linux/compiler_types.h | 31 ++++++++ include/linux/overflow.h | 42 ++++++++++ include/linux/slab.h | 106 +++++++++++++++++++++++++ 6 files changed, 367 insertions(+), 6 deletions(-) create mode 100644 scripts/coccinelle/api/kmalloc_objs.cocci -- Kees Cook