[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dc0d9e87-4f38-a6f9-8513-1c682bfaccc7@linux.alibaba.com>
Date: Thu, 23 Aug 2018 09:07:43 -0700
From: Yang Shi <yang.shi@...ux.alibaba.com>
To: Oleg Nesterov <oleg@...hat.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, mhocko@...nel.org,
willy@...radead.org, ldufour@...ux.vnet.ibm.com,
kirill@...temov.name, akpm@...ux-foundation.org,
peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, linux-mm@...ck.org, liu.song.a23@...il.com,
ravi.bangoria@...ux.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC v8 PATCH 2/5] uprobes: introduce has_uprobes helper
On 8/23/18 8:15 AM, Oleg Nesterov wrote:
> On 08/22, Srikar Dronamraju wrote:
>> * Vlastimil Babka <vbabka@...e.cz> [2018-08-22 12:55:59]:
>>
>>> On 08/15/2018 08:49 PM, Yang Shi wrote:
>>>> We need check if mm or vma has uprobes in the following patch to check
>>>> if a vma could be unmapped with holding read mmap_sem.
> Confused... why can't we call uprobe_munmap() under read_lock(mmap_sem) ?
I'm not sure if it is safe or not because it is not recommended and not
safe to update vma's vm flags with read mmap_sem. uprobe_munmap() may
update mm flags (MMF_RECALC_UPROBES). So, it sounds safer to not call it
under read mmap_sem.
>
> OK, it can race with find_active_uprobe() but I do not see anything really
> wrong, and a false-positive MMF_RECALC_UPROBES is fine.
Thanks for confirming this. If it is ok to have such race, we don't have
to have has_uprobes() helper anymore since it can be just called under
read mmap_sem without any special handling.
Yang
>
> Again, I think we should simply kill uprobe_munmap(), but this needs another
> discussion.
>
> Oleg.
Powered by blists - more mailing lists