Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Jan 2017 21:35:34 +0100
From: Greg KH <>
To: Kees Cook <>
Cc: Elena Reshetova <>,
	"" <>,
	Arnd Bergmann <>, Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,
	Peter Zijlstra <>,
	Will Deacon <>,
	David Windsor <>
Subject: Re: [RFCv2 PATCH 00/18] refcount_t API + usage

On Wed, Jan 18, 2017 at 12:06:19PM -0800, Kees Cook wrote:
> On Wed, Jan 18, 2017 at 2:30 AM, Greg KH <> wrote:
> > 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
> Where do you see this? I haven't seen refcount_t land in -next yet.

The patches leading up to refcount_t are in the tip tree.

> Should I carry these in the KSPP tree, or who should take them?

I think the refcount_t patch should also go to tip given it depends on
the kref patches.  But that's up to Peter, he would know best...


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.