From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752692AbcAVHgz (ORCPT ); Fri, 22 Jan 2016 02:36:55 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:35467 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751273AbcAVHgo (ORCPT ); Fri, 22 Jan 2016 02:36:44 -0500 Date: Fri, 22 Jan 2016 08:36:38 +0100 From: Ingo Molnar To: Alexei Starovoitov Cc: Josh Poimboeuf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Michal Marek , Peter Zijlstra , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Andi Kleen , Pedro Alves , Namhyung Kim , Bernd Petrovitsch , Chris J Arges , Andrew Morton , Jiri Slaby , Arnaldo Carvalho de Melo , Alexei Starovoitov , netdev@vger.kernel.org, daniel@iogearbox.net Subject: Re: [PATCH 23/33] x86/asm/bpf: Create stack frames in bpf_jit.S Message-ID: <20160122073638.GA28042@gmail.com> References: <20160122024427.GA6000@ast-mbp.thefacebook.com> <20160122035531.GA20502@treble.redhat.com> <20160122041845.GA7175@ast-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160122041845.GA7175@ast-mbp.thefacebook.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Alexei Starovoitov wrote: > > > I could be missing something. I think either this patch is not need or you > > > need to teach the tool to ignore all JITed stuff. I don't think it's > > > practical to annotate everything. Different JITs do their own magic. s390 > > > JIT is even more fancy. > > > > Well, but the point of these patches isn't to make the tool happy. It's > > really to make sure that runtime stack traces can be made reliable. Maybe I'm > > missing something but I don't see why JIT code can't honor > > CONFIG_FRAME_POINTER just like any other code. > > It can if there is no performance cost added. I can speak for x64 JIT, but the > rest needs to be analyzed as well. My point was that may be it's easier to > ignore all JITed code and just say that such call stacks may be unreliable? > live-patching is not applicable to JITed code anyway or you want to livepatch > the callees of it? So the rule is that if frame pointers are enabled all kernel code should have correct stack frames - in case an IRQ (or NMI) hits it or it crashes. Thanks, Ingo