From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 79FD332937B; Thu, 18 Dec 2025 11:59:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=63.228.1.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766059165; cv=none; b=iAixDGYPxfdPH5Cdp1fH+37Qg1+z+zFx6Ke5TKNe1E22zGM3/l7WtFQsjjc/vbugj6F/xHtOuDgsGElSt8c44X5pjV0PRMZiauvZFCY6V/VITRSMyLywH8k4Qcw+zO8vIjwNYCmusRFujitSLcYDRTWrOAwgdnDmwYDxe/TcDGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766059165; c=relaxed/simple; bh=XfA67wdvFVblSaJhY8c4UwObo/yUa9OkWj1ykN7PeX0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DBBKVQJ5ibfvIRr9JCYDCFyvRiDp3y1rYrKsY8d7Qj2FLd7bQMR7jWeqeH9ObOJDwemcDo5y1WAYa0rS6ZO4II79H2J6tmNFssvc7nMQTlwwELzQa7lxOImTibAOP9+UY3C12NYSwsEAJ77+wv0N+4JeVLkrE9p7C9vkKUkziWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org; spf=pass smtp.mailfrom=kernel.crashing.org; arc=none smtp.client-ip=63.228.1.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost [127.0.0.1]) by gate.crashing.org (8.18.1/8.18.1/Debian-2) with ESMTP id 5BIBwjSG450725; Thu, 18 Dec 2025 05:58:45 -0600 Received: (from segher@localhost) by gate.crashing.org (8.18.1/8.18.1/Submit) id 5BIBwi3N450723; Thu, 18 Dec 2025 05:58:44 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 18 Dec 2025 05:58:44 -0600 From: Segher Boessenkool To: Marco Elver Cc: Peter Zijlstra , Ard Biesheuvel , Kees Cook , Brendan Jackman , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org Subject: Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV Message-ID: References: <20251208-gcov-inline-noinstr-v1-0-623c48ca5714@google.com> <20251218095112.GX3707837@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-toolchains@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: Hi! On Thu, Dec 18, 2025 at 10:56:48AM +0100, Marco Elver wrote: > On Thu, 18 Dec 2025 at 10:51, Peter Zijlstra wrote: > > 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 :/ > > Unfortunately, yes. But let's try to get the builtin into Clang and > GCC now (for the latter, need to Cc GCC folks to help). > > Then we wait for 5 years. :-) > > There's a possibility to try and backport it to stable Clang and GCC > versions, but it's a long stretch (extremely unlikely). We (GCC) do not generally want to do backport features; even for bugfixes the risk/reward ratio comes into the picture. It *can* be done if some feature is important enough of course. If you have to wonder or ask if your feature is important enough, it is not. The reason we do not want backports of feature is it increases maintenance cost a lot, and so, development costs as well. I guess LLVM has a similar policy, but I of course do not speak for them. You might have more success getting the stuff backported to some distro(s) you care about? Or get people to use newer compilers more quickly of course, "five years" before people have it is pretty ridiculous, two years is at the tail end of things already. Segher