Re: [PATCH 3/6] mips: call find_vma with the mmap_sem held

2014-04-22 Thread Andreas Herrmann
On Sat, Apr 19, 2014 at 07:26:28PM -0700, Davidlohr Bueso wrote:
> Performing vma lookups without taking the mm->mmap_sem is asking
> for trouble. While doing the search, the vma in question can be
> modified or even removed before returning to the caller. Take the
> lock (exclusively) in order to avoid races while iterating through
> the vmacache and/or rbtree.
> 
> Updates two functions:
>   - process_fpemu_return()
>   - cteon_flush_cache_sigtramp()
> 
> This patch is completely *untested*.
> 
> Signed-off-by: Davidlohr Bueso 
> Cc: Ralf Baechle 
> Cc: linux-m...@linux-mips.org

Tested-by: Andreas Herrmann 


Thanks,

Andreas

> ---
>  arch/mips/kernel/traps.c | 2 ++
>  arch/mips/mm/c-octeon.c  | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index 074e857..c51bd20 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -712,10 +712,12 @@ int process_fpemu_return(int sig, void __user 
> *fault_addr)
>   si.si_addr = fault_addr;
>   si.si_signo = sig;
>   if (sig == SIGSEGV) {
> + down_read(>mm->mmap_sem);
>   if (find_vma(current->mm, (unsigned long)fault_addr))
>   si.si_code = SEGV_ACCERR;
>   else
>   si.si_code = SEGV_MAPERR;
> + up_read(>mm->mmap_sem);
>   } else {
>   si.si_code = BUS_ADRERR;
>   }
> diff --git a/arch/mips/mm/c-octeon.c b/arch/mips/mm/c-octeon.c
> index f41a5c5..05b1d7c 100644
> --- a/arch/mips/mm/c-octeon.c
> +++ b/arch/mips/mm/c-octeon.c
> @@ -137,8 +137,10 @@ static void octeon_flush_cache_sigtramp(unsigned long 
> addr)
>  {
>   struct vm_area_struct *vma;
>  
> + down_read(>mm->mmap_sem);
>   vma = find_vma(current->mm, addr);
>   octeon_flush_icache_all_cores(vma);
> + up_read(>mm->mmap_sem);
>  }
>  
>  
> -- 
> 1.8.1.4
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/6] mips: call find_vma with the mmap_sem held

2014-04-22 Thread Andreas Herrmann
On Sat, Apr 19, 2014 at 07:26:28PM -0700, Davidlohr Bueso wrote:
 Performing vma lookups without taking the mm-mmap_sem is asking
 for trouble. While doing the search, the vma in question can be
 modified or even removed before returning to the caller. Take the
 lock (exclusively) in order to avoid races while iterating through
 the vmacache and/or rbtree.
 
 Updates two functions:
   - process_fpemu_return()
   - cteon_flush_cache_sigtramp()
 
 This patch is completely *untested*.
 
 Signed-off-by: Davidlohr Bueso davidl...@hp.com
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: linux-m...@linux-mips.org

Tested-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com


Thanks,

Andreas

 ---
  arch/mips/kernel/traps.c | 2 ++
  arch/mips/mm/c-octeon.c  | 2 ++
  2 files changed, 4 insertions(+)
 
 diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
 index 074e857..c51bd20 100644
 --- a/arch/mips/kernel/traps.c
 +++ b/arch/mips/kernel/traps.c
 @@ -712,10 +712,12 @@ int process_fpemu_return(int sig, void __user 
 *fault_addr)
   si.si_addr = fault_addr;
   si.si_signo = sig;
   if (sig == SIGSEGV) {
 + down_read(current-mm-mmap_sem);
   if (find_vma(current-mm, (unsigned long)fault_addr))
   si.si_code = SEGV_ACCERR;
   else
   si.si_code = SEGV_MAPERR;
 + up_read(current-mm-mmap_sem);
   } else {
   si.si_code = BUS_ADRERR;
   }
 diff --git a/arch/mips/mm/c-octeon.c b/arch/mips/mm/c-octeon.c
 index f41a5c5..05b1d7c 100644
 --- a/arch/mips/mm/c-octeon.c
 +++ b/arch/mips/mm/c-octeon.c
 @@ -137,8 +137,10 @@ static void octeon_flush_cache_sigtramp(unsigned long 
 addr)
  {
   struct vm_area_struct *vma;
  
 + down_read(current-mm-mmap_sem);
   vma = find_vma(current-mm, addr);
   octeon_flush_icache_all_cores(vma);
 + up_read(current-mm-mmap_sem);
  }
  
  
 -- 
 1.8.1.4
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/