From: Julien Thierry <julien.thierry@arm.com>
To: Robin Murphy <robin.murphy@arm.com>,
Marc Zyngier <marc.zyngier@arm.com>,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, Suzuki K Pouloze <suzuki.poulose@arm.com>,
catalin.marinas@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, rostedt@goodmis.org,
Christoffer Dall <christoffer.dall@arm.com>,
james.morse@arm.com, Oleg Nesterov <oleg@redhat.com>,
yuzenghui@huawei.com, wanghaibin.wang@huawei.com,
liwei391@huawei.com
Subject: Re: [PATCH v2 3/5] arm64: Fix incorrect irqflag restore for priority masking
Date: Tue, 14 May 2019 14:08:55 +0100 [thread overview]
Message-ID: <0a0dfd57-af99-f603-a56f-ee05f5c7b98a@arm.com> (raw)
In-Reply-To: <5e8a85f5-c837-3ce8-5830-f3ae7897e326@arm.com>
On 14/05/2019 13:01, Robin Murphy wrote:
> 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 :/
>
Right, I see. I misunderstood what was meant by "cc" indicating that the
assembly modified the flags.
Due to the context I interpreted it as irqflags whereas it concerns the
condition flags (hence the 'c' I presume...). It all makes more sense now.
> 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?
>
Yes, definitely seems like it would be better! I'll take that
suggestion, thanks.
Cheers,
--
Julien Thierry
next prev parent reply other threads:[~2019-05-14 13:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 16:00 [PATCH v2 0/5] arm64: IRQ priority masking and Pseudo-NMI fixes Julien Thierry
2019-04-29 16:00 ` [PATCH v2 1/5] arm64: Do not enable IRQs for ct_user_exit Julien Thierry
2019-04-29 16:00 ` [PATCH v2 2/5] arm64: Fix interrupt tracing in the presence of NMIs Julien Thierry
2019-04-29 16:00 ` [PATCH v2 3/5] arm64: Fix incorrect irqflag restore for priority masking Julien Thierry
2019-05-07 8:36 ` Marc Zyngier
2019-05-14 9:25 ` Julien Thierry
2019-05-14 12:01 ` Robin Murphy
2019-05-14 13:08 ` Julien Thierry [this message]
2019-04-29 16:00 ` [PATCH v2 4/5] arm64: irqflags: Introduce explicit debugging for IRQ priorities Julien Thierry
2019-05-07 8:44 ` Marc Zyngier
2019-05-16 13:43 ` Julien Thierry
2019-04-29 16:00 ` [PATCH v2 5/5] arm64: fix kernel stack overflow in kdump capture kernel Julien Thierry
2019-05-23 16:51 ` [PATCH v2 0/5] arm64: IRQ priority masking and Pseudo-NMI fixes Will Deacon
2019-06-05 16:07 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0a0dfd57-af99-f603-a56f-ee05f5c7b98a@arm.com \
--to=julien.thierry@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liwei391@huawei.com \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=oleg@redhat.com \
--cc=robin.murphy@arm.com \
--cc=rostedt@goodmis.org \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=will.deacon@arm.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®