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?

quoted

quoted

+}
+
+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)
+