linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Question on i_mmap_mutex locking rule
@ 2012-04-02 12:04 Aneesh Kumar K.V
  2012-04-10  6:44 ` KAMEZAWA Hiroyuki
  0 siblings, 1 reply; 2+ messages in thread
From: Aneesh Kumar K.V @ 2012-04-02 12:04 UTC (permalink / raw)
  To: KAMEZAWA Hiroyuki, Andrew Morton; +Cc: linux-mm


Hi,

I started looking at unmap_hugepage_range. unmap_hugepage_range takes
i_mmap_mutex. But then the same lock is also taken higher up in the
stack. ie via the below chain

unmap_mapping_range (i_mmap_mutex)
 -> unmap_mapping_range_tree
    -> unmap_mapping_range_vma
       -> zap_page_range_single
          -> unmap_single_vma
             -> unmap_hugepage_range (i_mmap_mutex)

But there are other code path that doesn't take i_mmap_mutex. For ex:
-> madvise_dontneed
   -> zap_page_range
      -> unmap_vmas
         -> unmap_single_vma
            -> unmap_page_range
      

similarly unmap_region also don't take i_mmap_mutex. Don't we need to
ensure that we take i_mmap_mutex when we unmap a file backed range ?

-aneesh

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question on i_mmap_mutex locking rule
  2012-04-02 12:04 Question on i_mmap_mutex locking rule Aneesh Kumar K.V
@ 2012-04-10  6:44 ` KAMEZAWA Hiroyuki
  0 siblings, 0 replies; 2+ messages in thread
From: KAMEZAWA Hiroyuki @ 2012-04-10  6:44 UTC (permalink / raw)
  To: Aneesh Kumar K.V; +Cc: Andrew Morton, linux-mm

(2012/04/02 21:04), Aneesh Kumar K.V wrote:

> 
> Hi,
> 
> I started looking at unmap_hugepage_range. unmap_hugepage_range takes
> i_mmap_mutex. But then the same lock is also taken higher up in the
> stack. ie via the below chain
> 
> unmap_mapping_range (i_mmap_mutex)
>  -> unmap_mapping_range_tree
>     -> unmap_mapping_range_vma
>        -> zap_page_range_single
>           -> unmap_single_vma
>              -> unmap_hugepage_range (i_mmap_mutex)
> 


why not deadlock ?

> But there are other code path that doesn't take i_mmap_mutex. For ex:
> -> madvise_dontneed
>    -> zap_page_range
>       -> unmap_vmas
>          -> unmap_single_vma
>             -> unmap_page_range
>       
> 


IIUC, DONTNEED will not change vma layout...so it doesn't require
i_mmap_mutex.

Thanks,
-Kame 


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-04-10  6:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-02 12:04 Question on i_mmap_mutex locking rule Aneesh Kumar K.V
2012-04-10  6:44 ` KAMEZAWA Hiroyuki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).