[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0dcec9f4-eef8-499d-a96a-dc6ab3433039@redhat.com>
Date: Fri, 30 May 2025 20:34:25 +0200
From: David Hildenbrand <david@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Pu Lehui <pulehui@...weicloud.com>, lorenzo.stoakes@...cle.com,
mhiramat@...nel.org, peterz@...radead.org, Liam.Howlett@...cle.com,
akpm@...ux-foundation.org, vbabka@...e.cz, jannh@...gle.com,
pfalcato@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
pulehui@...wei.com
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
On 30.05.25 20:09, Oleg Nesterov wrote:
> Well, let me say this again ;) I can't really comment, I don't understand
> this code enough.
>
> That said...
>
> On 05/30, David Hildenbrand wrote:
>>
>> I wonder if there might be a clean way to move the uprobe_mmap() out of
>> vma_complete().
>
> Me too.
>
> Not only the uprobe_mmap() calls in vma_complete() doesn't look right
> "in general" (at least to me).
>
> To remind, vma_complete/uprobe_mmap/install_breakpoint is not even called
> in, say, this case when VMA grows and moves. See
> https://lore.kernel.org/all/20250526173845.GC4156@redhat.com/
> I guess we don't really care, but still...
>
>
> But just in case... I agree with Lehui and Lorenzo in that we need a short
> term fix, and the last patch from Lehui seems to fix the immediate problem.
Oh, there was a new patch yesterday. Too bad I wasn't CCed on that.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists