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 S1751833AbbG2AsJ (ORCPT <rfc822;w@1wt.eu>);
	Tue, 28 Jul 2015 20:48:09 -0400
Received: from ppsw-51.csi.cam.ac.uk ([131.111.8.151]:39486 "EHLO
	ppsw-51.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751131AbbG2AsH (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 28 Jul 2015 20:48:07 -0400
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Subject: Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and
 config option
To: Andy Lutomirski <luto@amacapital.net>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>
References: <cover.1437802102.git.luto@kernel.org> <55B64FEA.70204@oracle.com>
 <CALCETrUEYTCwYzA0bvG=EJOi+pdXX=FZXoaQc4tYGkJATM7x3g@mail.gmail.com>
 <55B659EC.5030009@oracle.com>
 <CALCETrV7zVbt0ZV4KYcSTUHjAOxzGmu3SXWoT7iECB=zWSN7Ew@mail.gmail.com>
 <CALCETrV275oYQY80yg6TJ-h9n2Db-uF-po90bF+JmKjnV5ZqYw@mail.gmail.com>
 <55B75993.90909@citrix.com>
 <CALCETrXt2OP=+JAj7gzUOJT+5=00Qg3Te11twSeK8F_9zn_nwg@mail.gmail.com>
 <55B7AE39.7000101@citrix.com>
 <CALCETrVd56uwkZw0YtaSHKHp5dh7NugQouigibJkr=e3Q_mYyA@mail.gmail.com>
 <55B7B791.2050208@oracle.com>
 <CALCETrXH5_PMqfH1en_5c+5gUpq8SjCnQ3Xaz-K6ej6FgBgLDQ@mail.gmail.com>
Cc: "security@kernel.org" <security@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        xen-devel <xen-devel@lists.xen.org>, Borislav Petkov <bp@alien8.de>,
        Jan Beulich <jbeulich@suse.com>, Sasha Levin <sasha.levin@oracle.com>
From: Andrew Cooper <andrew.cooper3@citrix.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55B822B8.3090608@citrix.com>
Date: Wed, 29 Jul 2015 01:47:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CALCETrXH5_PMqfH1en_5c+5gUpq8SjCnQ3Xaz-K6ej6FgBgLDQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 29/07/2015 01:21, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
>>> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
>>> <andrew.cooper3@citrix.com> wrote:
>>>> I suspect that the set_ldt(NULL, 0) call hasn't reached Xen before
>>>> xen_free_ldt() is attempting to nab back the pages which Xen still has
>>>> mapped as an LDT.
>>>>
>>> I just instrumented it with yet more LSL instructions.  I'm pretty
>>> sure that set_ldt really is clearing at least LDT entry zero.
>>> Nonetheless the free_ldt call still oopses.
>>>
>> Yes, I added some instrumentation to the hypervisor and we definitely set
>> LDT to NULL before failing.
>>
>> -boris
> Looking at map_ldt_shadow_page: what keeps shadow_ldt_mapcnt from
> getting incremented once on each CPU at the same time if both CPUs
> fault in the same shadow LDT page at the same time?

Nothing, but that is fine.  If a page is in use in two vcpus LDTs, it is
expected to have a type refcount of 2.

> Similarly, what
> keeps both CPUs from calling get_page_type at the same time and
> therefore losing track of the page type reference count?

a cmpxchg() loop in the depths of __get_page_type().

>
> I don't see why vmalloc or vm_unmap_aliases would have anything to do
> with this, though.

Nor me.  I have compiled your branch and will see about reproducing the
issue myself tomorrow.

~Andrew