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

const: mark struct vm_struct_operations

2009-09-27T18:39:25+00:00

* mark struct vm_area_struct::vm_ops as const
* mark vm_ops in AGP code

But leave TTM code alone, something is fishy there with global vm_ops
being used.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds

/dev/zero: avoid repeated access_ok() checks

2009-09-24T14:21:03+00:00

In read_zero, we check for access_ok() once for the count bytes.  It is
unnecessarily checked again in clear_user.  Use __clear_user, which does
not check for access_ok().

Signed-off-by: Nikanth Karthikesan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Driver-Core: extend devnode callbacks to provide permissions

2009-09-19T19:50:38+00:00

This allows subsytems to provide devtmpfs with non-default permissions
for the device node. Instead of the default mode of 0600, null, zero,
random, urandom, full, tty, ptmx now have a mode of 0666, which allows
non-privileged processes to access standard device nodes in case no
other userspace process applies the expected permissions.

This also fixes a wrong assignment in pktcdvd and a checkpatch.pl complain.

Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

mem_class: fix bug

2009-09-15T16:50:47+00:00

When I build and boot -next on fedora 10, I can not login anymore.
When I input the user name and password, the system does not output
any message and requires user to input the user name and password
again and again.

I find the patch which caused this problem with "GIT BISECT" command.
And the patch is
    commit 7c4b7daa1878972ed0137c95f23569124bd6e2b1
    "mem_class: use minor as index instead of searching the array".

Though I don't know the real reason why user could not login, I
confirmed the patch I made as following could resolve the problem on
fedora 10.

Signed-off-by: Jin Dongming 
Acked-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

mem_class: use minor as index instead of searching the array

2009-09-15T16:50:47+00:00

Declare the device list with the minor numbers as the index, which saves us from
searching for a matching list entry. Remove old devfs permissions declaration.

Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

writeback: add name to backing_dev_info

2009-09-11T07:20:26+00:00

This enables us to track who does what and print info. Its main use
is catching dirty inodes on the default_backing_dev_info, so we can
fix that up.

Signed-off-by: Jens Axboe

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