On Tue, 11 Nov 2014, Dave Hansen wrote:
> On 11/11/2014 10:27 AM, Thomas Gleixner wrote:
> > On Thu, 6 Nov 2014, Dave Hansen wrote:
> >> Instead of all of these games with dropping and reacquiring mmap_sem and
> >> adding other locks, or deferring the work, why don't we just do a
> >>
On 11/11/2014 10:27 AM, Thomas Gleixner wrote:
> On Thu, 6 Nov 2014, Dave Hansen wrote:
>> Instead of all of these games with dropping and reacquiring mmap_sem and
>> adding other locks, or deferring the work, why don't we just do a
>> get_user_pages()? Something along the lines of:
>>
>> while
On Thu, 6 Nov 2014, Dave Hansen wrote:
> Instead of all of these games with dropping and reacquiring mmap_sem and
> adding other locks, or deferring the work, why don't we just do a
> get_user_pages()? Something along the lines of:
>
> while (1) {
> ret = cmpxchg(addr)
> if (!ret)
>
On Thu, 6 Nov 2014, Dave Hansen wrote:
Instead of all of these games with dropping and reacquiring mmap_sem and
adding other locks, or deferring the work, why don't we just do a
get_user_pages()? Something along the lines of:
while (1) {
ret = cmpxchg(addr)
if (!ret)
On 11/11/2014 10:27 AM, Thomas Gleixner wrote:
On Thu, 6 Nov 2014, Dave Hansen wrote:
Instead of all of these games with dropping and reacquiring mmap_sem and
adding other locks, or deferring the work, why don't we just do a
get_user_pages()? Something along the lines of:
while (1) {
On Tue, 11 Nov 2014, Dave Hansen wrote:
On 11/11/2014 10:27 AM, Thomas Gleixner wrote:
On Thu, 6 Nov 2014, Dave Hansen wrote:
Instead of all of these games with dropping and reacquiring mmap_sem and
adding other locks, or deferring the work, why don't we just do a
get_user_pages()?
Instead of all of these games with dropping and reacquiring mmap_sem and
adding other locks, or deferring the work, why don't we just do a
get_user_pages()? Something along the lines of:
while (1) {
ret = cmpxchg(addr)
if (!ret)
break;
if (ret == -EFAULT)
Instead of all of these games with dropping and reacquiring mmap_sem and
adding other locks, or deferring the work, why don't we just do a
get_user_pages()? Something along the lines of:
while (1) {
ret = cmpxchg(addr)
if (!ret)
break;
if (ret == -EFAULT)
On Tue, 4 Nov 2014, Dave Hansen wrote:
> On 11/03/2014 01:29 PM, Thomas Gleixner wrote:
> > On Mon, 3 Nov 2014, Dave Hansen wrote:
>
> > That's not really true. You can evaluate that information with
> > mmap_sem held for read as well. Nothing can change the mappings until
> > you drop it. So you
On 11/03/2014 01:29 PM, Thomas Gleixner wrote:
> On Mon, 3 Nov 2014, Dave Hansen wrote:
> That's not really true. You can evaluate that information with
> mmap_sem held for read as well. Nothing can change the mappings until
> you drop it. So you could do:
>
>down_write(mm->bd_sem);
>
On 11/03/2014 01:29 PM, Thomas Gleixner wrote:
On Mon, 3 Nov 2014, Dave Hansen wrote:
That's not really true. You can evaluate that information with
mmap_sem held for read as well. Nothing can change the mappings until
you drop it. So you could do:
down_write(mm-bd_sem);
On Tue, 4 Nov 2014, Dave Hansen wrote:
On 11/03/2014 01:29 PM, Thomas Gleixner wrote:
On Mon, 3 Nov 2014, Dave Hansen wrote:
That's not really true. You can evaluate that information with
mmap_sem held for read as well. Nothing can change the mappings until
you drop it. So you could do:
On Mon, 3 Nov 2014, Dave Hansen wrote:
> On 10/27/2014 01:49 PM, Thomas Gleixner wrote:
> > Errm. Before user space can use the bounds table for the new mapping
> > it needs to add the entries, right? So:
> >
> > CPU 0 CPU 1
> >
> > down_write(mm->bd_sem);
>
On 10/27/2014 01:49 PM, Thomas Gleixner wrote:
> Errm. Before user space can use the bounds table for the new mapping
> it needs to add the entries, right? So:
>
> CPU 0 CPU 1
>
> down_write(mm->bd_sem);
> mpx_pre_unmap();
>clear bounds directory entries
On 10/27/2014 01:49 PM, Thomas Gleixner wrote:
Errm. Before user space can use the bounds table for the new mapping
it needs to add the entries, right? So:
CPU 0 CPU 1
down_write(mm-bd_sem);
mpx_pre_unmap();
clear bounds directory entries
unmap();
On Mon, 3 Nov 2014, Dave Hansen wrote:
On 10/27/2014 01:49 PM, Thomas Gleixner wrote:
Errm. Before user space can use the bounds table for the new mapping
it needs to add the entries, right? So:
CPU 0 CPU 1
down_write(mm-bd_sem);
On Tue, 28 Oct 2014, Ren Qiaowei wrote:
> On 10/28/2014 04:49 AM, Thomas Gleixner wrote:
> > On Mon, 27 Oct 2014, Ren Qiaowei wrote:
> > > If so, I guess that there are some questions needed to be considered:
> > >
> > > 1) Almost all palces which call do_munmap() will need to add
> > >
On 10/28/2014 04:49 AM, Thomas Gleixner wrote:
On Mon, 27 Oct 2014, Ren Qiaowei wrote:
If so, I guess that there are some questions needed to be considered:
1) Almost all palces which call do_munmap() will need to add
mpx_pre_unmap/post_unmap calls, like vm_munmap(), mremap(), shmdt(), etc..
On 10/28/2014 04:49 AM, Thomas Gleixner wrote:
On Mon, 27 Oct 2014, Ren Qiaowei wrote:
If so, I guess that there are some questions needed to be considered:
1) Almost all palces which call do_munmap() will need to add
mpx_pre_unmap/post_unmap calls, like vm_munmap(), mremap(), shmdt(), etc..
On Tue, 28 Oct 2014, Ren Qiaowei wrote:
On 10/28/2014 04:49 AM, Thomas Gleixner wrote:
On Mon, 27 Oct 2014, Ren Qiaowei wrote:
If so, I guess that there are some questions needed to be considered:
1) Almost all palces which call do_munmap() will need to add
mpx_pre_unmap/post_unmap
On Mon, 27 Oct 2014, Ren Qiaowei wrote:
> If so, I guess that there are some questions needed to be considered:
>
> 1) Almost all palces which call do_munmap() will need to add
> mpx_pre_unmap/post_unmap calls, like vm_munmap(), mremap(), shmdt(), etc..
What's the problem with that?
> 2)
On Mon, 27 Oct 2014, Ren Qiaowei wrote:
If so, I guess that there are some questions needed to be considered:
1) Almost all palces which call do_munmap() will need to add
mpx_pre_unmap/post_unmap calls, like vm_munmap(), mremap(), shmdt(), etc..
What's the problem with that?
2) before
On 10/24/2014 10:40 PM, Thomas Gleixner wrote:
On Sun, 12 Oct 2014, Qiaowei Ren wrote:
Since we are doing the freeing from munmap() (and other paths like it),
we hold mmap_sem for write. If we fault, the page fault handler will
attempt to acquire mmap_sem for read and we will deadlock. For now,
On 10/24/2014 10:40 PM, Thomas Gleixner wrote:
On Sun, 12 Oct 2014, Qiaowei Ren wrote:
Since we are doing the freeing from munmap() (and other paths like it),
we hold mmap_sem for write. If we fault, the page fault handler will
attempt to acquire mmap_sem for read and we will deadlock. For now,
On Sun, 12 Oct 2014, Qiaowei Ren wrote:
> Since we are doing the freeing from munmap() (and other paths like it),
> we hold mmap_sem for write. If we fault, the page fault handler will
> attempt to acquire mmap_sem for read and we will deadlock. For now, to
> avoid deadlock, we disable page faults
On Sun, 12 Oct 2014, Qiaowei Ren wrote:
Since we are doing the freeing from munmap() (and other paths like it),
we hold mmap_sem for write. If we fault, the page fault handler will
attempt to acquire mmap_sem for read and we will deadlock. For now, to
avoid deadlock, we disable page faults
There are two mappings in play: 1. The mapping with the actual data,
which userspace is munmap()ing or brk()ing away, etc... 2. The mapping
for the bounds table *backing* the data (is tagged with mpx_vma_ops,
see the patch "add MPX specific mmap interface").
If userspace use the prctl()
There are two mappings in play: 1. The mapping with the actual data,
which userspace is munmap()ing or brk()ing away, etc... 2. The mapping
for the bounds table *backing* the data (is tagged with mpx_vma_ops,
see the patch add MPX specific mmap interface).
If userspace use the prctl() indroduced
28 matches
Mail list logo
