From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755830Ab2LGHoO (ORCPT ); Fri, 7 Dec 2012 02:44:14 -0500 Received: from mail-ea0-f174.google.com ([209.85.215.174]:48733 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754741Ab2LGHoN (ORCPT ); Fri, 7 Dec 2012 02:44:13 -0500 MIME-Version: 1.0 In-Reply-To: <1354810175-4338-2-git-send-email-js1304@gmail.com> References: <1354810175-4338-1-git-send-email-js1304@gmail.com> <1354810175-4338-2-git-send-email-js1304@gmail.com> Date: Fri, 7 Dec 2012 09:44:11 +0200 X-Google-Sender-Auth: 7HBxvAmdTPUkBRG5TQl1CVevo84 Message-ID: Subject: Re: [RFC PATCH 1/8] mm, vmalloc: change iterating a vmlist to find_vm_area() From: Pekka Enberg To: Joonsoo Kim Cc: Andrew Morton , Russell King , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org, Chris Metcalf , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 6, 2012 at 6:09 PM, Joonsoo Kim wrote: > The purpose of iterating a vmlist is finding vm area with specific > virtual address. find_vm_area() is provided for this purpose > and more efficient, because it uses a rbtree. > So change it. You no longer take the 'vmlist_lock'. This is safe, because...? > Cc: Chris Metcalf > Cc: Guan Xuetao > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Signed-off-by: Joonsoo Kim > > diff --git a/arch/tile/mm/pgtable.c b/arch/tile/mm/pgtable.c > index de0de0c..862782d 100644 > --- a/arch/tile/mm/pgtable.c > +++ b/arch/tile/mm/pgtable.c > @@ -592,12 +592,7 @@ void iounmap(volatile void __iomem *addr_in) > in parallel. Reuse of the virtual address is prevented by > leaving it in the global lists until we're done with it. > cpa takes care of the direct mappings. */ > - read_lock(&vmlist_lock); > - for (p = vmlist; p; p = p->next) { > - if (p->addr == addr) > - break; > - } > - read_unlock(&vmlist_lock); > + p = find_vm_area((void *)addr); > > if (!p) { > pr_err("iounmap: bad address %p\n", addr); > diff --git a/arch/unicore32/mm/ioremap.c b/arch/unicore32/mm/ioremap.c > index b7a6055..13068ee 100644 > --- a/arch/unicore32/mm/ioremap.c > +++ b/arch/unicore32/mm/ioremap.c > @@ -235,7 +235,7 @@ EXPORT_SYMBOL(__uc32_ioremap_cached); > void __uc32_iounmap(volatile void __iomem *io_addr) > { > void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr); > - struct vm_struct **p, *tmp; > + struct vm_struct *vm; > > /* > * If this is a section based mapping we need to handle it > @@ -244,17 +244,10 @@ void __uc32_iounmap(volatile void __iomem *io_addr) > * all the mappings before the area can be reclaimed > * by someone else. > */ > - write_lock(&vmlist_lock); > - for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) { > - if ((tmp->flags & VM_IOREMAP) && (tmp->addr == addr)) { > - if (tmp->flags & VM_UNICORE_SECTION_MAPPING) { > - unmap_area_sections((unsigned long)tmp->addr, > - tmp->size); > - } > - break; > - } > - } > - write_unlock(&vmlist_lock); > + vm = find_vm_area(addr); > + if (vm && (vm->flags & VM_IOREMAP) && > + (vm->flags & VM_UNICORE_SECTION_MAPPING)) > + unmap_area_sections((unsigned long)vm->addr, vm->size); > > vunmap(addr); > } > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c > index 78fe3f1..9a1e658 100644 > --- a/arch/x86/mm/ioremap.c > +++ b/arch/x86/mm/ioremap.c > @@ -282,12 +282,7 @@ void iounmap(volatile void __iomem *addr) > in parallel. Reuse of the virtual address is prevented by > leaving it in the global lists until we're done with it. > cpa takes care of the direct mappings. */ > - read_lock(&vmlist_lock); > - for (p = vmlist; p; p = p->next) { > - if (p->addr == (void __force *)addr) > - break; > - } > - read_unlock(&vmlist_lock); > + p = find_vm_area((void __force *)addr); > > if (!p) { > printk(KERN_ERR "iounmap: bad address %p\n", addr); > -- > 1.7.9.5 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org