kernel-ark/drivers/char/mspec.c

455 lines
11 KiB
C
Raw Normal View History

/*
* Copyright (C) 2001-2006 Silicon Graphics, Inc. All rights
* reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of version 2 of the GNU General Public License
* as published by the Free Software Foundation.
*/
/*
* SN Platform Special Memory (mspec) Support
*
* This driver exports the SN special memory (mspec) facility to user
* processes.
* There are three types of memory made available thru this driver:
* fetchops, uncached and cached.
*
* Fetchops are atomic memory operations that are implemented in the
* memory controller on SGI SN hardware.
*
* Uncached are used for memory write combining feature of the ia64
* cpu.
*
* Cached are used for areas of memory that are used as cached addresses
* on our partition and used as uncached addresses from other partitions.
* Due to a design constraint of the SN2 Shub, you can not have processors
* on the same FSB perform both a cached and uncached reference to the
* same cache line. These special memory cached regions prevent the
* kernel from ever dropping in a TLB entry and therefore prevent the
* processor from ever speculating a cache line from this page.
*/
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/miscdevice.h>
#include <linux/spinlock.h>
#include <linux/mm.h>
Remove fs.h from mm.h Remove fs.h from mm.h. For this, 1) Uninline vma_wants_writenotify(). It's pretty huge anyway. 2) Add back fs.h or less bloated headers (err.h) to files that need it. As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files rebuilt down to 3444 (-12.3%). Cross-compile tested without regressions on my two usual configs and (sigh): alpha arm-mx1ads mips-bigsur powerpc-ebony alpha-allnoconfig arm-neponset mips-capcella powerpc-g5 alpha-defconfig arm-netwinder mips-cobalt powerpc-holly alpha-up arm-netx mips-db1000 powerpc-iseries arm arm-ns9xxx mips-db1100 powerpc-linkstation arm-assabet arm-omap_h2_1610 mips-db1200 powerpc-lite5200 arm-at91rm9200dk arm-onearm mips-db1500 powerpc-maple arm-at91rm9200ek arm-picotux200 mips-db1550 powerpc-mpc7448_hpc2 arm-at91sam9260ek arm-pleb mips-ddb5477 powerpc-mpc8272_ads arm-at91sam9261ek arm-pnx4008 mips-decstation powerpc-mpc8313_rdb arm-at91sam9263ek arm-pxa255-idp mips-e55 powerpc-mpc832x_mds arm-at91sam9rlek arm-realview mips-emma2rh powerpc-mpc832x_rdb arm-ateb9200 arm-realview-smp mips-excite powerpc-mpc834x_itx arm-badge4 arm-rpc mips-fulong powerpc-mpc834x_itxgp arm-carmeva arm-s3c2410 mips-ip22 powerpc-mpc834x_mds arm-cerfcube arm-shannon mips-ip27 powerpc-mpc836x_mds arm-clps7500 arm-shark mips-ip32 powerpc-mpc8540_ads arm-collie arm-simpad mips-jazz powerpc-mpc8544_ds arm-corgi arm-spitz mips-jmr3927 powerpc-mpc8560_ads arm-csb337 arm-trizeps4 mips-malta powerpc-mpc8568mds arm-csb637 arm-versatile mips-mipssim powerpc-mpc85xx_cds arm-ebsa110 i386 mips-mpc30x powerpc-mpc8641_hpcn arm-edb7211 i386-allnoconfig mips-msp71xx powerpc-mpc866_ads arm-em_x270 i386-defconfig mips-ocelot powerpc-mpc885_ads arm-ep93xx i386-up mips-pb1100 powerpc-pasemi arm-footbridge ia64 mips-pb1500 powerpc-pmac32 arm-fortunet ia64-allnoconfig mips-pb1550 powerpc-ppc64 arm-h3600 ia64-bigsur mips-pnx8550-jbs powerpc-prpmc2800 arm-h7201 ia64-defconfig mips-pnx8550-stb810 powerpc-ps3 arm-h7202 ia64-gensparse mips-qemu powerpc-pseries arm-hackkit ia64-sim mips-rbhma4200 powerpc-up arm-integrator ia64-sn2 mips-rbhma4500 s390 arm-iop13xx ia64-tiger mips-rm200 s390-allnoconfig arm-iop32x ia64-up mips-sb1250-swarm s390-defconfig arm-iop33x ia64-zx1 mips-sead s390-up arm-ixp2000 m68k mips-tb0219 sparc arm-ixp23xx m68k-amiga mips-tb0226 sparc-allnoconfig arm-ixp4xx m68k-apollo mips-tb0287 sparc-defconfig arm-jornada720 m68k-atari mips-workpad sparc-up arm-kafa m68k-bvme6000 mips-wrppmc sparc64 arm-kb9202 m68k-hp300 mips-yosemite sparc64-allnoconfig arm-ks8695 m68k-mac parisc sparc64-defconfig arm-lart m68k-mvme147 parisc-allnoconfig sparc64-up arm-lpd270 m68k-mvme16x parisc-defconfig um-x86_64 arm-lpd7a400 m68k-q40 parisc-up x86_64 arm-lpd7a404 m68k-sun3 powerpc x86_64-allnoconfig arm-lubbock m68k-sun3x powerpc-cell x86_64-defconfig arm-lusl7200 mips powerpc-celleb x86_64-up arm-mainstone mips-atlas powerpc-chrp32 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-29 22:36:13 +00:00
#include <linux/fs.h>
#include <linux/vmalloc.h>
#include <linux/string.h>
#include <linux/slab.h>
#include <linux/numa.h>
#include <asm/page.h>
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/atomic.h>
#include <asm/tlbflush.h>
#include <asm/uncached.h>
#include <asm/sn/addrs.h>
#include <asm/sn/arch.h>
#include <asm/sn/mspec.h>
#include <asm/sn/sn_cpuid.h>
#include <asm/sn/io.h>
#include <asm/sn/bte.h>
#include <asm/sn/shubio.h>
#define FETCHOP_ID "SGI Fetchop,"
#define CACHED_ID "Cached,"
#define UNCACHED_ID "Uncached"
#define REVISION "4.0"
#define MSPEC_BASENAME "mspec"
/*
* Page types allocated by the device.
*/
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
enum mspec_page_type {
MSPEC_FETCHOP = 1,
MSPEC_CACHED,
MSPEC_UNCACHED
};
#ifdef CONFIG_SGI_SN
static int is_sn2;
#else
#define is_sn2 0
#endif
/*
* One of these structures is allocated when an mspec region is mmaped. The
* structure is pointed to by the vma->vm_private_data field in the vma struct.
* This structure is used to record the addresses of the mspec pages.
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
* This structure is shared by all vma's that are split off from the
* original vma when split_vma()'s are done.
*
* The refcnt is incremented atomically because mm->mmap_sem does not
* protect in fork case where multiple tasks share the vma_data.
*/
struct vma_data {
atomic_t refcnt; /* Number of vmas sharing the data. */
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
spinlock_t lock; /* Serialize access to this structure. */
int count; /* Number of pages allocated. */
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
enum mspec_page_type type; /* Type of pages allocated. */
int flags; /* See VMD_xxx below. */
unsigned long vm_start; /* Original (unsplit) base. */
unsigned long vm_end; /* Original (unsplit) end. */
unsigned long maddr[0]; /* Array of MSPEC addresses. */
};
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
#define VMD_VMALLOCED 0x1 /* vmalloc'd rather than kmalloc'd */
/* used on shub2 to clear FOP cache in the HUB */
static unsigned long scratch_page[MAX_NUMNODES];
#define SH2_AMO_CACHE_ENTRIES 4
static inline int
mspec_zero_block(unsigned long addr, int len)
{
int status;
if (is_sn2) {
if (is_shub2()) {
int nid;
void *p;
int i;
nid = nasid_to_cnodeid(get_node_number(__pa(addr)));
p = (void *)TO_AMO(scratch_page[nid]);
for (i=0; i < SH2_AMO_CACHE_ENTRIES; i++) {
FETCHOP_LOAD_OP(p, FETCHOP_LOAD);
p += FETCHOP_VAR_SIZE;
}
}
status = bte_copy(0, addr & ~__IA64_UNCACHED_OFFSET, len,
BTE_WACQUIRE | BTE_ZERO_FILL, NULL);
} else {
memset((char *) addr, 0, len);
status = 0;
}
return status;
}
/*
* mspec_open
*
* Called when a device mapping is created by a means other than mmap
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
* (via fork, munmap, etc.). Increments the reference count on the
* underlying mspec data so it is not freed prematurely.
*/
static void
mspec_open(struct vm_area_struct *vma)
{
struct vma_data *vdata;
vdata = vma->vm_private_data;
atomic_inc(&vdata->refcnt);
}
/*
* mspec_close
*
* Called when unmapping a device mapping. Frees all mspec pages
* belonging to the vma.
*/
static void
mspec_close(struct vm_area_struct *vma)
{
struct vma_data *vdata;
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
int index, last_index, result;
unsigned long my_page;
vdata = vma->vm_private_data;
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
BUG_ON(vma->vm_start < vdata->vm_start || vma->vm_end > vdata->vm_end);
spin_lock(&vdata->lock);
index = (vma->vm_start - vdata->vm_start) >> PAGE_SHIFT;
last_index = (vma->vm_end - vdata->vm_start) >> PAGE_SHIFT;
for (; index < last_index; index++) {
if (vdata->maddr[index] == 0)
continue;
/*
* Clear the page before sticking it back
* into the pool.
*/
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
my_page = vdata->maddr[index];
vdata->maddr[index] = 0;
spin_unlock(&vdata->lock);
result = mspec_zero_block(my_page, PAGE_SIZE);
if (!result)
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
uncached_free_page(my_page);
else
printk(KERN_WARNING "mspec_close(): "
"failed to zero page %i\n",
result);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
spin_lock(&vdata->lock);
}
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
spin_unlock(&vdata->lock);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
if (!atomic_dec_and_test(&vdata->refcnt))
return;
if (vdata->flags & VMD_VMALLOCED)
vfree(vdata);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
else
kfree(vdata);
}
/*
* mspec_nopfn
*
* Creates a mspec page and maps it to user space.
*/
static unsigned long
mspec_nopfn(struct vm_area_struct *vma, unsigned long address)
{
unsigned long paddr, maddr;
unsigned long pfn;
int index;
struct vma_data *vdata = vma->vm_private_data;
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
BUG_ON(address < vdata->vm_start || address >= vdata->vm_end);
index = (address - vdata->vm_start) >> PAGE_SHIFT;
maddr = (volatile unsigned long) vdata->maddr[index];
if (maddr == 0) {
maddr = uncached_alloc_page(numa_node_id());
if (maddr == 0)
return NOPFN_OOM;
spin_lock(&vdata->lock);
if (vdata->maddr[index] == 0) {
vdata->count++;
vdata->maddr[index] = maddr;
} else {
uncached_free_page(maddr);
maddr = vdata->maddr[index];
}
spin_unlock(&vdata->lock);
}
if (vdata->type == MSPEC_FETCHOP)
paddr = TO_AMO(maddr);
else
paddr = maddr & ~__IA64_UNCACHED_OFFSET;
pfn = paddr >> PAGE_SHIFT;
return pfn;
}
static struct vm_operations_struct mspec_vm_ops = {
.open = mspec_open,
.close = mspec_close,
.nopfn = mspec_nopfn
};
/*
* mspec_mmap
*
* Called when mmaping the device. Initializes the vma with a fault handler
* and private data structure necessary to allocate, track, and free the
* underlying pages.
*/
static int
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
mspec_mmap(struct file *file, struct vm_area_struct *vma,
enum mspec_page_type type)
{
struct vma_data *vdata;
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
int pages, vdata_size, flags = 0;
if (vma->vm_pgoff != 0)
return -EINVAL;
if ((vma->vm_flags & VM_SHARED) == 0)
return -EINVAL;
if ((vma->vm_flags & VM_WRITE) == 0)
return -EPERM;
pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
vdata_size = sizeof(struct vma_data) + pages * sizeof(long);
if (vdata_size <= PAGE_SIZE)
vdata = kmalloc(vdata_size, GFP_KERNEL);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
else {
vdata = vmalloc(vdata_size);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
flags = VMD_VMALLOCED;
}
if (!vdata)
return -ENOMEM;
memset(vdata, 0, vdata_size);
mspec: handle shrinking virtual memory areas The shrinking of a virtual memory area that is mmap(2)'d to a memory special file (device drivers/char/mspec.c) can cause a panic. If the mapped size of the vma (vm_area_struct) is very large, mspec allocates a large vma_data structure with vmalloc(). But such a vma can be shrunk by an munmap(2). The current driver uses the current size of each vma to deduce whether its vma_data structure was allocated by kmalloc() or vmalloc(). So if the vma was shrunk it appears to have been allocated by kmalloc(), and mspec attempts to free it with kfree(). This results in a panic. This patch avoids the panic (by preserving the type of the allocation) and also makes mspec work correctly as the vma is split into pieces by the munmap(2)'s. All vma's derived from such a split vma share the same vma_data structure that represents all the pages mapped into this set of vma's. The mpec driver must be made capable of using the right portion of the structure for each member vma. In other words, it must index into the array of page addresses using the portion of the array that represents the current vma. This is enabled by storing the vma group's vm_start in the vma_data structure. The shared vma_data's are not protected by mm->mmap_sem in the fork() case so the reference count is left as atomic_t. Signed-off-by: Cliff Wickman <cpw@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-09-19 05:46:31 +00:00
vdata->vm_start = vma->vm_start;
vdata->vm_end = vma->vm_end;
vdata->flags = flags;
vdata->type = type;
spin_lock_init(&vdata->lock);
vdata->refcnt = ATOMIC_INIT(1);
vma->vm_private_data = vdata;
vma->vm_flags |= (VM_IO | VM_RESERVED | VM_PFNMAP);
if (vdata->type == MSPEC_FETCHOP || vdata->type == MSPEC_UNCACHED)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_ops = &mspec_vm_ops;
return 0;
}
static int
fetchop_mmap(struct file *file, struct vm_area_struct *vma)
{
return mspec_mmap(file, vma, MSPEC_FETCHOP);
}
static int
cached_mmap(struct file *file, struct vm_area_struct *vma)
{
return mspec_mmap(file, vma, MSPEC_CACHED);
}
static int
uncached_mmap(struct file *file, struct vm_area_struct *vma)
{
return mspec_mmap(file, vma, MSPEC_UNCACHED);
}
static const struct file_operations fetchop_fops = {
.owner = THIS_MODULE,
.mmap = fetchop_mmap
};
static struct miscdevice fetchop_miscdev = {
.minor = MISC_DYNAMIC_MINOR,
.name = "sgi_fetchop",
.fops = &fetchop_fops
};
static const struct file_operations cached_fops = {
.owner = THIS_MODULE,
.mmap = cached_mmap
};
static struct miscdevice cached_miscdev = {
.minor = MISC_DYNAMIC_MINOR,
.name = "mspec_cached",
.fops = &cached_fops
};
static const struct file_operations uncached_fops = {
.owner = THIS_MODULE,
.mmap = uncached_mmap
};
static struct miscdevice uncached_miscdev = {
.minor = MISC_DYNAMIC_MINOR,
.name = "mspec_uncached",
.fops = &uncached_fops
};
/*
* mspec_init
*
* Called at boot time to initialize the mspec facility.
*/
static int __init
mspec_init(void)
{
int ret;
int nid;
/*
* The fetchop device only works on SN2 hardware, uncached and cached
* memory drivers should both be valid on all ia64 hardware
*/
#ifdef CONFIG_SGI_SN
if (ia64_platform_is("sn2")) {
is_sn2 = 1;
if (is_shub2()) {
ret = -ENOMEM;
for_each_online_node(nid) {
int actual_nid;
int nasid;
unsigned long phys;
scratch_page[nid] = uncached_alloc_page(nid);
if (scratch_page[nid] == 0)
goto free_scratch_pages;
phys = __pa(scratch_page[nid]);
nasid = get_node_number(phys);
actual_nid = nasid_to_cnodeid(nasid);
if (actual_nid != nid)
goto free_scratch_pages;
}
}
ret = misc_register(&fetchop_miscdev);
if (ret) {
printk(KERN_ERR
"%s: failed to register device %i\n",
FETCHOP_ID, ret);
goto free_scratch_pages;
}
}
#endif
ret = misc_register(&cached_miscdev);
if (ret) {
printk(KERN_ERR "%s: failed to register device %i\n",
CACHED_ID, ret);
if (is_sn2)
misc_deregister(&fetchop_miscdev);
goto free_scratch_pages;
}
ret = misc_register(&uncached_miscdev);
if (ret) {
printk(KERN_ERR "%s: failed to register device %i\n",
UNCACHED_ID, ret);
misc_deregister(&cached_miscdev);
if (is_sn2)
misc_deregister(&fetchop_miscdev);
goto free_scratch_pages;
}
printk(KERN_INFO "%s %s initialized devices: %s %s %s\n",
MSPEC_BASENAME, REVISION, is_sn2 ? FETCHOP_ID : "",
CACHED_ID, UNCACHED_ID);
return 0;
free_scratch_pages:
for_each_node(nid) {
if (scratch_page[nid] != 0)
uncached_free_page(scratch_page[nid]);
}
return ret;
}
static void __exit
mspec_exit(void)
{
int nid;
misc_deregister(&uncached_miscdev);
misc_deregister(&cached_miscdev);
if (is_sn2) {
misc_deregister(&fetchop_miscdev);
for_each_node(nid) {
if (scratch_page[nid] != 0)
uncached_free_page(scratch_page[nid]);
}
}
}
module_init(mspec_init);
module_exit(mspec_exit);
MODULE_AUTHOR("Silicon Graphics, Inc. <linux-altix@sgi.com>");
MODULE_DESCRIPTION("Driver for SGI SN special memory operations");
MODULE_LICENSE("GPL");