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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 849EBC433ED for ; Tue, 13 Apr 2021 11:03:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68AAB613B7 for ; Tue, 13 Apr 2021 11:03:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345204AbhDMLDy (ORCPT ); Tue, 13 Apr 2021 07:03:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:60146 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345098AbhDMLDg (ORCPT ); Tue, 13 Apr 2021 07:03:36 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 947F3613C1; Tue, 13 Apr 2021 11:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618311797; bh=YN5QtVOU/fCpbRgeqeMvCPohzoOdRoQ9xxZfw5H3Yww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OvaM3/wIW2ManMdV4piZJcIhWIWR1AX9Pwrl00bRt/FBdLpPjuoT/a9bU1OsxdxkQ tbr95XbtmLktuTssfIl9IxPn+mgm+l89cZCCuhyqawa4c1tkqEYHhCjLI84g+fwl6g 4HfVwdCi8SHULz+aVMvuQ/xNMydNz+GRsTP3dCbx9tFpcsc5zbCBby4xH9KfRlOkAI EJk0aR9ZICE1yIqna6zeiID854O+u6QZ/iAxvDepDox6pownKCwYD+gpfjpZ3DOszd e7i4Ya8OCwh747wqlL+sYbRv65vRfoKrOj20+y1MgYkOM976HILd5JNgCpKVJ8B9iG +EMwocASPfApQ== Date: Tue, 13 Apr 2021 12:02:55 +0100 From: Mark Brown To: "Madhavan T. Venkataraman" Cc: Josh Poimboeuf , Mark Rutland , jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks Message-ID: <20210413110255.GB5586@sirena.org.uk> References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210409120859.GA51636@C02TD0UTHF1T.local> <20210409213741.kqmwyajoppuqrkge@treble> <20210412173617.GE5379@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: X-Cookie: Shake well before using. User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote: >=20 > OK. Just so I am clear on the whole picture, let me state my understandin= g so far. > Correct me if I am wrong. > 1. We are hoping that we can convert a significant number of SYM_CODE fun= ctions to > SYM_FUNC functions by providing them with a proper FP prolog and epilo= g so that > we can get objtool coverage for them. These don't need any blacklistin= g. I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC. I'd expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's required to be non standard due to some external interface - things like the exception vectors, ftrace, and stuff around suspend/hibernate. A quick grep seems to confirm this. > 3. We are going to assume that the reliable unwinder is only for livepatc= h purposes > and will only be invoked on a task that is not currently running. The = task either The reliable unwinder can also be invoked on itself. > 4. So, the only functions that will need blacklisting are the remaining S= YM_CODE functions > that might give up the CPU voluntarily. At this point, I am not even s= ure how > many of these will exist. One hopes that all of these would have ended= up as > SYM_FUNC functions in (1). There's stuff like ret_from_fork there. > I suggest we do (3) first. Then, review the assembly functions to do (1).= Then, review the > remaining ones to see which ones must be blacklisted, if any. I'm not clear what the concrete steps you're planning to do first are there - your 3 seems like a statement of assumptions. For flagging functions I do think it'd be safer to default to assuming that all SYM_CODE functions can't be unwound reliably rather than only explicitly listing ones that cause problems. --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmB1el4ACgkQJNaLcl1U h9A3PQf/VI0TAe26+qZlWoT60AoRxJ3FU1apGj5nPlp8H9phWjbQEmnD6j5LHfPL 1VAxKkqe73NAB2/t6LdOfanOjqzJ+YnPkZvV1j6yJLsMnwpDTwUJxykpIPH5nkcj 2Tx3mGR72FnQv2ubUdFeO2Wi4LA7js2uAPZvlZkBMgekd8TMpgIHxTIbJszXIAR2 AQP3x+0EmuigidoaSxvnAtTKnBK3z+/pc95xtlQgGpXX/WdrCVmkiCJQ0iaq8b17 St7awxqETDC7/7AixyeIwzx9P9iM7J9CfdiqREFfEeJ++Zy4z7XYK+0dJbpImCc9 cG1nWivPtAK2O/6Ld0oVIk5HRUGtFg== =iS5y -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- 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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 16D60C433ED for ; Tue, 13 Apr 2021 11:21:03 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 8E6D161019 for ; Tue, 13 Apr 2021 11:21:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E6D161019 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eTiSbeFNtBAzLcZFlHQsXXWyquewXDWF7DtmB3hfTdw=; b=YAAwYaeF+SomuSG66JheyEaLM aRoPtdKINrBhgYt9oP3ESzbydE17c0lFHdpp4g7CuF6zYWvirV72O0p1bZs9vzKNIcHdDGHR52cul 6wURKDSYzlMmouIRThn0TOBsG0aaEknA58zs+vedxCyqQI44g9Kpv7hBDhZN8OWUc5B8i6d0loBvK 1lnF1hEFC/aU+Xxep0vzD7b/gT6I3uWZvrtOtAoWMS1hE8/Yehrk0p8HL9zRf7MqgD3dK8CwBjaKc B5wvCxyIgtGDnxXkZ3HuYTuHn7FKYPT72t3dFzOMY/F73qx20eFR7nrSWAmnBvYwpaL3zMGpkuXGq BCQYEUqAw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lWH3x-0090Yg-L2; Tue, 13 Apr 2021 11:18:36 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWGpE-008wys-1G for linux-arm-kernel@desiato.infradead.org; Tue, 13 Apr 2021 11:03:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=f5ut3ggBk/PJH9iUvWPbGsKTYeGaU+ZhkYGRZ8YMuQM=; b=BbImIIplRhJRJX7tqasxCDADdU +8DUPzQSYvVpvCb2T+nZOa4pu1fg0RMcGzGhDadOwtJ9yQNxvdyXg13nCN3dYXNTsVsl8PraZRJKh lYj23Hx5d/iatd/n5v9IxB4mGfB8DT/DzQ9gnHPyi3q5/yC5BAlTO1UrljN7OmNosteDXSJdtaqXH qM2FXDvUyhB1yej7OveHDvZilJEe4XLfbFaxAGxpCaNORJCPCaorWTbwyVao8T5SvYpk1hdD3N6A1 8y2/SzVLBfIvG6If+hni8c0x/1F32C//OF0Qa0+WaYmIbdypN5nEcwvTfY9oNEHo0CMEezvN5XMGB 8fvE+MgQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWGpB-006wx0-I7 for linux-arm-kernel@lists.infradead.org; Tue, 13 Apr 2021 11:03:18 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 947F3613C1; Tue, 13 Apr 2021 11:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618311797; bh=YN5QtVOU/fCpbRgeqeMvCPohzoOdRoQ9xxZfw5H3Yww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OvaM3/wIW2ManMdV4piZJcIhWIWR1AX9Pwrl00bRt/FBdLpPjuoT/a9bU1OsxdxkQ tbr95XbtmLktuTssfIl9IxPn+mgm+l89cZCCuhyqawa4c1tkqEYHhCjLI84g+fwl6g 4HfVwdCi8SHULz+aVMvuQ/xNMydNz+GRsTP3dCbx9tFpcsc5zbCBby4xH9KfRlOkAI EJk0aR9ZICE1yIqna6zeiID854O+u6QZ/iAxvDepDox6pownKCwYD+gpfjpZ3DOszd e7i4Ya8OCwh747wqlL+sYbRv65vRfoKrOj20+y1MgYkOM976HILd5JNgCpKVJ8B9iG +EMwocASPfApQ== Date: Tue, 13 Apr 2021 12:02:55 +0100 From: Mark Brown To: "Madhavan T. Venkataraman" Cc: Josh Poimboeuf , Mark Rutland , jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks Message-ID: <20210413110255.GB5586@sirena.org.uk> References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210409120859.GA51636@C02TD0UTHF1T.local> <20210409213741.kqmwyajoppuqrkge@treble> <20210412173617.GE5379@sirena.org.uk> MIME-Version: 1.0 In-Reply-To: X-Cookie: Shake well before using. User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210413_040317_661282_5DF55F94 X-CRM114-Status: GOOD ( 17.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6530406583332722320==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6530406583332722320== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote: >=20 > OK. Just so I am clear on the whole picture, let me state my understandin= g so far. > Correct me if I am wrong. > 1. We are hoping that we can convert a significant number of SYM_CODE fun= ctions to > SYM_FUNC functions by providing them with a proper FP prolog and epilo= g so that > we can get objtool coverage for them. These don't need any blacklistin= g. I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC. I'd expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's required to be non standard due to some external interface - things like the exception vectors, ftrace, and stuff around suspend/hibernate. A quick grep seems to confirm this. > 3. We are going to assume that the reliable unwinder is only for livepatc= h purposes > and will only be invoked on a task that is not currently running. The = task either The reliable unwinder can also be invoked on itself. > 4. So, the only functions that will need blacklisting are the remaining S= YM_CODE functions > that might give up the CPU voluntarily. At this point, I am not even s= ure how > many of these will exist. One hopes that all of these would have ended= up as > SYM_FUNC functions in (1). There's stuff like ret_from_fork there. > I suggest we do (3) first. Then, review the assembly functions to do (1).= Then, review the > remaining ones to see which ones must be blacklisted, if any. I'm not clear what the concrete steps you're planning to do first are there - your 3 seems like a statement of assumptions. For flagging functions I do think it'd be safer to default to assuming that all SYM_CODE functions can't be unwound reliably rather than only explicitly listing ones that cause problems. --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmB1el4ACgkQJNaLcl1U h9A3PQf/VI0TAe26+qZlWoT60AoRxJ3FU1apGj5nPlp8H9phWjbQEmnD6j5LHfPL 1VAxKkqe73NAB2/t6LdOfanOjqzJ+YnPkZvV1j6yJLsMnwpDTwUJxykpIPH5nkcj 2Tx3mGR72FnQv2ubUdFeO2Wi4LA7js2uAPZvlZkBMgekd8TMpgIHxTIbJszXIAR2 AQP3x+0EmuigidoaSxvnAtTKnBK3z+/pc95xtlQgGpXX/WdrCVmkiCJQ0iaq8b17 St7awxqETDC7/7AixyeIwzx9P9iM7J9CfdiqREFfEeJ++Zy4z7XYK+0dJbpImCc9 cG1nWivPtAK2O/6Ld0oVIk5HRUGtFg== =iS5y -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- --===============6530406583332722320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6530406583332722320==--