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
| ||
|
Message-ID: <YU9Cy9kTew4ySeGZ@piliu.users.ipa.redhat.com> Date: Sat, 25 Sep 2021 23:39:55 +0800 From: Pingfan Liu <kernelfans@...il.com> To: Mark Rutland <mark.rutland@....com> Cc: linux-arm-kernel@...ts.infradead.org, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>, Joey Gouly <joey.gouly@....com>, Sami Tolvanen <samitolvanen@...gle.com>, Julien Thierry <julien.thierry@....com>, Thomas Gleixner <tglx@...utronix.de>, Yuichi Ito <ito-yuichi@...itsu.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCHv2 1/5] arm64/entry-common: push the judgement of nmi ahead On Fri, Sep 24, 2021 at 06:53:06PM +0100, Mark Rutland wrote: > On Fri, Sep 24, 2021 at 09:28:33PM +0800, Pingfan Liu wrote: > > In enter_el1_irq_or_nmi(), it can be the case which NMI interrupts an > > irq, which makes the condition !interrupts_enabled(regs) fail to detect > > the NMI. This will cause a mistaken account for irq. > Sorry about the confusing word "account", it should be "lockdep/rcu/.." > Can you please explain this in more detail? It's not clear which > specific case you mean when you say "NMI interrupts an irq", as that > could mean a number of distinct scenarios. > > AFAICT, if we're in an IRQ handler (with NMIs unmasked), and an NMI > causes a new exception we'll do the right thing. So either I'm missing a > subtlety or you're describing a different scenario.. > > Note that the entry code is only trying to distinguish between: > > a) This exception is *definitely* an NMI (because regular interrupts > were masked). > > b) This exception is *either* and IRQ or an NMI (and this *cannot* be > distinguished until we acknowledge the interrupt), so we treat it as > an IRQ for now. > b) is the aim. At the entry, enter_el1_irq_or_nmi() -> enter_from_kernel_mode()->rcu_irq_enter()/rcu_irq_enter_check_tick() etc. While at irqchip level, gic_handle_irq()->gic_handle_nmi()->nmi_enter(), which does not call rcu_irq_enter_check_tick(). So it is not proper to "treat it as an IRQ for now" > ... and we leave it to the irqchip to handle the gory details. We only The detail should hide in irqchip to decide if an exception is either NMI or IRQ. But could irqchip export the interface to entry? (This patch export two: handle_arch_nmi() and interrupt_is_nmi() ). Thanks, Pingfan
Powered by blists - more mailing lists