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=-15.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 C248AC4743D for ; Fri, 4 Jun 2021 20:38:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A4436613B4 for ; Fri, 4 Jun 2021 20:38:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231320AbhFDUkk (ORCPT ); Fri, 4 Jun 2021 16:40:40 -0400 Received: from linux.microsoft.com ([13.77.154.182]:43114 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229913AbhFDUkj (ORCPT ); Fri, 4 Jun 2021 16:40:39 -0400 Received: from [192.168.254.32] (unknown [47.187.214.213]) by linux.microsoft.com (Postfix) with ESMTPSA id 804C320B7178; Fri, 4 Jun 2021 13:38:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 804C320B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1622839132; bh=/45hWiDZcsHWctcr5hRZBQDWDhCLQeyVYjjw+Z2h/ao=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SOCXYevWE8GoQHgMS+3odsSucYuupPTeMrZQ3CPj2riFz+5QZ3Kla+sx5bOFcjDvR xQUrOnf+PaeR9D1GheUMoWk0//YkB6TQZAbCBpNS4ghgjHk5IvJDBpt9wuCDUkWGX9 M8JNMo4Cg8f/VoC+ib2xNR0kSPLQwvlUcJ/rsp5w= Subject: Re: [RFC PATCH v5 2/2] arm64: Create a list of SYM_CODE functions, check return PC against list To: Mark Brown Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210526214917.20099-3-madvenka@linux.microsoft.com> <20210604162415.GF4045@sirena.org.uk> From: "Madhavan T. Venkataraman" Message-ID: <903c61d7-5717-c9df-29c5-4f162f84e84c@linux.microsoft.com> Date: Fri, 4 Jun 2021 15:38:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210604162415.GF4045@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/4/21 11:24 AM, Mark Brown wrote: > On Wed, May 26, 2021 at 04:49:17PM -0500, madvenka@linux.microsoft.com wrote: > >> The unwinder should check if the return PC falls in any function that >> is considered unreliable from an unwinding perspective. If it does, >> mark the stack trace unreliable. > > Reviwed-by: Mark Brown > Thanks. > However it'd be good for someone else to double check this as it's > entirely possible that I've missed some case here. > I will request Mark Rutland to review this as well. >> + * Some special cases covered by sym_code_functions[] deserve a mention here: > >> + * - All EL1 interrupt and exception stack traces will be considered >> + * unreliable. This is the correct behavior as interrupts and exceptions >> + * can happen on any instruction including ones in the frame pointer >> + * prolog and epilog. Unless stack metadata is available so the unwinder >> + * can unwind through these special cases, such stack traces will be >> + * considered unreliable. >> + * > > If you're respinning this it's probably also worth noting that we only > ever perform reliable stack trace on either blocked tasks or the current > task which should if my reasoning is correct mean that the fact that > the exclusions here mean that we avoid having to worry about so many > race conditions when entering and leaving functions. If we got > preempted at the wrong moment for one of them then we should observe the > preemption and mark the trace as unreliable due to that which means that > any confusion the race causes is a non-issue. > I will add a comment that "livepatch only looks at tasks that are currently not on any CPU (except for the current task). Such tasks either blocked on something and gave up the CPU voluntarily. Or, they were preempted. The above comment applies to the latter case". Madhavan 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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 8FC0CC4743C for ; Fri, 4 Jun 2021 20:40:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 56041613F9 for ; Fri, 4 Jun 2021 20:40:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56041613F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=IrBaXtwQjOXYSuBXkakidzz7peIA1R4H46yNlyug3Ng=; b=OSPcOvZcCbZlcsUo5/rr8QZTrV BQOJ/EnEca+3jlIxvCuyirEijY/vXMXf+beWEa+t844HxoY7ttKT1DH2T5S0w+bNgCGvT5OSIC3oU mxYgj76fbkb8cWJo3/+K3PG/iWJo3Uwmbn/N+Zh0e/5XJ8ErgRww8knTkRUMtwUfj6jFrc0dvRMmW gWlovzm+zphwCqyRsSupuvJpKxx/31KJoGL9fh/QoXV6sJ7yxt8GmKa/AaGXbtuMvjFkJCkHZakfT 31CM9ra8HJ395I6SSHzuvUT0gge3KylXFQOquj1W0DLT5HjR35POaUVpUHK4dnwcIFnvvullM6192 PZxYfnCA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lpGan-00F8JJ-Py; Fri, 04 Jun 2021 20:38:57 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lpGak-00F8Id-1F for linux-arm-kernel@lists.infradead.org; Fri, 04 Jun 2021 20:38:55 +0000 Received: from [192.168.254.32] (unknown [47.187.214.213]) by linux.microsoft.com (Postfix) with ESMTPSA id 804C320B7178; Fri, 4 Jun 2021 13:38:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 804C320B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1622839132; bh=/45hWiDZcsHWctcr5hRZBQDWDhCLQeyVYjjw+Z2h/ao=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SOCXYevWE8GoQHgMS+3odsSucYuupPTeMrZQ3CPj2riFz+5QZ3Kla+sx5bOFcjDvR xQUrOnf+PaeR9D1GheUMoWk0//YkB6TQZAbCBpNS4ghgjHk5IvJDBpt9wuCDUkWGX9 M8JNMo4Cg8f/VoC+ib2xNR0kSPLQwvlUcJ/rsp5w= Subject: Re: [RFC PATCH v5 2/2] arm64: Create a list of SYM_CODE functions, check return PC against list To: Mark Brown Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210526214917.20099-3-madvenka@linux.microsoft.com> <20210604162415.GF4045@sirena.org.uk> From: "Madhavan T. Venkataraman" Message-ID: <903c61d7-5717-c9df-29c5-4f162f84e84c@linux.microsoft.com> Date: Fri, 4 Jun 2021 15:38:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210604162415.GF4045@sirena.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210604_133854_142209_A09EEA50 X-CRM114-Status: GOOD ( 21.00 ) 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: 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 6/4/21 11:24 AM, Mark Brown wrote: > On Wed, May 26, 2021 at 04:49:17PM -0500, madvenka@linux.microsoft.com wrote: > >> The unwinder should check if the return PC falls in any function that >> is considered unreliable from an unwinding perspective. If it does, >> mark the stack trace unreliable. > > Reviwed-by: Mark Brown > Thanks. > However it'd be good for someone else to double check this as it's > entirely possible that I've missed some case here. > I will request Mark Rutland to review this as well. >> + * Some special cases covered by sym_code_functions[] deserve a mention here: > >> + * - All EL1 interrupt and exception stack traces will be considered >> + * unreliable. This is the correct behavior as interrupts and exceptions >> + * can happen on any instruction including ones in the frame pointer >> + * prolog and epilog. Unless stack metadata is available so the unwinder >> + * can unwind through these special cases, such stack traces will be >> + * considered unreliable. >> + * > > If you're respinning this it's probably also worth noting that we only > ever perform reliable stack trace on either blocked tasks or the current > task which should if my reasoning is correct mean that the fact that > the exclusions here mean that we avoid having to worry about so many > race conditions when entering and leaving functions. If we got > preempted at the wrong moment for one of them then we should observe the > preemption and mark the trace as unreliable due to that which means that > any confusion the race causes is a non-issue. > I will add a comment that "livepatch only looks at tasks that are currently not on any CPU (except for the current task). Such tasks either blocked on something and gave up the CPU voluntarily. Or, they were preempted. The above comment applies to the latter case". Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel