MIPS: Avoid mcheck by flushing page range in huge_ptep_set_access_flags()

Problem:

1) Huge page mapping of anonymous memory is initially invalid.  Will be
   faulted in by copy-on-write mechanism.

2) Userspace attempts store at the end of the huge mapping.

3) TLB Refill exception handler fill TLB with a normal (4K sized)
   invalid page at the end of the huge mapping virtual address range.

4) Userspace restarted, and re-attempts the store at the end of the
   huge mapping.

5) Page from #3 is invalid, we get a fault and go to the hugepage
   fault handler.  This tries to map a huge page and calls
   huge_ptep_set_access_flags() to install the mapping.

6) We just call the generic ptep_set_access_flags() to set up the page
   tables, but the flush there assumes a normal (4K sized) page and
   only tries to flush the first part of the huge page virtual address
   out of the TLB, since the existing entry from step #3 doesn't
   conflict, nothing is flushed.

7) We attempt to load the mapping into the TLB, but because it
   conflicts with the entry from step #3, we get a Machine Check
   exception.

The fix: Flush the entire rage covered by the huge page in
huge_ptep_set_access_flags(), and remove the optimization in
local_flush_tlb_range() so that the flush actually does the correct
thing.

Signed-off-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Hillf Danton <dhillf@gmail.com>
Patchwork: https://patchwork.linux-mips.org/patch/4661/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
(cherry picked from commit dd617f258cc39d36be26afee9912624a2d23112c)
MIPS: N32: Fix preadv(2) and pwritev(2) entry points.

By using the native syscall entry point the kernel was also expecting
64-bit iovec structures.

This is broken since ddd9e91b71072b8ebe89311c3a44b077defa1756 [preadv/
pwritev: MIPS: Add preadv(2) and pwritev(2) syscalls.] which originally
added these two syscalls.  I walked through piles of code, including
libc and couldn't find anything that would have worked around the issue
so this change the API to what it should always have been.

Noticed and patch suggested by Al Viro.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
watchdog: Fix CPU hotplug regression

Norbert reported:
"3.7-rc6 booted with nmi_watchdog=0 fails to suspend to RAM or
 offline CPUs. It's reproducable with a KVM guest and physical
 system."

The reason is that commit bcd951cf(watchdog: Use hotplug thread
infrastructure) missed to take this into account. So the cpu offline
code gets stuck in the teardown function because it accesses non
initialized data structures.

Add a check for watchdog_enabled into that path to cure the issue.

Reported-and-tested-by: Norbert Warmuth <nwarmuth@t-online.de>
Tested-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1211231033230.2701@ionos
Link: http://bugs.launchpad.net/bugs/1079534
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
MODSIGN: Don't use enum-type bitfields in module signature info block

Don't use enum-type bitfields in the module signature info block as we can't be
certain how the compiler will handle them.  As I understand it, it is arch
dependent, and it is possible for the compiler to rearrange them based on
endianness and to insert a byte of padding to pad the three enums out to four
bytes.

Instead use u8 fields for these, which the compiler should emit in the right
order without padding.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
ASN.1: Fix an indefinite length skip error

Fix an error in asn1_find_indefinite_length() whereby small definite length
elements of size 0x7f are incorrecly classified as non-small.  Without this
fix, an error will be given as the length of the length will be perceived as
being very much greater than the maximum supported size.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
MIPS: N32: Fix signalfd4 syscall entry point

This needs to use the compat entry point or it's going to fail on big
endian systems.

Noticed by Al Viro.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: R3000/R3081: Fix CPU detection.

Broken since e05ea74fc56f347f872ef9946d27c53e8bf20864 (lmo) rsp.
cea7e2dfdef53fe55f359d00da562a268be06fd2 (kernel.org) [MIPS: Sort out CPU
type to name translation.]  These CPUs are no longer very popular to say
the least ...

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Reported-by: Murphy McCauley <murphy.mccauley@gmail.com>
MIPS: Fix endless loop when processing signals for kernel tasks

The problem occurs [1] when a kernel-mode task returns from a system
call with a pending signal.

A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).

The loop is as follows:

* syscall_exit_work:
 - work_pending:            // start_of_the_loop
 - work_notifysig:
   - do_notify_resume()
     - do_signal()
       - if (!user_mode(regs)) return;
 - resume_userspace         // TIF_SIGPENDING is still set
 - work_pending             // so we call work_pending => goto
                            // start_of_the_loop

More information can be found in another LKML thread:
http://www.serverphorums.com/read.php?12,457826

[1] The problem was also reproduced on !CONFIG_VM86 x86, and the
following fix was accepted.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29a2e2836ff9ea65a603c89df217f4198973a74f

Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/3571/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
lib/Makefile: Fix oid_registry build dependency

It is $(obj)/oid_registry.o that is dependent on $(obj)/oid_registry_data.c.
The object file cannot be built until $(obj)/oid_registry_data.c has been
generated.

A periodic and hard to reproduce parallel build failure is due to
this incorrect lib/Makefile dependency. The compile error is completely
disingenuous.

  GEN     lib/oid_registry_data.c
Compiling 49 OIDs
  CC      lib/oid_registry.o
gcc: error: lib/oid_registry.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
make[3]: *** [lib/oid_registry.o] Error 4

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull watchdog fix from Thomas Gleixner:
 "Trivial CPU hotplug regression fix for the watchdog code"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  watchdog: Fix CPU hotplug regression
Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

Pull module signing fixes from Rusty Russell:
 "David gave me these a month ago, during my git workflow churn :("

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  ASN.1: Fix an indefinite length skip error
  MODSIGN: Don't use enum-type bitfields in module signature info block
Merge branch 'more-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

Pull build fix from Rusty Russell:
 "Tim Gardner <tim.gardner@canonical.com> writes:
  > It is $(obj)/oid_registry.o that is dependent on $(obj)/oid_registry_data.c.
  > The object file cannot be built until $(obj)/oid_registry_data.c has been
  > generated.
  >
  > A periodic and hard to reproduce parallel build failure is due to
  > this incorrect lib/Makefile dependency. The compile error is completely
  > disingenuous.
  >
  >   GEN     lib/oid_registry_data.c
  > Compiling 49 OIDs
  >   CC      lib/oid_registry.o
  > gcc: error: lib/oid_registry.c: No such file or directory
  > gcc: fatal error: no input files
  > compilation terminated.
  > make[3]: *** [lib/oid_registry.o] Error 4

  I can't reproduce it either.  It's completely weird; nothing ever
  removes lib/oid_registry.c, so either gcc is giving the wrong message
  or it's a weird fs with a very odd race.

  But your version is definitely more correct than the previous one,
  so..."

* 'more-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  lib/Makefile: Fix oid_registry build dependency
Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus

Pull MIPS fixes from Ralf Baechle:
 "These are the fixes for the N32 syscall bugs found by Al, an
  extraneous break that broke detection for R3000 and R3081 processors,
  an endless loop processing signals for kernel task (x86 received the
  same fix a while ago) and a fix for transparent huge page which took
  ages to track down because it was so hard to come up with a workable
  test case."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Fix endless loop when processing signals for kernel tasks
  MIPS: R3000/R3081: Fix CPU detection.
  MIPS: N32: Fix signalfd4 syscall entry point
  MIPS: N32: Fix preadv(2) and pwritev(2) entry points.
  MIPS: Avoid mcheck by flushing page range in huge_ptep_set_access_flags()
mm: compaction: validate pfn range passed to isolate_freepages_block

