From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 6A6D51F9F70 for ; Thu, 18 Dec 2025 09:51:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766051479; cv=none; b=DeLvWzn3LWy1c5WL45Ag2svj2i+K+dYxAMH7Py41yf89LE57b2JIqRc4pYCDAD6lMkmg8TFMxszsyLejDbKHF1zZU9VK5LTrJ/USrUmddjZRPUUGReoL9w88H0GVV5ok0azRIt7ibBpZ/c+VwYReoHfx95/4/Omt+ye6FYdCENw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766051479; c=relaxed/simple; bh=0vUk+B9FSI/j3ihS03Ku6gFqn1gt57ss1G2MImLSk24=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lFMDcgZDsam5BWkIeemhxEEkU6i8JOMfsdndmrMQb8kQ5wG+oUhN/C/jHqM4p6/ERitKwtATstzh7OrhJxqlf/KLIjXnw5/DbEWE0kj3axStFq1+Drk9AegOLlYhuPzWhBnzWFfSsjlkJfgz4D8WhCtHARHGMfbwSKp6m+rKZ48= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=AdPcosY7; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="AdPcosY7" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CV5CQCad42/bUva9s7fv3RzPqF2E+dAhvuamq71vXP4=; b=AdPcosY7/N2ftPIlZSGYv9wySg aXQtTC+3n9obhUB+jVUZLwDVTCIaokANDZpEM0boo8Kr02lfKpDBEV1QGZsdGCha9rsV/7zwI44n1 Hxmt8rjM8mT8ZU3nIk1iWUF0vk0LRBJQb1npVStmaDdI2WP0+XAVzWaaAwZyIs3v97tzms0LZypV0 F4gFx3Ik6EYj4P21q9wT696EM4JUt/hMLnop4O8SF0syBlmpZyU0G3JaOEA+nXJyNwWWVho6xqQwh 5DZEHO6b1E+aCSCTu8qkhvbA/cXD/iTobUPT7la6hhbNh+AgioWL00L0OxcfX536yTtlZJvBtnrFI lGog+UEw==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vW9ni-00000008Ur8-3Uah; Thu, 18 Dec 2025 08:55:59 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C90A230056B; Thu, 18 Dec 2025 10:51:12 +0100 (CET) Date: Thu, 18 Dec 2025 10:51:12 +0100 From: Peter Zijlstra To: Ard Biesheuvel Cc: Marco Elver , Kees Cook , Brendan Jackman , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV Message-ID: <20251218095112.GX3707837@noisy.programming.kicks-ass.net> References: <20251208-gcov-inline-noinstr-v1-0-623c48ca5714@google.com> 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 Sat, Dec 13, 2025 at 08:59:44AM +0900, Ard Biesheuvel wrote: > > After that I sat down and finally got around to implement the builtin > > that should solve this once and for all, regardless of where it's > > called: https://github.com/llvm/llvm-project/pull/172030 > > What this will allow us to do is to remove the > > "K[AC]SAN_SANITIZE_noinstr.o := n" lines from the Makefile, and purely > > rely on the noinstr attribute, even in the presence of explicit > > instrumentation calls. > > > > Excellent! Thanks for the quick fix. Happy to test and/or look into > the kernel side of this once this lands. Well, would not GCC need to grow the same thing and then we must wait until these versions are the minimum supported versions for sanitizer builds. I mean, the extension is nice, but I'm afraid we can't really use it until much later :/