[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF636D0@IRSMSX102.ger.corp.intel.com>
Date: Fri, 1 Sep 2017 17:08:51 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Kees Cook <keescook@...omium.org>,
Peter Zijlstra <peterz@...radead.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
"Al Viro" <viro@...iv.linux.org.uk>, Tejun Heo <tj@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Johannes Weiner <hannes@...xchg.org>,
Li Zefan <lizefan@...wei.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
"Alexander Shishkin" <alexander.shishkin@...ux.intel.com>,
Eric Paris <eparis@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"dvhart@...radead.org" <dvhart@...radead.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: RE: [PATCH 00/15] v5 kernel core pieces refcount conversions
> On Fri, Sep 1, 2017 at 2:48 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, Aug 31, 2017 at 04:48:00PM -0700, Kees Cook wrote:
> >> On Wed, Aug 30, 2017 at 5:22 AM, Elena Reshetova
> >> <elena.reshetova@...el.com> wrote:
> >> > Now we have at least x86 support for ARCH_HAS_REFCOUNT merged and
> >> > arm and others on their way.
> >> >
> >> > Changes in v5:
> >> > * Kees catched that the following changes in
> >> > perf_event_context.refcount and futex_pi_state.refcount
> >> > are not correct now when ARCH_HAS_REFCOUNT is enabled:
> >> > - WARN_ON(!atomic_inc_not_zero(refcount));
> >> > + refcount_inc(refcount);
> >> > So they are now changed back to using refcount_inc_not_zero.
> >>
> >> Thanks!
> >>
> >> Reviewed-by: Kees Cook <keescook@...omium.org>
> >>
> >> Andrew, are you able to carry these patches in -mm, since they span a
> >> bunch of core kernel areas?
> >
> > No.. these patches should go through the regular trees that maintain
> > these various parts.
>
> Okay, sounds fine. Elena, can you split these up? (You'll probably
> have to examine MAINTAINERS and/or git history for each patch...)
Well, I can do this, but patches are already fully independent for cherry-pick and all maintainers
should be in the CC list, so I was hoping people can pull into their trees from this series.
But if people want to split, I can do a split...
Best Regards,
Elena.
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
Powered by blists - more mailing lists