Re: [PATCH 2/3] mm/mseal: limit scope of mseal address zero to address zero

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Jul 17, 2026 at 11:41:11AM +0100, David Hildenbrand (Arm) wrote:
> >>
> >>>  {
> >>>  	struct vm_area_struct *vma, *prev;
> >>>  	VMA_ITERATOR(vmi, current->mm, start);
> >>> @@ -66,6 +66,38 @@ static int mseal_apply(unsigned long start, unsigned long end)
> >>>  	return 0;
> >>>  }
> >>>
> >>> +static int mseal(unsigned long start, unsigned long end)
> >>
> >> I don't like that you go start - end on a function called "mseal". The actual
> >> system call goes start - len. It just looks confusing :) So either rename it
> >> to mseal_range(), or make it take a start, length pair.
> >
> > I'm not sure I really understand the confusion (I suppose you're equally
> > confused by the lack of flags parameter?),
> >
> > I find it silly that we avoid function names because a system call of the same
> > name exists.
> >
> > But I guess I can rename it to mseal_range() since I don't want the series
> > blocked on silly naming issues.
>
> I think we typically have a XXX call do_XXX, like with mprotect(). But not sure
> if there is a real rule to that, I'm sure there are exceptions. At least it's
> only an internal helper.

Yeah I think that's more the pattern.

>
> Just like with the "__*" functions, sometimes it indeed helps to just have a
> better description that shows the difference. But sometimes it's just really
> hard to name or restructure stuff.

Yup :)

>
> I think the page fault logic is especially hard to follow with things like
> do_fault() and __do_fault(), whereby we have another layer of do_read_fault()
> etc in-between :)

Yeah we are consistently inconsistent also on top of that :)

In general on reflection I realise I was being a bit stubborn here and Pedro is
right - mseal_range() is much better, reflects the [start, end) vs. [start,
start + len) thing better.

Will respin with that changed.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo