On Thu, Nov 17, 2016 at 01:01:49PM +0000, Reshetova, Elena wrote:
> >I think the sole motivator is a general distaste of atomic_t, which isn't a
> >good reason at all.
>
> I don't think anyone has this as motivation. But atomic_t is so
> powerful and flexible that easily ends up being misused (as past CVEs
> shown).
I don't think using atomic_t as reference count is abuse. There simply
wasn't anything better. The proposed refcount_t cures this.
> Even if we now find all occurrences of atomic_t used as
> refcounter (which we cannot actually guarantee in any case unless
> someone manually reads every line) and convert it to refcount_t, we
> still have atomic_t type present and new usage of it as refount will
> crawl in. It is just a matter of time IMO.
Improve tooling. The patterns shouldn't be _that_ hard to find. Once the
tools are good, new code isn't a problem either.
Anything: atomic*_{{dec,sub}_and_test,{add,sub}_return,fetch_{add,sub}}
followed by a call_rcu()/free().
