From: Marek Szyprowski <m.szyprowski@samsung.com> To: Davidlohr Bueso <davidlohr@hp.com>, akpm@linux-foundation.org Cc: aswin@hp.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pawel Osciak <pawel@osciak.com>, Kyungmin Park <kyungmin.park@samsung.com>, Mauro Carvalho Chehab <m.chehab@samsung.com>, linux-media@vger.kernel.org Subject: Re: [PATCH 7/6] media: videobuf2-dma-sg: call find_vma with the mmap_sem held Date: Tue, 29 Apr 2014 10:35:29 +0200 [thread overview] Message-ID: <535F6451.1030403@samsung.com> (raw) In-Reply-To: <1398708571.25549.10.camel@buesod1.americas.hpqcorp.net> Hello, On 2014-04-28 20:09, 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 in order to avoid races while iterating through > the vmacache and/or rbtree. > > Also do some very minor cleanup changes. > > This patch is only compile tested. NACK. mm->mmap_sem is taken by videobuf2-core to avoid AB-BA deadlock with v4l2 core lock. For more information, please check videobuf2-core.c. However you are right that this is a bit confusing and we need more comments about the place where mmap_sem is taken. Here is some background for this decision: https://www.mail-archive.com/linux-media@vger.kernel.org/msg38599.html http://www.spinics.net/lists/linux-media/msg40225.html > Signed-off-by: Davidlohr Bueso <davidlohr@hp.com> > Cc: Pawel Osciak <pawel@osciak.com> > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > Cc: Kyungmin Park <kyungmin.park@samsung.com> > Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> > Cc: linux-media@vger.kernel.org > --- > It would seem this is the last offending user. > v4l2 is a maze but I believe that this is needed as I don't > see the mmap_sem being taken by any callers of vb2_dma_sg_get_userptr(). > > drivers/media/v4l2-core/videobuf2-dma-sg.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c > index c779f21..2a21100 100644 > --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c > +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c > @@ -168,8 +168,9 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > unsigned long first, last; > int num_pages_from_user; > struct vm_area_struct *vma; > + struct mm_struct *mm = current->mm; > > - buf = kzalloc(sizeof *buf, GFP_KERNEL); > + buf = kzalloc(sizeof(*buf), GFP_KERNEL); > if (!buf) > return NULL; > > @@ -178,7 +179,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->offset = vaddr & ~PAGE_MASK; > buf->size = size; > > - first = (vaddr & PAGE_MASK) >> PAGE_SHIFT; > + first = (vaddr & PAGE_MASK) >> PAGE_SHIFT; > last = ((vaddr + size - 1) & PAGE_MASK) >> PAGE_SHIFT; > buf->num_pages = last - first + 1; > > @@ -187,7 +188,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > if (!buf->pages) > goto userptr_fail_alloc_pages; > > - vma = find_vma(current->mm, vaddr); > + down_write(&mm->mmap_sem); > + vma = find_vma(mm, vaddr); > if (!vma) { > dprintk(1, "no vma for address %lu\n", vaddr); > goto userptr_fail_find_vma; > @@ -218,7 +220,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->pages[num_pages_from_user] = pfn_to_page(pfn); > } > } else > - num_pages_from_user = get_user_pages(current, current->mm, > + num_pages_from_user = get_user_pages(current, mm, > vaddr & PAGE_MASK, > buf->num_pages, > write, > @@ -233,6 +235,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->num_pages, buf->offset, size, 0)) > goto userptr_fail_alloc_table_from_pages; > > + up_write(&mm->mmap_sem); > return buf; > > userptr_fail_alloc_table_from_pages: > @@ -244,6 +247,7 @@ userptr_fail_get_user_pages: > put_page(buf->pages[num_pages_from_user]); > vb2_put_vma(buf->vma); > userptr_fail_find_vma: > + up_write(&mm->mmap_sem); > kfree(buf->pages); > userptr_fail_alloc_pages: > kfree(buf); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com> To: Davidlohr Bueso <davidlohr@hp.com>, akpm@linux-foundation.org Cc: aswin@hp.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pawel Osciak <pawel@osciak.com>, Kyungmin Park <kyungmin.park@samsung.com>, Mauro Carvalho Chehab <m.chehab@samsung.com>, linux-media@vger.kernel.org Subject: Re: [PATCH 7/6] media: videobuf2-dma-sg: call find_vma with the mmap_sem held Date: Tue, 29 Apr 2014 10:35:29 +0200 [thread overview] Message-ID: <535F6451.1030403@samsung.com> (raw) In-Reply-To: <1398708571.25549.10.camel@buesod1.americas.hpqcorp.net> Hello, On 2014-04-28 20:09, 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 in order to avoid races while iterating through > the vmacache and/or rbtree. > > Also do some very minor cleanup changes. > > This patch is only compile tested. NACK. mm->mmap_sem is taken by videobuf2-core to avoid AB-BA deadlock with v4l2 core lock. For more information, please check videobuf2-core.c. However you are right that this is a bit confusing and we need more comments about the place where mmap_sem is taken. Here is some background for this decision: https://www.mail-archive.com/linux-media@vger.kernel.org/msg38599.html http://www.spinics.net/lists/linux-media/msg40225.html > Signed-off-by: Davidlohr Bueso <davidlohr@hp.com> > Cc: Pawel Osciak <pawel@osciak.com> > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > Cc: Kyungmin Park <kyungmin.park@samsung.com> > Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> > Cc: linux-media@vger.kernel.org > --- > It would seem this is the last offending user. > v4l2 is a maze but I believe that this is needed as I don't > see the mmap_sem being taken by any callers of vb2_dma_sg_get_userptr(). > > drivers/media/v4l2-core/videobuf2-dma-sg.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c > index c779f21..2a21100 100644 > --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c > +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c > @@ -168,8 +168,9 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > unsigned long first, last; > int num_pages_from_user; > struct vm_area_struct *vma; > + struct mm_struct *mm = current->mm; > > - buf = kzalloc(sizeof *buf, GFP_KERNEL); > + buf = kzalloc(sizeof(*buf), GFP_KERNEL); > if (!buf) > return NULL; > > @@ -178,7 +179,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->offset = vaddr & ~PAGE_MASK; > buf->size = size; > > - first = (vaddr & PAGE_MASK) >> PAGE_SHIFT; > + first = (vaddr & PAGE_MASK) >> PAGE_SHIFT; > last = ((vaddr + size - 1) & PAGE_MASK) >> PAGE_SHIFT; > buf->num_pages = last - first + 1; > > @@ -187,7 +188,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > if (!buf->pages) > goto userptr_fail_alloc_pages; > > - vma = find_vma(current->mm, vaddr); > + down_write(&mm->mmap_sem); > + vma = find_vma(mm, vaddr); > if (!vma) { > dprintk(1, "no vma for address %lu\n", vaddr); > goto userptr_fail_find_vma; > @@ -218,7 +220,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->pages[num_pages_from_user] = pfn_to_page(pfn); > } > } else > - num_pages_from_user = get_user_pages(current, current->mm, > + num_pages_from_user = get_user_pages(current, mm, > vaddr & PAGE_MASK, > buf->num_pages, > write, > @@ -233,6 +235,7 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx, unsigned long vaddr, > buf->num_pages, buf->offset, size, 0)) > goto userptr_fail_alloc_table_from_pages; > > + up_write(&mm->mmap_sem); > return buf; > > userptr_fail_alloc_table_from_pages: > @@ -244,6 +247,7 @@ userptr_fail_get_user_pages: > put_page(buf->pages[num_pages_from_user]); > vb2_put_vma(buf->vma); > userptr_fail_find_vma: > + up_write(&mm->mmap_sem); > kfree(buf->pages); > userptr_fail_alloc_pages: > kfree(buf); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-04-29 8:35 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-20 2:26 [PATCH 0/6] mm: audit find_vma() callers Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-20 2:26 ` [PATCH 1/6] blackfin/ptrace: call find_vma with the mmap_sem held Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-22 3:07 ` Steven Miao 2014-04-22 3:07 ` Steven Miao 2014-04-20 2:26 ` [PATCH 2/6] m68k: call find_vma with the mmap_sem held in sys_cacheflush() Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-20 8:04 ` Geert Uytterhoeven 2014-04-20 8:04 ` Geert Uytterhoeven 2014-04-20 8:04 ` Geert Uytterhoeven 2014-04-20 22:28 ` Davidlohr Bueso 2014-04-20 22:28 ` Davidlohr Bueso 2014-04-20 22:28 ` Davidlohr Bueso 2014-04-21 7:52 ` Geert Uytterhoeven 2014-04-21 7:52 ` Geert Uytterhoeven 2014-04-21 7:52 ` Geert Uytterhoeven [not found] ` <OF5CEC4294.867C780E-ONCA257CCB.00315352-CA257CCB.003674E6@csc.com> 2014-05-01 14:05 ` Linux-3.15-rcX - PowerPC Serial Console woes Geert Uytterhoeven 2014-08-07 22:44 ` [PATCH 2/6] m68k: call find_vma with the mmap_sem held in sys_cacheflush() Davidlohr Bueso 2014-08-07 22:44 ` Davidlohr Bueso 2014-08-07 22:44 ` Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-20 2:26 ` [PATCH 3/6] mips: call find_vma with the mmap_sem held Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-22 13:25 ` Andreas Herrmann 2014-04-22 13:25 ` Andreas Herrmann 2014-04-20 2:26 ` [PATCH 4/6] arc: " Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-22 6:02 ` Vineet Gupta 2014-04-22 6:02 ` Vineet Gupta 2014-04-20 2:26 ` [PATCH 5/6] drivers,sgi-gru/grufault.c: " Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-21 13:36 ` Dimitri Sivanich 2014-04-21 13:36 ` Dimitri Sivanich 2014-04-20 2:26 ` [PATCH 6/6] drm/exynos: " Davidlohr Bueso 2014-04-20 2:26 ` Davidlohr Bueso 2014-04-28 18:09 ` [PATCH 7/6] media: videobuf2-dma-sg: " Davidlohr Bueso 2014-04-28 18:09 ` Davidlohr Bueso 2014-04-29 8:35 ` Marek Szyprowski [this message] 2014-04-29 8:35 ` Marek Szyprowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=535F6451.1030403@samsung.com \ --to=m.szyprowski@samsung.com \ --cc=akpm@linux-foundation.org \ --cc=aswin@hp.com \ --cc=davidlohr@hp.com \ --cc=kyungmin.park@samsung.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=m.chehab@samsung.com \ --cc=pawel@osciak.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.