Re: [PATCH resend] kcov: allow simultaneous KCOV_ENABLE/KCOV_REMOTE_ENABLE

[Andrew Morton <akpm@linux-foundation.org>]

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...