On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote: > On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote: > > On Fri, Aug 23, 2024 at 03:45:32PM +0100, Will Deacon wrote: > > > On Thu, Aug 22, 2024 at 04:10:49PM +0100, Joey Gouly wrote: > > > > +static void permission_overlay_switch(struct task_struct *next) > > > > +{ > > > > + if (!system_supports_poe()) > > > > + return; > > > > + > > > > + current->thread.por_el0 = read_sysreg_s(SYS_POR_EL0); > > > > + if (current->thread.por_el0 != next->thread.por_el0) { > > > > + write_sysreg_s(next->thread.por_el0, SYS_POR_EL0); > > > > + /* ISB required for kernel uaccess routines when chaning POR_EL0 */ > > > > > > nit: typo "chaning". > > > > > > But more substantially, is this just to prevent spurious faults in the > > > context of a new thread using a stale value for POR_EL0? > > > > Not just prevent faults but enforce the permissions from the new > > thread's POR_EL0. The kernel may continue with a uaccess routine from > > here, we can't tell. > > Hmm, I wondered if that was the case. It's a bit weird though, because: > > - There's a window between switch_mm() and switch_to() where you might > reasonably expect to be able to execute uaccess routines I don't think we can have any uaccess between these two switches (a uaccess could fault, that's a pretty weird state between these two). > - kthread_use_mm() doesn't/can't look at this at all No, but a kthread would have it's own, most permissive, POR_EL0. > - GUP obviously doesn't care > > So what do we actually gain by having the uaccess routines honour this? I guess where it matters is more like not accidentally faulting because the previous thread had more restrictive permissions. -- Catalin