License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-04-17 06:20:36 +08: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 14:01:52 +08:00
|
|
|
#include <linux/export.h>
|
2005-04-17 06:20:36 +08: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 22:22:24 +08:00
|
|
|
#include <linux/kgdb.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/tlbflush.h>
|
|
|
|
|
2010-10-28 06:32:57 +08:00
|
|
|
|
|
|
|
#if defined(CONFIG_HIGHMEM) || defined(CONFIG_X86_32)
|
|
|
|
DEFINE_PER_CPU(int, __kmap_atomic_idx);
|
|
|
|
#endif
|
|
|
|
|
2005-04-17 06:20:36 +08: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 15:22:44 +08:00
|
|
|
|
2014-08-07 07:08:23 +08: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
|
|
|
|
|
2018-12-28 16:34:29 +08:00
|
|
|
atomic_long_t _totalhigh_pages __read_mostly;
|
|
|
|
EXPORT_SYMBOL(_totalhigh_pages);
|
2010-10-27 05:21:51 +08:00
|
|
|
|
|
|
|
EXPORT_PER_CPU_SYMBOL(__kmap_atomic_idx);
|
|
|
|
|
2006-09-26 14:31:11 +08:00
|
|
|
unsigned int nr_free_highpages (void)
|
|
|
|
{
|
2016-05-20 08:12:26 +08:00
|
|
|
struct zone *zone;
|
2006-09-26 14:31:11 +08:00
|
|
|
unsigned int pages = 0;
|
|
|
|
|
2016-05-20 08:12:26 +08:00
|
|
|
for_each_populated_zone(zone) {
|
|
|
|
if (is_highmem(zone))
|
|
|
|
pages += zone_page_state(zone, NR_FREE_PAGES);
|
2007-07-17 19:03:12 +08:00
|
|
|
}
|
2006-09-26 14:31:11 +08:00
|
|
|
|
|
|
|
return pages;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08: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 11:49:41 +08: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 07:45:02 +08:00
|
|
|
struct page *kmap_to_page(void *vaddr)
|
|
|
|
{
|
|
|
|
unsigned long addr = (unsigned long)vaddr;
|
|
|
|
|
2012-11-17 06:15:00 +08:00
|
|
|
if (addr >= PKMAP_ADDR(0) && addr < PKMAP_ADDR(LAST_PKMAP)) {
|
2012-12-12 08:01:17 +08:00
|
|
|
int i = PKMAP_NR(addr);
|
2012-08-01 07:45:02 +08:00
|
|
|
return pte_page(pkmap_page_table[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
return virt_to_page(addr);
|
|
|
|
}
|
2012-10-19 21:03:31 +08:00
|
|
|
EXPORT_SYMBOL(kmap_to_page);
|
2012-08-01 07:45:02 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static void flush_all_zero_pkmaps(void)
|
|
|
|
{
|
|
|
|
int i;
|
2008-08-01 09:15:21 +08:00
|
|
|
int need_flush = 0;
|
2005-04-17 06:20:36 +08: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 19:47:35 +08:00
|
|
|
BUG_ON(pte_none(pkmap_page_table[i]));
|
2005-04-17 06:20:36 +08: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 08:01:24 +08:00
|
|
|
pte_clear(&init_mm, PKMAP_ADDR(i), &pkmap_page_table[i]);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
set_page_address(page, NULL);
|
2008-08-01 09:15:21 +08:00
|
|
|
need_flush = 1;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2008-08-01 09:15:21 +08:00
|
|
|
if (need_flush)
|
|
|
|
flush_tlb_kernel_range(PKMAP_ADDR(0), PKMAP_ADDR(LAST_PKMAP));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-03-20 08:00:42 +08:00
|
|
|
/**
|
|
|
|
* kmap_flush_unused - flush all unused kmap mappings in order to remove stray mappings
|
|
|
|
*/
|
2007-05-03 01:27:15 +08: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 11:49:41 +08:00
|
|
|
lock_kmap();
|
2007-05-03 01:27:15 +08: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 11:49:41 +08:00
|
|
|
unlock_kmap();
|
2007-05-03 01:27:15 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static inline unsigned long map_new_virtual(struct page *page)
|
|
|
|
{
|
|
|
|
unsigned long vaddr;
|
|
|
|
int count;
|
2014-08-07 07:08:23 +08:00
|
|
|
unsigned int last_pkmap_nr;
|
|
|
|
unsigned int color = get_pkmap_color(page);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
start:
|
2014-08-07 07:08:23 +08:00
|
|
|
count = get_pkmap_entries_count(color);
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Find an empty entry */
|
|
|
|
for (;;) {
|
2014-08-07 07:08:23 +08:00
|
|
|
last_pkmap_nr = get_next_pkmap_nr(color);
|
|
|
|
if (no_more_pkmaps(last_pkmap_nr, color)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
flush_all_zero_pkmaps();
|
2014-08-07 07:08:23 +08:00
|
|
|
count = get_pkmap_entries_count(color);
|
2005-04-17 06:20:36 +08: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 07:08:23 +08:00
|
|
|
wait_queue_head_t *pkmap_map_wait =
|
|
|
|
get_pkmap_wait_queue_head(color);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
__set_current_state(TASK_UNINTERRUPTIBLE);
|
2014-08-07 07:08:23 +08: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 11:49:41 +08:00
|
|
|
unlock_kmap();
|
2005-04-17 06:20:36 +08:00
|
|
|
schedule();
|
2014-08-07 07:08:23 +08: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 11:49:41 +08:00
|
|
|
lock_kmap();
|
2005-04-17 06:20:36 +08: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 08:00:42 +08: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 14:29:26 +08:00
|
|
|
void *kmap_high(struct page *page)
|
2005-04-17 06:20:36 +08: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 11:49:41 +08:00
|
|
|
lock_kmap();
|
2005-04-17 06:20:36 +08:00
|
|
|
vaddr = (unsigned long)page_address(page);
|
|
|
|
if (!vaddr)
|
|
|
|
vaddr = map_new_virtual(page);
|
|
|
|
pkmap_count[PKMAP_NR(vaddr)]++;
|
2006-04-02 19:47:35 +08: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 11:49:41 +08:00
|
|
|
unlock_kmap();
|
2005-04-17 06:20:36 +08: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 11:49:41 +08: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-26 04:38:09 +08: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 11:49:41 +08: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 08:00:42 +08:00
|
|
|
/**
|
2011-11-01 08:09:09 +08:00
|
|
|
* kunmap_high - unmap a highmem page into memory
|
2008-03-20 08:00:42 +08: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 11:49:41 +08:00
|
|
|
*
|
|
|
|
* If ARCH_NEEDS_KMAP_HIGH_GET is not defined then this may be called
|
|
|
|
* only from user context.
|
2008-03-20 08:00:42 +08:00
|
|
|
*/
|
2008-02-05 14:29:26 +08:00
|
|
|
void kunmap_high(struct page *page)
|
2005-04-17 06:20:36 +08: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 11:49:41 +08:00
|
|
|
unsigned long flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
int need_wakeup;
|
2014-08-07 07:08:23 +08:00
|
|
|
unsigned int color = get_pkmap_color(page);
|
|
|
|
wait_queue_head_t *pkmap_map_wait;
|
2005-04-17 06:20:36 +08: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 11:49:41 +08:00
|
|
|
lock_kmap_any(flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
vaddr = (unsigned long)page_address(page);
|
2006-04-02 19:47:35 +08:00
|
|
|
BUG_ON(!vaddr);
|
2005-04-17 06:20:36 +08: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 07:08:23 +08:00
|
|
|
pkmap_map_wait = get_pkmap_wait_queue_head(color);
|
|
|
|
need_wakeup = waitqueue_active(pkmap_map_wait);
|
2005-04-17 06:20:36 +08: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 11:49:41 +08:00
|
|
|
unlock_kmap_any(flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* do wake-up, if needed, race-free outside of the spin lock */
|
|
|
|
if (need_wakeup)
|
2014-08-07 07:08:23 +08:00
|
|
|
wake_up(pkmap_map_wait);
|
2005-04-17 06:20:36 +08: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 08:01:23 +08:00
|
|
|
static struct page_address_map page_address_maps[LAST_PKMAP];
|
2005-04-17 06:20:36 +08: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 20:45:09 +08:00
|
|
|
static struct page_address_slot *page_slot(const struct page *page)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return &page_address_htable[hash_ptr(page, PA_HASH_ORDER)];
|
|
|
|
}
|
|
|
|
|
2008-03-20 08:00:42 +08: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 20:45:09 +08:00
|
|
|
void *page_address(const struct page *page)
|
2005-04-17 06:20:36 +08: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 08:00:42 +08:00
|
|
|
/**
|
|
|
|
* set_page_address - set a page's virtual address
|
|
|
|
* @page: &struct page to set
|
|
|
|
* @virtual: virtual address to use
|
|
|
|
*/
|
2005-04-17 06:20:36 +08: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 08:01:23 +08:00
|
|
|
pam = &page_address_maps[PKMAP_NR((unsigned long)virtual)];
|
2005-04-17 06:20:36 +08: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) */
|