From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Abd-El-Malek Subject: Re: Vanilla Linux and has_foreign_mapping Date: Mon, 21 Apr 2008 14:00:06 -0400 Message-ID: <480CD626.6030207@cmu.edu> References: <480BB358.3070508@cmu.edu> <480C7EA5.4070007@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <480C7EA5.4070007@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Mark McLoughlin , xen-devel , Eduardo Habkost List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge wrote: > Michael Abd-El-Malek wrote: >> I'm trying to add support to Linux 2.6.25 for the >> "has_foreign_mappings" MMU context flag. Xen's Linux 2.6.18 tree uses >> this flag, so that page tables are properly disposed of when an >> application exits when it has foreign mappings. > > I was hoping to avoid having to introduce that flag, but I have to admit > I haven't given it much analysis. How are you using it? A user-level application has a page table entry pointing to another domain's page. My virtual memory area's zap_pte handler (which I added to 2.6.25, a la 2.6.18) unmaps the grant. But on application exit on 2.6.25, my zap_pte function runs too late. There's a comment in gntdev.c that explains the need for has_foreign_mappings: /* This flag ensures that the page tables are not unpinned before the * VM area is unmapped. Therefore Xen still recognises the PTE as * belonging to an L1 pagetable, and the grant unmap operation will * succeed, even if the process does not exit cleanly. */ >> See: >> http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00038.html >> >> Unfortunately, I got the following kernel crash on process exit: >> >> BUG: unable to handle kernel paging request at ebdae008 >> IP: [] pgd_mop_up_pmds+0x6a/0xd8 > > Which line is that? My original 2.6.25 kernel didn't have debugging support, preventing objdump -S from giving me address-to-source-line translations. I rebuilt the kernel and here is the new stack dump: BUG: unable to handle kernel paging request at ebb11008 IP: [] pgd_mop_up_pmds+0x7b/0xe6 *pdpt = 000000007f01a027 Oops: 0003 [#1] SMP Modules linked in: efsvm(F) nfs lockd sunrpc dm_snapshot dm_mirror dm_mod Pid: 2607, comm: a.out Tainted: GF (2.6.25 #12) EIP: 0061:[] EFLAGS: 00010246 CPU: 0 EIP is at pgd_mop_up_pmds+0x7b/0xe6 EAX: ebb11000 EBX: 00000000 ECX: 00000001 EDX: 00000000 ESI: 7edc3007 EDI: eb8533f4 EBP: ebaedf28 ESP: ebaedefc DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 Process a.out (pid: 2607, ti=ebaec000 task=ed3f4ed0 task.ti=ebaec000) Stack: 2bb01007 00000000 00000000 00000000 ebb11000 00000001 00000000 2bb01007 ebb11000 ed3f4ed0 eb8533f4 ebaedf34 c0115c44 eb8533c0 ebaedf40 c0121bad eb8533c0 ebaedf4c c0121c34 eb8533c0 ebaedf60 c01250f2 00000000 ed3f4ed0 Call Trace: [] ? pgd_free+0xb/0x1e [] ? __mmdrop+0x19/0x2f [] ? mmput+0x71/0x74 [] ? exit_mm+0xd5/0xda [] ? do_exit+0x1b3/0x56f [] ? do_group_exit+0x6d/0x84 [] ? sys_exit_group+0xf/0x11 [] ? syscall_call+0x7/0xb ======================= Code: 00 00 00 89 55 dc 8b 45 dc 0b 45 d4 89 4d e0 09 c1 74 61 89 f0 89 da e8 8f d8 fe ff 90 89 45 f0 8b 4d e8 8b 45 e4 89 55 ec 89 da 04 c8 00 00 00 00 c7 44 c8 04 00 00 00 00 89 f0 e8 6a d8 fe EIP: [] pgd_mop_up_pmds+0x7b/0xe6 SS:ESP 0069:ebaedefc ---[ end trace b8f5f274f55408cd ]--- Fixing recursive fault but reboot is needed! pgd_free calls pgd_mop_up_pmds, where the crash is occurring at c0115b7b. Here's the relevant assembly and source code: pmd_t *pmd = (pmd_t *)pgd_page_vaddr(pgd); pgdp[i] = native_make_pgd(0); c0115b70: 8b 4d e8 mov -0x18(%ebp),%ecx c0115b73: 8b 45 e4 mov -0x1c(%ebp),%eax c0115b76: 89 55 ec mov %edx,-0x14(%ebp) c0115b79: 89 da mov %ebx,%edx c0115b7b: c7 04 c8 00 00 00 00 movl $0x0,(%eax,%ecx,8) c0115b82: c7 44 c8 04 00 00 00 movl $0x0,0x4(%eax,%ecx,8) c0115b89: 00 c0115b8a: 89 f0 mov %esi,%eax c0115b8c: ff 15 a0 5b 4c c0 call *0xc04c5ba0 { Any hints? Thanks, Mike