On Fri, Apr 24, 2015 at 1:21 PM, Andy Lutomirski <l...@amacapital.net> wrote: > > 2. SYSRETQ. The only way that I know of to see the problem is SYSRETQ > followed by a far jump or return. This is presumably *extremely* > rare. > > What if we fixed #2 up in do_stack_segment. We should double-check > the docs, but I think that this will only ever manifest as #SS(0) with > regs->ss == __USER_DS and !user_mode_64bit(regs).
Hmm. It smells a bit "too clever" for me, and in particular, I think you need a good test-case for this. But yeah, I guess that gets things out of any possibly critical paths. That said, I wouldn't even be sure about the SS(0). The rules about when you get SS and when you get GP are odd. Also, you need to check what happens when somebody does something like movl $-1,%eax ss ; movl (%eax),%eax because I think that gets a #DB(0) too with the situation you expect to be "unique", because the address wraps.. I dunno. So care and testing needed. I think the scheduler approach is a *lot* more obvious, quite frankly. Linus -- 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/