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 7E599C3DA7F for ; Mon, 12 Aug 2024 18:22:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFAE06B0098; Mon, 12 Aug 2024 14:22:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAA906B009F; Mon, 12 Aug 2024 14:22:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D72926B00A2; Mon, 12 Aug 2024 14:22:04 -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 B95296B0098 for ; Mon, 12 Aug 2024 14:22:04 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 36E0F8031C for ; Mon, 12 Aug 2024 18:22:04 +0000 (UTC) X-FDA: 82444412568.27.4589C5C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id 2E5FE16002B for ; Mon, 12 Aug 2024 18:22:01 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YBwr2DWt; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723486887; 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=/oufdRxM7z/2DO1R9Hx/h8OW5SxZbFm/dWBOKiXAsRQ=; b=l7Y3YqrysyR0cjWIdcp1OaW8QizUUJVZcjqkUeo1N2lvQ7sGq/DGix9mdmiFHVo+Kpz4RD rxcWmyjXfcYWUg5LC7WnzNyO542ZP82MVMz2VLUe3+PCL4a6mwsWH6IE/Ugzb+HZsxZXcG q7SBEsNwrTHe/ej4ur7yoITIp2nGyOo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YBwr2DWt; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723486887; a=rsa-sha256; cv=none; b=xcpviQpGnhiAlaWUIdfOtflN1yuCEJWRdEJ3s/AQdXyh7+0ddSyydokZ1XWCjHy16/0rlZ nQfyaEQ3kuoIjOZc8OpXpdHctRtYzecAnbp1n2dX2cXV3afd4zp88dXaJYdxMIW/eP24MM 6ORAfTMayE/uIPwHq21YwXOOU2foE4s= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2398F61464; Mon, 12 Aug 2024 18:22:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF840C32782; Mon, 12 Aug 2024 18:22:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723486920; bh=ws3lgZqtdR8fdkI1wDuo6WPxpiZC7n8mPZcO8DUfngc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YBwr2DWtldK2qiuYyAMPXwj2lruEt4qkTNXNxYEaPxOC8WeH6WaUS8SKea60G/1qA ugiqvIaGs59MbYKxNCszLu1mqEWfMbpG284xEa2+XVWJ3NhcEPCB+BdUiQ0I1EXmZU sKwTbZthZgJqXWABdNbJFDgxL/LpKmcurPrYpMq/l0AaxTq38E/kJURnxf8oGAOVHW lPdnST8bcyB8w2lFDbnU3XG3kHk7kaJBYSwlnRfUqL5ZBARxOxdA0afikNgMbdYrTi 5CD7UT6AhXylgK49dyzG2m7bqsmdHNy4TxzhLyT56WWLASHeeF52pto9/owdtqyQwx OQLLC6DGcTPQw== Date: Mon, 12 Aug 2024 11:22:00 -0700 From: Kees Cook To: Vlastimil Babka Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Gustavo A . R . Silva" , Bill Wendling , Justin Stitt , Jann Horn , Przemek Kitszel , Marco Elver , linux-mm@kvack.org, Nathan Chancellor , Nick Desaulniers , linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Subject: Re: [PATCH] slab: Introduce kmalloc_obj() and family Message-ID: <202408121113.D638922E4@keescook> References: <20240807235433.work.317-kees@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2E5FE16002B X-Stat-Signature: gciz5ee16wp6qk3x86oc7a4pj9zqeb3f X-HE-Tag: 1723486921-30462 X-HE-Meta: U2FsdGVkX19z/6oJopf0KsgZek8SY2w+9/0G4jX5UpAPfXpEkLpvkNvfTlRNuWM7I++tnjK1l/EnZ5QEEfsxY54dK4UzCtBitJ/26XodZfmpOnLRVWNd4cCGUbvUE1nNK6nEtv/w6MjsyepXkX2oMDv+Iy/kJB73cnArqiwFo3FrlV+7A3x8yVHOsbmWKtCjN9KG5fQJtwsMYNahR0w+tbR/fpt2/3jkcDfF+OwmqrjqPUu8w4rXmaU51RH/fSi0A21/MXLD19P8ejgLWTzurohAQgjYhtCHoc0us4chSQGiGcnvu8KciVm7+6ewrkYPYFAwK8+B7v7JOpEOdEKk4ZZiGAlSf+g/vRv8gglzWOSKpZutDWzTj6sLclzWWf2J0qLXSFVOgg3QMxpq64XnaQ7PQ6QI4Rv7jGLoSvhLu9Z8u+o++Y2n4vlVELg+GIeqE41021W95XrTmP8aIAKgQqMaMpivw/9H/d+XCYPrYtJ0SA4dQVHTgMMjZF5K1uVA/Dv/5p7gkODUNOIBRJsc7XDEMZE91aPotQE+lfi04OrEzgsP3Gnkn//0MFx0J5KxMjEMVt8jRhD5NvoYJg7Im8IaNyJQaGelfnghv1XsOzalTya/6Av7HVWLgjGHwvOwQ6tKMHyNLnNT19udFU2z1EmTIpI8cY/vIVFqFfnvjTM9Kp7xAZaecaUhioq5RVtQpll6UZRQnZPEzQvJbiAfm/JfHB358TWgaK6DcKFEW2ukbCHG1zKicE02Z6Oi6DnYUeCNM9xAWUGjz/j5TykJNc4NxVKe20gMZ1bzxQw+3odN0gE8vmRBvx2v8fCRkAwxZDmLZUwocadwa2DIAk2dczUX+HUJAn2AlJQ8ZY/Crw0mVqciuO9zYLddPQ6Ot1ymzWTXk0tcFt321VVIa3cPR8bllwByudflv33Pp79NbK+o+28ZTca+aVCHtmC5nHYhdkPQa7CwZ9Oc+oGbcct G6puhCXK I0+8DTVU3VtHwy30FNDSUJZmfOteDAX39ws98BzlbePRUwQPhoh5MsyCuBGQDiMs2lS6ukkonzWl1di7jQ3wVItPvoVZaIoe0WtL33o3cXw9WCJ3xoQ2Dh91i3WQU2bXdAOHZty6XBMabnMJOdBWnmA+8nHPShMsHRmMIaQiV6nuG47VZkxKpGoysZFGWHilYwhZZrPza9QJsYn7JZpbeBKpsFgoruxCP7eUb5RbeoGor12K/iz/hCPXKFXHIADwRofCj2u+S2JQjUzlKATuScYEQkyPm9EcoZ+fZmeN+ElFrJieyOhB0uRJV7Q0r6sOwp4URvHWoIrEPFCFDupIjkxzMWw== 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 Fri, Aug 09, 2024 at 10:59:52AM +0200, Vlastimil Babka wrote: > On 8/8/24 01:54, Kees Cook wrote: > > Introduce type-aware kmalloc-family helpers to replace the common > > idioms for single, array, and flexible object allocations: > > > > ptr = kmalloc(sizeof(*ptr), gfp); > > ptr = kcalloc(count, sizeof(*ptr), gfp); > > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > > ptr = kcalloc(count, sizeof(*ptr), gfp); > > ptr = kmalloc(struct_size(ptr, flex_member, count), gfp); > > > > These become, respectively: > > > > kmalloc_obj(p, gfp); > > kzalloc_obj(p, count, gfp); > > kmalloc_obj(p, count, gfp); > > kzalloc_obj(p, count, gfp); > > kmalloc_obj(p, flex_member, count, gfp); > > So I'm not a huge fan in hiding the assignment, but I understand there's > value in having guaranteed the target of the assignment is really the same > thing as the one used for sizeof() etc. > > But returning size seems awkward, it would be IMHO less confusing if it > still returned the object pointer, that could be then also assigned > elsewhere if needed, tested for NULL and ZERO_SIZE_PTR (now it's both 0?). Ah, I made this changed based on requests in earlier threads. But yes, the ambiguity with ZERO_SIZE_PTR does make me uncomfortable too. I think I can make the size an optional argument when splitting the functions as you request below... > I'm also not sure that having it all called kmalloc_obj() with 3 variants of > how many parameters it takes is such a win? e.g. kmalloc_obj(), > kcalloc_obj() and kcalloc_obj_flex() would be more obvious? I liked it because it's always doing the same thing: allocating a structure. But yes, I do see that it's a bit weird. Since "kcalloc" means "zero it also", how about the naming just uses pluralization instead? kmalloc_obj(p, gfp); kmalloc_objs(p, count, gfp); kmalloc_flex(p, flex_member, count, gfp); Does that looks okay? > > These each return the size of the allocation, so that other common > > idioms can be converted easily as well. For example: > > > > info->size = struct_size(ptr, flex_member, count); > > ptr = kmalloc(info->size, gfp); > > > > becomes: > > > > info->size = kmalloc_obj(ptr, flex_member, count, gfp); > > How about instead taking an &info->size parameter that assigns size to it, > so the ptr can be still returned but we also can record the size? If we wanted size output, we could add an optional final argument: kmalloc_obj(p, gfp, &size); kmalloc_objs(p, count, gfp, &size); kmalloc_flex(p, flex_member, count, gfp, &size); And as far as solving the concern of "hiding the assignment", what about trying to "show" that "p" is being assigned by requiring that it also use "&"? For example: kmalloc_obj(&p, gfp); kmalloc_objs(&p, count, gfp); kmalloc_flex(&p, flex_member, count, gfp); > Also the last time David asked for documentation, you say you would try, but > there's nothing new here? Dunno if the kerneldocs are feasible but there's > at least Documentation/core-api/memory-allocation.rst ... Whoops, yes. I totally missed adding those. I will add that once I have some direction on the above design ideas. Thanks for looking at this! -Kees -- Kees Cook