From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754331AbaD0QWu (ORCPT ); Sun, 27 Apr 2014 12:22:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53118 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753892AbaD0QQn (ORCPT ); Sun, 27 Apr 2014 12:16:43 -0400 Date: Sun, 27 Apr 2014 18:16:32 +0200 From: Jiri Olsa To: Mathias Krause Cc: Peter Zijlstra , Paul Mackerras , Ingo Molnar , Arnaldo Carvalho de Melo , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] perf x86: Fix perf to use non-executable stack, again Message-ID: <20140427161632.GA27784@krava.brq.redhat.com> References: <1398538965-10620-1-git-send-email-minipli@googlemail.com> <20140427092649.GA1111@krava.brq.redhat.com> <20140427103915.GC1111@krava.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 27, 2014 at 06:07:30PM +0200, Mathias Krause wrote: > On 27 April 2014 12:39, Jiri Olsa wrote: > > On Sun, Apr 27, 2014 at 12:03:50PM +0200, Mathias Krause wrote: > > [...] > >> 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? > > Not necessarily. What if a later version of a library already used by > perf needs an executable stack because it now makes use of nested > functions? Unlikely, though in that case no change to perf would be > made, but perf would then require an executable stack, too. I tried you can run binary with noexecstack having dynamic library dependency wit execstack > > Anyway, as Ingo votes for the global linker option as well, I'll send > a v2 of the patch containing your suggested linker flag. cool > > > 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.. > > Okay. > > > or insert test case for perf's executable stack to 'perf test' > > That won't work for systems preventing processes getting an executable > stack in the first place. That was the reason I stumbled about the could be disabled on such systems jirka