linux-kernel - Re: [RFC 1/3] Unified NMI delayed call mechanism

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C15A5D1.1040104@jp.fujitsu.com>
Date:	Mon, 14 Jun 2010 12:45:21 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Huang Ying <ying.huang@...el.com>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Don Zickus <dzickus@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC 1/3] Unified NMI delayed call mechanism

(2010/06/12 19:25), Ingo Molnar wrote:
> 
> * Huang Ying <ying.huang@...el.com> wrote:
> 
>> NMI can be triggered even when IRQ is masked. So it is not safe for NMI 
>> handler to call some functions. One solution is to delay the call via self 
>> interrupt, so that the delayed call can be done once the interrupt is 
>> enabled again. This has been implemented in MCE and perf event. This patch 
>> provides a unified version and make it easier for other NMI semantic handler 
>> to take use of the delayed call.
> 
> Instead of introducing this extra intermediate facility please use the same 
> approach the unified NMI watchdog is using (see latest -tip): a perf event 
> callback gives all the extra functionality needed.
> 
> The MCE code needs to be updated to use that - and then it will be integrated 
> into the events framework.

Hi Ingo,

I think this "NMI delayed call mechanism" could be a part of "the events
framework" that we are planning to get in kernel soon.  At least APEI will
use NMI to report some hardware events (likely error) to kernel.  So I
suppose we will go to have a delayed call as an event handler for APEI.

Generally speaking "event" can occur independently of the situation.
NMI can tell us some of external events, expecting urgent reaction for
the event, but we cannot do everything in NMI context.  Or we might have
a sudden urge to generate an internal event while interrupts are disabled.

I agree that generating a self interrupt is reasonable solution.
Note that it could be said that both of "MCE handled (=event log should
be delivered to userland asap)" and "perf events pending (=pending events
should be handled asap)" are kind of internal event that requires urgent
handling in non-NMI kernel context.  One question here is why we should
have different vectors for these events that uses same mechanism.

How about calling the vector LOCAL_EVENT_VECTOR or so?
I guess there should be better name if it is possible to inject an event
to other cpus via IPI with this vector...

Thanks,
H.Seto

--
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/