Re: Non-GPL export of invalidate_mmap_range

Paul E. McKenney
2004-02-20T14:01:16Z

On Fri, Feb 20, 2004 at 03:37:26PM -0500, Daniel Phillips wrote:
> Hi Paul,
>
> > I cannot think of any reasonable alternative to passing the parameter
> > down either, as it certainly does not be reasonable to duplicate the
> > code...
>
> Yes, it's simply the (small) price that has to be paid in order to be able to
> boast about our accurate semantics.

;-)

> > How about something like "private_too" instead of "zap"?
>
> How about just "all", which is what we mean.

Fair enough, certainly keeps a few more lines of code within 80 columns.

> > > -void zap_page_range(struct vm_area_struct *vma,
> > > - unsigned long address, unsigned long size)
> > > +void invalidate_page_range(struct vm_area_struct *vma,
> >
> > Would it be useful for this to be inline? (Wouldn't seem so,
> > zapping mappings has enough overhead that an extra level of
> > function call should be deep down in the noise...)
>
> Yes, it doesn't seem worth it just to save a stack frame.
>
> Actually, I erred there in that invalidate_mmap_range should not export the
> flag, because it never makes sense to pass in non-zero from a DFS.

Doesn't vmtruncate() want to pass non-zero "all" in to
invalidate_mmap_range() in order to maintain compatibility with existing
Linux semantics?

> > Doesn't the new argument need to be passed down through
> > invalidate_mmap_range_list()?
>
> It does, thanks for the catch. Please bear with me for a moment while I
> reroll this, then hopefully we can move on to the more interesting discussion
> of whether it's worth it. (Yes it is :)

;-)

Thanx, Paul