lkml.org 
[lkml]   [2020]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm/hugetlb: avoid get wrong ptep caused by race
From
Date
在 2020/2/19 11:49, Mike Kravetz 写道:
> On 2/18/20 6:09 PM, Longpeng (Mike) wrote:
>> 在 2020/2/19 4:52, Matthew Wilcox 写道:
>>> On Tue, Feb 18, 2020 at 08:10:25PM +0800, Longpeng(Mike) wrote:
>>>> {
>>>> - pgd_t *pgd;
>>>> - p4d_t *p4d;
>>>> - pud_t *pud;
>>>> - pmd_t *pmd;
>>>> + pgd_t *pgdp;
>>>> + p4d_t *p4dp;
>>>> + pud_t *pudp, pud;
>>>> + pmd_t *pmdp, pmd;
>>>
>>> Renaming the variables as part of a fix is a really bad idea. It obscures
>>> the actual fix and makes everybody's life harder. Plus, it's not even
>>> renaming to follow the normal convention -- there are only two places
>>> (migrate.c and gup.c) which follow this pattern in mm/ while there are
>>> 33 that do not.
>>>
>> Good suggestion, I've never noticed this, thanks.
>> By the way, could you give an example if we use this way to fix the bug?
>
> Matthew and others may have better suggestions for naming. However, I would
> keep the existing names and add:
>
> pud_t pud_entry;
> pmd_t pmd_entry;
>
> Then the *_entry variables are the target of the READ_ONCE()
>
> pud_entry = READ_ONCE(*pud);
> if (sz != PUD_SIZE && pud_none(pud_entry))
> ...
> ...
> pmd_entry = READ_ONCE(*pmd);
> if (sz != PMD_SIZE && pmd_none(pmd_entry))
> ...
> ...
>
Uh, looks much better.

BTW, I missed one of your email in my mail client, but I find it in lkml.org.
'''
I too would like some more information on the panic.
If your analysis is correct, then I would expect the 'ptep' returned by
huge_pte_offset() to not point to a pte but rather some random address.
This is because the 'pmd' calculated by pmd_offset(pud, addr) is not
really the address of a pmd. So, perhaps there is an addressing exception
at huge_ptep_get() near the beginning of hugetlb_fault()?

ptep = huge_pte_offset(mm, haddr, huge_page_size(h));
if (ptep) {
entry = huge_ptep_get(ptep);
...
'''
Yep, your analysis above is the same as mine, we got a 'dummy pmd' and then
cause access a bad address.

What's your opinion about the solution to fix this problem, not only
huge_pte_offset, some other places also have the same problem(e.g.
lookup_address_in_pgd) ?

> BTW, thank you for finding this issue!
>


--
Regards,
Longpeng(Mike)

\
 
 \ /
  Last update: 2020-02-19 13:53    [W:0.053 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site