Skip to content

x86: NMI-safe trap handlers

Mathieu Desnoyers lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest2 patches 160 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2x86_64 page fault NMI-safearch/x86/mm/fault.c+3 -1118 replies
2/2x86 NMI-safe INT3 and Page Faultarch/alpha/include/asm/thread_info.h arch/avr32/include/asm/thread_info.h arch/x86/include/asm/irqflags.h +13 more+145 -638 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [patch 0/2] x86: NMI-safe trap handlers

Hi,

There seem to have been some churn regarding Perf problems with per-cpu memory allocation which uses vmalloc. Long story short: faulting NMIs reactivate NMIs faster than supposed, because x86 re-enables NMIs at the first iret encountered, which leads to nested NMIs.

x86_32 cannot use vmalloc_sync_all() to sychronize the TLBs from every processes because the vmalloc area is mapped in a different address space for each process on this architecture. A second alternative is to duplicate the per-cpu allocation API to have a variant using kmalloc only. This would lead to code and API duplication and should probably be kept as last resort. A third solution to this problem is to make the page fault handler aware of NMIs and ensure it can be called from this context. This third solution is proposed by this patchset.

So I'm respinning this patchset which has been sitting for a while, used for about 1-2 years in the LTTng tree without problems, already tested in a -tip sub-branch in the past. It uses a ret/popf instruction pair instead of iret when it detects that a trap handler is nested over an NMI. A second patch takes care of making the page fault handler nmi-safe by using the cr3 register rather than accessing ->current, which could be in the middle of being changed by a context switch.

Thanks,

Mathieu

Signature · 4 lines
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com