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 S1751471AbdFFP4F (ORCPT <rfc822;w@1wt.eu>);
        Tue, 6 Jun 2017 11:56:05 -0400
Received: from mx1.redhat.com ([209.132.183.28]:41338 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751388AbdFFP4E (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 6 Jun 2017 11:56:04 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ED02ADF86E
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com ED02ADF86E
Date: Tue, 6 Jun 2017 17:56:01 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: zhong jiang <zhongjiang@huawei.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
Message-ID: <20170606155600.GA17705@redhat.com>
References: <5936B098.6020807@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5936B098.6020807@huawei.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 06 Jun 2017 15:56:04 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.