Messages in this thread | | | From | Woody Lin <> | Date | Wed, 13 Oct 2021 09:22:50 +0800 | Subject | Re: [PATCH] sched/scs: Reset the shadow stack when idle_task_exit |
| |
On Tue, Oct 12, 2021 at 6:57 PM Valentin Schneider <valentin.schneider@arm.com> wrote: > > On 12/10/21 18:35, Woody Lin wrote: > > On Tue, Oct 12, 2021 at 6:00 PM Valentin Schneider > > <valentin.schneider@arm.com> wrote: > >> > >> So AIUI for SCS that works just fine - one thing I'm unclear on is how the > >> following pops are going to work given the SP reset happens in the middle > >> of a call stack, but AFAICT that was already the case before I messed about > >> with init_idle(), so that must already be handled. > > > > Hi Valentin, > > > > Thanks for the question. The 'scs_task_reset' here resets only the > > '.thread_info.scs_sp' of the task, so the register (on arm64 it's x18) > > is still pointing to the same location for popping and storing call > > frames. The register will be updated to '.thread_info.scs_sp' in > > '__secondary_switched', which starts a new core and there is no popping > > after the updating, so it won't introduce an underflow. > > > > I think I got it; __secondary_switched() -> init_cpu_task() -> scs_load() > > Thanks! > > >> > >> I'm not familiar enough with KASAN to say whether that > >> kasan_unpoison_task_stack() should rather happen upon hotplugging the CPU > >> back (rather than on hot-unplug). If that is the case, then maybe somewhere > >> around cpu_startup_entry() might work (and then you could bunch these two > >> "needs to be re-run at init for the idle task" functions into a common > >> helper). > > > > unpoison looks more like an one-time thing to me; the idle tasks will > > reuse the same stack pages until system resets, so I think we don't need > > to re-unpoison that during hotplugging as long as it's unpoisoned in > > 'init_idle'. > > > > I would tend to agree, but was bitten by s390 freeing some memory on > hot-unplug and re-allocating it upon hotplug: > > 6a942f578054 ("s390: preempt: Fix preempt_count initialization") > > This makes me doubt whether we can assert the idle task stack pages are > perennial vs hotplug on all architectures.
I made a quick study on memory-hotplug and seems that only memory contains nothing other than migratable pages can be unplugged. So process stack pages should not be a concern for this, since which is an unmovable memory.
However I don't have a chance to work on a system that enables memory-hotplug so far, so couldn't verify this assumption further. Guess we can create a separate thread to clarify this more.
Regards, Woody
> > >> > >> > } > >> > > >> > -- > >> > 2.33.0.882.g93a45727a2-goog
| |