Re: [PATCH v2] mm: userfaultfd: avoid passing an invalid range to vma_merge()

[Peter Xu <peterx@xxxxxxxxxx>]

On Wed, May 17, 2023 at 06:51:42PM -0400, Liam R. Howlett wrote:
> > Yes, IIUC that's what we want because vma_merge() just handles everything
> > there (including split, or say, vma range adjustments) if any !NULL
> > returned.
> 
> I don't get your use of split here. __vma_adjust() used to be used by
> split, but it never split a VMA.  vma_merge() is not used by split at
> all.

I guess maybe I just made it confusing somehow when using "split" here..

I meant the vma range adjustments when vma_merge(), so indeed it's not
really a split, but it's still a logical split to me.

To be explicit, taking example of the uffd unregister case that was
essentially case 4, where part of PPPP will be "split" out and merged with
NNNN:

        ****
        PPPPPPNNNNNN
        might become
        PPNNNNNNNNNN
        case 4 below

        if (prev && addr < prev->vm_end) {	/* case 4 */
                vma_end = addr;
                adjust = next;
                adj_start = -(prev->vm_end - addr);
                err = dup_anon_vma(next, prev);
                ...
        } 

PPPP is adjusted here (where I was trying to refer as a "split", because
vma_end is less than before so part of PPPP is cut out):

	vma->vm_start = vma_start;
	vma->vm_end = vma_end;
	vma->vm_pgoff = vma_pgoff;

NNNN adjusted here (where the "split" part merged into NNNN):

	if (adj_start) {
		adjust->vm_start += adj_start;
		adjust->vm_pgoff += adj_start >> PAGE_SHIFT;
                ...
	}

I'll remember to stop using the word "split" in these cases in the future
to avoid confusion.

Thanks,

-- 
Peter Xu