On Tue, 12 Dec 2017, Andy Lutomirski wrote: > On Tue, Dec 12, 2017 at 12:37 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Tue, 12 Dec 2017, Dave Hansen wrote: > > > >> On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > >> > The only critical interaction is the return to user path (user CS/SS) and > >> > we made sure with the LAR touching that these are precached in the CPU > >> > before we go into fragile exit code. > >> > >> How do we make sure that it _stays_ cached? > >> > >> Surely there is weird stuff like WBINVD or SMI's that can come at very > >> inconvenient times and wipe it out of the cache. > > > > This does not look like cache in the sense of memory cache. It seems to be > > CPU internal state and I just stuffed WBINVD and alternatively CLFLUSH'ed > > the entries after the 'touch' via LAR. Still works. > > > > There *must* be some weird bug in this series. I find it very hard to > believe that x86 CPUs have a magic cache that caches any part of a > not-actually-in-a-segment-register descriptor entry. There is no bug in the code. There was just a bug in my brain which made me fail to see the obvious. See the other mail. Thanks, tglx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
