Pull Metag architecture and related fixes from James Hogan:
 "Mostly fixes for metag and parisc relating to upgrowing stacks.

   - Fix missing compiler barriers in metag memory barriers.
   - Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased
     beyond safe value.
   - Make maximum stack size configurable.  This reduces the default
     user stack size back to 80MB (especially on parisc after their
     removal of _STK_LIM_MAX override).  This only affects metag and
     parisc.
   - Remove metag _STK_LIM_MAX override to match other arches and follow
     parisc, now that it is safe to do so (due to the BUG_ON fix
     mentioned above).
   - Finally now that both metag and parisc _STK_LIM_MAX overrides have
     been removed, it makes sense to remove _STK_LIM_MAX altogether"

* tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
  asm-generic: remove _STK_LIM_MAX
  metag: Remove _STK_LIM_MAX override
  parisc,metag: Do not hardcode maximum userspace stack size
  metag: Reduce maximum stack size to 256MB
  metag: fix memory barriers

Pull drm/intel fixes from Dave Airlie:
 "Just some intel fixes.

  I have some radeon ones but I need to get some patches dropped from
  the pull req"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: Increase WM memory latency values on SNB
  drm/i915: restore backlight precision when converting from ACPI
  drm/i915: Use the first mode if there is no preferred mode in the EDID
  drm/i915/dp: force eDP lane count to max available lanes on BDW
  drm/i915/vlv: reset VLV media force wake request register
  drm/i915/SDVO: For sysfs link put directory and target in correct order
  drm/i915: use lane count and link rate from VBT as minimums for eDP
  drm/i915: clean up VBT eDP link param decoding
  drm/i915: consider the source max DP lane count too

Pull x86 fixes from Peter Anvin.

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86-64, modify_ldt: Make support for 16-bit segments a runtime option
  x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
  x86, rdrand: When nordrand is specified, disable RDSEED as well

Pull timer fix from Thomas Gleixner:
 "A single bug fix for a long standing issue:

   - Updating the expiry value of a relative timer _after_ letting the
     idle logic select a target cpu for the timer based on its stale
     expiry value is outright stupid.  Thanks to Viresh for spotting the
     brainfart"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  hrtimer: Set expiry time before switch_hrtimer_base()

Pull irq fixes from Thomas Gleixner:
 "Two small updates from the irq departement:

   - Provide missing inline stub for a SMP only function

   - Add sub-maintainer for the drivers/irqchip/ part of the irq
     subsystem.  YAY!"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  MAINTAINERS: Add co-maintainer for drivers/irqchip
  genirq: Provide irq_force_affinity fallback for non-SMP

Intel fixes for regressions, black screens and hangs, for 3.15.

* tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Increase WM memory latency values on SNB
  drm/i915: restore backlight precision when converting from ACPI
  drm/i915: Use the first mode if there is no preferred mode in the EDID
  drm/i915/dp: force eDP lane count to max available lanes on BDW
  drm/i915/vlv: reset VLV media force wake request register
  drm/i915/SDVO: For sysfs link put directory and target in correct order
  drm/i915: use lane count and link rate from VBT as minimums for eDP
  drm/i915: clean up VBT eDP link param decoding
  drm/i915: consider the source max DP lane count too

On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.

In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.

Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.

v2: Increase the latency values regardless of the pixel clock

Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by: NRobert Navarro <crshman@gmail.com>
Tested-by: NVitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by: NNico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKnut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

There are certain BDW high res eDP machines that regressed due to

commit 38aecea0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Mar 3 11:18:10 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.

The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Checkin:

b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

disabled 16-bit segments on 64-bit kernels due to an information
leak.  However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.

A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
Cc: <stable@vger.kernel.org>

_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
an arch's include/uapi/asm-generic/resource.h file, but is no longer
used since both parisc and metag removed the override. Therefore remove
it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
directly in include/asm-generic/resource.h.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>

Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
256MB, apparently in an attempt to prevent setup_arg_pages's
STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
far too large for Meta's limited virtual address space and hits a BUG_ON
(stack_top is usually 0x3ffff000).

