From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755944AbcJTGkw (ORCPT ); Thu, 20 Oct 2016 02:40:52 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34585 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754058AbcJTGkv (ORCPT ); Thu, 20 Oct 2016 02:40:51 -0400 Date: Thu, 20 Oct 2016 08:40:45 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: Mark Rutland , "linux-kernel@vger.kernel.org" , linux-arch , Andrew Morton , Heiko Carstens , "H. Peter Anvin" , Kees Cook , Andrew Lutomirski , Ingo Molnar , Thomas Gleixner Subject: Re: [PATCH 1/3] sched/core,x86: make struct thread_info arch specific again Message-ID: <20161020064045.GA29032@gmail.com> References: <1476901693-8492-1-git-send-email-mark.rutland@arm.com> <1476901693-8492-2-git-send-email-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > On Wed, Oct 19, 2016 at 11:28 AM, Mark Rutland wrote: > > From: Heiko Carstens > > > > commit c65eacbe290b ("sched/core: Allow putting thread_info into > > task_struct") made struct thread_info a generic struct with only a > > single flags member if THREAD_INFO_IN_TASK_STRUCT is selected. > > > > This change however seems to be quite x86 centric, since at least the > > generic preemption code (asm-generic/preempt.h) assumes that struct > > thread_info also has a preempt_count member, which apparently was not > > true for x86. > > > > We could add a bit more ifdefs to solve this problem too, but it seems > > to be much simpler to make struct thread_info arch specific > > again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a > > bit easier for architectures that have a couple of arch specific stuff > > in their thread_info definition. > > > > The arch specific stuff _could_ be moved to thread_struct. However > > keeping them in thread_info makes it easier: accessing thread_info > > members is simple, since it is at the beginning of the task_struct, > > while the thread_struct is at the end. At least on s390 the offsets > > needed to access members of the thread_struct (with task_struct as > > base) are too large for various asm instructions. This is not a > > problem when keeping these members within thread_info. > > Acked-by: Andy Lutomirski > > Ingo, there's a (somewhat weak) argument for sending this via > tip/urgent: it doesn't change generated code at all, and I think it > will avoid a silly depedency or possible conflict for the next merge > window, since both arm64 and s390 are going to need it. Can certainly do it if this is the final version of the patch. Mark? Thanks, Ingo