Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751314AbbG2E05 (ORCPT ); Wed, 29 Jul 2015 00:26:57 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:36490 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbbG2E04 (ORCPT ); Wed, 29 Jul 2015 00:26:56 -0400 MIME-Version: 1.0 In-Reply-To: <55B841FF.2000102@oracle.com> References: <55B64FEA.70204@oracle.com> <55B659EC.5030009@oracle.com> <55B75993.90909@citrix.com> <55B7AE39.7000101@citrix.com> <55B7B791.2050208@oracle.com> <55B822B8.3090608@citrix.com> <55B841FF.2000102@oracle.com> From: Andy Lutomirski Date: Tue, 28 Jul 2015 21:26:35 -0700 Message-ID: Subject: Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option To: Boris Ostrovsky Cc: Andrew Cooper , "security@kernel.org" , Peter Zijlstra , X86 ML , "linux-kernel@vger.kernel.org" , Steven Rostedt , xen-devel , Borislav Petkov , Jan Beulich , Sasha Levin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2285 Lines: 63 On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky wrote: > On 07/28/2015 08:47 PM, Andrew Cooper wrote: >> >> On 29/07/2015 01:21, Andy Lutomirski wrote: >>> >>> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky >>> wrote: >>>> >>>> On 07/28/2015 01:07 PM, Andy Lutomirski wrote: >>>>> >>>>> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper >>>>> 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. > > > So just for kicks I made lazy_max_pages() return 0 to free vmaps immediately > and the problem went away. > > I also saw this warning, BTW: > > [ 178.686542] ------------[ cut here ]------------ > [ 178.686554] WARNING: CPU: 0 PID: 16440 at > ./arch/x86/include/asm/mmu_context.h:96 load_mm_ldt+0x70/0x76() > [ 178.686558] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) Whoops! That should be checking preemptible(), not irqs_disabled(). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/