linux-kernel - Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

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:	Wed, 20 Dec 2006 12:39:09 +0100
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc:	"Arjan van de Ven" <arjan@...radead.org>,
	"Linus Torvalds" <torvalds@...l.org>,
	"Andrei Popa" <andrei.popa@...eo.ro>,
	"Andrew Morton" <akpm@...l.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Hugh Dickins" <hugh@...itas.com>,
	"Florian Weimer" <fw@...eb.enyo.de>,
	"Marc Haber" <mh+linux-kernel@...schlus.de>,
	"Martin Michlmayr" <tbm@...ius.com>,
	"Martin Schwidefsky" <schwidefsky@...ibm.com>,
	"Heiko Carstens" <heiko.carstens@...ibm.com>,
	"Arnd Bergmann" <arnd.bergmann@...ibm.com>
Subject: Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

On 20/12/06, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> fix page_mkclean_one()
>
> it had several issues:
>  - it failed to flush the cache
>  - it failed to flush the tlb
>  - it failed to do s390 (s390 guys, please verify this is now correct)
>
> Also, clear in a loop to ensure SMP safeness as suggested by Arjan.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> ---
>  mm/rmap.c |   29 +++++++++++++++--------------
>  1 file changed, 15 insertions(+), 14 deletions(-)
>
> Index: linux-2.6/mm/rmap.c
> ===================================================================
> --- linux-2.6.orig/mm/rmap.c
> +++ linux-2.6/mm/rmap.c
> @@ -432,7 +432,7 @@ static int page_mkclean_one(struct page
>  {
>         struct mm_struct *mm = vma->vm_mm;
>         unsigned long address;
> -       pte_t *pte, entry;
> +       pte_t *ptep;
>         spinlock_t *ptl;
>         int ret = 0;
>
> @@ -440,22 +440,23 @@ static int page_mkclean_one(struct page
>         if (address == -EFAULT)
>                 goto out;
>
> -       pte = page_check_address(page, mm, address, &ptl);
> -       if (!pte)
> +       ptep = page_check_address(page, mm, address, &ptl);
> +       if (!ptep)
>                 goto out;
>
> -       if (!pte_dirty(*pte) && !pte_write(*pte))
> -               goto unlock;
> -
> -       entry = ptep_get_and_clear(mm, address, pte);
> -       entry = pte_mkclean(entry);
> -       entry = pte_wrprotect(entry);
> -       ptep_establish(vma, address, pte, entry);
> -       lazy_mmu_prot_update(entry);
> -       ret = 1;
> +       while (pte_dirty(*ptep) || pte_write(*ptep)) {
> +               pte_t entry = ptep_get_and_clear(mm, address, ptep);
> +               flush_cache_page(vma, address, pte_pfn(entry));
> +               flush_tlb_page(vma, address);
> +               (void)page_test_and_clear_dirty(page); /* do the s390 thing */
> +               entry = pte_wrprotect(entry);
> +               entry = pte_mkclean(entry);
> +               set_pte_at(vma, address, ptep, entry);
> +               lazy_mmu_prot_update(entry);
> +               ret = 1;
> +       }
>
Having the assignment of "ret = 1;" inside the loop seems a little
pointless. Perhaps gcc can optimize it, but still, that assignment
really only needs to happen once outside the loop.


> -unlock:
> -       pte_unmap_unlock(pte, ptl);
> +       pte_unmap_unlock(ptep, ptl);
>  out:
>         return ret;
>  }
>

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/