On Sun, Apr 20, 2025 at 09:27:26PM -0400, Kent Overstreet wrote: > On Sun, Apr 20, 2025 at 06:08:41PM -0700, Kees Cook wrote: > > On Sun, Apr 20, 2025 at 11:59:13AM -0400, Kent Overstreet wrote: > > > Not sure we have a list for library code, but this might be of interest > > > to anyone who's had to debug refcount issues on refs with lots of users > > > (filesystem people), and I know the hardening folks deal with refcounts > > > a lot. > > > > Why not use refcount_t instead of atomic_t? > > It's rather pointless here since percpu refcounts don't (and can't) > support saturation, and atomic_long_t should always suffice - you'd have > to be doing something particularly bizarre for it not to, since > refcounts generally count things in memory. Ah yes, my eyes skipped over the "long" part when I was reading the patches. There's currently no sane reason to use refcount_t when already using atomic_long_t. Sorry for the noise! > Out of curiousity, has overflow of an atomic_long_t refcount ever been > observed? Not to my knowledge. :) -- Kees Cook