Commit 0bf380bc70ec ("mm: compaction: check pfn_valid when entering a
new MAX_ORDER_NR_PAGES block during isolation for migration") added a
check for pfn_valid() when isolating pages for migration as the scanner
does not necessarily start pageblock-aligned.

Since commit c89511ab2f8f ("mm: compaction: Restart compaction from near
where it left off"), the free scanner has the same problem.  This patch
makes sure that the pfn range passed to isolate_freepages_block() is
within the same block so that pfn_valid() checks are unnecessary.

In answer to Henrik's wondering why others have not reported this:
reproducing this requires a large enough hole with the right aligment to
have compaction walk into a PFN range with no memmap.  Size and
alignment depends in the memory model - 4M for FLATMEM and 128M for
SPARSEMEM on x86.  It needs a "lucky" machine.

Reported-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: vmscan: do not keep kswapd looping forever due to individual uncompactable zones

When a zone meets its high watermark and is compactable in case of
higher order allocations, it contributes to the percentage of the node's
memory that is considered balanced.

This requirement, that a node be only partially balanced, came about
when kswapd was desparately trying to balance tiny zones when all bigger
zones in the node had plenty of free memory.  Arguably, the same should
apply to compaction: if a significant part of the node is balanced
enough to run compaction, do not get hung up on that tiny zone that
might never get in shape.

When the compaction logic in kswapd is reached, we know that at least
25% of the node's memory is balanced properly for compaction (see
zone_balanced and pgdat_balanced).  Remove the individual zone checks
that restart the kswapd cycle.

Otherwise, we may observe more endless looping in kswapd where the
compaction code loops back to reclaim because of a single zone and
reclaim does nothing because the node is considered balanced overall.

See for example

  https://bugzilla.redhat.com/show_bug.cgi?id=866988

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-and-tested-by: Thorsten Leemhuis <fedora@leemhuis.info>
Reported-by: Jiri Slaby <jslaby@suse.cz>
Tested-by: John Ellson <john.ellson@comcast.net>
Tested-by: Zdenek Kabelac <zkabelac@redhat.com>
Tested-by: Bruno Wolff III <bruno@wolff.to>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
tmpfs: fix shared mempolicy leak

This fixes a regression in 3.7-rc, which has since gone into stable.

Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount
imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the
refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went
on expecting alloc_page_vma() to drop the refcount it had acquired.
This deserves a rework: but for now fix the leak in shmem_alloc_page().

Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use
the same refcounting there as in shmem_alloc_page(), delete its onstack
mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() -
those were invented to let swapin_readahead() make an unknown number of
calls to alloc_pages_vma() with one mempolicy; but since 00442ad04a5e,
alloc_pages_vma() has kept refcount in balance, so now no problem.

Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
video: st7735fb: add st7735 framebuffer driver

Add driver for the SPI-connected ST7735 display controller.
This driver requires that the platform support DT booting.

Signed-off-by: Matt Porter <mporter@ti.com>
regulator: tps65910: fix BUG_ON() shown with vrtc regulator

Fix BUG_ON() error if tps65910 VRTC regulator is used with out
rdev->desc->volt_table data. Recent changes in regulator core driver
which add support for "regulator_list_voltage_table" have BUG_ON() if
regulator descriptor do not voltage table information. This patch adds
the voltage table information to fix the issue.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
dmaengine: add helper function to request a slave DMA channel

Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.

With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
of: Add generic device tree DMA helpers

This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.

Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
  Thinking about DMA controllers purely from the context of the hardware to
  begin with, we can describe a device in terms of a DMA controller as
  follows ...
  	1. Number of DMA controllers
	2. Number of channels (maybe physical or logical)
	3. Mapping of DMA requests signals to DMA controller
	4. Number of DMA interrupts
	5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
  the above information from the DT and provide to the appropriate driver.
  However, due to the vast number of DMA controllers and not all are using a
  common driver (such as DMA Engine) it has been seen that this is not a
  trivial task. In previous discussions on this topic the following concerns
  have been raised ...
	1. How does the binding support devices with multiple DMA controllers?
  	2. How to support both legacy DMA controllers not using DMA Engine as
	   well as those that support DMA Engine.
	3. When using with DMA Engine how do we support the various
	   implementations where the opaque filter function parameter differs
	   between implementations?
	4. How do we handle DMA channels that are identified with a string
	   versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
  an agreement what can be or should be supported.

Design of DMA helpers

1. Registering DMA controllers

   In the case of DMA controllers that are using DMA Engine, requesting a
   channel is performed by calling the following function.

	struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
			dma_filter_fn filter_fn,
			void *filter_param);

   The mask variable is used to match a type of the device controller in a list
   of controllers. The filter_fn and filter_param are used to identify the
   required dma channel and return a handle to the dma channel of type dma_chan.

   From the examples I have seen, the mask and filter_fn are constant
   for a given DMA controller and therefore, we can specify these as controller
   specific data when registering the DMA controller with the device-tree DMA
   helpers.

   The filter_param variable is of an unknown type and is typically specific
   to the DMA engine implementation for a given DMA controller. To allow some
   flexibility in the type and formating of this filter_param we employ an
   xlate to translate the device-tree binding information into the appropriate
   format. The xlate function used for a DMA controller can also be specified
   when registering the DMA controller with the device-tree DMA helpers.

   Based upon the above, a function for registering the DMA controller with the
   DMA helpers now looks like the below. The data variable is used to pass a
   pointer to DMA controller specific data used by the xlate function.

	int of_dma_controller_register(struct device_node *np,
		struct dma_chan *(*of_dma_xlate)
		(struct of_phandle_args *, struct of_dma *),
		void *data)

   For example, in the case where DMA engine is used, we define the following
   structure (that stores the DMA engine capability mask and filter function)
   and pass this to the data variable in the above function.

	struct of_dma_filter_info {
		dma_cap_mask_t  dma_cap;
		dma_filter_fn   filter_fn;
	};

