From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 973C7CD3431 for ; Wed, 4 Sep 2024 08:43:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20E846B030F; Wed, 4 Sep 2024 04:43:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 193E36B0316; Wed, 4 Sep 2024 04:43:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8C716B0315; Wed, 4 Sep 2024 04:42:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C56736B030F for ; Wed, 4 Sep 2024 04:42:59 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8104E160F36 for ; Wed, 4 Sep 2024 08:42:59 +0000 (UTC) X-FDA: 82526415678.09.F69DB22 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id C3BFD1C0026 for ; Wed, 4 Sep 2024 08:42:56 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="GJ/rg0pj"; spf=pass (imf21.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=1725439282; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gfbtedWA2H2uG3nvyfFyCaR99wNtlyPccrF3rM2zK5c=; b=pGMo/sHICQwzWZT8AW4eC4/l7XYffz+5WBSWquwo263mMgvaHBNS5ttIi5DBmr/mMVP8ha 3cm/n6UoE4N1svvUpQsDlYcIVlevydn2PEzMwpswHbcSPk/owxWUtIvyXZu/H+xPGabMQG hUJAqoAjiJMeIxdXofqu0QLDh8JJYAE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725439282; a=rsa-sha256; cv=none; b=rxKo8chqZKHi0VzXSgkC586F2IQJRvjv4yzroNa5cHpqO2Gy/OJMXt/EArNfSNVa/HLOME 1XHncgsAZxyPzRnU/ZeDl9XEmqVSyNg2zgLB2SEmTosquC//j4uXrqSX4nFTRtBZotAFbO 3x3QliKX+z0qfrgGXMQDYTd2gLw/UMc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="GJ/rg0pj"; spf=pass (imf21.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3D4765C548A; Wed, 4 Sep 2024 08:42:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8793C4CEC2; Wed, 4 Sep 2024 08:42:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725439375; bh=xKZBluvkbAKSstSoxzBb+8HhTTN/uLkHKCKvOKCgba8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GJ/rg0pjGgFe19lnu75lwEA2U4JbVy0HAWzZOeAJSmMC2ijfc5sbhWt0CKKrSqTD1 uz7Rs+ozij0E5vScyRGOZ0S2MqaIGfJsdrPt2ft8OrjdLR+fK4OsPmu+OfkTTpDNr9 X2Rku+hUmVuJdvGijY1B3I32h5IvTrfijYagr65PSrJkwGXN25YjEraTEA38gedgSC UCQEWYFceC32jXYKWMC+Tmb+NJ0caZHHeRI/2rnsOk4Axj76M9ZaiwspDaIsMtmSyw J+4P57dJMd+Y9ZMRrhl2vJqTPBY1qo/Ct5EX5KkTCXpejNHeCInDvZD5vExuAkqSLp ruycsBUeUvKfA== Date: Wed, 4 Sep 2024 10:42:50 +0200 From: Christian Brauner To: Vlastimil Babka Cc: Jens Axboe , Jann Horn , Linus Torvalds , Mike Rapoport , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 00/15] slab: add struct kmem_cache_args Message-ID: <20240904-stauraum-kennst-5769fa810706@brauner> References: <20240903-work-kmem_cache_args-v2-0-76f97e9a4560@kernel.org> <8d8da7d3-5a8f-4c79-84d2-90535324cdcd@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8d8da7d3-5a8f-4c79-84d2-90535324cdcd@suse.cz> X-Rspamd-Queue-Id: C3BFD1C0026 X-Stat-Signature: 1ek4aacf3ez3g8mkrpza8ib4uzoap8om X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725439376-869537 X-HE-Meta: U2FsdGVkX1+Pp+Nmdv8OMm+iY+2w/CrFWezRuqp//4hRqPeaTG55/NUFzOmItgsJIoKKiGRU1nANXdKiNxcvSUbMSh8FcUdFw7OcD3e8mzFhE5QObEepSmE67wgdvTv+LcSQsW7t+AJz0EYz19yDRqb56nIMoOVoGs/Dsvd4X7E2SKN+JLotZnrEOSeD8FUPmX5FjEDK1RsuTDelJRXzXRutjfsQyw7B0Bkt2S0yhvYK4rYWMwguoa5sHV7ua7ghoHm+QC7ZAO4Vr/N0Gwrr7ySmmf/2wm9ijQyXNNxVG4wsbBiUPXoXHrzgPoq8sP7wc9kPGEx3N8mhz6KgpbA++2bgamhV8P23iZznfffc5HDEXZeA4wP0QBeGAckIUlvwVEQIsGySqoE9LltBYQYvewZUn1LTv24HK5Y0+F76bHNRQJd4Uzr49/vPY0k5J2i0KVeiQSg3qd/8C/HRp8VnODWazTKWyOIhq+5mXuqzwIBf3rHSgXTYx3qRi32owXZMQq1Vl9+WwxQqJlbX2RsmfF9o7NftJbNlEry0c9R166wGWIDo0Y5TVb9uHq4/MyO64ml7+SicRnWATrY0DZvkXYbPNXFzyDMG3kG4zWXYLPL53adZogFQ0wZOEoem434iFr4xGDotGWn/AiZkiR77c2wRdukcUWs1gcF+v7nOzorSD0Vbzy2wrF4JCIUDICiVLqP5tXBbrb23NuEGFS90Ivl3UavMbRmzN+oLKKztpZ1pnhvtAPiix2UhqBeMPlOm9pGCezQSCe3KqqkDquihGBEQcrn0uRtIH5x6A3HmneJ9MneD7Kw/YVlKNBF7QAJgOaf6VmV8xBOUgPagvI7etiWVMfm0LdDDMz+9XwUZve3rNEzZvZzX2hmp4UdifYtT+pNbAh1b5xeRptzYqHQcNlooNa7dX6KGKq4yNIoZUfPcJsCrKfi7hcMYYhEvvFQYyPTkItAwkrMZX0kz/Ob RFDpYJbZ IsQc8teV3hARzaHDi5eQvxK2jJKL0IXqQEyXl9apbylMky8/r6SqwO4BxeBTDiGSwUbr/5ifx7YXgOAKW8T/dc+Tw5ZFR0txz+0G8nkJmatN8tjCxmRU8L9EenjwWuoXlEHp1jW0HGH/Hh72tGdvFz5GGNPE+2kauTmuShioNemcOql+1+KzcG00oiYIs0E46fLMP9px85WzHGo/325c19FYdCMhj2XUJugpWZoNktHHFoN3yhu/uZYBwxlTIdRBk/TenvRzLhdM1u6rI44Pp6jgPqp8MRYTs1V8JHW0HgEOplhJ1S96swAgnZf1DTwXpfqcAsX/6m2GkS+QyVB3fOKXYaKOmwnZwAqCEUB2JprEnEcY5/hVRSX/NTw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Sep 04, 2024 at 10:25:32AM GMT, Vlastimil Babka wrote: > On 9/3/24 16:20, Christian Brauner wrote: > > Hey, > > > > 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. > > > > Signed-off-by: Christian Brauner > > Besides the nits I replied to individual patches, LGTM and thanks for doing > the work. You could add to all: > > Reviewed-by: Vlastimil Babka > > Too bad it's quite late for 6.12, right? It would have to be vfs tree anyway > for that due to the kmem_cache_create_rcu() prerequisities. Otherwise I can Imho, we can do it and Linus can always just tell us to go away and wait for v6.13. But if you prefer to wait that's fine for me too. And I don't even need to take it all through the vfs tree. I mean, I'm happy to do it but the vfs.file branch in it's current form is stable. So you could just git pull -S --no-ff git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs vfs.file and note in the merge message that you're bringing in the branch as prerequisites for the rework and then pull this series in. My pull requests will go out latest on Friday before the final release. If Linus merges it you can just send yours after. > handle it in the slab tree after the merge window, for 6.13. > > Also for any more postings please Cc the SLAB ALLOCATOR section, only a > small subset of that is completely MIA :) Sure.