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

drivers/char/mem.c: memory_open() cleanup: lookup minor device number from devlist

2009-06-18T20:03:54+00:00

memory_open() ignores devlist and does a switch for each item, duplicating
code and conditional definitions.

Clean it up by adding backing_dev_info to devlist and use it to lookup for
the minor device.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Adriano dos Santos Fernandes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Make /dev/zero reads interruptible by signals

2009-06-10T03:40:25+00:00

This helps with bad latencies for large reads from /dev/zero, but might
conceivably break some application that "knows" that a read of /dev/zero
cannot return early.  So do this early in the merge window to give us
maximal test coverage, even if the patch is totally trivial.

Obviously, no well-behaved application should ever depend on the read
being uninterruptible, but hey, bugs happen.

Signed-off-by: Linus Torvalds

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