Re: [PATCH v3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag

[Linus Torvalds]

On Fri, 15 May 2026 at 15:33, Minchan Kim <minchan@xxxxxxxxxx> wrote:
>
> I hope thisclarifies the motivation and mechanics behind this issue.

This still seems very hacky and a complete special case for one odd situation.

This all sounds like it's just because smap is a pig.

And yes, smap *is* a pig, but it should be trivial to just fix smap
for this case - fix the problem spot, don't add new horrid logic
elsewhere.

I really think the fix is to fix smap instead.

And I think smap is doing odd things. For example, it does

   pid_smaps_open -> do_maps_open -> proc_mem_open

and that proc_mem_open() takes that long-term ref to the mm. And then
does various memory allocations - and copying data to user space -
under that long-term ref, which is presumably what causes all the
latency issues.

But it doesn't actually seem to *need* a long-term ref to the mm. The
seqfile interface is designed so that it should all be chunkable, and
the locks and refs should be done at m_start/m_end time.

And the smap / maps m_start and m_end functions already *almost* seem
to do that. They literally look up the task again with

        priv->task = get_proc_task(priv->inode);

etc, but then they do that odd

        lock_ctx = &priv->lock_ctx;
        mm = lock_ctx->mm;
        if (!mm || !mmget_not_zero(mm)) {
                put_task_struct(priv->task);
                priv->task = NULL;
                return NULL;
        }

dance (where lock_ctx->mm is literally that long-term ref we hold).

And I don't see why they need to do any of this. I think it's all a
historical accident.

Because I think it could look up the mm from the task pointer every
time, without holding that long-term ref from proc_mem_open() at all.

IOW, at open time, we could save off the "this is the mm I opened",
but *without* any refcount, and then just verify that "yes, the task
mm still matches". No long-term refs anywhere.

Yes, yes, we'd need some sequence counter for when the mm changes due
to execve, but *that* should be absolutely trivial.

And wouldn't that make all of this go away entirely? And probably
clean up the code at the same time?

I think the only reason "proc_mem_open()" does what it does was that
it was simple. Not because it was a good idea.

                   Linus