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 S1751632AbcFBAjv (ORCPT <rfc822;w@1wt.eu>);
	Wed, 1 Jun 2016 20:39:51 -0400
Received: from TYO202.gate.nec.co.jp ([210.143.35.52]:64821 "EHLO
	tyo202.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750867AbcFBAju convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 1 Jun 2016 20:39:50 -0400
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
CC: Andrew Morton <akpm@linux-foundation.org>, Hugh Dickins <hughd@google.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v1] mm: thp: check pmd_trans_unstable() after
 split_huge_pmd()
Thread-Topic: [PATCH v1] mm: thp: check pmd_trans_unstable() after
 split_huge_pmd()
Thread-Index: AQHRu52tCOd07nenwEOJvfBl7Y9jQp/TxQKAgAD6poA=
Date: Thu, 2 Jun 2016 00:37:03 +0000
Message-ID: <20160602003702.GA18004@hori1.linux.bs1.fc.nec.co.jp>
References: <1464741400-12143-1-git-send-email-n-horiguchi@ah.jp.nec.com>
 <20160601093957.GA8493@node.shutemov.name>
In-Reply-To: <20160601093957.GA8493@node.shutemov.name>
Accept-Language: en-US, ja-JP
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.128.101.4]
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <E63B24DCDC0043479ECFD37B28B750F7@gisp.nec.co.jp>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jun 01, 2016 at 12:39:57PM +0300, Kirill A. Shutemov wrote:
> On Wed, Jun 01, 2016 at 09:36:40AM +0900, Naoya Horiguchi wrote:
> > split_huge_pmd() doesn't guarantee that the pmd is normal pmd pointing to
> > pte entries, which can be checked with pmd_trans_unstable().
> 
> Could you be more specific on when we don't have normal ptes after
> split_huge_pmd? Race with other thread? DAX?

Actually I don't have any such specific case in mind.
__split_huge_pmd could skip real split code. In most case the skip happens
when the pmd is already split and pointing to normal ptes, and I'm not sure
when the pmd could be none or bad ...

So my above description seems misstatement, I should say "some caller does
assertion and some does differently and some not, so let's do it in unified
manner".

- Naoya

>
> I guess we can modify split_huge_pmd() to return if the pmd was split or
> not.