|
From: David M. <da...@da...> - 2017-07-04 22:01:17
|
From: Elena Reshetova <ele...@in...> Date: Tue, 4 Jul 2017 15:52:55 +0300 > Changes in v2: > * rebase on top of net-next > * currently by default refcount_t = atomic_t (*) and uses all > atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. > This is a compromise for the systems that are critical on > performance (such as net) and cannot accept even slight delay > on the refcounter operations. > > This series, for various misc network components, replaces atomic_t reference > counters with the new refcount_t type and API (see include/linux/refcount.h). > By doing this we prevent intentional or accidental > underflows or overflows that can led to use-after-free vulnerabilities. > These are the last networking-related conversions with the exception of > network drivers (to be send separately). > > Please excuse the long patch set, but seems like breaking it up > won't save that much on CC list and most of the changes are > trivial. > > The patches are fully independent and can be cherry-picked separately. > In order to try with refcount functionality enabled in run-time, > CONFIG_REFCOUNT_FULL must be enabled. > > NOTE: automatic kernel builder for some reason doesn't like all my > network branches and regularly times out the builds on these branches. > Suggestion for "waiting a day for a good coverage" doesn't work, as > we have seen with generic network conversions. So please wait for the > full report from kernel test rebot before merging further up. > This has been compile-tested in 116 configs, but 71 timed out (including > all s390-related configs again). I am trying to see if they can fix > build coverage for me in meanwhile. > > * The respective change is currently merged into -next as > "locking/refcount: Create unchecked atomic_t implementation". Series applied, that's enough for this cycle, please. |
