linux-kernel - [v3 VM_PAT PATCH 0/3] x86 VM

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:	Thu,  5 Apr 2012 17:01:32 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Konstantin Khlebnikov <koct9i@...il.com>, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	Pallipadi Venkatesh <venki@...gle.com>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Nick Piggin <npiggin@...nel.dk>
Subject: [v3 VM_PAT PATCH 0/3] x86 VM_PAT series

On Thu, 2012-04-05 at 15:56 +0400, Konstantin Khlebnikov wrote:
> With this patches I see new ranges in /sys/kernel/debug/x86/pat_memtype_list
> This is 4k single-page vma mappged by X11. kernel fills them via vm_insert_pfn().
> Is this ok?

This is expected and I saw these new entries too (but not as many as you saw), as the
patch is tracking single page vma's coming from vm_insert_pfn() interface too.

Thinking a bit more about this in the context of your numbers, those new entries that
are getting tracked are not adding any new value. As the driver has already reserved the
whole aperture with write-combining attribute, tracking these single page vma's doesn't
help anymore.

> Maybe we shouldn't use PAT for small VMA?

For vm_insert_pfn(), expectation is that we just look up the memory attribute.
And for remap_pfn_range(), if the whole VMA is remapped, we reserve the new
attribute for the specified pfn-range, as typically drivers
call remap_pfn_range() for the whole VMA (can be a single page) with the desired
attribute (with out the prior reservation of the memory attribute for the pfn range).
So exposing two different API's for this behavior is probably the better way
to address this in a clean way. Revised patches follows.

Konstantin Khlebnikov (1):
  mm, x86, PAT: rework linear pfn-mmap tracking

Suresh Siddha (2):
  x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn
    vma routines
  x86, pat: separate the pfn attribute tracking for remap_pfn_range and
    vm_insert_pfn

 arch/x86/mm/pat.c             |   80 ++++++++++++++++++++++++++++------------
 include/asm-generic/pgtable.h |   57 +++++++++++++++++------------
 include/linux/mm.h            |   15 +-------
 mm/huge_memory.c              |    7 ++--
 mm/memory.c                   |   23 +++++-------
 5 files changed, 104 insertions(+), 78 deletions(-)

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