* Peter Zijlstra <[email protected]> wrote:

> On Thu, Jul 16, 2015 at 12:14:37PM -0700, Dave Hansen wrote:
> > +++ b/arch/x86/kernel/fpu/init.c    2015-07-16 12:02:15.284280976 -0700
> > @@ -136,6 +136,45 @@ static void __init fpu__init_system_gene
> >  unsigned int xstate_size;
> >  EXPORT_SYMBOL_GPL(xstate_size);
> >  
> > +#define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER)       \
> > +   BUILD_BUG_ON((sizeof(TYPE) -                    \
> > +                   offsetof(TYPE, MEMBER) -        \
> > +                   sizeof(((TYPE *)0)->MEMBER)) >  \
> > +                   0)                              \
> > +
> > +/*
> > + * We append the 'struct fpu' to the task_struct.
> > + */
> > +int __weak arch_task_struct_size(void)
> > +{
> > +   int task_size = sizeof(struct task_struct);
> > +
> > +   /*
> > +    * Subtract off the static size of the register state.
> > +    * It potentially has a bunch of padding.
> > +    */
> > +   task_size -= sizeof(((struct task_struct *)0)->thread.fpu.state);
> > +
> > +   /*
> > +    * Add back the dynamically-calculated register state
> > +    * size.
> > +    */
> > +   task_size += xstate_size;
> > +
> > +   /*
> > +    * We dynamically size 'struct fpu', so we require that
> > +    * it be at the end of 'thread_struct' and that
> > +    * 'thread_struct' be at the end of 'task_struct'.  If
> > +    * you hit a compile error here, check the structure to
> > +    * see if something got added to the end.
> > +    */
> > +   CHECK_MEMBER_AT_END_OF(struct fpu, state);
> > +   CHECK_MEMBER_AT_END_OF(struct thread_struct, fpu);
> > +   CHECK_MEMBER_AT_END_OF(struct task_struct, thread);
> > +
> > +   return task_size;
> > +}
> 
> Since you want these invariants true at all times, maybe put the
> BUILD_BUG_ON() in generic code instead of x86 specific? That way people
> poking at other archs are less likely to accidentally break your stuff.

Yeah.

Thanks,

        Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to