linux.git/drivers/char/mem.c, branch v2.6.30

drivers/char/mem.c: avoid OOM lockup during large reads from /dev/zero

2009-06-04T22:20:39+00:00

While running 20 parallel instances of dd as follows:

  #!/bin/bash
  for i in `seq 1 20`; do
           dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 &
  done
  wait

on a 16G machine, we noticed that rather than just killing the processes,
the entire kernel went down.  Stracing dd reveals that it first does an
mmap2, which makes 1GB worth of zero page mappings.  Then it performs a
read on those pages from /dev/zero, and finally it performs a write.

The machine died during the reads.  Looking at the code, it was noticed
that /dev/zero's read operation had been changed by
557ed1fa2620dc119adb86b34c614e152a629a80 ("remove ZERO_PAGE") from giving
zero page mappings to actually zeroing the page.

The zeroing of the pages causes physical pages to be allocated to the
process.  But, when the process exhausts all the memory that it can, the
kernel cannot kill it, as it is still in the kernel mode allocating more
memory.  Consequently, the kernel eventually crashes.

To fix this, I propose that when a fatal signal is pending during
/dev/zero read operation, we simply return and let the user process die.

Signed-off-by: Salman Qazi 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
[ Modified error return and comment trivially.  - Linus]
Signed-off-by: Linus Torvalds

x86, PAT: Remove duplicate memtype reserve in devmem mmap

2009-04-10T11:55:48+00:00

/dev/mem mmap code was doing memtype reserve/free for a while now.
Recently we added memtype tracking in remap_pfn_range, and /dev/mem mmap
uses it indirectly. So, we don't need seperate tracking in /dev/mem code
any more. That means another ~100 lines of code removed :-).

Signed-off-by: Suresh Siddha 
Signed-off-by: Venkatesh Pallipadi 
LKML-Reference: <20090409212709.085210000@intel.com>
Signed-off-by: Ingo Molnar

mm: make vread() and vwrite() declaration

2009-01-06T23:59:05+00:00

Sparse output following warnings.

mm/vmalloc.c:1436:6: warning: symbol 'vread' was not declared. Should it be static?
mm/vmalloc.c:1474:6: warning: symbol 'vwrite' was not declared. Should it be static?

However, it is used by /dev/kmem. fixed here.

Signed-off-by: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

device create: char: convert device_create_drvdata to device_create

2008-10-16T16:24:42+00:00

Now that device_create() has been audited, rename things back to the
original call to be sane.

Signed-off-by: Greg Kroah-Hartman

use generic_access_phys for /dev/mem mappings

2008-07-24T17:47:15+00:00

Use generic_access_phys as the access_process_vm access function for
/dev/mem mappings.  This makes it possible to debug the X server.

[akpm@linux-foundation.org: repair all the architectures which broke]
Signed-off-by: Rik van Riel 
Cc: Benjamin Herrensmidt 
Cc: Dave Airlie 
Cc: Hugh Dickins 
Cc: Paul Mackerras 
Cc: Arnd Bergmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

device create: char: convert device_create to device_create_drvdata

2008-07-22T04:54:41+00:00

device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.

Signed-off-by: Greg Kroah-Hartman

Subject: devmem, x86: fix rename of CONFIG_NONPROMISC_DEVMEM

2008-07-20T06:35:55+00:00

From: Arjan van de Ven 
Date: Sat, 19 Jul 2008 15:47:17 -0700

CONFIG_NONPROMISC_DEVMEM was a rather confusing name - but renaming it
to CONFIG_PROMISC_DEVMEM causes problems on architectures that do not
support this feature; this patch renames it to CONFIG_STRICT_DEVMEM,
so that architectures can opt-in into it.

( the polarity of the option is still the same as it was originally; it
  needs to be for now to not break architectures that don't have the
  infastructure yet to support this feature)

Signed-off-by: Arjan van de Ven 
Cc: "V.Radhakrishnan" 
Signed-off-by: Ingo Molnar 
---

x86: rename CONFIG_NONPROMISC_DEVMEM to CONFIG_PROMISC_DEVMEM

2008-07-17T22:28:57+00:00

Linus observed:

> The real bug is that we shouldn't have "double negatives", and
> certainly not negative config options. Making that "promiscuous
> /dev/mem" option a negated thing as a config option was bad.

right ... lets rename this option. There should never be a negation
in config options.

[ that reminds me of CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER, but that
  is for another commit ;-) ]

Signed-off-by: Ingo Molnar

mem: cdev lock_kernel() pushdown

2008-06-20T20:05:48+00:00

It's really hard to tell if this is necessary - lots of weird
magic happens by way of map_devmem()

Signed-off-by: Jonathan Corbet

make /dev/kmem a config option

2008-04-29T15:05:59+00:00

Make /dev/kmem a config option; /dev/kmem is VERY rarely used, and when
used, it's generally for no good (rootkits tend to be the most common
users).  With this config option, users have the choice to disable
/dev/kmem, saving some size as well.

A patch to disable /dev/kmem has been in the Fedora and RHEL kernels for
4+ years now without any known problems or legit users of /dev/kmem.

[akpm@linux-foundation.org: make CONFIG_DEVKMEM default to y]
Signed-off-by: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds