Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6275964yba; Tue, 14 May 2019 05:02:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwHi80OxjqpgthbBU73k1KtkGgQLrwKY8JflkU0x1Gg6YbatKcBBw4yyMFWUHTy1UAg8V5t X-Received: by 2002:a63:2cc9:: with SMTP id s192mr37968020pgs.24.1557835364609; Tue, 14 May 2019 05:02:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557835364; cv=none; d=google.com; s=arc-20160816; b=AY+nd1FPvKnLwnLwDU3zYcSJhdcnzdy+3H5TluZINtLxh6UC8pwcxwvF+PTu0GFDiH A6iKtL6gVUk8TNIeFrteylgOhEN0IbBrYTKx2l5PahhKiEuyuqZSps5JyahOQg6Dvkws U0Ptj49oi1RZgQoY7Q+iFr0ZMqTNIqakfglrEjdEEruse9gjinQL4iRkE502kfH1PE25 QOTcJy9+8vLYUJ8C3/TKua3mVXVoF0femqJIvKz/UQvCsEcF7b/lvCIu8N9E+cfalzgl vVwiLglc9fyx31bIY2TrYRqwIyzbSihoWkBlwnwt4KDf5sepLXHN3c4FgLyM5mL0ONdi nCbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hT1DPkHevGJyfowU9zjawBEuTt3fb/88TFq9tInbpck=; b=jJDH4MVoDQ9IHOrRhxjaYHEPIX7UFP4SExwsogNfKsejwbC1GcThSTl3MgVgqK6nq9 j7jtopy5LJOsQyqNqP9XpAL/Nqmi9lykGGvt6r25XTdldc/H8TCzPP/uvB2fwl242LOy nTUBegFRohb2CaQm+FjEPdTYkEInge7XuXd7fusdhykPvg9jmkegwmoVmVIQXa85DNE7 1ZmIPC5612yL1p6737oi8524lC7ezyETgN/5tNwZhyh2tKW90mSOU/HyfGB+TvOAWFdC Iavo8Ep82JaPRSOXxzmjyle8SlOuNdzyfYLuWmKAFn2TYKeaH6iRJey3//i+0wMU0qEo m1sA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bh2si20362559plb.430.2019.05.14.05.02.26; Tue, 14 May 2019 05:02:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726290AbfENMBT (ORCPT + 99 others); Tue, 14 May 2019 08:01:19 -0400 Received: from foss.arm.com ([217.140.101.70]:54622 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbfENMBT (ORCPT ); Tue, 14 May 2019 08:01:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 812F1341; Tue, 14 May 2019 05:01:18 -0700 (PDT) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0F0373F71E; Tue, 14 May 2019 05:01:15 -0700 (PDT) Subject: Re: [PATCH v2 3/5] arm64: Fix incorrect irqflag restore for priority masking To: Julien Thierry , Marc Zyngier , linux-arm-kernel@lists.infradead.org Cc: mark.rutland@arm.com, Suzuki K Pouloze , catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, Christoffer Dall , james.morse@arm.com, Oleg Nesterov , yuzenghui@huawei.com, wanghaibin.wang@huawei.com, liwei391@huawei.com References: <1556553607-46531-1-git-send-email-julien.thierry@arm.com> <1556553607-46531-4-git-send-email-julien.thierry@arm.com> <2b023ba4-b95b-f823-4635-6a75deef5386@arm.com> <1739c8ac-9073-798f-ed0b-0dc617c195d6@arm.com> From: Robin Murphy Message-ID: <5e8a85f5-c837-3ce8-5830-f3ae7897e326@arm.com> Date: Tue, 14 May 2019 13:01:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1739c8ac-9073-798f-ed0b-0dc617c195d6@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/05/2019 10:25, Julien Thierry wrote: [...] >>> +static inline int arch_irqs_disabled_flags(unsigned long flags) >>> +{ >>> + int res; >>> + >>> + asm volatile(ALTERNATIVE( >>> + "and %w0, %w1, #" __stringify(PSR_I_BIT) "\n" >>> + "nop", >>> + "cmp %w1, #" __stringify(GIC_PRIO_IRQON) "\n" >>> + "cset %w0, ne", >>> + ARM64_HAS_IRQ_PRIO_MASKING) >>> + : "=&r" (res) >>> + : "r" ((int) flags) >>> + : "memory"); >> >> I wonder if this should have "cc" as part of the clobber list. > > Is there any special semantic to "cc" on arm64? All I can find is that > in the general case it indicates that it is modifying the "flags" register. > > Is your suggestion only for the PMR case? Or is it something that we > should add regardless of PMR? > The latter makes sense to me, but for the former, I fail to understand > why this should affect only PMR. The PMR case really ought to have have a cc clobber, because who knows what this may end up inlined into, and compilers can get pretty aggressive with instruction scheduling in ways which leave a live value in CPSR across sizeable chunks of other code. It's true that the non-PMR case doesn't need it, but the surrounding code still needs to be generated to accommodate both possible versions of the alternative. From the look of the rest of the patch, the existing pseudo-NMI code has this bug in a few places. Technically you could omit it when ARM64_PSEUDO_NMI is configured out entirely, but at that point you may as well omit the whole alternative as well. It's probably not worth the bother unless it proves to have a significant impact on codegen overall. On which note the memory clobber also seems superfluous either way :/ That said, now that I've been looking at it for this long, if the aim is just to create a zero/nonzero value then couldn't the PMR case just be "eor %w0, %w1, #GIC_PRIO_IRQON" and avoid the need for clobbers at all? Robin.