Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow

Alexander Potapenko <[email protected]> Fri, 12 Jun 2026 08:55:54 +0200
Newsgroups org.kernel.vger.workflows,dev.linux.lists.llvm,org.kernel.vger.linux-doc,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.rust-for-linux,org.kvack.linux-mm
Message-ID <CAG_fn=V1+_xLgCZgdLnT7Y-muRO0CXkrNKkC8AzrqzWoL4eR8w@mail.gmail.com>
On Thu, Jun 11, 2026 at 6:21 PM Yunseong Kim <[email protected]> wrote:
>
> Two threads calling KCOV_DF_INIT_TRACK concurrently could both observe
> df->area == NULL, drop the lock to allocate, and then both assign their
> allocation to df->area, leaking one buffer.
>
> Fix by rechecking df->area after re-acquiring the lock. If another
> thread won the race, free the allocation and return -EBUSY. This
> matches the pattern used by KCOV_INIT_TRACE in kernel/kcov.c.
>
> Reported-by: sashiko-bot <[email protected]>
> Closes: https://sashiko.dev/#/patchset/20260603-kcov-dataflow-next-20260603-v2-0-fee0939de2c4%40est.tech
> Signed-off-by: Yunseong Kim <[email protected]>

Can we please avoid this?
kcov_dataflow.c is being introduced in the same series, there is no
need to send a buggy commit and a follow-up fix - just squash the two
together and note the changes after Signed-off-by: separated by a
triple dash.