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.
