2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* linux/drivers/char/mem.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
|
|
|
*
|
2010-03-10 16:21:52 -07:00
|
|
|
* Added devfs support.
|
2005-04-16 16:20:36 -06:00
|
|
|
* Jan-11-1998, C. Scott Ananian <cananian@alumni.princeton.edu>
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 08:09:05 -07:00
|
|
|
* Shared /dev/zero mmapping support, Feb 2000, Kanoj Sarcar <kanoj@sgi.com>
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/miscdevice.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/random.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/raw.h>
|
|
|
|
#include <linux/tty.h>
|
|
|
|
#include <linux/capability.h>
|
|
|
|
#include <linux/ptrace.h>
|
|
|
|
#include <linux/device.h>
|
2005-06-25 15:58:23 -06:00
|
|
|
#include <linux/highmem.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/backing-dev.h>
|
2005-06-25 15:58:24 -06:00
|
|
|
#include <linux/bootmem.h>
|
2007-06-04 01:59:47 -06:00
|
|
|
#include <linux/splice.h>
|
2006-10-13 09:42:10 -06:00
|
|
|
#include <linux/pfn.h>
|
2011-07-10 10:14:53 -06:00
|
|
|
#include <linux/export.h>
|
2012-07-10 23:18:44 -06:00
|
|
|
#include <linux/io.h>
|
2013-05-07 17:19:08 -06:00
|
|
|
#include <linux/aio.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
|
|
|
|
#ifdef CONFIG_IA64
|
|
|
|
# include <linux/efi.h>
|
|
|
|
#endif
|
|
|
|
|
2012-07-10 23:18:44 -06:00
|
|
|
#define DEVPORT_MINOR 4
|
|
|
|
|
2009-12-14 18:58:07 -07:00
|
|
|
static inline unsigned long size_inside_page(unsigned long start,
|
|
|
|
unsigned long size)
|
|
|
|
{
|
|
|
|
unsigned long sz;
|
|
|
|
|
2009-12-14 18:58:09 -07:00
|
|
|
sz = PAGE_SIZE - (start & (PAGE_SIZE - 1));
|
2009-12-14 18:58:07 -07:00
|
|
|
|
2009-12-14 18:58:09 -07:00
|
|
|
return min(sz, size);
|
2009-12-14 18:58:07 -07:00
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
#ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE
|
2012-09-12 12:05:58 -06:00
|
|
|
static inline int valid_phys_addr_range(phys_addr_t addr, size_t count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2011-03-23 17:42:58 -06:00
|
|
|
return addr + count <= __pa(high_memory);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2006-01-08 02:04:13 -07:00
|
|
|
|
2006-07-10 05:45:27 -06:00
|
|
|
static inline int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
|
2006-01-08 02:04:13 -07:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
#endif
|
|
|
|
|
2008-07-17 16:26:59 -06:00
|
|
|
#ifdef CONFIG_STRICT_DEVMEM
|
2008-03-07 00:01:47 -07:00
|
|
|
static inline int range_is_allowed(unsigned long pfn, unsigned long size)
|
2008-04-24 15:40:47 -06:00
|
|
|
{
|
2008-03-07 00:01:47 -07:00
|
|
|
u64 from = ((u64)pfn) << PAGE_SHIFT;
|
|
|
|
u64 to = from + size;
|
|
|
|
u64 cursor = from;
|
|
|
|
|
|
|
|
while (cursor < to) {
|
|
|
|
if (!devmem_is_allowed(pfn)) {
|
|
|
|
printk(KERN_INFO
|
|
|
|
"Program %s tried to access /dev/mem between %Lx->%Lx.\n",
|
2008-04-24 15:40:47 -06:00
|
|
|
current->comm, from, to);
|
|
|
|
return 0;
|
|
|
|
}
|
2008-03-07 00:01:47 -07:00
|
|
|
cursor += PAGE_SIZE;
|
|
|
|
pfn++;
|
2008-04-24 15:40:47 -06:00
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#else
|
2008-03-07 00:01:47 -07:00
|
|
|
static inline int range_is_allowed(unsigned long pfn, unsigned long size)
|
2008-04-24 15:40:47 -06:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
void __weak unxlate_dev_mem_ptr(unsigned long phys, void *addr)
|
2008-03-18 18:00:15 -06:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
2010-03-10 16:21:52 -07:00
|
|
|
* This funcion reads the *physical* memory. The f_pos points directly to the
|
|
|
|
* memory location.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t read_mem(struct file *file, char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
2012-09-12 12:05:58 -06:00
|
|
|
phys_addr_t p = *ppos;
|
2005-04-16 16:20:36 -06:00
|
|
|
ssize_t read, sz;
|
|
|
|
char *ptr;
|
|
|
|
|
2006-03-26 02:37:05 -07:00
|
|
|
if (!valid_phys_addr_range(p, count))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
|
|
|
read = 0;
|
|
|
|
#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
|
|
|
|
/* we don't have page 0 mapped on sparc and m68k.. */
|
|
|
|
if (p < PAGE_SIZE) {
|
2009-12-14 18:58:09 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (sz > 0) {
|
|
|
|
if (clear_user(buf, sz))
|
|
|
|
return -EFAULT;
|
2010-03-10 16:21:52 -07:00
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
read += sz;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
while (count > 0) {
|
2009-12-14 18:58:08 -07:00
|
|
|
unsigned long remaining;
|
|
|
|
|
2009-12-14 18:58:07 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-03-18 18:00:15 -06:00
|
|
|
if (!range_is_allowed(p >> PAGE_SHIFT, count))
|
|
|
|
return -EPERM;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
2010-03-10 16:21:52 -07:00
|
|
|
* On ia64 if a page has been mapped somewhere as uncached, then
|
|
|
|
* it must also be accessed uncached by the kernel or data
|
|
|
|
* corruption may occur.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
|
|
|
ptr = xlate_dev_mem_ptr(p);
|
2008-03-18 18:00:15 -06:00
|
|
|
if (!ptr)
|
|
|
|
return -EFAULT;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-12-14 18:58:08 -07:00
|
|
|
remaining = copy_to_user(buf, ptr, sz);
|
2008-03-18 18:00:15 -06:00
|
|
|
unxlate_dev_mem_ptr(p, ptr);
|
2009-12-14 18:58:08 -07:00
|
|
|
if (remaining)
|
|
|
|
return -EFAULT;
|
2008-03-18 18:00:15 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
read += sz;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ppos += read;
|
|
|
|
return read;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t write_mem(struct file *file, const char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
2012-09-12 12:05:58 -06:00
|
|
|
phys_addr_t p = *ppos;
|
2005-04-16 16:20:36 -06:00
|
|
|
ssize_t written, sz;
|
|
|
|
unsigned long copied;
|
|
|
|
void *ptr;
|
|
|
|
|
2006-03-26 02:37:05 -07:00
|
|
|
if (!valid_phys_addr_range(p, count))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
written = 0;
|
|
|
|
|
|
|
|
#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
|
|
|
|
/* we don't have page 0 mapped on sparc and m68k.. */
|
|
|
|
if (p < PAGE_SIZE) {
|
2009-12-14 18:58:09 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Hmm. Do something? */
|
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
written += sz;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
while (count > 0) {
|
2009-12-14 18:58:07 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-03-18 18:00:15 -06:00
|
|
|
if (!range_is_allowed(p >> PAGE_SHIFT, sz))
|
|
|
|
return -EPERM;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
2010-03-10 16:21:52 -07:00
|
|
|
* On ia64 if a page has been mapped somewhere as uncached, then
|
|
|
|
* it must also be accessed uncached by the kernel or data
|
|
|
|
* corruption may occur.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
|
|
|
ptr = xlate_dev_mem_ptr(p);
|
2008-03-18 18:00:15 -06:00
|
|
|
if (!ptr) {
|
|
|
|
if (written)
|
|
|
|
break;
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
copied = copy_from_user(ptr, buf, sz);
|
2009-12-14 18:58:08 -07:00
|
|
|
unxlate_dev_mem_ptr(p, ptr);
|
2005-04-16 16:20:36 -06:00
|
|
|
if (copied) {
|
2006-03-25 04:07:31 -07:00
|
|
|
written += sz - copied;
|
|
|
|
if (written)
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
2008-03-18 18:00:15 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
written += sz;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ppos += written;
|
|
|
|
return written;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
int __weak phys_mem_access_prot_allowed(struct file *file,
|
2008-03-18 18:00:20 -06:00
|
|
|
unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-01-08 02:04:10 -07:00
|
|
|
#ifndef __HAVE_PHYS_MEM_ACCESS_PROT
|
2010-03-10 16:21:52 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Architectures vary in how they handle caching for addresses
|
|
|
|
* outside of main memory.
|
|
|
|
*
|
|
|
|
*/
|
2010-04-06 15:35:08 -06:00
|
|
|
#ifdef pgprot_noncached
|
2012-09-12 12:05:58 -06:00
|
|
|
static int uncached_access(struct file *file, phys_addr_t addr)
|
2010-03-10 16:21:52 -07:00
|
|
|
{
|
|
|
|
#if defined(CONFIG_IA64)
|
|
|
|
/*
|
|
|
|
* On ia64, we ignore O_DSYNC because we cannot tolerate memory
|
|
|
|
* attribute aliases.
|
|
|
|
*/
|
|
|
|
return !(efi_mem_attributes(addr) & EFI_MEMORY_WB);
|
|
|
|
#elif defined(CONFIG_MIPS)
|
|
|
|
{
|
|
|
|
extern int __uncached_access(struct file *file,
|
|
|
|
unsigned long addr);
|
|
|
|
|
|
|
|
return __uncached_access(file, addr);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* Accessing memory above the top the kernel knows about or through a
|
|
|
|
* file pointer
|
|
|
|
* that was marked O_DSYNC will be done non-cached.
|
|
|
|
*/
|
|
|
|
if (file->f_flags & O_DSYNC)
|
|
|
|
return 1;
|
|
|
|
return addr >= __pa(high_memory);
|
|
|
|
#endif
|
|
|
|
}
|
2010-04-06 15:35:08 -06:00
|
|
|
#endif
|
2010-03-10 16:21:52 -07:00
|
|
|
|
2006-01-08 02:04:10 -07:00
|
|
|
static pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
|
|
|
|
unsigned long size, pgprot_t vma_prot)
|
|
|
|
{
|
|
|
|
#ifdef pgprot_noncached
|
2012-09-12 12:05:58 -06:00
|
|
|
phys_addr_t offset = pfn << PAGE_SHIFT;
|
2006-01-08 02:04:10 -07:00
|
|
|
|
|
|
|
if (uncached_access(file, offset))
|
|
|
|
return pgprot_noncached(vma_prot);
|
|
|
|
#endif
|
|
|
|
return vma_prot;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2006-09-27 02:50:16 -06:00
|
|
|
#ifndef CONFIG_MMU
|
|
|
|
static unsigned long get_unmapped_area_mem(struct file *file,
|
|
|
|
unsigned long addr,
|
|
|
|
unsigned long len,
|
|
|
|
unsigned long pgoff,
|
|
|
|
unsigned long flags)
|
|
|
|
{
|
|
|
|
if (!valid_mmap_phys_addr_range(pgoff, len))
|
|
|
|
return (unsigned long) -EINVAL;
|
2007-04-16 23:53:16 -06:00
|
|
|
return pgoff << PAGE_SHIFT;
|
2006-09-27 02:50:16 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/* can't do an in-place private mapping if there's no MMU */
|
|
|
|
static inline int private_mapping_ok(struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
return vma->vm_flags & VM_MAYSHARE;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
#define get_unmapped_area_mem NULL
|
|
|
|
|
|
|
|
static inline int private_mapping_ok(struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2009-09-27 12:29:37 -06:00
|
|
|
static const struct vm_operations_struct mmap_mem_ops = {
|
2008-07-23 22:27:07 -06:00
|
|
|
#ifdef CONFIG_HAVE_IOREMAP_PROT
|
|
|
|
.access = generic_access_phys
|
|
|
|
#endif
|
2008-03-18 18:00:21 -06:00
|
|
|
};
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static int mmap_mem(struct file *file, struct vm_area_struct *vma)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-01-08 02:04:13 -07:00
|
|
|
size_t size = vma->vm_end - vma->vm_start;
|
|
|
|
|
2006-07-10 05:45:27 -06:00
|
|
|
if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
|
2006-01-08 02:04:13 -07:00
|
|
|
return -EINVAL;
|
|
|
|
|
2006-09-27 02:50:16 -06:00
|
|
|
if (!private_mapping_ok(vma))
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2008-03-07 00:01:47 -07:00
|
|
|
if (!range_is_allowed(vma->vm_pgoff, size))
|
|
|
|
return -EPERM;
|
|
|
|
|
2008-03-18 18:00:20 -06:00
|
|
|
if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size,
|
|
|
|
&vma->vm_page_prot))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2005-10-28 18:46:18 -06:00
|
|
|
vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff,
|
2006-01-08 02:04:13 -07:00
|
|
|
size,
|
2005-04-16 16:20:36 -06:00
|
|
|
vma->vm_page_prot);
|
|
|
|
|
2008-03-18 18:00:21 -06:00
|
|
|
vma->vm_ops = &mmap_mem_ops;
|
|
|
|
|
mm: kill vma flag VM_RESERVED and mm->reserved_vm counter
A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:
| effect | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
This patch removes reserved_vm counter from mm_struct. Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.
Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Venkatesh Pallipadi <venki@google.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-10-08 17:29:02 -06:00
|
|
|
/* Remap-pfn-range will mark the range VM_IO */
|
2005-04-16 16:20:36 -06:00
|
|
|
if (remap_pfn_range(vma,
|
|
|
|
vma->vm_start,
|
|
|
|
vma->vm_pgoff,
|
2006-01-08 02:04:13 -07:00
|
|
|
size,
|
2008-03-18 18:00:21 -06:00
|
|
|
vma->vm_page_prot)) {
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EAGAIN;
|
2008-03-18 18:00:21 -06:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-29 01:58:34 -06:00
|
|
|
#ifdef CONFIG_DEVKMEM
|
2010-03-10 16:21:52 -07:00
|
|
|
static int mmap_kmem(struct file *file, struct vm_area_struct *vma)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-08-13 15:22:59 -06:00
|
|
|
unsigned long pfn;
|
|
|
|
|
2007-01-22 09:53:24 -07:00
|
|
|
/* Turn a kernel-virtual address into a physical page frame */
|
|
|
|
pfn = __pa((u64)vma->vm_pgoff << PAGE_SHIFT) >> PAGE_SHIFT;
|
2005-08-13 15:22:59 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
2010-03-10 16:21:52 -07:00
|
|
|
* RED-PEN: on some architectures there is more mapped memory than
|
|
|
|
* available in mem_map which pfn_valid checks for. Perhaps should add a
|
|
|
|
* new macro here.
|
2005-04-16 16:20:36 -06:00
|
|
|
*
|
|
|
|
* RED-PEN: vmalloc is not supported right now.
|
|
|
|
*/
|
2005-08-13 15:22:59 -06:00
|
|
|
if (!pfn_valid(pfn))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EIO;
|
2005-08-13 15:22:59 -06:00
|
|
|
|
|
|
|
vma->vm_pgoff = pfn;
|
2005-04-16 16:20:36 -06:00
|
|
|
return mmap_mem(file, vma);
|
|
|
|
}
|
2008-04-29 01:58:34 -06:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-04-29 01:58:34 -06:00
|
|
|
#ifdef CONFIG_DEVKMEM
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* This function reads the *virtual* memory as seen by the kernel.
|
|
|
|
*/
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t read_kmem(struct file *file, char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
unsigned long p = *ppos;
|
|
|
|
ssize_t low_count, read, sz;
|
2013-02-06 03:37:20 -07:00
|
|
|
char *kbuf; /* k-addr because vread() takes vmlist_lock rwlock */
|
2010-02-02 14:44:05 -07:00
|
|
|
int err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
read = 0;
|
|
|
|
if (p < (unsigned long) high_memory) {
|
|
|
|
low_count = count;
|
2010-03-10 16:21:52 -07:00
|
|
|
if (count > (unsigned long)high_memory - p)
|
|
|
|
low_count = (unsigned long)high_memory - p;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
|
|
|
|
/* we don't have page 0 mapped on sparc and m68k.. */
|
|
|
|
if (p < PAGE_SIZE && low_count > 0) {
|
2009-12-14 18:58:09 -07:00
|
|
|
sz = size_inside_page(p, low_count);
|
|
|
|
if (clear_user(buf, sz))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
2009-12-14 18:58:09 -07:00
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
read += sz;
|
|
|
|
low_count -= sz;
|
|
|
|
count -= sz;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
while (low_count > 0) {
|
2009-12-14 18:58:07 -07:00
|
|
|
sz = size_inside_page(p, low_count);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* On ia64 if a page has been mapped somewhere as
|
|
|
|
* uncached, then it must also be accessed uncached
|
|
|
|
* by the kernel or data corruption may occur
|
|
|
|
*/
|
|
|
|
kbuf = xlate_dev_kmem_ptr((char *)p);
|
|
|
|
|
|
|
|
if (copy_to_user(buf, kbuf, sz))
|
|
|
|
return -EFAULT;
|
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
read += sz;
|
|
|
|
low_count -= sz;
|
|
|
|
count -= sz;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count > 0) {
|
|
|
|
kbuf = (char *)__get_free_page(GFP_KERNEL);
|
|
|
|
if (!kbuf)
|
|
|
|
return -ENOMEM;
|
|
|
|
while (count > 0) {
|
2009-12-14 18:58:10 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2010-02-02 14:44:05 -07:00
|
|
|
if (!is_vmalloc_or_module_addr((void *)p)) {
|
|
|
|
err = -ENXIO;
|
|
|
|
break;
|
|
|
|
}
|
2009-12-14 18:58:10 -07:00
|
|
|
sz = vread(kbuf, (char *)p, sz);
|
|
|
|
if (!sz)
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
2009-12-14 18:58:10 -07:00
|
|
|
if (copy_to_user(buf, kbuf, sz)) {
|
2010-02-02 14:44:05 -07:00
|
|
|
err = -EFAULT;
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2009-12-14 18:58:10 -07:00
|
|
|
count -= sz;
|
|
|
|
buf += sz;
|
|
|
|
read += sz;
|
|
|
|
p += sz;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
free_page((unsigned long)kbuf);
|
|
|
|
}
|
2010-02-02 14:44:05 -07:00
|
|
|
*ppos = p;
|
|
|
|
return read ? read : err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t do_write_kmem(unsigned long p, const char __user *buf,
|
|
|
|
size_t count, loff_t *ppos)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
ssize_t written, sz;
|
|
|
|
unsigned long copied;
|
|
|
|
|
|
|
|
written = 0;
|
|
|
|
#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
|
|
|
|
/* we don't have page 0 mapped on sparc and m68k.. */
|
2009-12-14 18:58:10 -07:00
|
|
|
if (p < PAGE_SIZE) {
|
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Hmm. Do something? */
|
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
written += sz;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
while (count > 0) {
|
|
|
|
char *ptr;
|
|
|
|
|
2009-12-14 18:58:10 -07:00
|
|
|
sz = size_inside_page(p, count);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
2010-03-10 16:21:52 -07:00
|
|
|
* On ia64 if a page has been mapped somewhere as uncached, then
|
|
|
|
* it must also be accessed uncached by the kernel or data
|
|
|
|
* corruption may occur.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2009-12-14 18:58:10 -07:00
|
|
|
ptr = xlate_dev_kmem_ptr((char *)p);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
copied = copy_from_user(ptr, buf, sz);
|
|
|
|
if (copied) {
|
2006-03-25 04:07:31 -07:00
|
|
|
written += sz - copied;
|
|
|
|
if (written)
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
buf += sz;
|
|
|
|
p += sz;
|
|
|
|
count -= sz;
|
|
|
|
written += sz;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ppos += written;
|
|
|
|
return written;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function writes to the *virtual* memory as seen by the kernel.
|
|
|
|
*/
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t write_kmem(struct file *file, const char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
unsigned long p = *ppos;
|
|
|
|
ssize_t wrote = 0;
|
|
|
|
ssize_t virtr = 0;
|
2013-02-06 03:37:20 -07:00
|
|
|
char *kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
|
2010-02-02 14:44:05 -07:00
|
|
|
int err = 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (p < (unsigned long) high_memory) {
|
2009-12-14 18:58:10 -07:00
|
|
|
unsigned long to_write = min_t(unsigned long, count,
|
|
|
|
(unsigned long)high_memory - p);
|
2009-12-14 18:58:10 -07:00
|
|
|
wrote = do_write_kmem(p, buf, to_write, ppos);
|
2009-12-14 18:58:10 -07:00
|
|
|
if (wrote != to_write)
|
|
|
|
return wrote;
|
2005-04-16 16:20:36 -06:00
|
|
|
p += wrote;
|
|
|
|
buf += wrote;
|
|
|
|
count -= wrote;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count > 0) {
|
|
|
|
kbuf = (char *)__get_free_page(GFP_KERNEL);
|
|
|
|
if (!kbuf)
|
|
|
|
return wrote ? wrote : -ENOMEM;
|
|
|
|
while (count > 0) {
|
2009-12-14 18:58:10 -07:00
|
|
|
unsigned long sz = size_inside_page(p, count);
|
|
|
|
unsigned long n;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-02-02 14:44:05 -07:00
|
|
|
if (!is_vmalloc_or_module_addr((void *)p)) {
|
|
|
|
err = -ENXIO;
|
|
|
|
break;
|
|
|
|
}
|
2009-12-14 18:58:10 -07:00
|
|
|
n = copy_from_user(kbuf, buf, sz);
|
|
|
|
if (n) {
|
2010-02-02 14:44:05 -07:00
|
|
|
err = -EFAULT;
|
|
|
|
break;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2010-02-02 14:44:06 -07:00
|
|
|
vwrite(kbuf, (char *)p, sz);
|
2009-12-14 18:58:10 -07:00
|
|
|
count -= sz;
|
|
|
|
buf += sz;
|
|
|
|
virtr += sz;
|
|
|
|
p += sz;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
free_page((unsigned long)kbuf);
|
|
|
|
}
|
|
|
|
|
2010-02-02 14:44:05 -07:00
|
|
|
*ppos = p;
|
|
|
|
return virtr + wrote ? : err;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2008-04-29 01:58:34 -06:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-05-08 01:28:17 -06:00
|
|
|
#ifdef CONFIG_DEVPORT
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t read_port(struct file *file, char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
unsigned long i = *ppos;
|
|
|
|
char __user *tmp = buf;
|
|
|
|
|
|
|
|
if (!access_ok(VERIFY_WRITE, buf, count))
|
2010-03-10 16:21:52 -07:00
|
|
|
return -EFAULT;
|
2005-04-16 16:20:36 -06:00
|
|
|
while (count-- > 0 && i < 65536) {
|
2010-03-10 16:21:52 -07:00
|
|
|
if (__put_user(inb(i), tmp) < 0)
|
|
|
|
return -EFAULT;
|
2005-04-16 16:20:36 -06:00
|
|
|
i++;
|
|
|
|
tmp++;
|
|
|
|
}
|
|
|
|
*ppos = i;
|
|
|
|
return tmp-buf;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t write_port(struct file *file, const char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
unsigned long i = *ppos;
|
2013-02-06 03:37:20 -07:00
|
|
|
const char __user *tmp = buf;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
if (!access_ok(VERIFY_READ, buf, count))
|
2005-04-16 16:20:36 -06:00
|
|
|
return -EFAULT;
|
|
|
|
while (count-- > 0 && i < 65536) {
|
|
|
|
char c;
|
2006-03-25 04:07:31 -07:00
|
|
|
if (__get_user(c, tmp)) {
|
|
|
|
if (tmp > buf)
|
|
|
|
break;
|
2010-03-10 16:21:52 -07:00
|
|
|
return -EFAULT;
|
2006-03-25 04:07:31 -07:00
|
|
|
}
|
2010-03-10 16:21:52 -07:00
|
|
|
outb(c, i);
|
2005-04-16 16:20:36 -06:00
|
|
|
i++;
|
|
|
|
tmp++;
|
|
|
|
}
|
|
|
|
*ppos = i;
|
|
|
|
return tmp-buf;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t read_null(struct file *file, char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t write_null(struct file *file, const char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2013-05-07 17:18:27 -06:00
|
|
|
static ssize_t aio_read_null(struct kiocb *iocb, const struct iovec *iov,
|
|
|
|
unsigned long nr_segs, loff_t pos)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t aio_write_null(struct kiocb *iocb, const struct iovec *iov,
|
|
|
|
unsigned long nr_segs, loff_t pos)
|
|
|
|
{
|
|
|
|
return iov_length(iov, nr_segs);
|
|
|
|
}
|
|
|
|
|
2006-04-26 06:40:08 -06:00
|
|
|
static int pipe_to_null(struct pipe_inode_info *info, struct pipe_buffer *buf,
|
|
|
|
struct splice_desc *sd)
|
|
|
|
{
|
|
|
|
return sd->len;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t splice_write_null(struct pipe_inode_info *pipe, struct file *out,
|
2006-04-26 06:40:08 -06:00
|
|
|
loff_t *ppos, size_t len, unsigned int flags)
|
|
|
|
{
|
|
|
|
return splice_from_pipe(pipe, out, ppos, len, flags, pipe_to_null);
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t read_zero(struct file *file, char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
size_t written;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
if (!count)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!access_ok(VERIFY_WRITE, buf, count))
|
|
|
|
return -EFAULT;
|
|
|
|
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
written = 0;
|
|
|
|
while (count) {
|
|
|
|
unsigned long unwritten;
|
|
|
|
size_t chunk = count;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
if (chunk > PAGE_SIZE)
|
|
|
|
chunk = PAGE_SIZE; /* Just for latency reasons */
|
2009-09-23 16:57:09 -06:00
|
|
|
unwritten = __clear_user(buf, chunk);
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
written += chunk - unwritten;
|
2005-04-16 16:20:36 -06:00
|
|
|
if (unwritten)
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
break;
|
2009-06-09 21:40:25 -06:00
|
|
|
if (signal_pending(current))
|
|
|
|
return written ? written : -ERESTARTSYS;
|
2005-04-16 16:20:36 -06:00
|
|
|
buf += chunk;
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
count -= chunk;
|
2005-04-16 16:20:36 -06:00
|
|
|
cond_resched();
|
|
|
|
}
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
return written ? written : -EFAULT;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2013-05-07 17:18:27 -06:00
|
|
|
static ssize_t aio_read_zero(struct kiocb *iocb, const struct iovec *iov,
|
|
|
|
unsigned long nr_segs, loff_t pos)
|
|
|
|
{
|
|
|
|
size_t written = 0;
|
|
|
|
unsigned long i;
|
|
|
|
ssize_t ret;
|
|
|
|
|
|
|
|
for (i = 0; i < nr_segs; i++) {
|
|
|
|
ret = read_zero(iocb->ki_filp, iov[i].iov_base, iov[i].iov_len,
|
|
|
|
&pos);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
written += ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return written ? written : -EFAULT;
|
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static int mmap_zero(struct file *file, struct vm_area_struct *vma)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
#ifndef CONFIG_MMU
|
2005-04-16 16:20:36 -06:00
|
|
|
return -ENOSYS;
|
remove ZERO_PAGE
The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note
A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
(and thus mapcounted and count towards shared rss). These writes to
the struct page could cause excessive cacheline bouncing on big
systems. There are a number of ways this could be addressed if it is
an issue.
And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).
There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely
I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.
Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).
As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.
When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.
Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.
The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked. I don't see
much use to them except on benchmarks. All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus "snif" Torvalds <torvalds@linux-foundation.org>
2007-10-16 02:24:40 -06:00
|
|
|
#endif
|
|
|
|
if (vma->vm_flags & VM_SHARED)
|
|
|
|
return shmem_zero_setup(vma);
|
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
static ssize_t write_full(struct file *file, const char __user *buf,
|
2005-04-16 16:20:36 -06:00
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Special lseek() function for /dev/null and /dev/zero. Most notably, you
|
|
|
|
* can fopen() both devices with "a" now. This was previously impossible.
|
|
|
|
* -- SRB.
|
|
|
|
*/
|
2010-03-10 16:21:52 -07:00
|
|
|
static loff_t null_lseek(struct file *file, loff_t offset, int orig)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
return file->f_pos = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The memory devices use the full 32/64 bits of the offset, and so we cannot
|
|
|
|
* check against negative addresses: they are ok. The return value is weird,
|
|
|
|
* though, in that case (0).
|
|
|
|
*
|
|
|
|
* also note that seeking relative to the "end of file" isn't supported:
|
|
|
|
* it has no meaning, so it returns -EINVAL.
|
|
|
|
*/
|
2010-03-10 16:21:52 -07:00
|
|
|
static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
loff_t ret;
|
|
|
|
|
2013-01-23 15:07:38 -07:00
|
|
|
mutex_lock(&file_inode(file)->i_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
switch (orig) {
|
2010-03-10 16:21:52 -07:00
|
|
|
case SEEK_CUR:
|
|
|
|
offset += file->f_pos;
|
|
|
|
case SEEK_SET:
|
|
|
|
/* to avoid userland mistaking f_pos=-9 as -EBADF=-9 */
|
2013-06-05 11:09:39 -06:00
|
|
|
if (IS_ERR_VALUE((unsigned long long)offset)) {
|
2010-03-10 16:21:52 -07:00
|
|
|
ret = -EOVERFLOW;
|
2005-04-16 16:20:36 -06:00
|
|
|
break;
|
2010-03-10 16:21:52 -07:00
|
|
|
}
|
|
|
|
file->f_pos = offset;
|
|
|
|
ret = file->f_pos;
|
|
|
|
force_successful_syscall_return();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2013-01-23 15:07:38 -07:00
|
|
|
mutex_unlock(&file_inode(file)->i_mutex);
|
2005-04-16 16:20:36 -06:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-02-06 03:37:20 -07:00
|
|
|
static int open_port(struct inode *inode, struct file *filp)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define zero_lseek null_lseek
|
|
|
|
#define full_lseek null_lseek
|
|
|
|
#define write_zero write_null
|
|
|
|
#define read_full read_zero
|
2013-05-07 17:18:27 -06:00
|
|
|
#define aio_write_zero aio_write_null
|
2005-04-16 16:20:36 -06:00
|
|
|
#define open_mem open_port
|
|
|
|
#define open_kmem open_mem
|
|
|
|
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations mem_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = memory_lseek,
|
|
|
|
.read = read_mem,
|
|
|
|
.write = write_mem,
|
|
|
|
.mmap = mmap_mem,
|
|
|
|
.open = open_mem,
|
2006-09-27 02:50:16 -06:00
|
|
|
.get_unmapped_area = get_unmapped_area_mem,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2008-04-29 01:58:34 -06:00
|
|
|
#ifdef CONFIG_DEVKMEM
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations kmem_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = memory_lseek,
|
|
|
|
.read = read_kmem,
|
|
|
|
.write = write_kmem,
|
|
|
|
.mmap = mmap_kmem,
|
|
|
|
.open = open_kmem,
|
2006-09-27 02:50:16 -06:00
|
|
|
.get_unmapped_area = get_unmapped_area_mem,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
2008-04-29 01:58:34 -06:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations null_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = null_lseek,
|
|
|
|
.read = read_null,
|
|
|
|
.write = write_null,
|
2013-05-07 17:18:27 -06:00
|
|
|
.aio_read = aio_read_null,
|
|
|
|
.aio_write = aio_write_null,
|
2006-04-26 06:40:08 -06:00
|
|
|
.splice_write = splice_write_null,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2007-05-08 01:28:17 -06:00
|
|
|
#ifdef CONFIG_DEVPORT
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations port_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = memory_lseek,
|
|
|
|
.read = read_port,
|
|
|
|
.write = write_port,
|
|
|
|
.open = open_port,
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations zero_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = zero_lseek,
|
|
|
|
.read = read_zero,
|
|
|
|
.write = write_zero,
|
2013-05-07 17:18:27 -06:00
|
|
|
.aio_read = aio_read_zero,
|
|
|
|
.aio_write = aio_write_zero,
|
2005-04-16 16:20:36 -06:00
|
|
|
.mmap = mmap_zero,
|
|
|
|
};
|
|
|
|
|
2006-09-27 02:50:16 -06:00
|
|
|
/*
|
|
|
|
* capabilities for /dev/zero
|
|
|
|
* - permits private mappings, "copies" are taken of the source of zeros
|
2010-09-21 03:49:01 -06:00
|
|
|
* - no writeback happens
|
2006-09-27 02:50:16 -06:00
|
|
|
*/
|
2005-04-16 16:20:36 -06:00
|
|
|
static struct backing_dev_info zero_bdi = {
|
2009-06-12 06:45:52 -06:00
|
|
|
.name = "char/mem",
|
2010-09-21 03:49:01 -06:00
|
|
|
.capabilities = BDI_CAP_MAP_COPY | BDI_CAP_NO_ACCT_AND_WRITEBACK,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations full_fops = {
|
2005-04-16 16:20:36 -06:00
|
|
|
.llseek = full_lseek,
|
|
|
|
.read = read_full,
|
|
|
|
.write = write_full,
|
|
|
|
};
|
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
static const struct memdev {
|
|
|
|
const char *name;
|
2011-07-23 18:24:48 -06:00
|
|
|
umode_t mode;
|
2009-07-04 08:51:29 -06:00
|
|
|
const struct file_operations *fops;
|
|
|
|
struct backing_dev_info *dev_info;
|
|
|
|
} devlist[] = {
|
2009-09-18 15:01:12 -06:00
|
|
|
[1] = { "mem", 0, &mem_fops, &directly_mappable_cdev_bdi },
|
2008-04-29 01:58:34 -06:00
|
|
|
#ifdef CONFIG_DEVKMEM
|
2009-09-18 15:01:12 -06:00
|
|
|
[2] = { "kmem", 0, &kmem_fops, &directly_mappable_cdev_bdi },
|
2008-04-29 01:58:34 -06:00
|
|
|
#endif
|
2009-09-18 15:01:12 -06:00
|
|
|
[3] = { "null", 0666, &null_fops, NULL },
|
2007-05-08 01:28:17 -06:00
|
|
|
#ifdef CONFIG_DEVPORT
|
2009-09-18 15:01:12 -06:00
|
|
|
[4] = { "port", 0, &port_fops, NULL },
|
2005-04-16 16:20:36 -06:00
|
|
|
#endif
|
2009-09-18 15:01:12 -06:00
|
|
|
[5] = { "zero", 0666, &zero_fops, &zero_bdi },
|
|
|
|
[7] = { "full", 0666, &full_fops, NULL },
|
|
|
|
[8] = { "random", 0666, &random_fops, NULL },
|
|
|
|
[9] = { "urandom", 0666, &urandom_fops, NULL },
|
2012-05-08 17:37:51 -06:00
|
|
|
#ifdef CONFIG_PRINTK
|
kmsg: export printk records to the /dev/kmsg interface
Support for multiple concurrent readers of /dev/kmsg, with read(),
seek(), poll() support. Output of message sequence numbers, to allow
userspace log consumers to reliably reconnect and reconstruct their
state at any given time. After open("/dev/kmsg"), read() always
returns *all* buffered records. If only future messages should be
read, SEEK_END can be used. In case records get overwritten while
/dev/kmsg is held open, or records get faster overwritten than they
are read, the next read() will return -EPIPE and the current reading
position gets updated to the next available record. The passed
sequence numbers allow the log consumer to calculate the amount of
lost messages.
[root@mop ~]# cat /dev/kmsg
5,0,0;Linux version 3.4.0-rc1+ (kay@mop) (gcc version 4.7.0 20120315 ...
6,159,423091;ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
7,160,424069;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
SUBSYSTEM=acpi
DEVICE=+acpi:PNP0A03:00
6,339,5140900;NET: Registered protocol family 10
30,340,5690716;udevd[80]: starting version 181
6,341,6081421;FDC 0 is a S82078B
6,345,6154686;microcode: CPU0 sig=0x623, pf=0x0, revision=0x0
7,346,6156968;sr 1:0:0:0: Attached scsi CD-ROM sr0
SUBSYSTEM=scsi
DEVICE=+scsi:1:0:0:0
6,347,6289375;microcode: CPU1 sig=0x623, pf=0x0, revision=0x0
Cc: Karel Zak <kzak@redhat.com>
Tested-by: William Douglas <william.douglas@intel.com>
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-02 18:29:41 -06:00
|
|
|
[11] = { "kmsg", 0644, &kmsg_fops, NULL },
|
2012-05-08 17:37:51 -06:00
|
|
|
#endif
|
2009-06-17 17:27:48 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
static int memory_open(struct inode *inode, struct file *filp)
|
|
|
|
{
|
2009-07-04 08:51:29 -06:00
|
|
|
int minor;
|
|
|
|
const struct memdev *dev;
|
2009-06-17 17:27:48 -06:00
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
minor = iminor(inode);
|
|
|
|
if (minor >= ARRAY_SIZE(devlist))
|
2009-10-09 12:31:02 -06:00
|
|
|
return -ENXIO;
|
2009-06-17 17:27:48 -06:00
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
dev = &devlist[minor];
|
|
|
|
if (!dev->fops)
|
2009-10-09 12:31:02 -06:00
|
|
|
return -ENXIO;
|
2009-06-17 17:27:48 -06:00
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
filp->f_op = dev->fops;
|
|
|
|
if (dev->dev_info)
|
|
|
|
filp->f_mapping->backing_dev_info = dev->dev_info;
|
2009-06-17 17:27:48 -06:00
|
|
|
|
2010-10-01 15:20:22 -06:00
|
|
|
/* Is /dev/mem or /dev/kmem ? */
|
|
|
|
if (dev->dev_info == &directly_mappable_cdev_bdi)
|
|
|
|
filp->f_mode |= FMODE_UNSIGNED_OFFSET;
|
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
if (dev->fops->open)
|
2009-10-09 12:31:02 -06:00
|
|
|
return dev->fops->open(inode, filp);
|
|
|
|
|
|
|
|
return 0;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-07-03 01:24:21 -06:00
|
|
|
static const struct file_operations memory_fops = {
|
2010-03-10 16:21:52 -07:00
|
|
|
.open = memory_open,
|
llseek: automatically add .llseek fop
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.
The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.
New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.
The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.
Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.
Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.
===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{
<+...
nonseekable_open(...)
...+>
}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{
<+...
(
nonseekable_open(...)
|
nested_open(...)
)
...+>
}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}
@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}
@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};
@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};
@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};
@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};
@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};
// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};
@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};
// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};
// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};
// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};
@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};
// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////
@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};
@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};
@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};
@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Julia Lawall <julia@diku.dk>
Cc: Christoph Hellwig <hch@infradead.org>
2010-08-15 10:52:59 -06:00
|
|
|
.llseek = noop_llseek,
|
2005-04-16 16:20:36 -06:00
|
|
|
};
|
|
|
|
|
2011-07-23 18:24:48 -06:00
|
|
|
static char *mem_devnode(struct device *dev, umode_t *mode)
|
2009-09-18 15:01:12 -06:00
|
|
|
{
|
|
|
|
if (mode && devlist[MINOR(dev->devt)].mode)
|
|
|
|
*mode = devlist[MINOR(dev->devt)].mode;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2005-03-23 10:53:09 -07:00
|
|
|
static struct class *mem_class;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
static int __init chr_dev_init(void)
|
|
|
|
{
|
2009-07-04 08:51:29 -06:00
|
|
|
int minor;
|
2007-10-17 00:25:46 -06:00
|
|
|
int err;
|
|
|
|
|
|
|
|
err = bdi_init(&zero_bdi);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2010-03-10 16:21:52 -07:00
|
|
|
if (register_chrdev(MEM_MAJOR, "mem", &memory_fops))
|
2005-04-16 16:20:36 -06:00
|
|
|
printk("unable to get major %d for memory devs\n", MEM_MAJOR);
|
|
|
|
|
2005-03-23 10:53:09 -07:00
|
|
|
mem_class = class_create(THIS_MODULE, "mem");
|
2010-04-06 15:34:55 -06:00
|
|
|
if (IS_ERR(mem_class))
|
|
|
|
return PTR_ERR(mem_class);
|
|
|
|
|
2009-09-18 15:01:12 -06:00
|
|
|
mem_class->devnode = mem_devnode;
|
2009-07-04 08:51:29 -06:00
|
|
|
for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
|
|
|
|
if (!devlist[minor].name)
|
|
|
|
continue;
|
2012-07-10 23:18:44 -06:00
|
|
|
|
|
|
|
/*
|
2013-02-06 03:37:20 -07:00
|
|
|
* Create /dev/port?
|
2012-07-10 23:18:44 -06:00
|
|
|
*/
|
|
|
|
if ((minor == DEVPORT_MINOR) && !arch_has_dev_port())
|
|
|
|
continue;
|
|
|
|
|
2009-07-04 08:51:29 -06:00
|
|
|
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
|
|
|
|
NULL, devlist[minor].name);
|
|
|
|
}
|
2006-07-25 18:13:31 -06:00
|
|
|
|
2010-08-06 09:34:43 -06:00
|
|
|
return tty_init();
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
fs_initcall(chr_dev_init);
|