linux-stable.git, branch v3.8.9

Linux 3.8.9

2013-04-25T19:52:16+00:00

Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."

2013-04-25T19:51:25+00:00

commit 3b5e50edaf500f392f4a372296afc0b99ffa7e70 upstream.

This reverts commit c17a6554782ad531f4713b33fd6339ba67ef6391.

Manuel Lauss writes:

lmo commit c17a6554 (MIPS: page.h: Provide more readable definition for
PAGE_MASK) apparently breaks ioremap of 36-bit addresses on my Alchemy
systems (PCI and PCMCIA) The reason is that in arch/mips/mm/ioremap.c
line 157  (phys_addr &= PAGE_MASK) bits 32-35 are cut off.  Seems the
new PAGE_MASK is explicitly 32bit, or one could make it signed instead
of unsigned long.

From: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

s390: move dummy io_remap_pfn_range() to asm/pgtable.h

2013-04-25T19:51:24+00:00

commit 4f2e29031e6c67802e7370292dd050fd62f337ee upstream.

Commit b4cbb197c7e7 ("vm: add vm_iomap_memory() helper function") added
a helper function wrapper around io_remap_pfn_range(), and every other
architecture defined it in .

The s390 choice of  may make sense, but is not very convenient
for this case, and gratuitous differences like that cause unexpected errors like this:

   mm/memory.c: In function 'vm_iomap_memory':
   mm/memory.c:2439:2: error: implicit declaration of function 'io_remap_pfn_range' [-Werror=implicit-function-declaration]

Glory be the kbuild test robot who noticed this, bisected it, and
reported it to the guilty parties (ie me).

Signed-off-by: Linus Torvalds 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

Btrfs: make sure nbytes are right after log replay

2013-04-25T19:51:24+00:00

commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream.

While trying to track down a tree log replay bug I noticed that fsck was always
complaining about nbytes not being right for our fsynced file.  That is because
the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
nbytes are not necessarily updated properly when we log it.  So to fix this we
need to set nbytes to whatever it is on the inode that is on disk, so when we
replay the extents we can just add the bytes that are being added as we replay
the extent.  This makes it work for the case that we have the wrong nbytes or
the case that we logged everything and nbytes is actually correct.  With this
I'm no longer getting nbytes errors out of btrfsck.

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason 
Signed-off-by: Lingzhu Xiang 
Reviewed-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

vm: convert mtdchar mmap to vm_iomap_memory() helper

2013-04-25T19:51:24+00:00

commit 8558e4a26b00225efeb085725bc319f91201b239 upstream.

This is my example conversion of a few existing mmap users.  The mtdchar
case is actually disabled right now (and stays disabled), but I did it
because it showed up on my "git grep", and I was familiar with the code
due to fixing an overflow problem in the code in commit 9c603e53d380
("mtdchar: fix offset overflow detection").

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vm: convert HPET mmap to vm_iomap_memory() helper

2013-04-25T19:51:24+00:00

commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream.

This is my example conversion of a few existing mmap users.  The HPET
case is simple, widely available, and easy to test (Clemens Ladisch sent
a trivial test-program for it).

Test-program-by: Clemens Ladisch 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vm: convert fb_mmap to vm_iomap_memory() helper

2013-04-25T19:51:24+00:00

commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream.

This is my example conversion of a few existing mmap users.  The
fb_mmap() case is a good example because it is a bit more complicated
than some: fb_mmap() mmaps one of two different memory areas depending
on the page offset of the mmap (but happily there is never any mixing of
the two, so the helper function still works).

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper

2013-04-25T19:51:24+00:00

commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream.

This is my example conversion of a few existing mmap users.  The pcm
mmap case is one of the more straightforward ones.

Acked-by: Takashi Iwai 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vm: add vm_iomap_memory() helper function

2013-04-25T19:51:24+00:00

commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream.

Various drivers end up replicating the code to mmap() their memory
buffers into user space, and our core memory remapping function may be
very flexible but it is unnecessarily complicated for the common cases
to use.

Our internal VM uses pfn's ("page frame numbers") which simplifies
things for the VM, and allows us to pass physical addresses around in a
denser and more efficient format than passing a "phys_addr_t" around,
and having to shift it up and down by the page size.  But it just means
that drivers end up doing that shifting instead at the interface level.

It also means that drivers end up mucking around with internal VM things
like the vma details (vm_pgoff, vm_start/end) way more than they really
need to.

So this just exports a function to map a certain physical memory range
into user space (using a phys_addr_t based interface that is much more
natural for a driver) and hides all the complexity from the driver.
Some drivers will still end up tweaking the vm_page_prot details for
things like prefetching or cacheability etc, but that's actually
relevant to the driver, rather than caring about what the page offset of
the mapping is into the particular IO memory region.

Acked-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

userns: Changing any namespace id mappings should require privileges

2013-04-25T19:51:23+00:00

commit 41c21e351e79004dbb4efa4bc14a53a7e0af38c5 upstream.

Changing uid/gid/projid mappings doesn't change your id within the
namespace; it reconfigures the namespace.  Unprivileged programs should
*not* be able to write these files.  (We're also checking the privileges
on the wrong task.)

Given the write-once nature of these files and the other security
checks, this is likely impossible to usefully exploit.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Greg Kroah-Hartman