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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Vlastimil Babka <vbabka@xxxxxxx> [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)
> >> > +
> 




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux