* David Hildenbrand <david@xxxxxxxxxx> [220621 17:04]: > On 21.06.22 22:46, Liam Howlett wrote: > > From: "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> > > > > Using the maple tree interface mt_find() will handle the RCU locking and > > will start searching at the address up to the limit, ULONG_MAX in this > > case. > > > > Add kernel documentation to this API. > > > > Link: https://lkml.kernel.org/r/20220504010716.661115-13-Liam.Howlett@xxxxxxxxxx > > Signed-off-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > > Acked-by: Vlastimil Babka <vbabka@xxxxxxx> > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > > Cc: David Howells <dhowells@xxxxxxxxxx> > > Cc: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> > > Cc: SeongJae Park <sj@xxxxxxxxxx> > > Cc: Will Deacon <will@xxxxxxxxxx> > > Cc: Davidlohr Bueso <dave@xxxxxxxxxxxx> > > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > --- > > mm/mmap.c | 28 ++++++++++------------------ > > 1 file changed, 10 insertions(+), 18 deletions(-) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index d7e6baa2f40f..fdb61252448f 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -2486,11 +2486,18 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, > > > > EXPORT_SYMBOL(get_unmapped_area); > > > > -/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */ > > +/** > > + * find_vma() - Find the VMA for a given address, or the next vma. > > + * @mm: The mm_struct to check > > + * @addr: The address > > + * > > + * Returns: The VMA associated with addr, or the next vma. > > + * May return %NULL in the case of no vma at addr or above. > > Nit: inconsistent use of VMA vs. vma. I'll update the comment. > > > + */ > > struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) > > { > > - struct rb_node *rb_node; > > struct vm_area_struct *vma; > > + unsigned long index = addr; > > > > mmap_assert_locked(mm); > > /* Check the cache first. */ > > @@ -2498,22 +2505,7 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) > > if (likely(vma)) > > return vma; > > > > - rb_node = mm->mm_rb.rb_node; > > - > > - while (rb_node) { > > - struct vm_area_struct *tmp; > > - > > - tmp = rb_entry(rb_node, struct vm_area_struct, vm_rb); > > - > > - if (tmp->vm_end > addr) { > > - vma = tmp; > > - if (tmp->vm_start <= addr) > > - break; > > - rb_node = rb_node->rb_left; > > - } else > > - rb_node = rb_node->rb_right; > > - } > > - > > + vma = mt_find(&mm->mm_mt, &index, ULONG_MAX); > > I guess it would be handy to have a mt_find() variant that simply > consumes an address, because for example here, we don't actually care > about the output semantics? Does anything speak against such a utility > function or is this here really just a corner case? > > That would make that code *even easier* to read. That makes sense. I just don't want to have a whole lot of APIs that do the same thing. I'll add it to my list and see how often we see the pattern though. > > > if (vma) > > vmacache_update(addr, vma); > > return vma; > > Reviewed-by: David Hildenbrand <david@xxxxxxxxxx> > > -- > Thanks, > > David / dhildenb >
