Re: [PATCH v12 2/3] sched: Move task_mm_cid_work to mm work_struct

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Apr 09, 2025 at 10:15:42AM -0400, Mathieu Desnoyers wrote:
> On 2025-04-09 10:03, Peter Zijlstra wrote:
> > On Tue, Mar 11, 2025 at 07:28:45AM +0100, Gabriele Monaco wrote:
> > > +static inline void rseq_preempt_from_tick(struct task_struct *t)
> > > +{
> > > +	u64 rtime = t->se.sum_exec_runtime - t->se.prev_sum_exec_runtime;
> > > +
> > > +	if (rtime > RSEQ_UNPREEMPTED_THRESHOLD)
> > > +		rseq_preempt(t);
> > > +}
> > 
> > This confused me.
> > 
> > The goal seems to be to tickle __rseq_handle_notify_resume() so it'll
> > end up queueing that work thing. But why do we want to set PREEMPT_BIT
> > here?
> 
> In that scenario, we trigger (from tick) the fact that we may recompact the
> mm_cid, and thus need to update the rseq mm_cid field before returning to
> userspace.
> 
> Changing the value of the mm_cid field while userspace is within a rseq
> critical section should abort the critical section, because the rseq
> critical section should be able to expect the mm_cid to be invariant
> for the whole c.s..

But, if we run that compaction in a worker, what guarantees the
compaction is done and mm_cid is stable, but the time this task returns
to userspace again?