From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759076AbcGKPIV (ORCPT ); Mon, 11 Jul 2016 11:08:21 -0400 Received: from foss.arm.com ([217.140.101.70]:53598 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753300AbcGKPIU (ORCPT ); Mon, 11 Jul 2016 11:08:20 -0400 Date: Mon, 11 Jul 2016 16:08:03 +0100 From: Mark Rutland To: Andy Lutomirski Cc: Nadav Amit , linux-arch , Kees Cook , Josh Poimboeuf , Borislav Petkov , "linux-kernel@vger.kernel.org" , Jann Horn , Heiko Carstens , "kernel-hardening@lists.openwall.com" , Brian Gerst , X86 ML , Linus Torvalds Subject: Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct Message-ID: <20160711150802.GB7691@leverpostej> References: <20160711100808.GB31221@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote: > On Jul 11, 2016 3:08 AM, "Mark Rutland" wrote: > > > > Hi, > > > > On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote: > > > If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, > > > then thread_info is defined as a single 'u32 flags' and is the first > > > entry of task_struct. thread_info::task is removed (it serves no > > > purpose if thread_info is embedded in task_struct), and > > > thread_info::cpu gets its own slot in task_struct. > > > > > > This is heavily based on a patch written by Linus. > > > > I've been considering how we'd implement this for arm64, and I suspect > > that we'll also need to fold our preempt_count into task_struct > > (following from the style of asm-generic/preempt.h). > > > > As far as I can see, we can't make our preempt-count a percpu variable > > as with x86, as our percpu ops themselves are based on disabling > > preemption. > > How do you intend to find 'current' to get to the preempt count > without first disabling preemption? Good point. For some reason I had convinced myself that it only mattered for RMW sequences, so evidently I hadn't considered things thoroughly enough. :( > > To that end, would it be possible to keep the thread_info definition per > > arch, even with CONFIG_THREAD_INFO_IN_TASK? > > In principal, yes, but could you alternatively put it in > thread_struct? My goal here is to encourage people to clean up their > use of thread_info vs thread_struct at the same time. For x86, that > cleanup was trivial -- most of the work was addressing relative to > current instead of the stack pointer, and that had to happen > regardless. I'm more than happy to do that, modulo the above permitting. Sorry for the noise! Thanks, Mark.