From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751523AbdFGCVN (ORCPT <rfc822;w@1wt.eu>);
        Tue, 6 Jun 2017 22:21:13 -0400
Received: from szxga03-in.huawei.com ([45.249.212.189]:7385 "EHLO
        szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751474AbdFGCVL (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 6 Jun 2017 22:21:11 -0400
Message-ID: <593762FF.10705@huawei.com>
Date: Wed, 7 Jun 2017 10:20:47 +0800
From: zhong jiang <zhongjiang@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Oleg Nesterov <oleg@redhat.com>
CC: Michal Hocko <mhocko@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
        "David Rientjes" <rientjes@google.com>,
        Hugh Dickins <hughd@google.com>,
        "Linux Memory Management List" <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, Xishi Qiu <qiuxishi@huawei.com>
Subject: Re: double call identical release when there is a race hitting
References: <5936B098.6020807@huawei.com> <20170606155600.GA17705@redhat.com>
In-Reply-To: <20170606155600.GA17705@redhat.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.29.68]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A020206.59376314.00A0,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2014-11-16 11:51:01,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3d6103fb240909ed47c57f700f74cb2c
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2017/6/6 23:56, Oleg Nesterov wrote:
> I can't answer authoritatively, but
>
> On 06/06, zhong jiang wrote:
>> Hi
>>
>> when I review the code, I find the following scenario will lead to a race ,
>> but I am not sure whether the real issue will hit or not.
>>
>> cpu1                                                                      cpu2
>> exit_mmap                                               mmu_notifier_unregister
>>    __mmu_notifier_release                                 srcu_read_lock
>>             srcu_read_lock
>>             mm->ops->release(mn, mm)                 mm->ops->release(mn,mm)
>>            srcu_read_unlock                                         srcu_read_unlock
>>
>>
>> obviously,  the specified mm will call identical release function when
>> the related condition satisfy.  is it right?
> I think you are right, this is possible, perhaps the comments should mention
> this explicitly.
>
> See the changelog in d34883d4e35c0a994e91dd847a82b4c9e0c31d83 "mm: mmu_notifier:
> re-fix freed page still mapped in secondary MMU":
>
> 	"multiple ->release() callouts", we needn't care it too much ...
>
> Oleg.
>
>
> .
>
Thank you for clarification.
 yes,  I see that the author admit that this is a issue.   The patch describe that it is really rare.
 Anyway, this issue should be fixed in a separate patch.

but so far  the issue still exist unfortunately.

Regards
zhongjiang