linux-kernel - Re: [PATCH v2] mm/hugetlb: Fix calculation of adjust_range_if_pmd_sharing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Jul 2020 19:26:56 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2] mm/hugetlb: Fix calculation of
 adjust_range_if_pmd_sharing_possible

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