From: Mark Salyzyn <salyzyn@xxxxxxxxxxx> Date: Fri, 28 Jul 2017 11:07:53 -0700 > On 07/28/2017 10:41 AM, Andrew Lunn wrote: >> On Fri, Jul 28, 2017 at 10:15:23AM -0700, Mark Salyzyn wrote: >>> (Resend to wider audience to comply with >>> Documentation/networking/netdev-FAQ.txt) >>> >>> Please apply/backport the following upstream feature and followup >>> grouped fixes patches to the stable trees (expect included in at least >>> 3.10.y, 3.18.y, 4.4.y and 4.9.y): >> .. _stable_kernel_rules: >> >> Hi Mark >> >> Everything you ever wanted to know about Linux -stable releases >> =============================================================== >> >> Rules on what kind of patches are accepted, and which ones are not, >> into the >> "-stable" tree: >> >> - It must be obviously correct and tested. >> - It cannot be bigger than 100 lines, with context. >> >> The first patch you list is 342 lines. The second one is 634. >> >> Please could you read the rules and then provide some justification >> for ignoring many of the rules. >> >> Andrew > > The first four patches add a new dependent upstream API and type, > refcount_t. New APIs will notoriously cause a large number of lines to > be adjusted. They are complete (ToT will/should match stable), > orthogonal, and without CONFIG_REFCOUNT_FULL completely inert in all > places where atomic_t reference counters used, and are replaced with > refcount_t in the followup patches that take advantage of this new > type. > > The first four do _nothing_ at all to the kernel as-is, but represent > a dependency for the following changes. > > The remaining patches (for the most part) take advantage of this new > API to mostly fix, or report/warn when they can not, Use-After-Free > (KASAN) bugs which can lead to root attack exploits. atomic_t are > subject to unbounded attacks, refcount_t are relatively immune to > unbounded attacks. It is admittedly not a complete fix, but greatly > reduce the chances of the security issues. The recommendation is to > turn on CONFIG_REFCOUNT_FULL, but that is a decision to balance > between security and performance. > > For any platform that requires the latest security updates, refcount_t > is going to be a requirement. I urge you to overlook the first four > patch sizes because of their status as an orthogonal type and API, > necessary dependency for security improvements. Sorry, even with this explanation this -stable require is completely and totally inappropriate. You guys are really pushing things way too far with this refcount_t stuff, seriously. NACK.