lkml.org 
[lkml]   [2018]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v1 3/4] arm64: Fix the page leak in pud/pmd_set_huge
    On Wed, Mar 14, 2018 at 02:18:24PM +0530, Chintan Pandya wrote:
    > While setting huge page, we need to take care of
    > previously existing next level mapping. Since,
    > we are going to overrite previous mapping, the
    > only reference to next level page table will get
    > lost and the next level page table will be zombie,
    > occupying space forever. So, free it before
    > overriding.

    > @@ -939,6 +940,9 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
    > return 0;
    >
    > BUG_ON(phys & ~PUD_MASK);
    > + if (pud_val(*pud) && !pud_huge(*pud))
    > + free_page((unsigned long)__va(pud_val(*pud)));
    > +
    > set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot));
    > return 1;
    > }
    > @@ -953,6 +957,9 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot)
    > return 0;
    >
    > BUG_ON(phys & ~PMD_MASK);
    > + if (pmd_val(*pmd) && !pmd_huge(*pmd))
    > + free_page((unsigned long)__va(pmd_val(*pmd)));
    > +

    As Marc noted, (assuming the subsequent revert is applied) in both of
    these cases, these tables are still live, and thus it is not safe to
    free them.

    Consider that immediately after freeing the pages, they may get
    re-allocated elsewhere, where they may be modified. If this happens
    before TLB invalidation, page table walks may allocate junk into TLBs,
    resulting in a number of problems.

    It is *never* safe to free a live page table, therefore NAK to this
    patch.

    Thanks,
    Mark.

    \
     
     \ /
      Last update: 2018-03-14 11:54    [W:2.220 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site