Re: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing_possible

[Peter Xu <peterx@redhat.com>]

Hi, Mike,

On Thu, Jul 30, 2020 at 02:49:18PM -0700, Mike Kravetz wrote:
> On 7/30/20 1:16 PM, Peter Xu wrote:
> > This is found by code observation only.
> > 
> > Firstly, the worst case scenario should assume the whole range was covered by
> > pmd sharing.  The old algorithm might not work as expected for ranges
> > like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the
> > expected range should be (0, 2g).
> > 
> > Since at it, remove the loop since it should not be required.  With that, the
> > new code should be faster too when the invalidating range is huge.
> 
> Thanks Peter!
> 
> That is certainly much simpler than the loop in current code.  You say there
> are instances where old code 'might not work' for ranges like (1g-2m, 1g+2m).
> Not sure I understand what you mean by adjusted and expected ranges in the
> message.  Both are possible 'adjusted' ranges depending on vma size.
> 
> Just trying to figure out if there is an actual problem in the existing code
> that needs to be fixed in stable.  I think the existing code is correct, just
> inefficient.

Thanks for the quick review!

I'm not sure whether that will cause a real problem, but iiuc in my previous
example of (1g-2m, 1g+2m) in the commit message, the old code will extend the
range to (0, 1g+2m).  In this case, if unluckily the (1g, 2g) range is a pud
with shared pmd, then imho we face the risk of partial tlb flushing with the
old code, because it will only flush tlb for range (0, 1g+2m) but not (0, 2g).
If that's the case, maybe it worths cc stable.

Anyway, I'd like to double confirm with you in case I missed something.

Thanks,

-- 
Peter Xu