[CRIU] [PATCH 09/14] restore: Restore FPU state

[Cyrill Gorcunov]

On Thu, Dec 20, 2012 at 12:28:22AM +0400, Pavel Emelyanov wrote:
> > 
> > +static void show_rt_xsave_frame(struct xsave_struct *x)
> > +{
> > +	struct fpx_sw_bytes *fpx = (void *)&x->i387.sw_reserved;
> > +	struct xsave_hdr_struct *xsave_hdr = &x->xsave_hdr;
> > +	struct i387_fxsave_struct *i387 = &x->i387;
> > +	struct ymmh_struct *ymmh = &x->ymmh;
> > +
> > +	unsigned int i;
> > +
> > +	(void)i;
> > +	(void)ymmh;
> 
> Garbage?

Kind of. Wanted to add printing the complete xsave frame including
registers contents, but because of a nit in logging system (ie
we can't _continue_ printing without leading timestamp) drpped
this idea but forgot to get rid of this vars. Thanks!

> > +
> > +#define assign_reg(dst, src, e)		do { dst.e = (__typeof__(dst.e))src->e; } while (0)
> > +#define assign_array(dst, src, e)	memcpy(dst.e, (src)->e, sizeof(dst.e))
> 
> Don't we have too many of this assignment helpers already?

Well, not that many actually -- one in dumping stage, counterpart in
restore stage. Still eliminating all this (including ones in restorer.c
code) will be a good thing for sure. But letme cleanup this macros on top
of the series.

> > +
> > +	*x = (struct xsave_struct) { };
> 
> What for?

We use anonymous memory for this data allocation, thus this area
should be already zeroified, but I fear what will happen if
one day we change allocation rules for restorer arguments. What
is worse -- this area must be zeroified, so I'm not sure how
to guard ourself here, maybe use BUG_ON(mem_is_not_zero())?

	Cyrill