On Thu, Sep 25, 2025 at 08:00:40PM +0100, Mark Brown wrote: > On Thu, Sep 25, 2025 at 07:36:50PM +0100, Catalin Marinas wrote: > > On Thu, Sep 25, 2025 at 06:01:07PM +0100, Mark Brown wrote: > > > On Thu, Sep 25, 2025 at 05:46:46PM +0100, Catalin Marinas wrote: > > > > On Sun, Sep 21, 2025 at 02:21:35PM +0100, Mark Brown wrote: > > > > We can't have scheduled? That's actually a pleasant surprise, that was > > > the main hole I was thinking of in the cover letter. > > > Well, double-check. AFAICT, gcs_free() is only called on the exit_mm() > > path when a thread dies. > > > I think gcs_free() may have been called in other contexts before the > > cleanups you had in 6.16 (there were two more call sites for > > gcs_free()). If that's the case, we could turn these checks into > > WARN_ON_ONCE(). > > Yeah, just I need to convince myself that we're always running the > exit_mm() path in the context of the exiting thread. Like you say it > needs checking but hopefully you're right and the current code is more > correct than I had thought.
The only path to gcs_free() is via mm_release() -> deactivate_mm(). mm_release() is called from either exit_mm_release() or exec_mm_release(). These two functions are only called with current and current->mm. I guess for historical reasons, they take task and mm parameters but in recent mainline, they don't seem to get anything other than current. -- Catalin
