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
| ||
|
Date: Wed, 04 Apr 2012 08:43:27 +0400 From: Konstantin Khlebnikov <khlebnikov@...nvz.org> To: Suresh Siddha <suresh.b.siddha@...el.com> CC: Konstantin Khlebnikov <koct9i@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 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: Re: [x86 PAT PATCH 1/2] x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn vma routines Suresh Siddha wrote: > On Tue, 2012-04-03 at 09:37 +0400, Konstantin Khlebnikov wrote: >> Suresh Siddha wrote: >>> 'pfn' argument for track_pfn_vma_new() can be used for reserving the attribute >>> for the pfn range. No need to depend on 'vm_pgoff' >>> >>> Similarly, untrack_pfn_vma() can depend on the 'pfn' argument if it >>> is non-zero or can use follow_phys() to get the starting value of the pfn >>> range. >>> >>> Also the non zero 'size' argument can be used instead of recomputing >>> it from vma. >>> >>> This cleanup also prepares the ground for the track/untrack pfn vma routines >>> to take over the ownership of setting PAT specific vm_flag in the 'vma'. >>> >>> Signed-off-by: Suresh Siddha<suresh.b.siddha@...el.com> >>> Cc: Venkatesh Pallipadi<venki@...gle.com> >>> Cc: Konstantin Khlebnikov<khlebnikov@...nvz.org> >>> --- >>> arch/x86/mm/pat.c | 30 +++++++++++++++++------------- >>> 1 files changed, 17 insertions(+), 13 deletions(-) >>> >>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c >>> index f6ff57b..617f42b 100644 >>> --- a/arch/x86/mm/pat.c >>> +++ b/arch/x86/mm/pat.c >>> @@ -693,14 +693,10 @@ int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t *prot, >>> unsigned long pfn, unsigned long size) >>> { >>> unsigned long flags; >>> - resource_size_t paddr; >>> - unsigned long vma_size = vma->vm_end - vma->vm_start; >>> >>> - if (is_linear_pfn_mapping(vma)) { >>> - /* reserve the whole chunk starting from vm_pgoff */ >>> - paddr = (resource_size_t)vma->vm_pgoff<< PAGE_SHIFT; >>> - return reserve_pfn_range(paddr, vma_size, prot, 0); >>> - } >>> + /* reserve the whole chunk starting from pfn */ >>> + if (is_linear_pfn_mapping(vma)) >>> + return reserve_pfn_range(pfn, size, prot, 0); >> >> you mix here pfn and paddr: old code passes paddr as first argument of reserve_pfn_range(). > > oops. That was my oversight. I updated the two patches to address this. > Also I cleared VM_PAT flag as part of the untrack_pfn_vma(), so that the > use cases (like the i915 case) which just evict the pfn's (by using > unmap_mapping_range) with out actually removing the vma will do the > free_pfn_range() only when it is required. > > Attached (to this e-mail) are the -v2 versions of the PAT patches. I > tested these on my SNB laptop. Ok, I'll send them as part of updated patchset. > > thanks, > suresh -- 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/
Powered by blists - more mailing lists