Re: [RFC PATCH v2 02/14] kcov: fix INIT_TRACK race in kcov_dataflow
Alexander Potapenko <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.rust,gmane.linux.kbuild.devel,gmane.linux.kernel.mm,gmane.linux.kernel.workflows,gmane.linux.documentation |
|---|---|
| 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.