2. Representing and requesting channel information

   Please see the dma binding documentation included in this patch for a
   description of how DMA controllers and client information should be
   represented with device-tree. For more information on how this binding
   came about please see [3]. In addition to this, feedback received from
   the Linux kernel summit showed a consensus (among those who attended) to
   use a name to identify DMA client information [4].

   A DMA channel can be requested by calling the following function, where name
   is a required parameter used for identifying a DMA channel. This function
   has been designed to return a structure of type dma_chan to work with the
   DMA engine driver. Note that if DMA engine is used then drivers should be
   using the DMA engine API dma_request_slave_channel() (implemented in part 2
   of this series, "dmaengine: add helper function to request a slave DMA
   channel") which will in turn call the below function if device-tree is
   present. The aim being to have a common DMA engine interface regardless of
   whether device tree is being used.

	struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
						      char *name)

3. Supporting legacy devices not using DMA Engine

   These devices present a problem, as there may not be a uniform way to easily
   support them with regard to device tree. Ideally, these should be migrated
   to DMA engine. However, if this is not possible, then they should still be
   able to use this binding, the only constaint imposed by this implementation
   is that when requesting a DMA channel via of_dma_request_slave_channel(), it
   will return a type of dma_chan.

This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
have validated that MMC is working on the PANDA board with this implementation.
My development branch for testing on OMAP can be found here [5].

v6: - minor corrections in DMA binding documentation
v5: - minor update to binding documentation
    - added loop to exhaustively search for a slave channel in the case where
      there could be alternative channels available
v4: - revert the removal of xlate function from v3
    - update the proposed binding format and APIs based upon discussions [3]
v3: - avoid passing an xlate function and instead pass DMA engine parameters
    - define number of dma channels and requests in dma-controller node
v2: - remove of_dma_to_resource API
    - make property #dma-cells required (no fallback anymore)
    - another check in of_dma_xlate_onenumbercell() function

[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
[4] http://pad.linaro.org/arm-mini-summit-2012
[5] https://github.com/jonhunter/linux/tree/dev-dt-dma

Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>