Re: [PATCH v2] arm64: Introduce IRQ stack

From: Catalin Marinas <catalin.marinas@arm.com>
To: Jungseok Lee <jungseoklee85@gmail.com>
Cc: mark.rutland@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, takahiro.akashi@linaro.org,
	James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm64: Introduce IRQ stack
Date: Fri, 18 Sep 2015 16:03:02 +0100	[thread overview]
Message-ID: <20150918150302.GA24449@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <6A6F7BF2-D75E-4D8D-B0F7-45294C4C4426@gmail.com>

On Fri, Sep 18, 2015 at 09:57:56PM +0900, Jungseok Lee wrote:
> On Sep 18, 2015, at 1:21 AM, Catalin Marinas wrote:
> > So, without any better suggestion for current_thread_info(), I'm giving
> > up the idea of using SPSel == 0 in the kernel. I'll look at your patch
> > in more detail. BTW, I don't think we need the any count for the irq
> > stack as we don't re-enter the same IRQ stack.
> 
> Another interrupt could come in since IRQ is enabled when handling softirq
> according to the following information which are self-evident.
> 
> (Am I missing something?)

No. I had the wrong impression that we switch to the softirqd stack for
softirqs but you are right, if we run them on the same stack the IRQs
are enabled and they can be re-entered before we return from this
exception handler.

I've seen other architectures implementing a dedicated softirq stack but
for now we should just re-use the current IRQ stack.

> In my first approach using SPSel = 0, current_thread_info function was inefficient
> in order to handle this case correctly.

I agree. And we don't have any other scratch register left as we use
tpidr_el1 for per-cpu areas.

> BTW, in this context, it is only meaningful to decide whether a current interrupt
> is re-enterrant or not. Its actual value is not important, but I could not figure
> out a better implementation than this one yet. Any suggestions are welcome!

James' idea of checking the lower SP bits instead of a count may work.

-- 
Catalin