On Fri, Sep 15, 2017 at 02:38:51PM +0200, Laurent Dufour wrote:
> > /*
> > * well... answering your question - it seems raw versions of seqcount
> > * functions don't call lockdep's lock_acquire/lock_release...
> > *
> > * but I have never told you that. never.
> > */
>
> Hum... I'm not
Hi,
On 14/09/2017 11:40, Sergey Senozhatsky wrote:
> On (09/14/17 11:15), Laurent Dufour wrote:
>> On 14/09/2017 11:11, Sergey Senozhatsky wrote:
>>> On (09/14/17 10:58), Laurent Dufour wrote:
>>> [..]
That's right, but here this is the sequence counter mm->mm_seq, not the
vm_seq one.
>
On (09/14/17 11:15), Laurent Dufour wrote:
> On 14/09/2017 11:11, Sergey Senozhatsky wrote:
> > On (09/14/17 10:58), Laurent Dufour wrote:
> > [..]
> >> That's right, but here this is the sequence counter mm->mm_seq, not the
> >> vm_seq one.
> >
> > d'oh... you are right.
>
> So I'm doubting abo
On 14/09/2017 11:11, Sergey Senozhatsky wrote:
> On (09/14/17 10:58), Laurent Dufour wrote:
> [..]
>> That's right, but here this is the sequence counter mm->mm_seq, not the
>> vm_seq one.
>
> d'oh... you are right.
So I'm doubting about the probability of a deadlock here, but I don't like
to se
On (09/14/17 10:58), Laurent Dufour wrote:
[..]
> That's right, but here this is the sequence counter mm->mm_seq, not the
> vm_seq one.
d'oh... you are right.
-ss
On 14/09/2017 10:13, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/14/17 09:55), Laurent Dufour wrote:
> [..]
>>> so if there are two CPUs, one doing write_seqcount() and the other one
>>> doing read_seqcount() then what can happen is something like this
>>>
>>> CPU0
Hi,
On (09/14/17 09:55), Laurent Dufour wrote:
[..]
> > so if there are two CPUs, one doing write_seqcount() and the other one
> > doing read_seqcount() then what can happen is something like this
> >
> > CPU0CPU1
> >
> >
Hi,
On 14/09/2017 02:31, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/13/17 18:56), Laurent Dufour wrote:
>> Hi Sergey,
>>
>> On 13/09/2017 13:53, Sergey Senozhatsky wrote:
>>> Hi,
>>>
>>> On (09/08/17 20:06), Laurent Dufour wrote:
> [..]
>>> ok, so what I got on my box is:
>>>
>>> vm_munmap() ->
Hi,
On (09/13/17 18:56), Laurent Dufour wrote:
> Hi Sergey,
>
> On 13/09/2017 13:53, Sergey Senozhatsky wrote:
> > Hi,
> >
> > On (09/08/17 20:06), Laurent Dufour wrote:
[..]
> > ok, so what I got on my box is:
> >
> > vm_munmap() -> down_write_killable(&mm->mmap_sem)
> > do_munmap()
> > __
Hi Sergey,
On 13/09/2017 13:53, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/08/17 20:06), Laurent Dufour wrote:
> [..]
>> @@ -903,6 +910,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
>> long start,
>> mm->map_count--;
>> mpol_put(vma_policy(next));
>>
Hi,
On (09/08/17 20:06), Laurent Dufour wrote:
[..]
> @@ -903,6 +910,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned
> long start,
> mm->map_count--;
> mpol_put(vma_policy(next));
> kmem_cache_free(vm_area_cachep, next);
> + write_s
From: Peter Zijlstra
Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
counts such that we can easily test if a VMA is changed.
The unmap_page_range() one allows us to make assumptions about
page-tables; when we find the seqcount hasn't changed we can assume
page-tables are
12 matches
Mail list logo
