Messages in this thread | | | From | Keith Packard <> | Subject | Re: [PATCH 2/3] ARM: Move thread_info into task_struct (v7 only) | Date | Tue, 07 Sep 2021 08:24:36 -0700 |
| |
Ard Biesheuvel <ardb@kernel.org> writes:
> Sure, so it is precisely for that reason that it is better to isolate > changes that can be isolated.
I'll go ahead and split this apart then; that is how I did development, after all.
> All the time. 'current' essentially never changes value from the POV > of code running in task context, so there is usually no reason to care > about preemption/migration when referring to it. Using per-CPU > variables is what creates the problem here.
Thanks for helping me -- I just got the wrong model stuck in my head over the weekend somehow.
If I do have this figured out, we should be able to stick the per_cpu_offset value in thread_info and use TPIDRPRW to hold 'current' as code using per_cpu_offset should already be disabling preemption. That should be an easier change than putting a kernel pointer in a user-visible register.
> Given that we are already relying on the MP extensions for this > anyway, I personally think that using another thread ID register to > carry 'current' is a reasonable approach as well, since it would also > allow us to get per-task stack protector support into the compiler. > But I would like to hear from some other folks on cc as well.
That would be awesome; I assume that doesn't require leaving per_cpu_offset in a thread ID register?
In any case, I'll give my plan a try, and then see about trying your plan as well so I can compare the complexity of the two solutions.
-- -keith [unhandled content-type:application/pgp-signature] | |