Re: [PATCH v2] percpu: add basic double free check

[Sebastian Andrzej Siewior]

On 2026-01-16 21:15:33 [-0800], Dennis Zhou wrote:
> > The patch does appear to do that which it set out to do.  But do we
> > want to do it?  Is there a history of callers double-freeing percpu
> > memory?  Was there some bug which would have been more rapidly and
> > easily solved had this change been in place?
> > 
> 
> Originally, Sebastian posted he ran into the issue where he double freed
> in [1] (linked in patch). Maybe he can elaborate how that bug was
> introduced.
> 
> Wrt do we want to do it - I think it doesn't hurt and makes it more
> explicit that something very wrong occurred. Percpu memory really 
> expects users to be good samaritans. If you do happen to accidentally
> double free without the warning, in a contrived case you could
> experience unexplained behavior for some time before crashing in a spot
> that would leave your head scratching. If anything I think there could
> be an argument to fail louder.

I did write some code and there was a free path I did not expect to
happen. While it was rare to happen, it did not always crash right away.
Once I had the pattern I was wondering why none of the memory debug
switches did something. 
Adding this does not look expensive, allocating per-CPU is hardly done
in a hot path so I did not add anything but I don't mind hiding it
behind a config switch similar to SLAB_DEBUG.
While we do have way less per-CPU allocations compared to SLAB, I think
it is important to have some kind of sanity checks for it to ensure it
is used properly.
I would go with a WARN_ON_ONCE but if there is a desire for rate limited
multiple warnings, fine.

> [1] https://lore.kernel.org/linux-mm/20250904143514.Yk6Ap-jy@xxxxxxxxxxxxx/
> 
> Thanks,
> Dennis

Sebastian