Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1440698

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct

From Mark Rutland <mark.rutland@arm.com>
Newsgroups linux.kernel
Subject Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct
Date 2016-07-11 17:10 +0200
Message-ID <rTL0l-ej-3@gated-at.bofh.it> (permalink)
References <rOqfT-8f8-5@gated-at.bofh.it> <rOqfU-8f8-33@gated-at.bofh.it> <rTGk2-5Co-29@gated-at.bofh.it> <rTKQG-8n2-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Jul 11, 2016 at 07:55:17AM -0700, Andy Lutomirski wrote:
> On Jul 11, 2016 3:08 AM, "Mark Rutland" <mark.rutland@arm.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?

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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting  thread_info into task_struct Mark Rutland <mark.rutland@arm.com> - 2016-07-11 12:10 +0200
  Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting  thread_info into task_struct Andy Lutomirski <luto@amacapital.net> - 2016-07-11 17:00 +0200
    Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting  thread_info into task_struct Mark Rutland <mark.rutland@arm.com> - 2016-07-11 17:10 +0200
    Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting  thread_info into task_struct Mark Rutland <mark.rutland@arm.com> - 2016-07-11 18:40 +0200
      Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting  thread_info into task_struct Linus Torvalds <torvalds@linux-foundation.org> - 2016-07-11 18:50 +0200

csiph-web