Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags

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

 



On Mon, Oct 29, 2012 at 9:57 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On current AMD64 processors,

Can you verify that this is true for older cpu's too (ie the old
pre-64-bit ones, say K6 and original Athlon)?

>                 This is done because a table entry is allowed
> to be upgraded (by marking it as present

Well, that was traditionally solved by not caching not-present entries
at all. Which can be a problem for some things (prefetch of NULL etc),
so caching and then re-checking on faults is potentially the correct
thing, but I'm just mentioning it because it might not be much of an
argument for older microarchitectures..

>, or by removing its write,
> execute or supervisor restrictions) without explicitly maintaining TLB
> coherency. Such an upgrade will be found when the table is re-walked,
> which resolves the fault.

.. but this is obviously what we're interested in. And since AMD has
documented it (as well as Intel), I have this strong suspicion that
operating systems have traditionally relied on this behavior.

I don't remember the test coverage details from my Transmeta days, and
while I certainly saw the page table walker, it wasn't my code.

My gut feel is that this is likely something x86 just always does
(because it's the right thing to do to keep things simple for
software), but getting explicit confirmation about older AMD cpu's
would definitely be good.

                  Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]