Date: Mon, 11 Jul 2016 07:55:17 -0700 From: Andy Lutomirski <luto@...capital.net> To: Mark Rutland <mark.rutland@....com> Cc: Nadav Amit <nadav.amit@...il.com>, linux-arch <linux-arch@...r.kernel.org>, Kees Cook <keescook@...omium.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Borislav Petkov <bp@...en8.de>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Jann Horn <jann@...jh.net>, Heiko Carstens <heiko.carstens@...ibm.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Brian Gerst <brgerst@...il.com>, X86 ML <x86@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v4 26/29] sched: Allow putting thread_info into task_struct On Jul 11, 2016 3:08 AM, "Mark Rutland" <mark.rutland@....com> 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? > > 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. --Andy
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.