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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80157C41513 for ; Mon, 31 Jul 2023 21:47:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3F3C2800B0; Mon, 31 Jul 2023 17:47:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEFBC28007A; Mon, 31 Jul 2023 17:47:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D90342800B0; Mon, 31 Jul 2023 17:47:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C719028007A for ; Mon, 31 Jul 2023 17:47:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9E9DD1C9ADA for ; Mon, 31 Jul 2023 21:47:08 +0000 (UTC) X-FDA: 81073242936.08.ACE405A Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf24.hostedemail.com (Postfix) with ESMTP id D1716180017 for ; Mon, 31 Jul 2023 21:47:06 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=CztjLyfq; spf=none (imf24.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690840026; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vTIB+9jOZpp5OUrJxulSYIOZhA9Dpc6dGOGdH6SgMUw=; b=8lOFeWukdB84A2fAGXN0h0JDnmNf9nFqD9qnshziIhfBDZXTIWBRO2zC02hjZ9+0hRFLDL MKcCn9tdMiQgwjsH/hau8ZxWevr/KjcBsmoRRny1J9vVcbJlDpJ5DPiFt0zDHIh4Uhqx4d A35W3966jr+tn8nVLjaHlRxDpQyf9Cw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690840026; a=rsa-sha256; cv=none; b=Bq5AP/4V1SlknV1lCneXv+N0ra9BpKY20t/bJDuRKUFaLcVjNfHu9dPiqNXr/Tgt7/Jlla HcLe31ADgTvV/nXRXeLug9BJEkQZWIncxafyRLPgwtcQ6MNlZ+mTJjCmFH8gmGwEKiBCpv xaDQYpnMNwKUBBXO7RIH5ibiHbo7DRU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=CztjLyfq; spf=none (imf24.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=vTIB+9jOZpp5OUrJxulSYIOZhA9Dpc6dGOGdH6SgMUw=; b=CztjLyfqcdrFKznDsLQyVMumAI MN3Xna4qhxwpkV4FiIedm9yhrd8/l9X3R1rELIM6w6jiAUYNvsWeUNfNX0kRxnWuibkdN56xgYU3F WqI7lUf1lNSIxS51cJCvE4zW3pDRLHuMSlh2ESprJKMTkPFNV+FTAdXNCdTAMqBOQJeRw+5TDcwPk WLl4wnTsMUR97Exiyc0+o18OmIW+qTmQmfo7V4o+svym0ooDszJ6obRAKyK/Cz9rCAlkte3H+V4xv TjvBifgNXlOtGpzS09pMJuV8fsPGfHcZH+mMOCpPjhyJY51SrujtQrMqBzVhk2Ji3cQ0Vp4WSlYXg X1xkQqJQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qQaiV-00D67t-1f; Mon, 31 Jul 2023 21:46:15 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id A6C4E3002D9; Mon, 31 Jul 2023 23:46:12 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 7BAE620D70602; Mon, 31 Jul 2023 23:46:12 +0200 (CEST) Date: Mon, 31 Jul 2023 23:46:12 +0200 From: Peter Zijlstra To: Josh Poimboeuf Cc: Valentin Schneider , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, rcu@vger.kernel.org, linux-kselftest@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Yair Podemsky Subject: Re: [RFC PATCH v2 11/20] objtool: Flesh out warning related to pv_ops[] calls Message-ID: <20230731214612.GC51835@hirez.programming.kicks-ass.net> References: <20230720163056.2564824-1-vschneid@redhat.com> <20230720163056.2564824-12-vschneid@redhat.com> <20230728153334.myvh5sxppvjzd3oz@treble> <20230731213631.pywytiwdqgtgx4ps@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230731213631.pywytiwdqgtgx4ps@treble> X-Rspamd-Queue-Id: D1716180017 X-Rspam-User: X-Stat-Signature: y68szhe6fj3t8ixy1pdn5ksqtu8y1ees X-Rspamd-Server: rspam03 X-HE-Tag: 1690840026-950053 X-HE-Meta: U2FsdGVkX1/4noJtrOOM1fgiS2FujZihP3gfbs6udDEALC01kZwYUnBW7FS6j2CYmUBvCk1BgRX/mfZl8kytySRdc0CQ2k3yfPrsSJG61DzNUfYSd8wBfcAOhBx9ydrjR0WocK9U60kQIcOKsTgo67+MOFk2nNt7Ix3fJVt2KJPvzd3+1KKVbwE7vk8+I+kO44IHf3vXXfm7+pgYai6F/rxKlWvyTt7fybh9k7oLzRPuuYzcprGwXLA0Q0ZMkzFHtuURNeQZLeb1SI6Lr7n8DuAkatRgONyvwiciq68n+cRgjeXF6Ruid78QErKILNCjzg00CGC8iNtozhRiApT7sOUGGireZywzNA8XHXLlFavR6FNtQdHDMPpKMuspWT42y58YcqFIQajHWCrUEMobEPpqPO2YksXg41trf+9PZbFl45RIvOFmbs3/uTzCYhitTactz2vffAcA3A/dzwmfMve0cP8r8iS/OGcxPf/r2a50oAx85KRiWkfpPAvLlWXtJS7hG9/D5oopJypYfpNUZQjPPSSZ67XH9aEm2VG2ftHc21Xiw0lLxs20gInQ34ddiganBPdvR6eH6SPBsS5LyvAnOg4RfD4EpzUvhgrtsSFxgkmwAro6DLDWmfyVhjxHfA2r3tErrLZ4ob0BKBTHNMthsik3r67xVtpBIDcyPd/yZgxBZg/OaA1M0vUYub40azdrTA8h+W9WJnrZ/HCrPYSMFPdzIXiWJGipoRY8gjEwpRPAc3qOFYlSU5MQ93Xj6FzBcNXKBdCtKg3tKfwXC93cR+2mXVdi8ydO+W/gqjUtYx03TN2XYTkx0nIGEcjfYQt/sUa55M/oeFH++Xx9amiKtZ60Kin930JMJOpj1TYahMMHFYvaAB4Y6FFPSux9dmiw+ecPS+OsCb1v+6uaXyhVoQ8REL0bX3PVUItUUBvecC20G9ee6+w6gMrjw4iXYTocoR+DJmkgLxpyZiz sebf3fvd 8JxQ1QE0LePj0FO27ac1r0SuqLu/vHP2GA4fIUg1Rit9cHpOlx723l7cpn0dOAaTuGXXlEa9QGBWlOVrxNPbLbxmgfwrJdyHlHM8zXSQXW7HLPlHSdZzuazPei5QbGGSbNYAE8SdyRYX0peDRXF/usZrHQUfrMigoMPctU1IBW9GAHMdVl40v4LCa1G6NC3OTLtdsBc/X5FZlP93nG8sXPkb9LST/Cf84P5bCRBjC1ilZXDDf67hF2Hwf35RY2utKiFZx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jul 31, 2023 at 04:36:31PM -0500, Josh Poimboeuf wrote: > On Mon, Jul 31, 2023 at 12:16:59PM +0100, Valentin Schneider wrote: > > You're quite right - fabricating an artificial warning with a call to __flush_tlb_local(): > > > > vmlinux.o: warning: objtool: pv_ops[1]: indirect call to native_flush_tlb_local() leaves .noinstr.text section > > vmlinux.o: warning: objtool: __flush_tlb_all_noinstr+0x4: call to {dynamic}() leaves .noinstr.text section > > > > Interestingly the second one doesn't seem to have triggered the "pv_ops" > > bit of call_dest_name. Seems like any call to insn_reloc(NULL, x) will > > return NULL. > > Yeah, that's weird. > > > Trickling down the file yields: > > > > vmlinux.o: warning: objtool: pv_ops[1]: indirect call to native_flush_tlb_local() leaves .noinstr.text section > > vmlinux.o: warning: objtool: __flush_tlb_all_noinstr+0x4: call to pv_ops[0]() leaves .noinstr.text section > > > > In my case (!PARAVIRT_XXL) pv_ops should look like: > > [0]: .cpu.io_delay > > [1]: .mmu.flush_tlb_user() > > > > so pv_ops[1] looks right. Seems like pv_call_dest() gets it right because > > it uses arch_dest_reloc_offset(). > > > > If I use the above to fix up validate_call(), would we still need > > pv_call_dest() & co? > > The functionality in pv_call_dest() is still needed because it goes > through all the possible targets for the .mmu.flush_tlb_user() pointer > -- xen_flush_tlb() and native_flush_tlb_local() -- and makes sure > they're noinstr. > > Ideally it would only print a single warning for this case, something > like: > > vmlinux.o: warning: objtool: __flush_tlb_all_noinstr+0x4: indirect call to native_flush_tlb_local() leaves .noinstr.text section But then what for the case where there are multiple implementations and more than one isn't noinstr? IIRC that is where these double prints came from. One is the callsite (always one) and the second is the offending implementation (but there could be more). > I left out "pv_ops[1]" because it's already long enough :-) The index number is useful when also looking at the assembler, which IIRC is an indexed indirect call.