Re: [PATCH resend] kcov: allow simultaneous KCOV_ENABLE/KCOV_REMOTE_ENABLE
From: Andrew Morton
Date: Mon May 11 2026 - 17:49:05 EST
On Mon, 11 May 2026 17:03:49 +0200 Jann Horn <jannh@xxxxxxxxxx> 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@xxxxxxxxxx
>
> 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...