However the commit "metag: Reduce maximum stack size to 256MB" reduces
the absolute stack size limit to a safe value for metag. This allows the
default _STK_LIM_MAX override to be removed, bringing the default
behaviour in line with all other architectures. Parisc in particular
recently removed their override of _STK_LIMT_MAX in commit e0d8898d
(parisc: remove _STK_LIM_MAX override) since it subtly affects stack
allocation semantics in userland. Meta's uapi/asm/resource.h can now be
removed and switch to using generic-y.
Suggested-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>

This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>

Specify the maximum stack size for arches where the stack grows upward
(parisc and metag) in asm/processor.h rather than hard coding in
fs/exec.c so that metag can specify a smaller value of 256MB rather than
1GB.

This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
beyond a safe value by root. E.g. when starting a process after running
"ulimit -H -s unlimited" it will then attempt to use a stack size of the
maximum 1GB which is far too big for metag's limited user virtual
address space (stack_top is usually 0x3ffff000):

BUG: failure at fs/exec.c:589/shift_arg_pages()!
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)

Volatile access doesn't really imply the compiler barrier. Volatile access
is only ordered with respect to other volatile accesses, it isn't ordered
with respect to general memory accesses. Gcc may reorder memory accesses
around volatile access, as we can see in this simple example (if we
compile it with optimization, both increments of *b will be collapsed to
just one):

void fn(volatile int *a, long *b)
{
	(*b)++;
	*a = 10;
	(*b)++;
}

Consequently, we need the compiler barrier after a write to the volatile
variable, to make sure that the compiler doesn't reorder the volatile
write with something else.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

The invalidation is required in order to maintain proper semantics
under CoW conditions. In scenarios where a process clones several
threads, a thread operating on a core whose DTLB entry for a
particular hugepage has not been invalidated, will be reading from
the hugepage that belongs to the forked child process, even after
hugetlb_cow().

The thread will not see the updated page as long as the stale DTLB
entry remains cached, the thread attempts to write into the page,
the child process exits, or the thread gets migrated to a different
processor.
Signed-off-by: NAnthony Iliopoulos <anthony.iliopoulos@huawei.com>
Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corpSuggested-by: NShay Goikhman <shay.goikhman@huawei.com>
Acked-by: NDave Hansen <dave.hansen@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v2.6.16+ (!)

Thomas Gleixner has asked me to assist with the review and merging of
patches for the irqchip subsystem.
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1400006821-32145-1-git-send-email-jason@lakedaemon.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Pull file locking fix from Jeff Layton:
 "Fix for regression in handling of F_GETLK commands"

* tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux:
  locks: only validate the lock vs. f_mode in F_SETLK codepaths

Pull hwmon fixes from Guenter Roeck:
 "Fix resource leak as well as broken store function in emc1403 driver,
  and add support for additional chip revisions"

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (emc1403) Support full range of known chip revision numbers
  hwmon: (emc1403) Fix resource leak on module unload
  hwmon: (emc1403) fix inverted store_hyst()

Pull a percpu fix from Tejun Heo:
 "Fix for a percpu allocator bug where it could try to kfree() a memory
  region allocated using vmalloc().  The bug has been there for years
  now and is unlikely to have ever triggered given the size of struct
  pcpu_chunk.  It's still theoretically possible and the fix is simple
  and safe enough, so the patch is marked with -stable"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
  percpu: make pcpu_alloc_chunk() use pcpu_mem_free() instead of kfree()

Pull workqueue fixes from Tejun Heo:
 "Fixes for two bugs in workqueue.

  One is exiting with internal mutex held in a failure path of
  wq_update_unbound_numa().  The other is a subtle and unlikely
  use-after-possible-last-put in the rescuer logic.  Both have been
  around for quite some time now and are unlikely to have triggered
  noticeably often.  All patches are marked for -stable backport"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: fix a possible race condition between rescuer and pwq-release
  workqueue: make rescuer_thread() empty wq->maydays list before exiting
  workqueue: fix bugs in wq_update_unbound_numa() failure path

Pull cgroup fixes from Tejun Heo:
 "During recent restructuring, device_cgroup unified config input check
  and enforcement logic; unfortunately, it turned out to share too much.
  Aristeu's patches fix the breakage and marked for -stable backport.

  The other two patches are fallouts from kernfs conversion.  The blkcg
  change is temporary and will go away once kernfs internal locking gets
  simplified (patches pending)"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  blkcg: use trylock on blkcg_pol_mutex in blkcg_reset_stats()
  device_cgroup: check if exception removal is allowed
  device_cgroup: fix the comment format for recently added functions
  device_cgroup: rework device access check and exception checking
  cgroup: fix the retry path of cgroup_mount()

Pull xen bug fixes from David Vrabel:
 - Fix arm64 crash on boot.
 - Quiet a noisy arm build warning (virt_to_pfn() redefined).

* tag 'stable/for-linus-3.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  arm64: introduce virt_to_pfn
  xen/events/fifo: correctly align bitops
  arm/xen: Remove definiition of virt_to_pfn in asm/xen/page.h

Pull cifs fix from Steve French:
 "Small cifs fix for metadata caching"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: fix actimeo=0 corner case when cifs_i->time == jiffies

Pull md bugfixes from Neil Brown:
 "Two bugfixes for md in 3.15

  Both tagged for -stable"

* tag 'md/3.15-fixes' of git://neil.brown.name/md:
  md: avoid possible spinning md thread at shutdown.
  md/raid10: call wait_barrier() for each request submitted.

Pull ARM SoC fixes from Olof Johansson:
 "Seems like we've had more fixes than usual this release cycle, but
  there's nothing in particular that we're doing differently.  Perhaps
  it's just one of those cycles where more people are finding more
  regressions (and/or that the latency of when people actually test
  what's been in the tree for a while is catching up so that we get the
  bug reports now).

  The bigger changes here are are for TI and Marvell platforms:
   * Timing changes for GPMC (generic localbus) on OMAP causing some
     largeish DTS deltas.
   * Fixes to window allocation on PCI for mvebu touching drivers/
     stuff.  Patches have acks from subsystem maintainers where needed.
   * A fix from Thomas for a botched DT conversion in drivers/edma.

  There's a handful of other fixes for the above platforms as well as
  sunxi, at91, i.MX.  I also included a MAINTAINER update for Broadcom,
  and a trivial move of a binding doc.

  I know you said you'd be offline this week, but I might as well post
  it for when you return.  :)"

I'm not quite offline yet.  Doing a few pulls in the last hour before my
internet goes away..

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
  MAINTAINERS: update Broadcom ARM tree location and add an SoC family
  ARM: dts: i.MX53: Fix ipu register space size
  ARM: dts: kirkwood: fix mislocated pcie-controller nodes
  ARM: sunxi: Enable GMAC in sunxi_defconfig
  ARM: common: edma: Fix xbar mapping
  ARM: sun7i: Fix i2c4 base address
  ARM: Kirkwood: T5325: Fix double probe of Codec
  ARM: mvebu: enable the SATA interface on Armada 375 DB
  ARM: mvebu: specify I2C bus frequency on Armada 370 DB
  ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces
  ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree
  ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree
  ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree
  ARM: dts: AM3517: Disable absent IPs inherited from OMAP3
  ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox
  ARM: dts: OMAP5: Add mailbox dt node to fix boot warning
  ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
  ARM: dts: am437x-gp-evm: Do not reset gpio5
  ARM: dts: omap3-igep0020: use SMSC9221 timings
  PCI: mvebu: split PCIe BARs into multiple MBus windows when needed
  ...

The datasheet for EMC1413/EMC1414, which is fully compatible to
EMC1403/1404 and uses the same chip identification, references revision
numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers
from 0x01 to 0x04 to make sure none are missed.
Signed-off-by: NJosef Gajdusek <atx@atx.name>
Cc: stable@vger.kernel.org
[Guenter Roeck: Updated headline and description]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Commit 454aee17 claims to convert driver emc1403 to use
devm_hwmon_device_register_with_groups, however the patch itself makes
use of hwmon_device_register_with_groups instead. As the driver remove
function was still dropped, the hwmon device is no longer unregistered
on driver removal, leading to a resource leak.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Fixes: 454aee17 hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org [3.13+]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Attempts to set the hysteresis value to a temperature below the target
limit fails with "write error: Numerical result out of range" due to
an inverted comparison.
Signed-off-by: NJosef Gajdusek <atx@atx.name>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org
[Guenter Roeck: Updated headline and description]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

