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: Thu, 30 Sep 2010 13:21:14 +0800 From: Huang Ying <ying.huang@...el.com> To: Don Zickus <dzickus@...hat.com> Cc: huang ying <huang.ying.caritas@...il.com>, Robert Richter <robert.richter@....com>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andi Kleen <andi@...stfloor.org> Subject: Re: [PATCH -v2 7/7] x86, NMI, Remove do_nmi_callback logic On Thu, 2010-09-30 at 12:04 +0800, Don Zickus wrote: > On Wed, Sep 29, 2010 at 02:55:58PM +0800, huang ying wrote: > > Hi, Don, > > > > I think we all agree that to use order to determine the reason/source > > of NMI. The difference is that I want to keep as many direct calls in > > default_do_nmi() as possible, while you guys want to wrap almost all > > code in default_do_nmi() into notifier handler and leave only one > > notify_die() in defualt_do_nmi(). And I want to use different die_val > > (and their calling order in default_do_nmi()) to determine the order > > while you guys want to use priority (based on its value) to determine > > the order. > > Well, I just wanted to see if we can minimize the number of times we > walked the die_chain. Priorities was an interesting idea, I am not sure > it works out. Registering two handlers, seems clunky. But I am open to > the discussions. die_chain is used for multiple purposes now. Although I don't like the idea. I think it may be possible to use just one walking of die_chain to determine the source/reason of NMI. But we need several walking of die_chain after determining the source/reason and before the default processing. Such as DIE_NMIWATCHDOG before go panic. > > On the other hand, I think we should call corresponding DIE_NMIxxx > > before the default operations, such as for watchdog, call > > DIE_NMIWATCHDOG before go panic, for unknown nmi, call DIE_NMIUNKNOWN > > before the default processing (may panic). > > > > I think it is important to distinguish between die chain used to > > determine the source/reason of NMI and the die chain used to see if > > any other driver wanted to do some processing before the default > > operation. > > I guess I still prefer to take your patch set with its change and then > layer any new ideas on top. I have a feeling this discussion could go on > forever regarding how die_chains can work. Yes. I will send out a new version soon. Best Regards, Huang Ying -- 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