[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4398BBD5-31AB-4342-9572-32763B016175@fb.com>
Date: Fri, 26 Jul 2019 21:19:54 +0000
From: Song Liu <songliubraving@...com>
To: Oleg Nesterov <oleg@...hat.com>
CC: lkml <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"matthew.wilcox@...cle.com" <matthew.wilcox@...cle.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"Kernel Team" <Kernel-team@...com>,
"william.kucharski@...cle.com" <william.kucharski@...cle.com>
Subject: Re: [PATCH v8 2/4] uprobe: use original page when all uprobes are
removed
> On Jul 26, 2019, at 1:44 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>
> On 07/25, Song Liu wrote:
>>
>> I guess I know the case now. We can probably avoid this with an simp.le
>> check for old_page == new_page?
>
> better yet, I think we can check PageAnon(old_page) and avoid the unnecessary
> __replace_page() in this case. See the patch below.
I added PageAnon(old_page) check in v9 of the patch.
>
> Anyway, why __replace_page() needs to lock both pages? This doesn't look nice
> even if it were correct. I think it can do lock_page(old_page) later.
>
Agreed. I have changed the v9 to only unmap old_page. So it should be cleaner.
Thanks again for these good suggestions,
Song
Powered by blists - more mailing lists