lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 19 Sep 2015 17:44:37 +0900 From: Jungseok Lee <jungseoklee85@...il.com> To: Catalin Marinas <catalin.marinas@....com> Cc: mark.rutland@....com, will.deacon@....com, linux-kernel@...r.kernel.org, takahiro.akashi@...aro.org, James Morse <james.morse@....com>, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH v2] arm64: Introduce IRQ stack On Sep 19, 2015, at 12:31 AM, Catalin Marinas wrote: > On Fri, Sep 18, 2015 at 04:03:02PM +0100, Catalin Marinas wrote: >> 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. > > Another thought (it seems that x86 does something similar): we know the > IRQ stack is not re-entered until interrupts are enabled in > __do_softirq. If we enable __ARCH_HAS_DO_SOFTIRQ, we can implement an > arm64-specific do_softirq_own_stack() which increments a counter before > calling __do_softirq. The difference from your patch is that > irq_stack_entry only reads such counter, doesn't need to write it. > > Yet another idea is to reserve some space in the lower address part of > the stack with a "stack type" information. It still requires another > read, so I think the x86 approach is probably better. I've realized both hardirq and softirq should be handled on a separate stack in order to reduce kernel stack size, which is a principal objective of this patch. (If I'm not missing something) It is not possible to get a big win with implementing do_softirq_own_stack() since hardirq is handled using a task stack. This prevents a size of kernel stack from being decreased. However, it would be meaningful to separate hard IRQ stack and soft IRQ one as the next step. Best Regards Jungseok Lee-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists