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 08B2F37F738
	for <linux-kernel@vger.kernel.org>; Mon, 11 May 2026 21:48:58 +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=1778536139; cv=none; b=eaTUMv+7CrCTAj2AlXFc2AC/+5Rj6hnnNd2oHpdDP9r89/xQbL332PB4IJklL8t/0M/c5DMThTD+m7NO2ZW388U9we7lYvHeW0IQKlCGchRpDZ1478YwUIYZkkwEmNI5QQkGw3FtUTzUeH0+YRNTCw6Fnw2ICX7NhSR8RDk6y50=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1778536139; c=relaxed/simple;
	bh=Bcw99HcIDYpvq5D6FHVynLd4MeXnvojEh8aF6YlAsxE=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=tDAIJdTgh6cZLgPVoWtNqd6klGzLsIQh+p+3Sae626VPIMAxGUJH1P5LvnnCmnBEFNjoS7PrEOg7Z4oeDPSU7KjtLncvEeiQos+1Qj+iq2cOn3VeTJMYLgZWqxOBeUMWXqQS0c4nm8G7u1slPb5MrjMSARxeRG86akMV5tOHdBc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=r0ikJAcX; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="r0ikJAcX"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66F1BC2BCF5;
	Mon, 11 May 2026 21:48:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1778536138;
	bh=Bcw99HcIDYpvq5D6FHVynLd4MeXnvojEh8aF6YlAsxE=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=r0ikJAcXHzTgCqPhVVdZfW4U8fpvE5CH6gRUCExGoD3FCuD4ZxovzLbqvAN2CQqBi
	 /rh4DpyFrCkgsfgO+qrJtKv6k+OOex7M84J6cQDAByE40BJ801b7hhgDfGCwx3uodE
	 LlMlg/8b2JAbjCbvFZ/BzQrcpQFiyp2CH/pxWRLQ=
Date: Mon, 11 May 2026 14:48:57 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Jann Horn <jannh@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>, Andrey Konovalov
 <andreyknvl@gmail.com>, Alexander Potapenko <glider@google.com>,
 kasan-dev@googlegroups.com, Marco Elver <elver@google.com>,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH resend] kcov: allow simultaneous
 KCOV_ENABLE/KCOV_REMOTE_ENABLE
Message-Id: <20260511144857.f9377ee9f9d51258afa99cf7@linux-foundation.org>
In-Reply-To: <CAG48ez1jhidxz25bfDLS8MStchcd6Fr76PJs+p8BpFUFLLOZ9A@mail.gmail.com>
References: <20260505-kcov-simultaneous-remote-v1-1-a670ba7cefd2@google.com>
	<20260508182358.8a7775b2bfe0211c87278484@linux-foundation.org>
	<CAG48ez1jhidxz25bfDLS8MStchcd6Fr76PJs+p8BpFUFLLOZ9A@mail.gmail.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 11 May 2026 17:03:49 +0200 Jann Horn <jannh@google.com> wrote:

> > checkpatch asked:
> >
> > WARNING: Using vsprintf specifier '%px' potentially exposes the kernel memory layout, if you don't really need the address please consider using '%p'.
> > #141: FILE: kernel/kcov.c:463:
> > +               kcov_debug("t = %px, kcov->t = %px\n", t, kcov->t);
> 
> Yep, I saw that when running checkpatch but decided to leave it this
> way. I didn't introduce that line, I just moved it around; and other
> parts of kcov use %px to identify the task as well, so changing just
> this spot to %p would be inconsistent. I guess I should have noted
> that below the patch...
> 
> (And kcov_debug() maps to pr_debug(), so these things will not
> normally show up in the kernel log.)

yup.

> > and Sashiko found a femtobug:
> >         https://sashiko.dev/#/patchset/20260505-kcov-simultaneous-remote-v1-1-a670ba7cefd2@google.com
> 
> Hm. In my view, this isn't different from the previous behavior - if
> the state is broken, WARN_ON() will print a warning and the function
> will bail out immediately without dropping references.
> 
> I think if we hit a WARN_ON(), generally this means some state has
> been corrupted and/or programmer assumptions have been broken, and it
> doesn't really make sense to try to go for full correctness (dropping
> references properly and such) because the system is already in a state
> the programmer didn't consider. Instead, I think it's best to not
> touch the broken state, and prefer leaking memory rather than
> potentially making things worse by dropping references (which could
> make the situation worse and cause UAF or similar).

yup.

As said, femtobugs.  Things to add to the todo list somewhere...