Message ID | 20240904-work-kmem_cache_args-v3-0-05db2179a8c2@kernel.org (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 BCCBCCA0ED3 for <linux-mm@archiver.kernel.org>; Wed, 4 Sep 2024 10:21:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F3306B02EC; Wed, 4 Sep 2024 06:21:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4796B6B02F0; Wed, 4 Sep 2024 06:21:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F2706B02EC; Wed, 4 Sep 2024 06:21:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 09A436B0296 for <linux-mm@kvack.org>; Wed, 4 Sep 2024 06:21:55 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9C4D21C53B1 for <linux-mm@kvack.org>; Wed, 4 Sep 2024 10:21:54 +0000 (UTC) X-FDA: 82526664948.14.31347B3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id C9A5F1C000A for <linux-mm@kvack.org>; Wed, 4 Sep 2024 10:21:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=iwZWd2oK; spf=pass (imf20.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@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=1725445237; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=ttD5rKJN3VUsr6w+rQFSn6vSc+1ICdybHIpccT4RO50=; b=fIVPEtaBorC86rsW0EqFjwYuJ+t1u2x0GbyLGsN+JePFICOFGvq3oCwNWXIH6s+bF8osK6 0uIi5g28BIpS3v//KdGlKK/BOARH4Uvb0F8qsOaiZ0uasqCYTXnHDthsBJVybHnuG+9OF6 0g4kcGLeY8yfeg+YS3EWaXIKErK6Mx8= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=iwZWd2oK; spf=pass (imf20.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725445237; a=rsa-sha256; cv=none; b=y/tZTMbd1SZ0lpGU+UMiXA+lOBMufoH6gebhdKCNc/VfHJXBEbi11AemJJ0LYVwaLlDQbA srl9JEIByXbNv3N2qO3wLaj1kHV6tYFvE4dQHAa6RPnGoMF9Z+OXhy/msaefvvRYs5Y5Eu XGQ9ymFGEj8IVrZKSBrKAu5g3F95f1I= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3EB485C5706; Wed, 4 Sep 2024 10:21:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E095AC4CEC8; Wed, 4 Sep 2024 10:21:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725445311; bh=qpIaXZ9wpnw8HqkV16+tOm664xAQ9ILaft0Wsy1nwYA=; h=From:Subject:Date:To:Cc:From; b=iwZWd2oKEolnEt3tXTv1Dn5n2m5rHaf5jeju8Z8DJElivkZtOJPAQGkRGhZ8OY6Pv SkHv3TaWERBrAO0uNAxUI2jrS6IJFzh6mlYTX0oCBEQp7cxmKFty2uM1eFZ2QZcWi4 SB6urPwuWsqRu5l3qOr8mXNsokVhuHg5RRdvqWcH/zGypWmFHB6OxgKgebbR9+c5pX u+7cSQx5rK0HsDdIps/a411Q1/ngnNMn4wii7gmrnOT7+KD8tdnhPP0kG4kXqIjLFv /SMf8r7ZytrIK77ldRiFjdIw7TtcDvobUdx2YcZdPKDAHuv9fh30wuzl4e1Q2F+whp cmHoLeK4U3COg== From: Christian Brauner <brauner@kernel.org> Subject: [PATCH v3 00/17] slab: add struct kmem_cache_args Date: Wed, 04 Sep 2024 12:21:05 +0200 Message-Id: <20240904-work-kmem_cache_args-v3-0-05db2179a8c2@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAJE02GYC/4XOyw7CIBAF0F9pWEtD6QNx5X8Y01A6tKQvMxjUN P13oStdGJc3mXvurMQBWnDklKwEwVtnlzmE/JAQ3au5A2rbkAlnvGCScfpYcKDDBFOtle6hVtg 5ClJUTAquRVuQUL0hGPvc2cs15EY5oA2qWfcR88alxo4QT3vr7gu+9gd8Fgt/tnxGGeWiZWWjW Znx43kAnGFMF+xIHPP8U8l/KDwoojJSgFRFWbEvZdu2N8aVVMYaAQAA To: Vlastimil Babka <vbabka@suse.cz>, Jens Axboe <axboe@kernel.dk>, Jann Horn <jannh@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Mike Rapoport <rppt@kernel.org> Cc: Kees Cook <kees@kernel.org>, Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Roman Gushchin <roman.gushchin@linux.dev>, Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Christian Brauner <brauner@kernel.org> X-Mailer: b4 0.15-dev-37811 X-Developer-Signature: v=1; a=openpgp-sha256; l=4620; i=brauner@kernel.org; h=from:subject:message-id; bh=qpIaXZ9wpnw8HqkV16+tOm664xAQ9ILaft0Wsy1nwYA=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMaTdMNnJ3HaRT2CXsmvP111VPlJ7X6VsVNB4c7rge/bnm 4cvJVTLd5SyMIhxMciKKbI4tJuEyy3nqdhslKkBM4eVCWQIAxenAEzk0W6GvxJv/PTnZVuoCQRd L1i4e2/YhXk/tV32dB4+Xnzm172S7I2MDEuTznDemXEsOld9/5mJ86/KcTEyFTsd7HBlb97UUDZ fgh0A X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 X-Stat-Signature: 3adpcgxn9pfq369uzh3kj114131rubqo X-Rspam-User: X-Rspamd-Queue-Id: C9A5F1C000A X-Rspamd-Server: rspam02 X-HE-Tag: 1725445312-387346 X-HE-Meta: U2FsdGVkX18bqQHeczQv/ztRxlMoFKQhkJbGVoEXMzzRqobmwYbwcKO+xLyLcdkVMQYVrH+7v62tyhvZp0LJ/F+xk6kfKLET/Wtfy+cwKrEB7/ew77S/teN+m1T11b370doYgVBULVwdmFrAZwTw9xQuSOCcmJ0bGiPnC7Op/oASKyvYEaqAvoQ590MFvFdTd93lVeE9FYxaYYCoIF5vmeHUXWBGwuiJuwGIUQXsa1fNhcbpMZ+i4Ydh8/5NGtQtjCUJiJZ0zWL8dG8XZF8DGztZ8q7bdNIe6ZwMtgCj1WbbdAx0U6uLsgQAv4/7boyJesLFoXgcmK4aBc5jaJTeZwLpqoZQZrSLbX2dhIunbooyW6MwAbclSxEtrnoRnWjTqE5ck5AUu2Q7afo7edoLU743pu453kjMC6uMMnl3SsSpwMItGiS959MUMOQ+OLoby46Ccy8tzJffW8q2zTfvdNxT/iHHy5I5CzEKnkuAyuYU4KfpE0bzHtohg60z8RFu0pBWusD/+SJ/qrehuZhg+z1ix+eoB1JJ+GHyqvnyfuFLJ6uoVZMd+0Q3039xWUVMH7bwDd3xOsv20X5Vb0ZiQJ8333vcWR14nPouL054n7tPVAckErgqAk1LyVusF03RUweeFYtJjfrJ3xEWRkeDqT/pr+dcRnpKezRq2RZ8Angyzeloe79KkhGAcDTU/Q4JYCUO+xAZnJbhwF8oVz9QFEYFciwC5TFn0/Qp5L8MZ80WKrf2CPKHDGaEn7rbSEzq61A6fAtysocHR1Zb0UAFJv3MWfYpcuOGoTGdpypkBc53v2kEhMWg9Aya03YovvlpjJqoS5BsXd2vbhwmhNu7NP+irQh8mvLkoW4YeFU7SR5y5/FU4HEiOvZWStGjm4JG0E3luAq5cU0DFRhZMfg44Ys83mstBKtQCJ5mqaMBf9cr3cFWeikfkpsJLSbeUeJI+/dGGkm4x4rCc1fJzwH J9Z/xDEz i3oo4igCHsjWU5q0PJ1f9Np4CxT1QV9UBCuPQC9YgLamRiJNro9kWE7SdZ/fYEDPQzxI0NZFHUU0dyMnT/EtJZB63vftixczV+7ToPeZdrndp/gBR2QgbqUSlkRPnwywS0hXpAt3RAN9RLUrJEC6jhBCQKS5Rccn0u+/pe3fIvSukD08iPEnLYItrWEkSY/OZuj2z7VbToklksU72SdDVZjgcSEzqzs8kdIGhTYsv5H6x4jjcD/9+lrOY0mG7dVHUZQmLGqMUR+QFIXmbCfPgpAR+A5oweD3mrnPucSyxd5WOinvGACUwgtmXte0q4ILLDFLqZUngYcvuD8xLtbPq6bd86j5odp+xJru+hLvMhYHjfHVi13dbErR1SFn4f77vDQ2bMsxQaWqD3o+BJXdDh73xUEm8L8VDk3BjU6KVVJ/v1BcBVBkxUE244d6Mm+NE3HKUraa/L+t4ajH4dhi/KOckuZNKg/0jPvEpsqROnwY5NRXDw6K27oLJeo0LjhkYNc9qgFhzwVOp5ctVo/yV1rrPhkhup18k7aSDqM+/DaejBt0YW1imoz0eR4gFzHXhS5EI8sxWqe8EiR5kvjsYfZn54k3wLNNkmQocqETc3w9hKg4= 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
slab: add struct kmem_cache_args
|
expand
|
Hey, No meaningful changes in v3. This is mostly to make it easy for Vlastimil to pull. --- As discussed last week the various kmem_cache_*() functions should be replaced by a unified function that is based around a struct, with only the basic parameters passed separately. Vlastimil already said that he would like to keep core parameters out of the struct: name, object size, and flags. I personally don't care much and would not object to moving everything into the struct but that's a matter of taste and I yield that decision power to the maintainer. In the first version I pointed out that the choice of name is somewhat forced as kmem_cache_create() is taken and the only way to reuse it would be to replace all users in one go. Or to do a global sed/kmem_cache_create()/kmem_cache_create2()/g. And then introduce kmem_cache_setup(). That doesn't strike me as a viable option. If we really cared about the *_create() suffix then an alternative might be to do a sed/kmem_cache_setup()/kmem_cache_create()/g after every user in the kernel is ported. I honestly don't think that's worth it but I wanted to at least mention it to highlight the fact that this might lead to a naming compromise. However, I came up with an alternative using _Generic() to create a compatibility layer that will call the correct variant of kmem_cache_create() depending on whether struct kmem_cache_args is passed or not. That compatibility layer can stay in place until we updated all calls to be based on struct kmem_cache_args. From a cursory grep (and not excluding Documentation mentions) we will have to replace 44 kmem_cache_create_usercopy() calls and about 463 kmem_cache_create() calls which makes for a bit above 500 calls to port to kmem_cache_setup(). That'll probably be good work for people getting into kernel development. To: Vlastimil Babka <vbabka@suse.cz> To: Jens Axboe <axboe@kernel.dk> To: Jann Horn <jannh@google.com> To: Linus Torvalds <torvalds@linux-foundation.org> To: Mike Rapoport <rppt@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org> --- Changes in v3: - Reworded some commit messages. - Picked up various RvBs. - Added two patches to make two functions static inline. - Link to v2: https://lore.kernel.org/r/20240903-work-kmem_cache_args-v2-0-76f97e9a4560@kernel.org Changes in v2: - Remove kmem_cache_setup() and add a compatibility layer built around _Generic() so that we can keep the kmem_cache_create() name and type switch on the third argument to either call __kmem_cache_create() or __kmem_cache_create_args(). - Link to v1: https://lore.kernel.org/r/20240902-work-kmem_cache_args-v1-0-27d05bc05128@kernel.org --- Christian Brauner (17): slab: s/__kmem_cache_create/do_kmem_cache_create/g slab: add struct kmem_cache_args slab: port kmem_cache_create() to struct kmem_cache_args slab: port kmem_cache_create_rcu() to struct kmem_cache_args slab: port kmem_cache_create_usercopy() to struct kmem_cache_args slab: pass struct kmem_cache_args to create_cache() slab: pull kmem_cache_open() into do_kmem_cache_create() slab: pass struct kmem_cache_args to do_kmem_cache_create() slab: remove rcu_freeptr_offset from struct kmem_cache slab: port KMEM_CACHE() to struct kmem_cache_args slab: port KMEM_CACHE_USERCOPY() to struct kmem_cache_args slab: create kmem_cache_create() compatibility layer file: port to struct kmem_cache_args slab: remove kmem_cache_create_rcu() slab: make kmem_cache_create_usercopy() static inline slab: make __kmem_cache_create() static inline io_uring: port to struct kmem_cache_args fs/file_table.c | 11 ++- include/linux/slab.h | 116 ++++++++++++++++++++++++------ io_uring/io_uring.c | 14 ++-- mm/slab.h | 6 +- mm/slab_common.c | 197 +++++++++++---------------------------------------- mm/slub.c | 162 +++++++++++++++++++++--------------------- 6 files changed, 236 insertions(+), 270 deletions(-) --- base-commit: 6e016babce7c845ed015da25c7a097fa3482d95a change-id: 20240902-work-kmem_cache_args-e9760972c7d4