linux-kernel - Re: [PATCH v4 07/66] mm: Add VMA iterator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211210182103.h6tkphmejksu2dll@revolver>
Date:   Fri, 10 Dec 2021 18:24:10 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Vlastimil Babka <vbabka@...e.cz>
CC:     "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Song Liu <songliubraving@...com>,
        Davidlohr Bueso <dave@...olabs.net>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        David Rientjes <rientjes@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Rik van Riel <riel@...riel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michel Lespinasse <walken.cr@...il.com>,
        Jerome Glisse <jglisse@...hat.com>,
        Minchan Kim <minchan@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Rom Lemarchand <romlem@...gle.com>
Subject: Re: [PATCH v4 07/66] mm: Add VMA iterator

* Vlastimil Babka <vbabka@...e.cz> [211210 10:08]:
> On 12/10/21 03:02, Liam Howlett wrote:
> > 
> > vma_find() uses mas_find() which was created to implement find_vma().
> > As a replacement, the search looks for an entry at the address and if
> > nothing exists, it will continue the search upwards.  The result is that
> > the first entry can be found at the address passed.  Every subsequent
> > call to vma_find() would search from the end of the previous range - as
> > saved in the maple state, or the vma iterator in this case.
> > 
> > mas_next(), however is more of a traditional linked list operation that
> > finds the next entry _after_ the one containing the index in the maple
> > state.  The only difference is on the start when the maple state is not
> > currently pointing at an entry at all (the node is set to MAS_START).
> > 
> > mas_find() can be thought of as:
> > 
> > entry = mas_walk();
> > if (!entry)
> > 	entry = mas_next_entry();
> > 
> > return entry;
> > 
> > 
> > mas_next can be though to as:
> > 
> > if (mas_is_start())
> > 	mas_walk();
> > 
> > return mas_next_entry();
> > 
> > 
> > Matthew uses mas_find() for his implementation of the vma iterator so
> > that the first entry is not skipped.
> 
> Yeah, but if vma_next() is going to replace the cases where we already have
> a vma and use vma->vm_next to get the next one, then mas_next() would be a
> better fit?
> 
> Do I understand correctly that e.g. after a mas_pause(), vma_next() done via
> max_next() might return the same vma again, while vma_prev() will not, and
> vma_next() implemented by mas_next() also wouldn't? Isn't that unexpected
> semantics?
> 

No, mas_pause() will set the mas->node to MAS_PAUSE, which causes
mas_find() to start searching for mas->last + 1 and up so a duplicate
should not occur.

...Unless the VMA you found was expanded while paused but this, I think,
only happens on stack expansion.  During stack expansion the VMA can
grow with holding the mmap_lock in read mode, so if something is
iterating over the VMAs and pauses on the stack VMA then the stack grows
and the iterator resumes, it could return the stack vma twice if
expanding upwards... Is this actually a potential issue or did I miss
something?

> >> 
> >> > +}
> >> > +
> >> > +static inline struct vm_area_struct *vma_prev(struct vma_iterator *vmi)
> >> > +{
> >> > +	return mas_prev(&vmi->mas, 0);
> >> > +}
> >> > +
> >> > +static inline unsigned long vma_iter_addr(struct vma_iterator *vmi)
> >> > +{
> >> > +	return vmi->mas.index;
> >> > +}
> >> > +
> >> > +#define for_each_vma(vmi, vma)		while ((vma = vma_next(&vmi)) != NULL)
> >> > +
>