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

2016-07-11 Thread Linus Torvalds
On Mon, Jul 11, 2016 at 9:31 AM, Mark Rutland wrote: >> >> So until you do the wire that actually disables preemption you can >> schedule away as much as you want, and after that write you no longer >> will. > > I was assuming a percpu pointer to current (or preempt count).

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

2016-07-11 Thread Linus Torvalds
On Mon, Jul 11, 2016 at 9:31 AM, Mark Rutland wrote: >> >> So until you do the wire that actually disables preemption you can >> schedule away as much as you want, and after that write you no longer >> will. > > I was assuming a percpu pointer to current (or preempt count). So for the same

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

2016-07-11 Thread Mark Rutland
On Mon, Jul 11, 2016 at 09:06:58AM -0700, Linus Torvalds wrote: > On Jul 11, 2016 7:55 AM, "Andy Lutomirski" <[1]l...@amacapital.net> wrote: > > > > How do you intend to find 'current' to get to the preempt count > > without first disabling preemption? > > Actually, that is the classic case of

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

2016-07-11 Thread Mark Rutland
On Mon, Jul 11, 2016 at 09:06:58AM -0700, Linus Torvalds wrote: > On Jul 11, 2016 7:55 AM, "Andy Lutomirski" <[1]l...@amacapital.net> wrote: > > > > How do you intend to find 'current' to get to the preempt count > > without first disabling preemption? > > Actually, that is the classic case of

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

2016-07-11 Thread Mark Rutland
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, > > >

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

2016-07-11 Thread Mark Rutland
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

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

2016-07-11 Thread Andy Lutomirski
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

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

2016-07-11 Thread Andy Lutomirski
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.

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

2016-07-11 Thread Mark Rutland
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

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

2016-07-11 Thread Mark Rutland
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