2005-04-17 02:20:36 +04:00
/*
* High memory handling common code and variables .
*
* ( C ) 1999 Andrea Arcangeli , SuSE GmbH , andrea @ suse . de
* Gerhard Wichert , Siemens AG , Gerhard . Wichert @ pdb . siemens . de
*
*
* Redesigned the x86 32 - bit VM architecture to deal with
* 64 - bit physical space . With current x86 CPUs this
* means up to 64 Gigabytes physical RAM .
*
* Rewrote high memory support to move the page cache into
* high memory . Implemented permanent ( schedulable ) kmaps
* based on Linus ' idea .
*
* Copyright ( C ) 1999 Ingo Molnar < mingo @ redhat . com >
*/
# include <linux/mm.h>
2011-10-16 10:01:52 +04:00
# include <linux/export.h>
2005-04-17 02:20:36 +04:00
# include <linux/swap.h>
# include <linux/bio.h>
# include <linux/pagemap.h>
# include <linux/mempool.h>
# include <linux/blkdev.h>
# include <linux/init.h>
# include <linux/hash.h>
# include <linux/highmem.h>
2010-08-05 18:22:24 +04:00
# include <linux/kgdb.h>
2005-04-17 02:20:36 +04:00
# include <asm/tlbflush.h>
2010-10-28 02:32:57 +04:00
# if defined(CONFIG_HIGHMEM) || defined(CONFIG_X86_32)
DEFINE_PER_CPU ( int , __kmap_atomic_idx ) ;
# endif
2005-04-17 02:20:36 +04:00
/*
* Virtual_count is not a pure " count " .
* 0 means that it is not mapped , and has not been mapped
* since a TLB flush - it is usable .
* 1 means that there are no users , but it has been mapped
* since the last TLB flush - so we can ' t use it .
* n means that there are ( n - 1 ) current users of it .
*/
# ifdef CONFIG_HIGHMEM
2005-10-21 11:22:44 +04:00
2014-08-07 03:08:23 +04:00
/*
* Architecture with aliasing data cache may define the following family of
* helper functions in its asm / highmem . h to control cache color of virtual
* addresses where physical memory pages are mapped by kmap .
*/
# ifndef get_pkmap_color
/*
* Determine color of virtual address where the page should be mapped .
*/
static inline unsigned int get_pkmap_color ( struct page * page )
{
return 0 ;
}
# define get_pkmap_color get_pkmap_color
/*
* Get next index for mapping inside PKMAP region for page with given color .
*/
static inline unsigned int get_next_pkmap_nr ( unsigned int color )
{
static unsigned int last_pkmap_nr ;
last_pkmap_nr = ( last_pkmap_nr + 1 ) & LAST_PKMAP_MASK ;
return last_pkmap_nr ;
}
/*
* Determine if page index inside PKMAP region ( pkmap_nr ) of given color
* has wrapped around PKMAP region end . When this happens an attempt to
* flush all unused PKMAP slots is made .
*/
static inline int no_more_pkmaps ( unsigned int pkmap_nr , unsigned int color )
{
return pkmap_nr = = 0 ;
}
/*
* Get the number of PKMAP entries of the given color . If no free slot is
* found after checking that many entries , kmap will sleep waiting for
* someone to call kunmap and free PKMAP slot .
*/
static inline int get_pkmap_entries_count ( unsigned int color )
{
return LAST_PKMAP ;
}
/*
* Get head of a wait queue for PKMAP entries of the given color .
* Wait queues for different mapping colors should be independent to avoid
* unnecessary wakeups caused by freeing of slots of other colors .
*/
static inline wait_queue_head_t * get_pkmap_wait_queue_head ( unsigned int color )
{
static DECLARE_WAIT_QUEUE_HEAD ( pkmap_map_wait ) ;
return & pkmap_map_wait ;
}
# endif
2006-09-26 10:31:11 +04:00
unsigned long totalhigh_pages __read_mostly ;
2008-07-20 09:39:46 +04:00
EXPORT_SYMBOL ( totalhigh_pages ) ;
2006-09-26 10:31:11 +04:00
2010-10-27 01:21:51 +04:00
EXPORT_PER_CPU_SYMBOL ( __kmap_atomic_idx ) ;
2006-09-26 10:31:11 +04:00
unsigned int nr_free_highpages ( void )
{
2016-05-20 03:12:26 +03:00
struct zone * zone ;
2006-09-26 10:31:11 +04:00
unsigned int pages = 0 ;
2016-05-20 03:12:26 +03:00
for_each_populated_zone ( zone ) {
if ( is_highmem ( zone ) )
pages + = zone_page_state ( zone , NR_FREE_PAGES ) ;
2007-07-17 15:03:12 +04:00
}
2006-09-26 10:31:11 +04:00
return pages ;
}
2005-04-17 02:20:36 +04:00
static int pkmap_count [ LAST_PKMAP ] ;
static __cacheline_aligned_in_smp DEFINE_SPINLOCK ( kmap_lock ) ;
pte_t * pkmap_page_table ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
/*
* Most architectures have no use for kmap_high_get ( ) , so let ' s abstract
* the disabling of IRQ out of the locking in that case to save on a
* potential useless overhead .
*/
# ifdef ARCH_NEEDS_KMAP_HIGH_GET
# define lock_kmap() spin_lock_irq(&kmap_lock)
# define unlock_kmap() spin_unlock_irq(&kmap_lock)
# define lock_kmap_any(flags) spin_lock_irqsave(&kmap_lock, flags)
# define unlock_kmap_any(flags) spin_unlock_irqrestore(&kmap_lock, flags)
# else
# define lock_kmap() spin_lock(&kmap_lock)
# define unlock_kmap() spin_unlock(&kmap_lock)
# define lock_kmap_any(flags) \
do { spin_lock ( & kmap_lock ) ; ( void ) ( flags ) ; } while ( 0 )
# define unlock_kmap_any(flags) \
do { spin_unlock ( & kmap_lock ) ; ( void ) ( flags ) ; } while ( 0 )
# endif
2012-08-01 03:45:02 +04:00
struct page * kmap_to_page ( void * vaddr )
{
unsigned long addr = ( unsigned long ) vaddr ;
2012-11-17 02:15:00 +04:00
if ( addr > = PKMAP_ADDR ( 0 ) & & addr < PKMAP_ADDR ( LAST_PKMAP ) ) {
2012-12-12 04:01:17 +04:00
int i = PKMAP_NR ( addr ) ;
2012-08-01 03:45:02 +04:00
return pte_page ( pkmap_page_table [ i ] ) ;
}
return virt_to_page ( addr ) ;
}
2012-10-19 17:03:31 +04:00
EXPORT_SYMBOL ( kmap_to_page ) ;
2012-08-01 03:45:02 +04:00
2005-04-17 02:20:36 +04:00
static void flush_all_zero_pkmaps ( void )
{
int i ;
2008-08-01 05:15:21 +04:00
int need_flush = 0 ;
2005-04-17 02:20:36 +04:00
flush_cache_kmaps ( ) ;
for ( i = 0 ; i < LAST_PKMAP ; i + + ) {
struct page * page ;
/*
* zero means we don ' t have anything to do ,
* > 1 means that it is still in use . Only
* a count of 1 means that it is free but
* needs to be unmapped
*/
if ( pkmap_count [ i ] ! = 1 )
continue ;
pkmap_count [ i ] = 0 ;
/* sanity check */
2006-04-02 15:47:35 +04:00
BUG_ON ( pte_none ( pkmap_page_table [ i ] ) ) ;
2005-04-17 02:20:36 +04:00
/*
* Don ' t need an atomic fetch - and - clear op here ;
* no - one has the page mapped , and cannot get at
* its virtual address ( and hence PTE ) without first
* getting the kmap_lock ( which is held here ) .
* So no dangers , even with speculative execution .
*/
page = pte_page ( pkmap_page_table [ i ] ) ;
2012-12-12 04:01:24 +04:00
pte_clear ( & init_mm , PKMAP_ADDR ( i ) , & pkmap_page_table [ i ] ) ;
2005-04-17 02:20:36 +04:00
set_page_address ( page , NULL ) ;
2008-08-01 05:15:21 +04:00
need_flush = 1 ;
2005-04-17 02:20:36 +04:00
}
2008-08-01 05:15:21 +04:00
if ( need_flush )
flush_tlb_kernel_range ( PKMAP_ADDR ( 0 ) , PKMAP_ADDR ( LAST_PKMAP ) ) ;
2005-04-17 02:20:36 +04:00
}
2008-03-20 03:00:42 +03:00
/**
* kmap_flush_unused - flush all unused kmap mappings in order to remove stray mappings
*/
2007-05-02 21:27:15 +04:00
void kmap_flush_unused ( void )
{
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
lock_kmap ( ) ;
2007-05-02 21:27:15 +04:00
flush_all_zero_pkmaps ( ) ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
unlock_kmap ( ) ;
2007-05-02 21:27:15 +04:00
}
2005-04-17 02:20:36 +04:00
static inline unsigned long map_new_virtual ( struct page * page )
{
unsigned long vaddr ;
int count ;
2014-08-07 03:08:23 +04:00
unsigned int last_pkmap_nr ;
unsigned int color = get_pkmap_color ( page ) ;
2005-04-17 02:20:36 +04:00
start :
2014-08-07 03:08:23 +04:00
count = get_pkmap_entries_count ( color ) ;
2005-04-17 02:20:36 +04:00
/* Find an empty entry */
for ( ; ; ) {
2014-08-07 03:08:23 +04:00
last_pkmap_nr = get_next_pkmap_nr ( color ) ;
if ( no_more_pkmaps ( last_pkmap_nr , color ) ) {
2005-04-17 02:20:36 +04:00
flush_all_zero_pkmaps ( ) ;
2014-08-07 03:08:23 +04:00
count = get_pkmap_entries_count ( color ) ;
2005-04-17 02:20:36 +04:00
}
if ( ! pkmap_count [ last_pkmap_nr ] )
break ; /* Found a usable entry */
if ( - - count )
continue ;
/*
* Sleep for somebody else to unmap their entries
*/
{
DECLARE_WAITQUEUE ( wait , current ) ;
2014-08-07 03:08:23 +04:00
wait_queue_head_t * pkmap_map_wait =
get_pkmap_wait_queue_head ( color ) ;
2005-04-17 02:20:36 +04:00
__set_current_state ( TASK_UNINTERRUPTIBLE ) ;
2014-08-07 03:08:23 +04:00
add_wait_queue ( pkmap_map_wait , & wait ) ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
unlock_kmap ( ) ;
2005-04-17 02:20:36 +04:00
schedule ( ) ;
2014-08-07 03:08:23 +04:00
remove_wait_queue ( pkmap_map_wait , & wait ) ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
lock_kmap ( ) ;
2005-04-17 02:20:36 +04:00
/* Somebody else might have mapped it while we slept */
if ( page_address ( page ) )
return ( unsigned long ) page_address ( page ) ;
/* Re-start */
goto start ;
}
}
vaddr = PKMAP_ADDR ( last_pkmap_nr ) ;
set_pte_at ( & init_mm , vaddr ,
& ( pkmap_page_table [ last_pkmap_nr ] ) , mk_pte ( page , kmap_prot ) ) ;
pkmap_count [ last_pkmap_nr ] = 1 ;
set_page_address ( page , ( void * ) vaddr ) ;
return vaddr ;
}
2008-03-20 03:00:42 +03:00
/**
* kmap_high - map a highmem page into memory
* @ page : & struct page to map
*
* Returns the page ' s virtual memory address .
*
* We cannot call this from interrupts , as it may block .
*/
2008-02-05 09:29:26 +03:00
void * kmap_high ( struct page * page )
2005-04-17 02:20:36 +04:00
{
unsigned long vaddr ;
/*
* For highmem pages , we can ' t trust " virtual " until
* after we have the lock .
*/
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
lock_kmap ( ) ;
2005-04-17 02:20:36 +04:00
vaddr = ( unsigned long ) page_address ( page ) ;
if ( ! vaddr )
vaddr = map_new_virtual ( page ) ;
pkmap_count [ PKMAP_NR ( vaddr ) ] + + ;
2006-04-02 15:47:35 +04:00
BUG_ON ( pkmap_count [ PKMAP_NR ( vaddr ) ] < 2 ) ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
unlock_kmap ( ) ;
2005-04-17 02:20:36 +04:00
return ( void * ) vaddr ;
}
EXPORT_SYMBOL ( kmap_high ) ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
# ifdef ARCH_NEEDS_KMAP_HIGH_GET
/**
* kmap_high_get - pin a highmem page into memory
* @ page : & struct page to pin
*
* Returns the page ' s current virtual memory address , or NULL if no mapping
2010-01-25 23:38:09 +03:00
* exists . If and only if a non null address is returned then a
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
* matching call to kunmap_high ( ) is necessary .
*
* This can be called from any context .
*/
void * kmap_high_get ( struct page * page )
{
unsigned long vaddr , flags ;
lock_kmap_any ( flags ) ;
vaddr = ( unsigned long ) page_address ( page ) ;
if ( vaddr ) {
BUG_ON ( pkmap_count [ PKMAP_NR ( vaddr ) ] < 1 ) ;
pkmap_count [ PKMAP_NR ( vaddr ) ] + + ;
}
unlock_kmap_any ( flags ) ;
return ( void * ) vaddr ;
}
# endif
2008-03-20 03:00:42 +03:00
/**
2011-11-01 04:09:09 +04:00
* kunmap_high - unmap a highmem page into memory
2008-03-20 03:00:42 +03:00
* @ page : & struct page to unmap
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
*
* If ARCH_NEEDS_KMAP_HIGH_GET is not defined then this may be called
* only from user context .
2008-03-20 03:00:42 +03:00
*/
2008-02-05 09:29:26 +03:00
void kunmap_high ( struct page * page )
2005-04-17 02:20:36 +04:00
{
unsigned long vaddr ;
unsigned long nr ;
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
unsigned long flags ;
2005-04-17 02:20:36 +04:00
int need_wakeup ;
2014-08-07 03:08:23 +04:00
unsigned int color = get_pkmap_color ( page ) ;
wait_queue_head_t * pkmap_map_wait ;
2005-04-17 02:20:36 +04:00
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
lock_kmap_any ( flags ) ;
2005-04-17 02:20:36 +04:00
vaddr = ( unsigned long ) page_address ( page ) ;
2006-04-02 15:47:35 +04:00
BUG_ON ( ! vaddr ) ;
2005-04-17 02:20:36 +04:00
nr = PKMAP_NR ( vaddr ) ;
/*
* A count must never go down to zero
* without a TLB flush !
*/
need_wakeup = 0 ;
switch ( - - pkmap_count [ nr ] ) {
case 0 :
BUG ( ) ;
case 1 :
/*
* Avoid an unnecessary wake_up ( ) function call .
* The common case is pkmap_count [ ] = = 1 , but
* no waiters .
* The tasks queued in the wait - queue are guarded
* by both the lock in the wait - queue - head and by
* the kmap_lock . As the kmap_lock is held here ,
* no need for the wait - queue - head ' s lock . Simply
* test if the queue is empty .
*/
2014-08-07 03:08:23 +04:00
pkmap_map_wait = get_pkmap_wait_queue_head ( color ) ;
need_wakeup = waitqueue_active ( pkmap_map_wait ) ;
2005-04-17 02:20:36 +04:00
}
highmem: atomic highmem kmap page pinning
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
2009-03-05 06:49:41 +03:00
unlock_kmap_any ( flags ) ;
2005-04-17 02:20:36 +04:00
/* do wake-up, if needed, race-free outside of the spin lock */
if ( need_wakeup )
2014-08-07 03:08:23 +04:00
wake_up ( pkmap_map_wait ) ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( kunmap_high ) ;
# endif
# if defined(HASHED_PAGE_VIRTUAL)
# define PA_HASH_ORDER 7
/*
* Describes one page - > virtual association
*/
struct page_address_map {
struct page * page ;
void * virtual ;
struct list_head list ;
} ;
2012-12-12 04:01:23 +04:00
static struct page_address_map page_address_maps [ LAST_PKMAP ] ;
2005-04-17 02:20:36 +04:00
/*
* Hash table bucket
*/
static struct page_address_slot {
struct list_head lh ; /* List of page_address_maps */
spinlock_t lock ; /* Protect this bucket's list */
} ____cacheline_aligned_in_smp page_address_htable [ 1 < < PA_HASH_ORDER ] ;
2011-08-17 16:45:09 +04:00
static struct page_address_slot * page_slot ( const struct page * page )
2005-04-17 02:20:36 +04:00
{
return & page_address_htable [ hash_ptr ( page , PA_HASH_ORDER ) ] ;
}
2008-03-20 03:00:42 +03:00
/**
* page_address - get the mapped virtual address of a page
* @ page : & struct page to get the virtual address of
*
* Returns the page ' s virtual address .
*/
2011-08-17 16:45:09 +04:00
void * page_address ( const struct page * page )
2005-04-17 02:20:36 +04:00
{
unsigned long flags ;
void * ret ;
struct page_address_slot * pas ;
if ( ! PageHighMem ( page ) )
return lowmem_page_address ( page ) ;
pas = page_slot ( page ) ;
ret = NULL ;
spin_lock_irqsave ( & pas - > lock , flags ) ;
if ( ! list_empty ( & pas - > lh ) ) {
struct page_address_map * pam ;
list_for_each_entry ( pam , & pas - > lh , list ) {
if ( pam - > page = = page ) {
ret = pam - > virtual ;
goto done ;
}
}
}
done :
spin_unlock_irqrestore ( & pas - > lock , flags ) ;
return ret ;
}
EXPORT_SYMBOL ( page_address ) ;
2008-03-20 03:00:42 +03:00
/**
* set_page_address - set a page ' s virtual address
* @ page : & struct page to set
* @ virtual : virtual address to use
*/
2005-04-17 02:20:36 +04:00
void set_page_address ( struct page * page , void * virtual )
{
unsigned long flags ;
struct page_address_slot * pas ;
struct page_address_map * pam ;
BUG_ON ( ! PageHighMem ( page ) ) ;
pas = page_slot ( page ) ;
if ( virtual ) { /* Add */
2012-12-12 04:01:23 +04:00
pam = & page_address_maps [ PKMAP_NR ( ( unsigned long ) virtual ) ] ;
2005-04-17 02:20:36 +04:00
pam - > page = page ;
pam - > virtual = virtual ;
spin_lock_irqsave ( & pas - > lock , flags ) ;
list_add_tail ( & pam - > list , & pas - > lh ) ;
spin_unlock_irqrestore ( & pas - > lock , flags ) ;
} else { /* Remove */
spin_lock_irqsave ( & pas - > lock , flags ) ;
list_for_each_entry ( pam , & pas - > lh , list ) {
if ( pam - > page = = page ) {
list_del ( & pam - > list ) ;
spin_unlock_irqrestore ( & pas - > lock , flags ) ;
goto done ;
}
}
spin_unlock_irqrestore ( & pas - > lock , flags ) ;
}
done :
return ;
}
void __init page_address_init ( void )
{
int i ;
for ( i = 0 ; i < ARRAY_SIZE ( page_address_htable ) ; i + + ) {
INIT_LIST_HEAD ( & page_address_htable [ i ] . lh ) ;
spin_lock_init ( & page_address_htable [ i ] . lock ) ;
}
}
# endif /* defined(CONFIG_HIGHMEM) && !defined(WANT_PAGE_VIRTUAL) */