linux-kernel - Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear

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]

Message-ID: <Pine.LNX.4.64.0704131838310.8399@blonde.wat.veritas.com>
Date:	Fri, 13 Apr 2007 18:54:01 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Zachary Amsden <zach@...are.com>
cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}

On Mon, 26 Mar 2007, Zachary Amsden wrote:
> David Rientjes wrote:
> >  Date: Sun, 25 Mar 2007 23:07:43 -0800
> >  From: Zachary Amsden <zach@...are.com>
> >
> >  If you actually clear the bit, you need to:
> >
> >  +         pte_update_defer(vma->vm_mm, addr, ptep);
> >
> >  The reason is, when updating PTEs, the hypervisor must be notified.  Using
> >  atomic operations to do this is fine for all hypervisors I am aware of.
> >  However, for hypervisors which shadow page tables, if these PTE
> >  modifications are not trapped, you need a post-modification call to fulfill
> >  the update of the shadow page table.
> >
> > Cc: Zachary Amsden <zach@...are.com>
> > Cc: Hugh Dickins <hugh@...itas.com>
> > Signed-off-by: David Rientjes <rientjes@...gle.com>
> >   
> 
> Acked-by: Zachary Amsden <zach@...are.com>
> 
> David, thanks for cleaning this up.

Zach, while looking at your recent patches, I ran across the comment
on pte_update_defer, and where it was being used, and now think that
David's patch is actually incorrect.  Previously pte_update_defer
was being used where a flush_tlb_page followed immediately after
within the same macro; with David's patch, mm's clear_refs_pte_range
is calling ptep_test_and_clear_young (including pte_update_defer) on
several ptes, then unlocking the page table, and later flushing TLB.
That's exactly wrong for pte_update_defer, isn't it?

I do find the name confusing (pte_update_defer is for use only when
the TLB update is not deferred, right?): indeed, its distinction from
pte_update very prone to errors of this kind.  I'm all for deferring
work, but is there some way the right thing could be done automatically?
Or, how much would be lost if we just replaced all the pte_update_defers
by pte_updates?

I'm not proposing any patch myself: just bringing to your attention.

Hugh
-
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/