Re: [PATCH] mm: protect against concurrent vma expansion

2013-01-03 Thread Al Viro
On Thu, Jan 03, 2013 at 06:40:05PM -0600, Simon Jeons wrote: > On Wed, 2012-12-19 at 19:01 -0800, Michel Lespinasse wrote: > > Hi Simon, > > > > On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote: > > > One question. > > > > > > I found that mainly callsite of expand_stack() is #PF, but it holds

Re: [PATCH] mm: protect against concurrent vma expansion

2013-01-03 Thread Simon Jeons
On Thu, 2013-01-03 at 16:50 -0800, Michel Lespinasse wrote: > On Thu, Jan 3, 2013 at 4:40 PM, Simon Jeons wrote: > > On Wed, 2012-12-19 at 19:01 -0800, Michel Lespinasse wrote: > >> Hi Simon, > >> > >> On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote: > >> > One question. > >> > > >> > I found

Re: [PATCH] mm: protect against concurrent vma expansion

2013-01-03 Thread Michel Lespinasse
On Thu, Jan 3, 2013 at 4:40 PM, Simon Jeons wrote: > On Wed, 2012-12-19 at 19:01 -0800, Michel Lespinasse wrote: >> Hi Simon, >> >> On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote: >> > One question. >> > >> > I found that mainly callsite of expand_stack() is #PF, but it holds >> > mmap_sem ea

Re: [PATCH] mm: protect against concurrent vma expansion

2013-01-03 Thread Simon Jeons
On Wed, 2012-12-19 at 19:01 -0800, Michel Lespinasse wrote: > Hi Simon, > > On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote: > > One question. > > > > I found that mainly callsite of expand_stack() is #PF, but it holds > > mmap_sem each time before call expand_stack(), how can hold a *shared*

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-19 Thread Michel Lespinasse
Hi Simon, On Wed, Dec 19, 2012 at 5:56 PM, Simon Jeons wrote: > One question. > > I found that mainly callsite of expand_stack() is #PF, but it holds > mmap_sem each time before call expand_stack(), how can hold a *shared* > mmap_sem happen? the #PF handler calls down_read(&mm->mmap_sem) before

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-19 Thread Simon Jeons
On Tue, 2012-12-04 at 06:48 -0800, Michel Lespinasse wrote: > expand_stack() runs with a shared mmap_sem lock. Because of this, there > could be multiple concurrent stack expansions in the same mm, which may > cause problems in the vma gap update code. > > I propose to solve this by taking the mm-

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-04 Thread Michel Lespinasse
expand_stack() runs with a shared mmap_sem lock. Because of this, there could be multiple concurrent stack expansions in the same mm, which may cause problems in the vma gap update code. I propose to solve this by taking the mm->page_table_lock around such vma expansions, in order to avoid the con

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-03 Thread Andrew Morton
On Mon, 3 Dec 2012 16:35:01 -0800 Michel Lespinasse wrote: > On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton > wrote: > > On Fri, 30 Nov 2012 22:56:27 -0800 > > Michel Lespinasse wrote: > > > >> expand_stack() runs with a shared mmap_sem lock. Because of this, there > >> could be multiple concur

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-03 Thread Michel Lespinasse
On Mon, Dec 3, 2012 at 3:01 PM, Andrew Morton wrote: > On Fri, 30 Nov 2012 22:56:27 -0800 > Michel Lespinasse wrote: > >> expand_stack() runs with a shared mmap_sem lock. Because of this, there >> could be multiple concurrent stack expansions in the same mm, which may >> cause problems in the vma

Re: [PATCH] mm: protect against concurrent vma expansion

2012-12-03 Thread Andrew Morton
On Fri, 30 Nov 2012 22:56:27 -0800 Michel Lespinasse wrote: > expand_stack() runs with a shared mmap_sem lock. Because of this, there > could be multiple concurrent stack expansions in the same mm, which may > cause problems in the vma gap update code. > > I propose to solve this by taking the m

[PATCH] mm: protect against concurrent vma expansion

2012-11-30 Thread Michel Lespinasse
expand_stack() runs with a shared mmap_sem lock. Because of this, there could be multiple concurrent stack expansions in the same mm, which may cause problems in the vma gap update code. I propose to solve this by taking the mm->page_table_lock around such vma expansions, in order to avoid the con