On Wed, Jan 29, 2025 at 04:19:50PM +0100, Vlastimil Babka wrote:
> On 1/27/25 16:50, Lorenzo Stoakes wrote:
> > + if (flags & __VMG_FLAG_REMOVE_MIDDLE) {
> > + *remove = vmg->middle;
> > + remove = &vp->remove2;
> > + }
> > + if (flags & __VMG_FLAG_REMOVE_NEXT)
> > + *remove = vmg->next;
> > +
> > + if (flags & __VMG_FLAG_ADJUST_MIDDLE_START)
> > + adjust = vmg->middle;
> > + else if (flags & __VMG_FLAG_ADJUST_NEXT_START)
> > + adjust = vmg->next;
> > + else
> > + adjust = NULL;
> > +
> > + vp->adj_next = adjust;
>
> Realized this has kinda made it more obvious that vp->adj_next is a misnomer?
Well yes and no.
It is badly named, as it sounds like adj_start, which is an offset, but it is
equivalent to 'adjust' elsewhere.
But it _is_ the 'next' VMA from the one which we are otherwise manipulating, so
'adjusted next' is sort of a vaguely reasonable-ish name.
But at the same time, it's all horrible and maybe this whole
vma_prepare()/complete() will be the target of my next round of
churn^D^D^D^D^Drefactorings...
I also don't like the various 'special casing' of these situations in
vma_complete(), and it feels like - maybe we can use or adapt the vmg structure
for split as well and put the vma_prepare()/vma_complete() stuff there too...
Anyway. One thing at a time.
