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:	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