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 55E88347BC9 for ; Thu, 19 Mar 2026 20:12:42 +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=1773951162; cv=none; b=J24uvZTrIGv35y50nQDXVU1kCPPQNmxOWwZrKmXghBiXPFlqQf7/mizP42MGQ3Qm6f1VHBbSkhUawFYdxZF2shP+Ibc9MRfOEJkbMsH8qzkv4/ij2789VTCfIL1NZY4qtz+JqKwe4uT+6cwRq09Ru1VKYbu57QKyv4rCJ27tbTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773951162; c=relaxed/simple; bh=RUNNQNOc9YnBPWpX2JqssxtPvNCwOlMdV1VPxAuBUTY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NpKYW8Eus8JrQffuDb2x5STgUq6++stQ8ML+ppgwErdCytiZsGR9AXlw17X9G+QhbwDoNFhfm7nveffbiTuKD9V7UCq/xXKqydqlEdcucHXyKaGZLiF+jMQeihu7jimdytGu5qa/7NCEOaq3v0hej0ehLXwj86iMat/rEcKReww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Po9XJlj9; 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="Po9XJlj9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED3F9C19424; Thu, 19 Mar 2026 20:12:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773951162; bh=RUNNQNOc9YnBPWpX2JqssxtPvNCwOlMdV1VPxAuBUTY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Po9XJlj9kP/fGKJurAFjhBTmIYSFbwkerCr9J8SssGXIxLX+6yOcyqiLTkWFRXvne vemaGMU4/41Jz+0rdM8kGaItZPLZv3MoaYXIcTGHHqmwrhl2yOsE5Q8e96aOcEcH5C vMpmBPR/hxf8owgzbluLEp1YHlOwgWdCy1mvWzQxvtvNj5Kn1SGsPDQt1IRwC1GubX sshATMUFFgJ0M728l5b677zuJ6vSgfCotOOjUyXKKr2ti1R12JSkWV6CxbHHlaCeZ+ X9q8FBcbk+mf/4qEYK0tj/T993Us51Po5SCK2ki6qBVR+2cjrOjvjUpckYUd3AC8xt qIMG+hSPddUKw== Date: Thu, 19 Mar 2026 13:12:41 -0700 From: Kees Cook To: Alejandro Colomar Cc: LKML , corbet@lwn.net, serge@hallyn.com, Martin Uecker , linux-mm@kvack.org Subject: Re: kalloc_objs() may not be as safe as it seems Message-ID: <202603191308.ED08BC65B2@keescook> References: <202603171402.B2BD1B1@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 In-Reply-To: On Wed, Mar 18, 2026 at 05:33:35PM +0100, Alejandro Colomar wrote: > How about using a struct? That's the idiomatic way of having > incompatible types. Since these are used through macros, it wouldn't > change anything to users. > > The macro definitions would have to change. For example: > > -#define GFP_NOFS (__GFP_RECLAIM | __GFP_IO) > +#define GFP_NOFS ((void)0, (struct gfp){__GFP_RECLAIM | __GFP_IO}) > > We don't need any new language features. This is backwards compatible > up to C99. And it might end up being simpler than __strict typedef. Yeah, if we can convince the mm folks. (Added to CC.) It'd require some kind of macro to build bits in the many places where values are or'ed together. > [...] > After sleeping, I had some idea. > > We could have coccinelle add typeof() around the first parameter when > it's an expression (not a type). Then, we could enforce that the first > parameter is a type name. > > That is: > > p = kmalloc_objs(int, 42); // ok > -q = kmalloc_objs(*p, 7); > +q = kmalloc_objs(typeof(*p), 7); > > I expect this would be doable with coccinelle. > > Then, new code would be required to pass a type name. And people could > slowly replace the existing typeof() calls at their own pace. > > What do you think? Well, it'd serve as a visual indicator, but it's redundant (typeof() is already used internally). Given it would only be a potential for confusion on integral types, I'm less convinced this needs solving. For completeness, though, this Coccinelle script: // Options: --include-headers-for-types --all-includes --include-headers --keep-comments virtual patch @type_not_var depends on patch@ type TYPE; TYPE *VAR; identifier ALLOC = {kmalloc_obj,kzalloc_obj,kmalloc_objs,kzalloc_objs,kmalloc_flex,kzalloc_flex}; @@ VAR = ALLOC( - *VAR + TYPE , ...) Produces: 6007 files changed, 12430 insertions(+), 11767 deletions(-) Which is a lot of churn... -- Kees Cook