[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2017 11:30:31 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Elena Reshetova <elena.reshetova@...el.com>
Cc: kernel-hardening@...ts.openwall.com, keescook@...omium.org,
arnd@...db.de, tglx@...utronix.de, mingo@...hat.com,
h.peter.anvin@...el.com, peterz@...radead.org, will.deacon@....com,
dwindsor@...il.com
Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage
On Wed, Jan 18, 2017 at 11:11:29AM +0200, Elena Reshetova wrote:
> Changes since v1:
> - kref INIT fixes are moved to a proper separate commit
> - Peter's commits are now properly integrated into series
> - various small fixes are incorporated based on testing
> results and feedback
>
> This patch series is build on top of Peter's Zijlstra patches
> that provide refcount_t type and API definition.
> The rest of patches convert various places of kernel subsystems
> where atomic_t was used for reference counting to new refcount_t type and API.
> By doing this, we make sure that underflows and overflows
> cannot occur in these places and therefore no use-after-free situation
> can be created and misused by an attacker.
Your first 7 patches are fine, and most of them are already in the tip
tree and getting use in linux-next now. I'd recommend submitting the
remaining one(s?) that are not there yet to be included, that will get
refcount_t into 4.11-rc1.
Then comes the real work :)
You will need to break up the remaining patches into "one-per-type" and
start submitting them to the various submaintainers for inclusion. You
can do that once 4.11-rc1 is out. That's going to be a lot of different
patches, and your patch-maintaince skills are going to be tested here...
With those submissions, lots of them will start to trickly into
linux-next and start to show up in 4.12-rc1. You'll then need to
refresh your patchset, drop the ones that were accepted, and do it all
over again. If some maintainers are just ignoring you, you'll have to
go through some other tree for them (I can take the driver ones through
my driver tree.)
It's going to be work, but is totally doable. I recommend setting up a
separate git or quilt tree that can get included into linux-next and
kbuild for testing and refreshing as the patches start to flow upstream.
Kernel development isn't always a lot of coding, it's primarily dealing
with stuff like this, welcome to the club :)
hope this helps,
greg k-h
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
