linux-kernel - Re: [PATCH v9 2/3] sched: Move task_mm_cid_work to mm work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b8508fe41425dd7cd568ade401f2d2622aa343d5.camel@redhat.com>
Date: Tue, 25 Feb 2025 08:05:08 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...hat.org>, Shuah Khan <shuah@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 linux-mm@...ck.org
Subject: Re: [PATCH v9 2/3] sched: Move task_mm_cid_work to mm work_struct

On Mon, 2025-02-24 at 15:50 -0500, Mathieu Desnoyers wrote:
> On 2025-02-24 08:28, Gabriele Monaco wrote:
> [...]
> > diff --git a/kernel/rseq.c b/kernel/rseq.c
> > index 2cb16091ec0ae..936863fe7eb37 100644
> > --- a/kernel/rseq.c
> > +++ b/kernel/rseq.c
> > @@ -419,6 +419,7 @@ void __rseq_handle_notify_resume(struct ksignal
> > *ksig, struct pt_regs *regs)
> >   	}
> >   	if (unlikely(rseq_update_cpu_node_id(t)))
> >   		goto error;
> > +	task_queue_mm_cid(t);
> 
> Given that task_queue_mm_cid() will be called quite frequently from
> __rseq_handle_notify_resume, perhaps it would be best to move at
> least
> the portion responsible for checks (including the time_before()) to
> include/linux/sched.h to eliminate a function call from the fast
> path.
> 
> 

Right, good idea. Thinking about that, task_queue_mm_cid checks a bit
more than the __rseq_handle_notify_resume.
As far as I understand, as long as we only call task_queue_mm_cid from
__rseq_handle_notify_resume, it won't ever be called from a kthread (I
assume the t->rseq implies t->mm and not PF_KTHREAD but also by
construction since it's called in return to user).

In short, considering we already check for PF_EXITING, the following is
just superfluous:

  if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)))
  	return;

and we could just keep the time_before check in
__rseq_handle_notify_resume, perhaps adding a t->mm check just to avoid
a perceived NULL pointer dereference, which seems not possible anyway.

Am I missing any corner case?

Thanks,
Gabriele