linux-kernel - Re: [x86 PAT PATCH 1/2] x86, pat: remove the dependency on '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:	Tue, 03 Apr 2012 16:31:21 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
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

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.

thanks,
suresh

View attachment "0001-x86-pat-remove-the-dependency-on-vm_pgoff-in-track-u.patch" of type "text/x-patch" (2890 bytes)

View attachment "0002-mm-x86-PAT-rework-linear-pfn-mmap-tracking.patch" of type "text/x-patch" (8404 bytes)