On Mon, 19 Jul 2021 11:23:35 +0800 Xiyu Yang [off-list ref] wrote:

refcount_t type and corresponding API can protect refcounters from
accidental underflow and overflow and further use-after-free situations.

Grumble.

For x86_64 defconfig this takes rmap.o text size from 13226 bytes to
13622.

For x86_64 allmodconfig this takes rmap.o text size from 66576 bytes to
67858.

I didn't check which config option is making the bloat so much worse,
but this really is quite bad.  We bust a gut to make savings which are
1% the size of this!  Is the refcount_t really so much better than a
bare atomic_t that this impact is justified?

Can someone pleeeeeeze take a look at what is happening here and put
the refcount code on a very serious diet?