On Mon, Nov 17, 2014 at 10:50 AM, Borislav Petkov <[email protected]> wrote: > On Fri, Nov 14, 2014 at 09:56:38PM +0000, Luck, Tony wrote: >> ... >> But I think that means we need more than one of these structures ... >> we may not be done with one before a new machine check occurs. So >> we'd have to make an NMI-safe allocator to grab one for use inside >> do_machine_check() > > Well, I think we might do something with a lockless list as it is being > done in ghes.c. > > It allocates entries from its own pool in the NMI handler and > llist_add's them to a list. > > Then, in user context it does llist_del_all and then looks at each of > the elements at leisure and stress-free :-) > > Pool alloc/free is NMI-safe too so we should be good. It looks pretty > clean, I'd give it a try.
Would it be worth making a decision on task_work_add vs. stack switching first? Stack switching pros: all this lockless allocation stuff is completely unnecessary, and it's plausible that the stack switching code will be added anyway. task_work_add pros: conceptually simpler mce.c diff. Tony, did the code survive your new stress test? --Andy > >> General testing note - one thing I did see was that if inject 1000 >> errors at 0.3s interval from my ssh'd login ... the serial console >> keeps streaming messages for about 40 seconds after my test says it is >> all done. This might be a factor in the other tests I've been running >> against the stack-switching code (especially with extra debug) ... at >> some point __log_buf must get full - what happens then? > > Start gets overwritten AFAICR. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
