On Tue, Apr 22, 2014 at 4:17 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 04/22/2014 12:55 PM, Brian Gerst wrote: >> On Tue, Apr 22, 2014 at 2:51 PM, H. Peter Anvin <h...@zytor.com> wrote: >>> On 04/22/2014 11:17 AM, Brian Gerst wrote: >>>>> >>>>> That is the entry condition that we have to deal with. The fact that >>>>> the switch to the IST is unconditional is what makes ISTs hard to deal >>>>> with. >>>> >>>> Right, that is why you switch away from the IST as soon as possible, >>>> copying the data that is already pushed there to another stack so it >>>> won't be overwritten by a recursive fault. >>>> >>> >>> That simply will not work if you can take a #GP due to the "safe" MSR >>> functions from NMI and #MC context, which would be my main concern. >> >> In that case (#2 above), you would switch to the previous %rsp (in the >> NMI/MC stack), copy the exception frame from the IST, and continue >> with the #GP handler. That effectively is the same as it is today, >> where no stack switch occurs on the #GP fault. >> > > 1. You take #GP. This causes an IST stack switch. > 2. You immediately thereafter take an NMI. This switches stacks again. > 3. Now you take another #GP. This causes another IST stack, and now you > have clobbered your return information, and cannot resume.
You are right. That will not work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
