On Mon, 19 Jul 2021 11:23:35 +0800 Xiyu Yang <xiyuyang19@xxxxxxxxxxxx> 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?