From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756199AbbGPV3G (ORCPT ); Thu, 16 Jul 2015 17:29:06 -0400 Received: from www.sr71.net ([198.145.64.142]:54624 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755619AbbGPV3F (ORCPT ); Thu, 16 Jul 2015 17:29:05 -0400 Message-ID: <55A8221E.8030108@sr71.net> Date: Thu, 16 Jul 2015 14:29:02 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Peter Zijlstra , Borislav Petkov , Linus Torvalds , "linux-kernel@vger.kernel.org" Subject: Re: [RFC][PATCH] x86, fpu: dynamically allocate 'struct fpu' References: <20150716191437.A334FF2E@viggo.jf.intel.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/16/2015 12:25 PM, Andy Lutomirski wrote: > On Thu, Jul 16, 2015 at 12:14 PM, Dave Hansen wrote: >> +#define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) \ >> + BUILD_BUG_ON((sizeof(TYPE) - \ >> + offsetof(TYPE, MEMBER) - \ >> + sizeof(((TYPE *)0)->MEMBER)) > \ >> + 0) \ >> + > > You could save a bit of typing by using offsetofend here. Something > along the lines of BUILD_BUG_ON(sizeof(TYPE) != offsetofend(TYPE, > MEMBER)); Good point. >> #endif /* _ASM_X86_FPU_H */ >> diff -puN arch/x86/kernel/process.c~dynamically-allocate-struct-fpu arch/x86/kernel/process.c >> --- a/arch/x86/kernel/process.c~dynamically-allocate-struct-fpu 2015-07-16 10:50:42.360571875 -0700 >> +++ b/arch/x86/kernel/process.c 2015-07-16 12:00:59.204808551 -0700 >> @@ -81,7 +81,7 @@ EXPORT_SYMBOL_GPL(idle_notifier_unregist >> */ >> int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src) >> { >> - *dst = *src; >> + memcpy(dst, src, arch_task_struct_size()); > > This is actually vaguely performance-critical, which makes me thing > that using some kind of inline or other real way (config macro, ifdef, > etc) to detect whether there's an arch override would be better than a > weak function. Fair enough. I'll send out another version in a bit if there are no more comments.