Re: [tip:perf/urgent 4/5] arch/x86//events/amd/core.c:542:9: error: 'NMI_HANDLED' undeclared; did you mean 'IRQ_HANDLED'?

["Lendacky, Thomas" <Thomas.Lendacky@amd.com>]

On 4/3/19 9:47 AM, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/urgent
> head:   60f52ab61c7dc0a991125903ae06a35d1812698c
> commit: 6d3edaae16c6c7d238360f2841212c2b26774d5e [4/5] x86/perf/amd: Resolve NMI latency issues for active PMCs
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
>          git checkout 6d3edaae16c6c7d238360f2841212c2b26774d5e
>          # save the attached .config to linux build tree
>          make ARCH=i386
> 
> All error/warnings (new ones prefixed by >>):
> 
>     arch/x86//events/amd/core.c: In function 'amd_pmu_handle_irq':
>     arch/x86//events/amd/core.c:538:10: error: 'NMI_DONE' undeclared (first use in this function); did you mean 'EM_NONE'?
>        return NMI_DONE;
>               ^~~~~~~~
>               EM_NONE
>     arch/x86//events/amd/core.c:538:10: note: each undeclared identifier is reported only once for each function it appears in
>>> arch/x86//events/amd/core.c:542:9: error: 'NMI_HANDLED' undeclared (first use in this function); did you mean 'IRQ_HANDLED'?
>       return NMI_HANDLED;
>              ^~~~~~~~~~~
>              IRQ_HANDLED
>>> arch/x86//events/amd/core.c:543:1: warning: control reaches end of non-void function [-Wreturn-type]
>      }
>      ^
> 

Looks like I need to change that include back to asm/nmi.h. I should have
looked closer at linux/nmi.h after the checkpatch message.

I'll send a patch to address it.

Thanks,
Tom

> vim +542 arch/x86//events/amd/core.c
> 
>     493	
>     494	/*
>     495	 * Because of NMI latency, if multiple PMC counters are active or other sources
>     496	 * of NMIs are received, the perf NMI handler can handle one or more overflowed
>     497	 * PMC counters outside of the NMI associated with the PMC overflow. If the NMI
>     498	 * doesn't arrive at the LAPIC in time to become a pending NMI, then the kernel
>     499	 * back-to-back NMI support won't be active. This PMC handler needs to take into
>     500	 * account that this can occur, otherwise this could result in unknown NMI
>     501	 * messages being issued. Examples of this is PMC overflow while in the NMI
>     502	 * handler when multiple PMCs are active or PMC overflow while handling some
>     503	 * other source of an NMI.
>     504	 *
>     505	 * Attempt to mitigate this by using the number of active PMCs to determine
>     506	 * whether to return NMI_HANDLED if the perf NMI handler did not handle/reset
>     507	 * any PMCs. The per-CPU perf_nmi_counter variable is set to a minimum of the
>     508	 * number of active PMCs or 2. The value of 2 is used in case an NMI does not
>     509	 * arrive at the LAPIC in time to be collapsed into an already pending NMI.
>     510	 */
>     511	static int amd_pmu_handle_irq(struct pt_regs *regs)
>     512	{
>     513		struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
>     514		int active, handled;
>     515	
>     516		/*
>     517		 * Obtain the active count before calling x86_pmu_handle_irq() since
>     518		 * it is possible that x86_pmu_handle_irq() may make a counter
>     519		 * inactive (through x86_pmu_stop).
>     520		 */
>     521		active = __bitmap_weight(cpuc->active_mask, X86_PMC_IDX_MAX);
>     522	
>     523		/* Process any counter overflows */
>     524		handled = x86_pmu_handle_irq(regs);
>     525	
>     526		/*
>     527		 * If a counter was handled, record the number of possible remaining
>     528		 * NMIs that can occur.
>     529		 */
>     530		if (handled) {
>     531			this_cpu_write(perf_nmi_counter,
>     532				       min_t(unsigned int, 2, active));
>     533	
>     534			return handled;
>     535		}
>     536	
>     537		if (!this_cpu_read(perf_nmi_counter))
>   > 538			return NMI_DONE;
>     539	
>     540		this_cpu_dec(perf_nmi_counter);
>     541	
>   > 542		return NMI_HANDLED;
>   > 543	}
>     544	
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>