From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCHv2 2/3] mm: don't free pages until mm locks
	are released
Date: Mon, 16 Nov 2015 12:02:56 +0000
Message-ID: <5649C5F0.2020100@citrix.com>
References: <1447440595-1151-1-git-send-email-david.vrabel@citrix.com>
	<1447440595-1151-3-git-send-email-david.vrabel@citrix.com>
	<5649D18602000078000B52BD@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=75553db89=david.vrabel@citrix.com>)
	id 1ZyIUw-0002A7-FP
	for xen-devel@lists.xenproject.org; Mon, 16 Nov 2015 12:03:02 +0000
In-Reply-To: <5649D18602000078000B52BD@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, Jun Nakajima <jun.nakajima@intel.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

On 16/11/15 11:52, Jan Beulich wrote:
>>>> On 13.11.15 at 19:49, <david.vrabel@citrix.com> wrote:
>> @@ -2805,6 +2806,9 @@ int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>>      prev_mfn = mfn_x(get_gfn(tdom, gpfn, &p2mt_prev));
>>      if ( mfn_valid(_mfn(prev_mfn)) )
>>      {
>> +        prev_page = mfn_to_page(_mfn(prev_mfn));
>> +        get_page(prev_page, tdom);
> 
> If you're absolutely sure that this can never fail, then still at the very
> least this imo should be documented by a respective ASSERT() (or
> ASSERT_UNREACHABLE()).

What are you suggesting may fail?

David