From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA4E3C388F2 for ; Tue, 20 Oct 2020 15:59:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5382D2224A for ; Tue, 20 Oct 2020 15:59:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="f9tjk2f0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gJoT0PYA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5382D2224A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=d8vo8Emd+kfUKuPQI7/A2/a3BecoqN3cwh1s3UBh73U=; b=f9tjk2f0ZADqgP/R+kJTq0OH6 YQpCEiU7he6ADRDiJE1enb9qSBMddeVY4LDOZtG9eFYptncwDS1MAsWviKuWpx9ZMf5p5r/K51nz5 kzWDxGDP6sACTenqiBIGsP/obayc/M+43k+nmgy9sA3yz9tVqhdkCRqy9nW7PmEZw028u/ZkZIILf 3HjykM0zdHZsMD2ram74ffTWqJ5x0wNSgEsfr3eHKqV9Y6AHEX5mtFqdggCIszlkI9m9A8+k5Y5TI 2ANiZ1Ee5l6H0llA3B0VI8goXK19N60STAO2Vl8AmmURslkDKMoXmMnekW5BKUJkyoccY/FSbwQw2 QUI3B2ZGg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUu1f-0003B5-4R; Tue, 20 Oct 2020 15:58:15 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUu1c-00039j-A1 for linux-arm-kernel@lists.infradead.org; Tue, 20 Oct 2020 15:58:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603209491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6rKJUp/hFuoSptP9CoWz5upgdM+KXQTN0SbAhamuu80=; b=gJoT0PYAXybCuedP6RFCz6gxjzXzAg6p+F5MKedrp87fMy9ClIBo5niEm2qiMCC6kpgB3j 53MzfmRhXB48riSdmdD8RyYa90QceLUmq8ZNidCzsYtslYkRfXR2rgZsu/7X1IJb0cuXOR zGCDOi90USI9LAMRP3wO4b0PVsvWS/g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-296-sCqQLHNnMSOZBz2EoKvXNg-1; Tue, 20 Oct 2020 11:58:09 -0400 X-MC-Unique: sCqQLHNnMSOZBz2EoKvXNg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 99B7E186842E; Tue, 20 Oct 2020 15:58:07 +0000 (UTC) Received: from treble (ovpn-114-84.rdu2.redhat.com [10.10.114.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 59C4F60C0F; Tue, 20 Oct 2020 15:58:05 +0000 (UTC) Date: Tue, 20 Oct 2020 10:58:02 -0500 From: Josh Poimboeuf To: Mark Rutland Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20201020155802.da6ca652hramdlnb@treble> References: <20201012172605.10715-1-broonie@kernel.org> <20201015141612.GC50416@C02TD0UTHF1T.local> <20201015154951.GD4390@sirena.org.uk> <20201015212931.mh4a5jt7pxqlzxsg@treble> <20201016111431.GB84361@C02TD0UTHF1T.local> <20201020100352.GA48360@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201020100352.GA48360@C02TD0UTHF1T.local> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201020_115812_445240_61CDA15D X-CRM114-Status: GOOD ( 23.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , linux-kernel@vger.kernel.org, Mark Brown , live-patching@vger.kernel.org, Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 20, 2020 at 11:03:52AM +0100, Mark Rutland wrote: > On Fri, Oct 16, 2020 at 12:14:31PM +0100, Mark Rutland wrote: > > Mark B's reply dropped this, but the next paragraph covered that: > > > > | I was planning to send a mail once I've finished writing a test, but > > | IIUC there are some windows where ftrace/kretprobes > > | detection/repainting may not work, e.g. if preempted after > > | ftrace_return_to_handler() decrements curr_ret_stack, but before the > > | arch trampoline asm restores the original return addr. So we might > > | need something like an in_return_trampoline() to detect and report > > | that reliably. > > > > ... so e.g. for a callchain A->B->C, where C is instrumented there are > > windows where B might be missing from the trace, but the trace is > > reported as reliable. > > I'd missed a couple of details, and I think I see how each existing > architecture prevents this case now. > > Josh, just to confirm the x86 case, am I right in thinking that the ORC > unwinder will refuse to unwind from the return_to_handler and > kretprobe_trampoline asm? IIRC objtool shouldn't build unwind info for > those as return_to_handler is marked with SYM_CODE_{START,END}() and > kretprobe_trampoline is marked with STACK_FRAME_NON_STANDARD(). Hm, return_to_handler() actually looks like a bug. UNWIND_HINT_EMPTY sets end=1, which causes the ORC unwinder to treat it like entry code (end of the stack). So while it does stop the unwind, it fails to report an error. This would be fixed by the idea I previously mentioned, changing UNWIND_HINT_EMPTY -> UNWIND_HINT_UNDEFINED (end=0) for the non-entry cases. I'll need to work up some patches. > Both powerpc and s390 refuse to reliably unwind through exceptions, so > they can rely on function call boundaries to keep the callchain in a > sane state. Yes, and also true for x86 frame pointers. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel