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 57BF6288A2 for ; Sun, 22 Feb 2026 01:08:49 +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=1771722529; cv=none; b=q4bQ2guk1JJ5BdwX1KGLfmH+u1nSqu0+fPkjirnaqaw+IHJaN3dNy5dEdYaARsiIte+qS2MevHZN9/BgjDE34iCBPx2YRnxse0J844Eo/Ka+kT04HvsScMOY5ZOtB8qIZAGteYEbbzLaO3tIBQLESJNh3QjZg/wfY2O+7Ld0hUk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771722529; c=relaxed/simple; bh=fZusbj3ZwGYdWfr8cepaRjt09uPQLgvujbdbyKJ0nco=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mUpaZF3huKvTGbpxI+2MnqkgiVbu4w0znpsbo7+m+INGB/QACW3f/IBi6snRV37PuXVZDUnRICTC0Jmi2Iwk4eQ5E5n8nUlCbEtOQ31Hva0LKhB/rNZOm61v1MaklgbSCLLD0ZJmkX6QmcHTw26nRlM5QtUiYC8x4lB5WRk7BZ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHgmLRO3; 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="HHgmLRO3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9303C4CEF7; Sun, 22 Feb 2026 01:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771722528; bh=fZusbj3ZwGYdWfr8cepaRjt09uPQLgvujbdbyKJ0nco=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HHgmLRO3/jEttnxtKq+taXbZMBfSxGbJg7k1ASTMB7DQdnsifcbaaJ9NzQYWaev7W jq1XHD8naXIVFi8L5qHvnTRW1kCDSCzTBtUF24pzJKHFqkZK7B1Cs51cUeMlguFDHM XpC7liCvzA2m7JHaC63X4YdIvDjquojhaZzlmGSz/dZ8Np63sbK/bPusXOWzduXfU1 Y76vI7HrLUh9u+gYDQ9hGXrOI3C2I4e6Iqa6TDfAnD0Dw9w3oRWtI6DPdFuFPLIck8 YT/kiI4aJ4sAGCVMHC1Fg7j2wErQJX7+UBOaiSDiWQGFbQ7jYWz68GRqiHT1H5OV0C iU6y6JybBSSsg== Date: Sat, 21 Feb 2026 17:08:47 -0800 From: Eric Biggers To: Kees Cook Cc: Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] kmalloc_obj treewide refactor for v7.0-rc1 Message-ID: <20260222010847.GA2135@quark> References: <202602210108.0EABDA1CDD@keescook> <202602211442.1BE76271@keescook> <202602211508.57394C771A@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: <202602211508.57394C771A@keescook> On Sat, Feb 21, 2026 at 03:19:56PM -0800, Kees Cook wrote: > On Sat, Feb 21, 2026 at 03:01:15PM -0800, Linus Torvalds wrote: > > But I think I found the real bug: > > > > #define overflows_flex_counter_type(TYPE, FAM, COUNT) \ > > (!overflows_type(COUNT, typeof_flex_counter(((TYPE *)NULL)->FAM))) > > > > WTF is up with that '!' there? That seems entirely bogus. So now > > overflows_flex_counter_type() will return true in it *doesn't* > > overflow the type. > > > > So I think clang was not actually the problem. That whole code looks buggy. > > I would agree. This code mutated a few times but the logic and > docs for this function are in sync ("Returns: true if @COUNT can be > represented") but I renamed it somewhere along the way in a confusing > way and then got the above quoted macro's usage wrong. > > > But that actually makes me *less* happy, because it means that this > > whole patch must have been ENTIRELY untested in any shape or form. > > > > If I read this right, none of this should have successfully booted > > anywhere if you had actually tested it outside of just compile-testing > > it. > > Right, I am surprised as well, since I explicitly did boot testing on > the tree-wide refactor, though I admit the most recent validation over > the last few weeks has been on the compile testing side due to tracking > down type mismatches. > > FWIW, I have now been able to reproduce the objtool warning, though, > using Fedora 42's Clang 20. I'm frustrated that it didn't show with the > other builds I did, and that 0day never sent a single email about it > over the weeks that I've had my tree up for testing. Just spent a while bisecting why the kernel wasn't booting on 8934827db540 with clang 21.1.8 before I noticed Linus's fix (for a pull request that wasn't Cc'ed to any mailing lists other than linux-kernel). Do we have a sense of how this made it in? __flex_counter expands to '(void *)NULL' for clang versions before 22 (despite the incorrect comment above it that says clang >= 19), causing typeof_flex_counter to evaluate to size_t, causing (!overflows_type(COUNT, typeof_flex_counter(((TYPE *)NULL)->FAM))) to always be true on 64-bit. So it looks like k*alloc_flex() always returned NULL, unless the kernel was built with pre-release clang 22. Not sure what I'm missing. It looks like the conversions of kmalloc() et al to kmalloc_flex() et al were never in linux-next, so presumably that was a factor? - Eric