From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73ACA56451 for ; Thu, 21 Mar 2024 10:23:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.58.85.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711016586; cv=none; b=NfD2KYcdNRS53IJLCwNlOUA5qRQK3a96gFWqhhWN6kJNWTo1gO7JDuoOe1D5Z5Y1ceaE56hW9zEWPZG6VpXXwNE0nsLD07JPKsm/Bu3yCFnPpsb6Cynmy/YCHxEuhkoQE939suK9ep4p/k5JnZYMosn95l65hTRra0g0iK8KjCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711016586; c=relaxed/simple; bh=5JPCZ+qBJS79Nz0MHkbWXC6seLKtP4tznYnQqpZf1HQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: MIME-Version:Content-Type; b=O8EbWDAcX7/VoDPD3yoXJkTQ7ouE+3TQz2jdKzulknCAELsRISR7YEQBj/sWOYsPDNMkzXBR9gCA8H90fcpa1G8sY7P0YuUNZ+qbnTeMDlln6yEZEv3++aIbqLnoI6X0+SO1ienoWohIdUhFUlmNkGqgYZZTAfKcyQpatKjcDpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM; spf=pass smtp.mailfrom=aculab.com; arc=none smtp.client-ip=185.58.85.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aculab.com Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-212-p3JOoYAWPBWRUG8sgCg1aA-1; Thu, 21 Mar 2024 10:22:55 +0000 X-MC-Unique: p3JOoYAWPBWRUG8sgCg1aA-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 21 Mar 2024 10:22:30 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Thu, 21 Mar 2024 10:22:30 +0000 From: David Laight To: 'Jiangfeng Xiao' , "Russell King (Oracle)" CC: "arnd@arndb.de" , "keescook@chromium.org" , "haibo.li@mediatek.com" , "angelogioacchino.delregno@collabora.com" , "amergnat@baylibre.com" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "douzhaolei@huawei.com" , "gustavoars@kernel.org" , "jpoimboe@kernel.org" , "kepler.chenxin@huawei.com" , "kirill.shutemov@linux.intel.com" , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "nixiaoming@huawei.com" , "peterz@infradead.org" , "wangbing6@huawei.com" , "wangfangpeng1@huawei.com" , "jannh@google.com" , "willy@infradead.org" Subject: RE: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Topic: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Index: AQHae3ROEuI+AaCprEesIWGaAOB7ebFB9uHA Date: Thu, 21 Mar 2024 10:22:30 +0000 Message-ID: References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Precedence: bulk X-Mailing-List: linux-hardening@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How aggressively does the compiler optimise 'noreturn' functions? Consider: void f(...) { =09... =09if () { =09=09... =09=09noreturn(...); =09} } Without the noreturn() call it is a leaf function. So the compiler doesn't need to save 'lr' on stack (or the save could be deferred to inside the conditional). Since noreturn() doesn't return it can be jumped to. Additionally 'lr' can be used as a scratch register prior to the noreturn() call. So it is likely that inside noreturn() (and anything it might call) you don't have a valid 'lr' chain at all. No amount of picking between 'pc' and 'pc-1' is going to fix that. The only way you can find a return address is by searching the stack and hoping to find something that works. So you need the compiler to 'not believe' the 'noreturn' attribute. Setup a normal call frame and put a faulting instruction after the call in case it returns. That would give you half a chance of generating a backtrace. Without that I suspect you are playing whack-a-mole. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 33839C54E68 for ; Thu, 21 Mar 2024 10:23:35 +0000 (UTC) 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:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3tAkwURudcWIoDBepiKsGojRX1hF28pU+kJ7bm96/sM=; b=FFH3g96yYxMbV+ 8jJcKvCD1l9VD5zIAyNzdltthsGoVucADpB9ht3kCLG+593VT02ZFstnpkKGe8H2znjGqAslMHyqK Rm7bFpIAKDTsCdoy+AJEMQzxFXPHmsxRugeWpf6nuXDoWY58cOxaOc0Z/lDjKnFKuqY5zBK1xHA8V oKoAomKQgPqrU/SXaUOHzb9C9fR0SWujZLIGSNbZ7nC0XYEOSkogAAj3PryNzhti/VfvQp9j4dUxa uIDJWoPHCCNZ0285Itf8dG5u6iM9HBU2i32S/GWbWIkHO/9T0YN5P3YgygrnigLMBsysr9T8sUSYb 0cNt6UTSoY6tYfn3Wy4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnFZt-00000002cqo-0dqh; Thu, 21 Mar 2024 10:23:17 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.85.151]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnFZl-00000002cmo-3u4a for linux-arm-kernel@lists.infradead.org; Thu, 21 Mar 2024 10:23:14 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-212-p3JOoYAWPBWRUG8sgCg1aA-1; Thu, 21 Mar 2024 10:22:55 +0000 X-MC-Unique: p3JOoYAWPBWRUG8sgCg1aA-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Thu, 21 Mar 2024 10:22:30 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Thu, 21 Mar 2024 10:22:30 +0000 From: David Laight To: 'Jiangfeng Xiao' , "Russell King (Oracle)" CC: "arnd@arndb.de" , "keescook@chromium.org" , "haibo.li@mediatek.com" , "angelogioacchino.delregno@collabora.com" , "amergnat@baylibre.com" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "douzhaolei@huawei.com" , "gustavoars@kernel.org" , "jpoimboe@kernel.org" , "kepler.chenxin@huawei.com" , "kirill.shutemov@linux.intel.com" , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "nixiaoming@huawei.com" , "peterz@infradead.org" , "wangbing6@huawei.com" , "wangfangpeng1@huawei.com" , "jannh@google.com" , "willy@infradead.org" Subject: RE: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Topic: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Thread-Index: AQHae3ROEuI+AaCprEesIWGaAOB7ebFB9uHA Date: Thu, 21 Mar 2024 10:22:30 +0000 Message-ID: References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240321_032310_313798_1E5F21BF X-CRM114-Status: UNSURE ( 9.40 ) X-CRM114-Notice: Please train this message. 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 How aggressively does the compiler optimise 'noreturn' functions? Consider: void f(...) { ... if () { ... noreturn(...); } } Without the noreturn() call it is a leaf function. So the compiler doesn't need to save 'lr' on stack (or the save could be deferred to inside the conditional). Since noreturn() doesn't return it can be jumped to. Additionally 'lr' can be used as a scratch register prior to the noreturn() call. So it is likely that inside noreturn() (and anything it might call) you don't have a valid 'lr' chain at all. No amount of picking between 'pc' and 'pc-1' is going to fix that. The only way you can find a return address is by searching the stack and hoping to find something that works. So you need the compiler to 'not believe' the 'noreturn' attribute. Setup a normal call frame and put a faulting instruction after the call in case it returns. That would give you half a chance of generating a backtrace. Without that I suspect you are playing whack-a-mole. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel