From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753819AbaD0Kjc (ORCPT <rfc822;w@1wt.eu>);
	Sun, 27 Apr 2014 06:39:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:55354 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753402AbaD0Kja (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 27 Apr 2014 06:39:30 -0400
Date: Sun, 27 Apr 2014 12:39:15 +0200
From: Jiri Olsa <jolsa@redhat.com>
To: Mathias Krause <minipli@googlemail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Paul Mackerras <paulus@samba.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf x86: Fix perf to use non-executable stack, again
Message-ID: <20140427103915.GC1111@krava.brq.redhat.com>
References: <1398538965-10620-1-git-send-email-minipli@googlemail.com>
 <20140427092649.GA1111@krava.brq.redhat.com>
 <CA+rthh_-nbyb=9TU5X=2gDMMgzngU6LqLejRMU8GNvrDZ1kVTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+rthh_-nbyb=9TU5X=2gDMMgzngU6LqLejRMU8GNvrDZ1kVTA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 27, 2014 at 12:03:50PM +0200, Mathias Krause wrote:

SNIP

> >> 1.7.10.4
> >>
> >
> > hum, how about fixing this once and for all.. ;-)
> > please check attached patch, thanks
> 
> Yeah, I thought about this option too but declined it for two reasons:
> 1/ The kernel sources should provide good quality examples, even for
> usage outside of the kernel. Imagine somebody taking the memcpy
> implementation for his own project but not copying the LDFLAGS. That
> would make his code have an executable stack while with the .GNU-stack
> marker in the assembler file it won't.

that 'somebody' should check/know better ;-) but ok, fair enough

> 2/ What if somebody tries to add/link code to perf that makes use of
> nested functions? That'll make perf fail as the trampoline code
> generated by gcc won't be executable due to the enforced
> non-executable stack by -Wl,-z,noexecstack.

I guess in that case he would change the Makefile as well?

anyway I have no objection for leaving that code in assembly
objects, but I suggest we use the global option as well to
prevent any future surprise..

or insert test case for perf's executable stack to 'perf test'

thanks,
jirka