[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180418125008.203632feeaf0cac4e51c5b79@linux-foundation.org>
Date: Wed, 18 Apr 2018 12:50:08 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: Michal Hocko <mhocko@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Laura Abbott <labbott@...hat.com>,
Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
LKML <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v2] fork: Unconditionally clear stack on fork
On Wed, 18 Apr 2018 09:38:07 -0700 Kees Cook <keescook@...omium.org> wrote:
> >> So some quite careful quantitative testing is needed here, methinks.
> >
> > Well, I did some more with perf and cycle counts on running 100,000
> > execs of /bin/true.
> >
> > before:
> > Cycles: 218858861551 218853036130 214727610969 227656844122 224980542841
> > Mean: 221015379122.60
> > Std Dev: 4662486552.47
> >
> > after:
> > Cycles: 213868945060 213119275204 211820169456 224426673259 225489986348
> > Mean: 217745009865.40
> > Std Dev: 5935559279.99
> >
> > It continues to look like it's faster, though the deviation is rather
> > wide, but I'm not sure what I could do that would be less noisy. I'm
> > open to ideas!
>
> Friendly ping. Andrew, can you add this to -mm?
I did so on Feb 21 but didn't merge it up because I'd told myself that
careful perf testing is needed. I guess we've sufficiently ticked that
box. Kind of. Maybe.
Oh well, it's easy enough to revert. I'll add it to the next
batch-for-Linus.
Powered by blists - more mailing lists