Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp617250pxb; Tue, 9 Feb 2021 08:26:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3lTRDvTOUhQksw5IBfgumWTiiV1n5Hq9CVS/eGCSjlPydAlhJ/bHI6YVeSrlhvM0nzr/x X-Received: by 2002:a17:906:804a:: with SMTP id x10mr23089566ejw.184.1612887974914; Tue, 09 Feb 2021 08:26:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612887974; cv=none; d=google.com; s=arc-20160816; b=VdcCn5fM46CZiw2WmZ5C2j74UqjypySc6Y48iZIxuzXpgpaqBD92l+vhzbao8J8aC7 AO1RoS/q05ilZMkd/SxhKaWD0vj82YmhtEEgeWEd4PG7VhJTSmXAEeRJR6iaF6q7owHY avA/DhI8RsWJYPU1oFXuA3jAmfgiHP7UlKEgGFBLbiAGfk2iSCSTo7vdNcMJ9TidYpWO D4w2EVSDifZ2sVMcM5RIPXILNdwp6t8of+5gYJCgdgHdelyy0Su4G3wGtd+IURqq8kaw P6p4adoYBFXtABHIhSMSAYjllBa6Fj8yDlbb1Pu5Fbiag45KIpezVMW524fMTKtohV71 hRvg== 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=Fnqy1YnymfhhTNjzdgV1GtWpdANUOkHB0zW274Bne5A=; b=f1ohjggoqOtYu0zpI9LIzoeqVTsu6hS7TIBQ+/PDSi5UDwGNP67+b+VheheMgwr4EY 5+bRUhl95THhJ09EbRu8NUYDlcZ/U2/ou06FSVnIVBPU8nAAc3WmOKOrQo286ni9NE1f 4/YJvgI2qpDNxJALckuCJmEz6NRJRl+kCT14RhIBKZrIL4wolRt7Fl6BIagjOKaMoTJY A2OfSbwtvgPE4sPASE4EdsveTDX/7lXLd+wzUmW8S6pGZDjZGTlsP2s7gdz+kpHY1COP ntCpmCj4gjHi3WFElofJo58uouj6jztMwBNrb/R8YWqAPVE8uXUZyFcaGPhonugsmWz3 pKzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DUi1BLvZ; 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 lu24si13503777ejb.42.2021.02.09.08.25.40; Tue, 09 Feb 2021 08:26:14 -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=DUi1BLvZ; 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 S232637AbhBIQXs (ORCPT + 99 others); Tue, 9 Feb 2021 11:23:48 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:48264 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231520AbhBIQXq (ORCPT ); Tue, 9 Feb 2021 11:23:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612887740; 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=Fnqy1YnymfhhTNjzdgV1GtWpdANUOkHB0zW274Bne5A=; b=DUi1BLvZTDEsWtLWd4yI91y/NJ32bkoiaDK3jlYDSiDuiCzFNpmyj4Fbsv6z6VAwjF2HjK FZcRb4ULUlhOTsYRNJJQ/hAyz+LptnEiyjCphniUvZ88pVYpjl1BtWz/dXPBJdgJdRmes3 TtQ3AWQq4NHdNgXwh/h5ioi85Mj+M+0= 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-437-7ZuLcs4WOtyZC-GWEToQFA-1; Tue, 09 Feb 2021 11:22:18 -0500 X-MC-Unique: 7ZuLcs4WOtyZC-GWEToQFA-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 E0693835E22; Tue, 9 Feb 2021 16:22:16 +0000 (UTC) Received: from treble (ovpn-120-169.rdu2.redhat.com [10.10.120.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4580460861; Tue, 9 Feb 2021 16:22:16 +0000 (UTC) Date: Tue, 9 Feb 2021 10:22:14 -0600 From: Josh Poimboeuf To: Thomas Gleixner Cc: LKML , x86@kernel.org, Kees Cook Subject: Re: [patch 05/12] x86/irq: Provide macro for inlining irq stack switching Message-ID: <20210209162214.twr35rrb2qwvlx3f@treble> References: <20210204204903.350275743@linutronix.de> <20210204211154.618389756@linutronix.de> <20210208204209.yccd76j7sp2zbv37@treble> <87zh0db7ha.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zh0db7ha.fsf@nanos.tec.linutronix.de> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 09, 2021 at 04:12:33PM +0100, Thomas Gleixner wrote: > On Mon, Feb 08 2021 at 14:42, Josh Poimboeuf wrote: > > On Thu, Feb 04, 2021 at 09:49:08PM +0100, Thomas Gleixner wrote: > >> #ifdef CONFIG_X86_64 > >> + > >> +#ifdef CONFIG_UNWINDER_FRAME_POINTER > >> +# define IRQSTACK_CALL_CONSTRAINT , ASM_CALL_CONSTRAINT > >> +#else > >> +# define IRQSTACK_CALL_CONSTRAINT > >> +#endif > > > > Is this really needed? i.e. does ASM_CALL_CONSTRAINT actually affect > > code generation with !FRAME_POINTER? > > The problem is that if the asm inline is the first operation in a > function some compilers insert the asm inline before setting up the > frame pointer. > > That's actualy irrelevant here as the compiler cannot reorder against > the C code leading to the asm inline. So we can probably replace it with > a big fat comment. Actually, I think keeping ASM_CALL_CONSTRAINT is a good idea. What I meant was, is the #ifdef needed? My previous understanding was that ASM_CALL_CONSTRAINT has no effect for !FRAME_POINTER (i.e., ORC). So is there any reason to *not* have ASM_CALL_CONSTRAINT with ORC? -- Josh