virt_to_pfn has been defined in arch/arm/include/asm/memory.h by commit
e26a9e00 "ARM: Better virt_to_page() handling" and Xen has come to rely
on it.  Introduce virt_to_pfn on arm64 too.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>

switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.

But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.

Update expiry time before calling switch_hrtimer_base().

[ tglx: Rewrote changelog once again ]
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: linaro-kernel@lists.linaro.org
Cc: linaro-networking@linaro.org
Cc: fweisbec@gmail.com
Cc: arvind.chauhan@arm.com
Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

One can logically expect that when the user has specified "nordrand",
the user doesn't want any use of the CPU random number generator,
neither RDRAND nor RDSEED, so disable both.
Reported-by: NStephan Mueller <smueller@chronox.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Link: http://lkml.kernel.org/r/21542339.0lFnPSyGRS@myon.chronox.deSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Pull nfsd fixes from Bruce Fields.

* 'for-3.15' of git://linux-nfs.org/~bfields/linux:
  NFSD: Call ->set_acl with a NULL ACL structure if no entries
  NFSd: call rpc_destroy_wait_queue() from free_client()
  NFSd: Move default initialisers from create_client() to alloc_client()

Merge misc fixes from Andrew Morton:
 "4 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm, thp: close race between mremap() and split_huge_page()
  mm: postpone the disabling of kmemleak early logging
  MAINTAINERS: update maintainership of LTP
  drivers/rtc/rtc-hym8563.c: set uie_unsupported

It's critical for split_huge_page() (and migration) to catch and freeze
all PMDs on rmap walk.  It gets tricky if there's concurrent fork() or
mremap() since usually we copy/move page table entries on dup_mm() or
move_page_tables() without rmap lock taken.  To get it work we rely on
rmap walk order to not miss any entry.  We expect to see destination VMA
after source one to work correctly.

But after switching rmap implementation to interval tree it's not always
possible to preserve expected walk order.

It works fine for dup_mm() since new VMA has the same vma_start_pgoff()
/ vma_last_pgoff() and explicitly insert dst VMA after src one with
vma_interval_tree_insert_after().

But on move_vma() destination VMA can be merged into adjacent one and as
result shifted left in interval tree.  Fortunately, we can detect the
situation and prevent race with rmap walk by moving page table entries
under rmap lock.  See commit 38a76013.

Problem is that we miss the lock when we move transhuge PMD.  Most
likely this bug caused the crash[1].

[1] http://thread.gmane.org/gmane.linux.kernel.mm/96473

Fixes: 108d6642 ("mm anon rmap: remove anon_vma_moveto_tail")
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Acked-by: NMichel Lespinasse <walken@google.com>
Cc: Dave Jones <davej@redhat.com>
Cc: David Miller <davem@davemloft.net>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: <stable@vger.kernel.org>        [3.7+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 8910ae89 ("kmemleak: change some global variables to int"),
in addition to the atomic -> int conversion, moved the disabling of
kmemleak_early_log to the beginning of the kmemleak_init() function,
before the full kmemleak tracing is actually enabled.  In this small
window, kmem_cache_create() is called by kmemleak which triggers
additional memory allocation that are not traced.  This patch restores
the original logic with kmemleak_early_log disabling when kmemleak is
fully functional.

Fixes: 8910ae89 (kmemleak: change some global variables to int)
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Also remove sf.net git repo which is no longer available and update link
to LTP web pages.
Signed-off-by: NCyril Hrubis <chrubis@suse.cz>
Signed-off-by: NCaspar Zhang <caspar@casparzhang.com>
Signed-off-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: NJan Stancek <jstancek@redhat.com>
Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: NStanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The alarm of the hym8563 only supports a minute accuracy, while the uie
wants an alarm one second in the future.  Therefore things like the
select() syscall will fail with a timeout, because the next alarm will
happen in a worst case of 60 seconds.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge tag 'davinci-fixes-for-v3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes

Pull "DaVinci fixes for v3.15" from Sekhar Nori:

The patch fixes EDMA crossbar mapping to actually
make it work. The patch has been tagged for stable.

* tag 'davinci-fixes-for-v3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: common: edma: Fix xbar mapping
Signed-off-by: NOlof Johansson <olof@lixom.net>