Re: [PATCH] mm/hugetlb: avoid get wrong ptep caused by race

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



在 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)




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux