On Thu, Oct 13, 2016 at 4:41 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > Hi, > > On Thu, Oct 13, 2016 at 01:57:10PM +0200, Heiko Carstens wrote: >> 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. > > The exact same applies for arm64 on all counts. This is also simpler than both > attempts I had at this, so FWIW: > > Acked-by: Mark Rutland <mark.rutland@xxxxxxx> > > To make merging less painful, I guess we'll need a stable branch with (just) > this and whatever patch we end up with for fixing current_thread_info(), so we > can independently merge the arch-specific parts. > > I guess it'd make sense for the tip tree to host that? > I wonder if this could even make 4.9. It's pretty clearly a no-op. Ingo? -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html