linux-kernel - Re: [PATCH] x86: Fix CPA memtype reserving in the set_pages

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:	Mon, 03 Aug 2009 12:18:45 +0200
From:	Thomas Hellstrom <thellstrom@...are.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Dave Airlie <airlied@...ux.ie>,
	Arjan van de Ven <arjan@...radead.org>,
	"suresh.b.siddha@...el.com" <suresh.b.siddha@...el.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"venkatesh.pallipadi@...el.com" <venkatesh.pallipadi@...el.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"dri-devel@...ts.sourceforge.net" <dri-devel@...ts.sourceforge.net>
Subject: Re: [PATCH] x86: Fix CPA memtype reserving in the set_pages_array
 cases

Ingo Molnar wrote:
> * Thomas Hellstrom <thellstrom@...are.com> wrote:
>
>   
>> Dave Airlie wrote:
>>     
>>>> hm, i'm missing a description about how this bug was triggered. How 
>>>> did you end up getting highmem pages to a cpa call?
>>>>     
>>>>         
>>> GEM and TTM both allocate page arrays and just pass them to cpa,
>>> we don't know what type of pages the allocator gives us back and we 
>>> really shouldn't have to, so having cpa ignore highmem pages is 
>>> certainly the right option.
>>>
>>> GEM just uses shmem code to alloc the pages and TTM has its own allocator.
>>>
>>>   
>>>       
>> Yes, Dave is right.
>>
>> Although I'm not 100% sure the TTM code I was using that triggered this  
>> has made it into 2.6.31.
>> Old AGP uses (GFP_KERNEL | GFP_DMA32 | __GFP_ZERO), which (correct me if  
>> I'm wrong) never hands back highmem pages. This means that Intel's GEM  
>> is the only likely user for 2.6.31.
>>     
>
> (please dont top-post) I'm not sure you folks noticed this bit of my 
> mail:
>
>   
>>>> ok, that's a bug introduced in .29 but which was latent until now:  
>>>> drivers/char/agp/generic.c now uses it plus (indirectly) a number of  
>>>> AGP drivers, since:
>>>>
>>>>  commit 07613ba2f464f59949266f4337b75b91eb610795
>>>>  Author: Dave Airlie <airlied@...hat.com>
>>>>  Date:   Fri Jun 12 14:11:41 2009 +1000
>>>>
>>>>      agp: switch AGP to use page array instead of unsigned long array
>>>>
>>>> I dont see how it can end up with highmem pages though. All the 
>>>> graphics apperture allocations happen to lowmem AFAICS. Did GEM add 
>>>> the possibility for user pages (highmem amongst them) ending up in 
>>>> that pool? Which code does that?
>>>>         
>
> 	Ingo
>   
Sorry, my bad.

The TTM code I tested is not in yet, and after double-checking it looks 
like Intel's gem is not changing caching policy before binding to AGP.

This means the highmem problems that I saw were triggered by a 
combination of the virtual->physical bugfix and code that's not in the 
kernel yet, and since it's an optimization of the current code it's not 
likely to land in 2.6.31. The highmem fixes could thus, AFAICT be 
stripped out of the patch, unless GFP_DMA32 on a highmem system can 
actually hand back highmem pages, in which case AGP will not work correctly.

As for highmem use in the future, the TTM page arrays are populated 
using fault(), which means that there will be an overhead ordering the 
pages so that we can use the set_pages_array() interface instead of 
set_memory() that we use today. Therefore, if possible, I'd prefer if we 
could pass arrays containing highmem pages to the set_pages_array() 
interface.

There are no aliased mappings since

1) Any user space mappings to these pages are killed before changing 
caching policy.
2) The pages are allocated and owned by the driver.
3) kmap_atomic_prot() and vmap() are used to map these pages in kernel 
space.

Code is in ttm_tt.c ttm_bo.c and ttm_bo_util.c

Thanks.
/Thomas
--
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/