On Wed, May 04, 2016 at 03:41:49PM -0700, Dave Hansen wrote: > It's my fault, but you also need to go update > > fpu__xfeature_set_state() > and > __raw_xsave_addr() > > The theoretical problem is that you might ask for a __raw_xsave_addr() > of a component which has been compacted out of an XSAVES buffer and thus > has no address. We could work around this by doing a memmove() and > moving the components "up" after the one we are trying to set in order > to make space. > > But, since we *always* call XSAVES with an instruction mask of -1 and > end up with a requested feature bitmap (RFBM) equal to XCR0, I think we > can do a shortcut because we'll practically *always* have an > xcomp_bv==RFBM==XCR0, which means that all (present) components will > always have an address. > > So, the alternative to doing the memmove() is to add some WARN_ON_FPU() > checks to enforce xcomp_bv==RFBM==XCR0 in places where we call > XSAVES/XRSTORS and __raw_xsave_addr(), maybe more.
In the coming version 5 patches, we are going to have one additional patch for fixing __fpu_restore_sig() for the compacted format. I changed my existing patch a little and run into some problems. Fixing it now. Our ptrace tests went OK before, but are failing now. It might be relating to what you are saying? I will check it.
