Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp615506pxb; Wed, 24 Feb 2021 10:15:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJwl2Znp4jc9iHpeJ2YmpuLcGIFWTfEaSo3dgP4eNCn3mq3CDBXzD0ZSqwH2nomEXx6MSF+I X-Received: by 2002:a05:6402:890:: with SMTP id e16mr17070426edy.335.1614190511620; Wed, 24 Feb 2021 10:15:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614190511; cv=none; d=google.com; s=arc-20160816; b=P8cxDfiqsm3+qc6UBphU3SgLQ4LcvjYGKjwimVwBEHyFUgrYfc+hGaZ8Lh0dQbAyVG +TCYggYO7t5krQHpvTqtaKP6boM7u583uFktAo8HkieulylXzt91H9NqGgPo83Vdinxc GDJsqiWqjiYO1rUsjB8/3J16HBX47zcBfHfTsUu+HCISl4osVwIyGLngTwMfOn+41gbS /bKhjECUVQXhtS4W+kLVaqr1fwFhNcSnDWp3zqwC6kwfvwsSnm3boSFjWVKvborxDXMY B19hVRJMzCy1O0/7pLM3vJaHz18SjkHfb39KSiAGGebhuoA63GQXzQA0hzIpTl+9DKOS IOFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=7Q3FXi0hQvn8pTwg2Nl9y14ZmyNsebtglhIHEb4N6mQ=; b=LyycCjCQy8E7Q6JC7pj6ynAbT5f8XPRDkbdhpdGrli0nBGM/yDnobMSURN6/d7jikL 1WSxPzRmUZ/RWdQG6oIOgZjS+6nTyun+nomSyMQZgrxn3nbZq5SddGl/L4l6t7F4NExu fgox806Gl2tFouXLKqsKzLJ+8BmK9xDn9N+rdyAXIcaJMz70HzqeDJfsbsrhUr33PfNf xcVB/E5Q1mTUfkDrPaMVXNLpgDBQvgj1HHS9bPXmrPGKtS+hSCBMh4lyUdHfyWG5aEZ+ GwjemsjEgcphuuzh6niYYIrEvgQ5l5vdMvVewqdIXeGrZmzLhnbRzxf0pMylEMbU3mOb 5A1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cJbQZELY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si1753623ejt.322.2021.02.24.10.14.47; Wed, 24 Feb 2021 10:15:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cJbQZELY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234215AbhBXSON (ORCPT + 99 others); Wed, 24 Feb 2021 13:14:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:42092 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233912AbhBXSOI (ORCPT ); Wed, 24 Feb 2021 13:14:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614190361; 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=7Q3FXi0hQvn8pTwg2Nl9y14ZmyNsebtglhIHEb4N6mQ=; b=cJbQZELYjOgHtw5wjMO/0Cd38HWal+RWCSFB/+zcxl2tIHbvHHPPAi4l2c3o/BTWaLM/Jw vE3QQ/WoWeSqcV464yBIUPXcWnhSlnXssO62slWz1GKqvNBhALzqoroK4/kvALeoaJ1FIv SHcmYGX+Pczt2G6WCqZM5JiYQCP96BQ= 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-231-dZT2pBPqNbiXRp00Wlpx2Q-1; Wed, 24 Feb 2021 13:12:37 -0500 X-MC-Unique: dZT2pBPqNbiXRp00Wlpx2Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 53ADEC7401; Wed, 24 Feb 2021 18:12:36 +0000 (UTC) Received: from treble (ovpn-118-134.rdu2.redhat.com [10.10.118.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 93B6750DE6; Wed, 24 Feb 2021 18:12:35 +0000 (UTC) Date: Wed, 24 Feb 2021 12:12:33 -0600 From: Josh Poimboeuf To: Peter Zijlstra Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Ivan Babrou , Steven Rostedt Subject: Re: [PATCH 2/2] x86/unwind/orc: Silence warnings caused by missing ORC data Message-ID: <20210224181233.f5q2scq43e2j372j@treble> References: <06d02c4bbb220bd31668db579278b0352538efbb.1612534649.git.jpoimboe@redhat.com> <20210224151805.zrujocamlb5pxf7m@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 24, 2021 at 07:07:31PM +0100, Peter Zijlstra wrote: > On Wed, Feb 24, 2021 at 09:18:05AM -0600, Josh Poimboeuf wrote: > > On Wed, Feb 24, 2021 at 03:52:01PM +0100, Peter Zijlstra wrote: > > > On Fri, Feb 05, 2021 at 08:24:03AM -0600, Josh Poimboeuf wrote: > > > > The ORC unwinder attempts to fall back to frame pointers when ORC data > > > > is missing for a given instruction. It sets state->error, but then > > > > tries to keep going as a best-effort type of thing. That may result in > > > > further warnings if the unwinder gets lost. > > > > > > > > Until we have some way to register generated code with the unwinder, > > > > missing ORC will be expected, and occasionally going off the rails will > > > > also be expected. So don't warn about it. > > > > > > I recently ran into another variant of missing ORC data, some files are > > > simply not processed by objtool, eg. arch/x86/realmode/init.c. Would it > > > make sense to have the vmlinux pass (when it isn't used to generate orc > > > in the first place) also check that all code it finds has ORC data? > > > > > > It's not fool proof, but it should help find files we're missing for > > > some raisin. > > > > Doesn't validate_reachable_instructions() basically already do that? > > Nope, I'm talking about the case where we generate ORC for each .o file > (and 'forget' to run objtool on some of them). And then run objtool > again on vmlinux to validate (things like noinstr). > > At that point it might make sense to also check that all code does > indeed have an ORC to double check our initial (per translation unit) > invocation didn't accidentally miss someone. What I meant was, validate_reachable_instructions() should already be able to report that situation, if it were called on vmlinux. Right now I think noinstr avoids calling it. I'm already working on some vmlinux rework which will enable that checking. Then we'll have to go through the unreachable warnings and try to fix them. -- Josh