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.