Re: [RFC PATCH 5/8] mm: Take placement mappings gap into account

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2024-02-16 at 15:12 +0200, Kirill A. Shutemov wrote:
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 9addf16dbf18..160bb6db7a16 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -3393,12 +3393,14 @@ extern unsigned long __must_check
> > vm_mmap(struct file *, unsigned long,
> >   
> >   struct vm_unmapped_area_info {
> >   #define VM_UNMAPPED_AREA_TOPDOWN 1
> > +#define VM_UNMAPPED_START_GAP_SET 2
> 
> The flag seems to be an workaround not to clear the structure. I
> think
> users need to be updated to clear the structure. In most cases rework
> code
> to use C99 struct initializer would do the trick.

Yea, it's just a treewide change to initialize them all. It should be
easy to review at least. I'll add a patch to do this.

> > @@ -1586,7 +1589,7 @@ static unsigned long unmapped_area(struct
> > vm_unmapped_area_info *info)
> >         if (mas_empty_area(&mas, low_limit, high_limit - 1,
> > length))
> >                 return -ENOMEM;
> >   
> > -       gap = mas.index;
> > +       gap = mas.index + start_gap;
> >         gap += (info->align_offset - gap) & info->align_mask;
> 
> Do we care to check if alignment itself would satisfy start_gap
> requirement?

Ugh, I think actually the alignment stuff clobbers the guard gap in the
search up scenario. I'm also seeing some weird results as I throw test
values into the existing logic, but very likely I just need to look at
this not late on a Friday. Thanks for pointing it out.


> >   unsigned long
> >   __get_unmapped_area(struct file *file, unsigned long addr,
> > unsigned long len,
> > -               unsigned long pgoff, unsigned long flags,
> > vm_flags_t vm_flags)
> > +                   unsigned long pgoff, unsigned long flags,
> > vm_flags_t vm_flags)
> 
> Unrelated space change.

Sure.