When hot adding the same memory after hot removal, the following
messages are shown:

  WARNING: CPU: 20 PID: 6 at mm/page_alloc.c:4968 free_area_init_node+0x3fe/0x426()
  ...
  Call Trace:
    dump_stack+0x46/0x58
    warn_slowpath_common+0x81/0xa0
    warn_slowpath_null+0x1a/0x20
    free_area_init_node+0x3fe/0x426
    hotadd_new_pgdat+0x90/0x110
    add_memory+0xd4/0x200
    acpi_memory_device_add+0x1aa/0x289
    acpi_bus_attach+0xfd/0x204
    acpi_bus_attach+0x178/0x204
    acpi_bus_scan+0x6a/0x90
    acpi_device_hotplug+0xe8/0x418
    acpi_hotplug_work_fn+0x1f/0x2b
    process_one_work+0x14e/0x3f0
    worker_thread+0x11b/0x510
    kthread+0xe1/0x100
    ret_from_fork+0x7c/0xb0

The detaled explanation is as follows:

When hot removing memory, pgdat is set to 0 in try_offline_node().  But
if the pgdat is allocated by bootmem allocator, the clearing step is
skipped.

And when hot adding the same memory, the uninitialized pgdat is reused.
But free_area_init_node() checks wether pgdat is set to zero.  As a
result, free_area_init_node() hits WARN_ON().

This patch clears pgdat which is allocated by bootmem allocator in
try_offline_node().
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix unconditional initialization failure on non-exynos3250 SoCs.

Commit df9e26d0 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
introduced rtc source clock support, but also added initialization
failure on SoCs, which doesn't need such clock.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Found this in the message log on a s390 system:

    BUG kmalloc-192 (Not tainted): Poison overwritten
    Disabling lock debugging due to kernel taint
    INFO: 0x00000000684761f4-0x00000000684761f7. First byte 0xff instead of 0x6b
    INFO: Allocated in call_usermodehelper_setup+0x70/0x128 age=71 cpu=2 pid=648
     __slab_alloc.isra.47.constprop.56+0x5f6/0x658
     kmem_cache_alloc_trace+0x106/0x408
     call_usermodehelper_setup+0x70/0x128
     call_usermodehelper+0x62/0x90
     cgroup_release_agent+0x178/0x1c0
     process_one_work+0x36e/0x680
     worker_thread+0x2f0/0x4f8
     kthread+0x10a/0x120
     kernel_thread_starter+0x6/0xc
     kernel_thread_starter+0x0/0xc
    INFO: Freed in call_usermodehelper_exec+0x110/0x1b8 age=71 cpu=2 pid=648
     __slab_free+0x94/0x560
     kfree+0x364/0x3e0
     call_usermodehelper_exec+0x110/0x1b8
     cgroup_release_agent+0x178/0x1c0
     process_one_work+0x36e/0x680
     worker_thread+0x2f0/0x4f8
     kthread+0x10a/0x120
     kernel_thread_starter+0x6/0xc
     kernel_thread_starter+0x0/0xc

There is a use-after-free bug on the subprocess_info structure allocated
by the user mode helper.  In case do_execve() returns with an error
____call_usermodehelper() stores the error code to sub_info->retval, but
sub_info can already have been freed.

Regarding UMH_NO_WAIT, the sub_info structure can be freed by
__call_usermodehelper() before the worker thread returns from
do_execve(), allowing memory corruption when do_execve() failed after
exec_mmap() is called.

Regarding UMH_WAIT_EXEC, the call to umh_complete() allows
call_usermodehelper_exec() to continue which then frees sub_info.

To fix this race the code needs to make sure that the call to
call_usermodehelper_freeinfo() is always done after the last store to
sub_info->retval.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Reviewed-by: NOleg Nesterov <oleg@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Adds support for RTC device inside PM8941 PMIC.  The RTC in this PMIC
have two register spaces.  Thus the rtc-pm8xxx is slightly reworked to
reflect these differences.

The register set for different PMIC chips are selected on DT compatible
string base.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: simplify and fix locking in pm8xxx_rtc_set_time()]
Signed-off-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Josh Cartwright <joshc@codeaurora.org>
Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If an anonymous mapping is not allowed to fault thp memory and then
madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never
collapse this memory into thp memory.

This occurs because the madvise(2) handler for thp, hugepage_madvise(),
clears VM_NOHUGEPAGE on the stack and it isn't stored in vma->vm_flags
until the final action of madvise_behavior().  This causes the
khugepaged_enter_vma_merge() to be a no-op in hugepage_madvise() when
the vma had previously had VM_NOHUGEPAGE set.

Fix this by passing the correct vma flags to the khugepaged mm slot
handler.  There's no chance khugepaged can run on this vma until after
madvise_behavior() returns since we hold mm->mmap_sem.

It would be possible to clear VM_NOHUGEPAGE directly from vma->vm_flags
in hugepage_advise(), but I didn't want to introduce special case
behavior into madvise_behavior().  I think it's best to just let it
always set vma->vm_flags itself.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Reported-by: NSuleiman Souhlal <suleiman@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Driver calling of_reserved_mem_device_init() might be interested if the
initialization has been successful or not, so add support for returning
error code.

This fixes a build warining caused by commit 7bfa5ab6 ("drivers:
dma-coherent: add initialization from device tree"), which has been
merged without this change and without fixing function return value.

Fixes: 7bfa5ab6 ("drivers: dma-coherent: add initialization from device tree")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Cc: Josh Cartwright <joshc@codeaurora.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Compound page should be freed by put_page() or free_pages() with correct
order.  Not doing so will cause tail pages leaked.

The compound order can be obtained by compound_order() or use
HPAGE_PMD_ORDER in our case.  Some people would argue the latter is
faster but I prefer the former which is more general.

This bug was observed not just on our servers (the worst case we saw is
11G leaked on a 48G machine) but also on our workstations running Ubuntu
based distro.

  $ cat /proc/vmstat  | grep thp_zero_page_alloc
  thp_zero_page_alloc 55
  thp_zero_page_alloc_failed 0

This means there is (thp_zero_page_alloc - 1) * (2M - 4K) memory leaked.

Fixes: 97ae1749 ("thp: implement refcounting for huge zero page")
Signed-off-by: NYu Zhao <yuzhao@google.com>
Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>
Cc: Bob Liu <lliubbo@gmail.com>
Cc: <stable@vger.kernel.org>	[3.8+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Following up the arm testing of gcov, turns out gcov on ARM64 works fine
as well.  Only change needed is adding ARM64 to Kconfig depends.

Tested with qemu and mach-virt
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
Acked-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

During file system stress testing on 3.10 and 3.12 based kernels, the
umount command occasionally hung in fsnotify_unmount_inodes in the
section of code:

                spin_lock(&inode->i_lock);
                if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
                        spin_unlock(&inode->i_lock);
                        continue;
                }

As this section of code holds the global inode_sb_list_lock, eventually
the system hangs trying to acquire the lock.

Multiple crash dumps showed:

The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point
back at itself.  As this is not the value of list upon entry to the
function, the kernel never exits the loop.

To help narrow down problem, the call to list_del_init in
inode_sb_list_del was changed to list_del.  This poisons the pointers in
the i_sb_list and causes a kernel to panic if it transverse a freed
inode.

Subsequent stress testing paniced in fsnotify_unmount_inodes at the
bottom of the list_for_each_entry_safe loop showing next_i had become
free.

We believe the root cause of the problem is that next_i is being freed
during the window of time that the list_for_each_entry_safe loop
temporarily releases inode_sb_list_lock to call fsnotify and
fsnotify_inode_delete.

The code in fsnotify_unmount_inodes attempts to prevent the freeing of
inode and next_i by calling __iget.  However, the code doesn't do the
__iget call on next_i

	if i_count == 0 or
	if i_state & (I_FREEING | I_WILL_FREE)

The patch addresses this issue by advancing next_i in the above two cases
until we either find a next_i which we can __iget or we reach the end of
the list.  This makes the handling of next_i more closely match the
handling of the variable "inode."

The time to reproduce the hang is highly variable (from hours to days.) We
ran the stress test on a 3.10 kernel with the proposed patch for a week
without failure.

During list_for_each_entry_safe, next_i is becoming free causing
the loop to never terminate.  Advance next_i in those cases where
__iget is not done.
Signed-off-by: NJerry Hoemann <jerry.hoemann@hp.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Ken Helias <kenhelias@firemail.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit edc2ca61 ("mm, compaction: move pageblock checks up from
isolate_migratepages_range()") commonizes isolate_migratepages variants
and make them use isolate_migratepages_block().

isolate_migratepages_block() could stop the execution when enough pages
are isolated, but, there is no code in isolate_migratepages_range() to
handle this case.  In the result, even if isolate_migratepages_block()
returns prematurely without checking all pages in the range,

isolate_migratepages_block() is called repeately on the following
pageblock and some pages in the previous range are skipped to check.
Then, CMA is failed frequently due to this fact.

To fix this problem, this patch let isolate_migratepages_range() know
the situation that enough pages are isolated and stop the isolation in
that case.

Note that isolate_migratepages() has no such problem, because, it always
stops the isolation after just one call of isolate_migratepages_block().
Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit ff7ee93f ("cgroup/kmemleak: Annotate alloc_page() for cgroup
allocations") introduces kmemleak_alloc() for alloc_page_cgroup(), but
corresponding kmemleak_free() is missing, which makes kmemleak be
wrongly disabled after memory offlining.  Log is pasted at the end of
this commit message.

This patch add kmemleak_free() into free_page_cgroup().  During page
offlining, this patch removes corresponding entries in kmemleak rbtree.
After that, the freed memory can be allocated again by other subsystems
without killing kmemleak.

  bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak

  Offlined Pages 32768
  kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing)
  CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x46/0x58
    create_object+0x266/0x2c0
    kmemleak_alloc+0x26/0x50
    kmem_cache_alloc+0xd3/0x160
    __sigqueue_alloc+0x49/0xd0
    __send_signal+0xcb/0x410
    send_signal+0x45/0x90
    __group_send_sig_info+0x13/0x20
    do_notify_parent+0x1bb/0x260
    do_exit+0x767/0xa40
    do_group_exit+0x44/0xa0
    SyS_exit_group+0x17/0x20
    system_call_fastpath+0x16/0x1b

  kmemleak: Kernel memory leak detector disabled
  kmemleak: Object 0xffff880016900000 (size 524288):
  kmemleak:   comm "swapper/0", pid 0, jiffies 4294667296
  kmemleak:   min_count = 0
  kmemleak:   count = 0
  kmemleak:   flags = 0x1
  kmemleak:   checksum = 0
  kmemleak:   backtrace:
        log_early+0x63/0x77
        kmemleak_alloc+0x4b/0x50
        init_section_page_cgroup+0x7f/0xf5
        page_cgroup_init+0xc5/0xd0
        start_kernel+0x333/0x408
        x86_64_start_reservations+0x2a/0x2c
        x86_64_start_kernel+0xf5/0xfc

Fixes: ff7ee93f (cgroup/kmemleak: Annotate alloc_page() for cgroup allocations)
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Acked-by: NMichal Hocko <mhocko@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: <stable@vger.kernel.org>	[3.2+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull two nfsd fixes from Bruce Fields:
 "One regression from the 3.16 xdr rewrite, one an older bug exposed by
  a separate bug in the client's new SEEK code"

* 'for-3.18' of git://linux-nfs.org/~bfields/linux:
  nfsd4: fix crash on unknown operation number
  nfsd4: fix response size estimation for OP_SEQUENCE

Merge tag 'trace-fixes-v3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull ftrace trampoline accounting fixes from Steven Rostedt:
 "Adding the new code for 3.19, I discovered a couple of minor bugs with
  the accounting of the ftrace_ops trampoline logic.

  One was that the old hash was not updated before calling the modify
  code for an ftrace_ops.  The second bug was what let the first bug go
  unnoticed, as the update would check the current hash for all
  ftrace_ops (where it should only check the old hash for modified
  ones).  This let things work when only one ftrace_ops was registered
  to a function, but could break if more than one was registered
  depending on the order of the look ups.

  The worse thing that can happen if this bug triggers is that the
  ftrace self checks would find an anomaly and shut itself down"

* tag 'trace-fixes-v3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace: Fix checking of trampoline ftrace_ops in finding trampoline
  ftrace: Set ops->old_hash on modifying what an ops hooks to

Pull ARM fixes from Russell King:
 "A couple of ARM fixes.

  We fix some printk formats for ptrdiff_t quantities which cause GCC
  4.9 to complain, and we also blacklist known buggy GCC 4.8.x compilers
  as their miscompilation is serious enough to cause filesystem
  corruption, even through many distros have fixed their versions"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: fix some printk formats
  ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854

When unmapping a range of pages in zap_pte_range, the page being
unmapped is added to an mmu_gather_batch structure for asynchronous
freeing. If we run out of space in the batch structure before the range
has been completely unmapped, then we break out of the loop, force a
TLB flush and free the pages that we have batched so far. If there are
further pages to unmap, then we resume the loop where we left off.

Unfortunately, we forget to update addr when we break out of the loop,
which causes us to truncate the range being invalidated as the end
address is exclusive. When we re-enter the loop at the same address, the
page has already been freed and the pte_present test will fail, meaning
that we do not reconsider the address for invalidation.

This patch fixes the problem by incrementing addr by the PAGE_SIZE
before breaking out of the loop on batch failure.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull media fixes from Mauro Carvalho Chehab:
 "A series of driver fixes:
   - a few compilation fixes with randconfigs
   - one potential compilation breakage on userspace due to the usage of
     a gcc extension
   - several warnings fixed
   - some other random driver fixes"

* tag 'media/v3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (22 commits)
  [media] s5p-jpeg: Avoid -Wuninitialized warning in s5p_jpeg_parse_hdr
  [media] s5p-fimc: Only build suspend/resume for PM
  [media] s5p-jpeg: Only build suspend/resume for PM
  [media] Remove references to non-existent PLAT_S5P symbol
  [media] videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory()
  [media] tw68: remove bogus I2C_ALGOBIT dependency
  [media] usbvision-video: two use after frees
  [media] tw68: remove deprecated IRQF_DISABLED
  [media] xc5000: use after free in release()
  [media] em28xx-input: NULL dereference on error
  [media] wl128x: fix fmdbg compiler warning
  Revert "[media] v4l2-dv-timings: fix a sparse warning"
  [media] hackrf: harmless off by one in debug code
  [media] cx23885: initialize config structs for T9580
  [media] v4l: uvcvideo: Fix buffer completion size check
  [media] vivid: fix buffer overrun
  [media] saa7146: Create a device name before it's used
  [media] em28xx: fix uninitialized variable warning
  [media] vivid: fix Kconfig FB dependency
  [media] anysee: make sure loading modules is const
  ...

Pull EDAC fixes from Borislav Petkov:
 "Correct severity of reported errors in several EDAC drivers.  From
  Jason Baron"

* tag 'edac_fixes_for_3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
  e7xxx_edac: Report CE events properly
  cpc925_edac: Report UE events properly
  i82860_edac: Report CE events properly
  i3200_edac: Report CE events properly

Pull spi fixes from Mark Brown:
 "Quite a few driver fixes in here, including some fairly substantial
  ones for the recently added Rockchip driver, plus a fix for spidev to
  more reliably support bidirectional transfers which is fairly large
  but basically mechanical.

  It's a bit more code than I'd like but all fixes"

* tag 'spi-v3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: orion: fix potential NULL pointer de-reference
  spi/rockchip: spi controller must be disabled in tx callback too
  spi/rockchip: fix bug that cause spi transfer timed out in DMA duplex mode
  spi/rockchip: fix bug that case spi can't go as fast as slave request
  spi: pl022: Fix incorrect dma_unmap_sg
  spi: spidev: Use separate TX and RX bounce buffers
  spi: dw: Initialize of_node to discover DT node children

Pull regulator fixes from Mark Brown:
 "A couple of fixes for v3.18, one fix for an incorrect voltage to
  register mapping in the rk808 driver and a fix for a build failure in
  some SH defconfigs"

* tag 'regulator-v3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Include err.h from consumer.h to fix build failure
  regulator: rk808: Fix min_uV for DCDC1 & DCDC2

Merge remote-tracking branches 'spi/fix/dw', 'spi/fix/orion', 'spi/fix/pl022', 'spi/fix/rockchip' and 'spi/fix/spidev' into spi-linus

Pull ARM SoC fixes from Olof Johansson:
 "Another week, another small batch of fixes.

  Most of these make zynq, socfpga and sunxi platforms work a bit
  better:

   - due to new requirements for regulators, DWMMC on socfpga broke past
     v3.17
   - SMP spinup fix for socfpga
   - a few DT fixes for zynq
   - another option (FIXED_REGULATOR) for sunxi is needed that used to
     be selected by other options but no longer is.
   - a couple of small DT fixes for at91
   - ...and a couple for i.MX"

* tag 'armsoc-for-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: dts: imx28-evk: Let i2c0 run at 100kHz
  ARM: i.MX6: Fix "emi" clock name typo
  ARM: multi_v7_defconfig: enable CONFIG_MMC_DW_ROCKCHIP
  ARM: sunxi_defconfig: enable CONFIG_REGULATOR_FIXED_VOLTAGE
  ARM: dts: socfpga: Add a 3.3V fixed regulator node
  ARM: dts: socfpga: Fix SD card detect
  ARM: dts: socfpga: rename gpio nodes
  ARM: at91/dt: sam9263: fix PLLB frequencies
  power: reset: at91-reset: fix power down register
  MAINTAINERS: add atmel ssc driver maintainer entry
  arm: socfpga: fix fetching cpu1start_addr for SMP
  ARM: zynq: DT: trivial: Fix mc node
  ARM: zynq: DT: Add cadence watchdog node
  ARM: zynq: DT: Add missing reference for memory-controller
  ARM: zynq: DT: Add missing reference for ADC
  ARM: zynq: DT: Add missing address for L2 pl310
  ARM: zynq: DT: Remove 222 MHz OPP
  ARM: zynq: DT: Fix GEM register area size

Pull vfs updates from Al Viro:
 "overlayfs merge + leak fix for d_splice_alias() failure exits"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  overlayfs: embed middle into overlay_readdir_data
  overlayfs: embed root into overlay_readdir_data
  overlayfs: make ovl_cache_entry->name an array instead of pointer
  overlayfs: don't hold ->i_mutex over opening the real directory
  fix inode leaks on d_splice_alias() failure exits
  fs: limit filesystem stacking depth
  overlay: overlay filesystem documentation
  overlayfs: implement show_options
  overlayfs: add statfs support
  overlay filesystem
  shmem: support RENAME_WHITEOUT
  ext4: support RENAME_WHITEOUT
  vfs: add RENAME_WHITEOUT
  vfs: add whiteout support
  vfs: export check_sticky()
  vfs: introduce clone_private_mount()
  vfs: export __inode_permission() to modules
  vfs: export do_splice_direct() to modules
  vfs: add i_op->dentry_open()

Merge tag 'imx-fixes-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes

Merge "ARM: imx: fixes for 3.18" from Shawn Guo:

The i.MX fixes for 3.18:
 - Revert one patch which increases I2C bus frequency on imx28-evk
 - Fix a typo on imx6q EIM clock name

* tag 'imx-fixes-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: dts: imx28-evk: Let i2c0 run at 100kHz
  ARM: i.MX6: Fix "emi" clock name typo
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 78b81f46 ("ARM: dts: imx28-evk: Run I2C0 at 400kHz") caused issues
when doing the following sequence in loop:

- Boot the kernel
- Perform audio playback
- Reboot the system via 'reboot' command

In many times the audio card cannot be probed, which causes playback to fail.

After restoring to the original i2c0 frequency of 100kHz there is no such
problem anymore.

This reverts commit 78b81f46.

Cc: <stable@vger.kernel.org> # 3.16+
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Fix a typo error, the "emi" names refer to the eim clocks.

The change fixes typo in EIM and EIM_SLOW pre-output dividers and
selectors clock names. Notably EIM_SLOW clock itself is named correctly.
Signed-off-by: NSteve Longerbeam <steve_longerbeam@mentor.com>
[vladimir_zapolskiy@mentor.com: ported to v3.17]
Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

same story...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

no sense having it a pointer - all instances have it pointing to
local variable in the same stack frame
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

just use it to serialize the assignment
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

When modifying code, ftrace has several checks to make sure things
are being done correctly. One of them is to make sure any code it
modifies is exactly what it expects it to be before it modifies it.
In order to do so with the new trampoline logic, it must be able
to find out what trampoline a function is hooked to in order to
see if the code that hooks to it is what's expected.

The logic to find the trampoline from a record (accounting descriptor
for a function that is hooked) needs to only look at the "old_hash"
of an ops that is being modified. The old_hash is the list of function
an ops is hooked to before its update. Since a record would only be
pointing to an ops that is being modified if it was already hooked
before.

Currently, it can pick a modified ops based on its new functions it
will be hooked to, and this picks the wrong trampoline and causes
the check to fail, disabling ftrace.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

ftrace: squash into ordering of ops for modification

The code that checks for trampolines when modifying function hooks
tests against a modified ops "old_hash". But the ops old_hash pointer
is not being updated before the changes are made, making it possible
to not find the right hash to the callback and possibly causing
ftrace to break in accounting and disable itself.

Have the ops set its old_hash before the modifying takes place.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

Pull MIPS fixes from Ralf Baechle:
 "This is the first round of fixes and tying up loose ends for MIPS.

   - plenty of fixes for build errors in specific obscure configurations
   - remove redundant code on the Lantiq platform
   - removal of a useless SEAD I2C driver that was causing a build issue
   - fix an earlier TLB exeption handler fix to also work on Octeon.
   - fix ISA level dependencies in FPU emulator's instruction decoding.
   - don't hardcode kernel command line in Octeon software emulator.
   - fix an earlier fix for the Loondson 2 clock setting"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: SEAD3: Fix I2C device registration.
  MIPS: SEAD3: Nuke PIC32 I2C driver.
  MIPS: ftrace: Fix a microMIPS build problem
  MIPS: MSP71xx: Fix build error
  MIPS: Malta: Do not build the malta-amon.c file if CMP is not enabled
  MIPS: Prevent compiler warning from cop2_{save,restore}
  MIPS: Kconfig: Add missing MIPS_CPS dependencies to PM and cpuidle
  MIPS: idle: Remove leftover __pastwait symbol and its references
  MIPS: Sibyte: Include the swarm subdir to the sb1250 LittleSur builds
  MIPS: ptrace.h: Add a missing include
  MIPS: ath79: Fix compilation error when CONFIG_PCI is disabled
  MIPS: MSP71xx: Remove compilation error when CONFIG_MIPS_MT is present
  MIPS: Octeon: Remove special case for simulator command line.
  MIPS: tlbex: Properly fix HUGE TLB Refill exception handler
  MIPS: loongson2_cpufreq: Fix CPU clock rate setting mismerge
  pci: pci-lantiq: remove duplicate check on resource
  MIPS: Lasat: Add missing CONFIG_PROC_FS dependency to PICVUE_PROC
  MIPS: cp1emu: Fix ISA restrictions for cop1x_op instructions

Pull arm64 fixes from Catalin Marinas:

 - enable 48-bit VA space now that KVM has been fixed, together with a
   couple of fixes for pgd allocation alignment and initial memblock
   current_limit.  There is still a dependency on !ARM_SMMU which needs
   to be updated as it uses the page table manipulation macros of the
   host kernel
 - eBPF fixes following changes/conflicts during the merging window
 - Compat types affecting compat_elf_prpsinfo
 - Compilation error on UP builds
 - ASLR fix when /proc/sys/kernel/randomize_va_space == 0
 - DT definitions for CLCD support on ARMv8 model platform

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: Fix memblock current_limit with 64K pages and 48-bit VA
  arm64: ASLR: Don't randomise text when randomise_va_space == 0
  arm64: vexpress: Add CLCD support to the ARMv8 model platform
  arm64: Fix compilation error on UP builds
  Documentation/arm64/memory.txt: fix typo
  net: bpf: arm64: minor fix of type in jited
  arm64: bpf: add 'load 64-bit immediate' instruction
  arm64: bpf: add 'shift by register' instructions
  net: bpf: arm64: address randomize and write protect JIT code
  arm64: mm: Correct fixmap pagetable types
  arm64: compat: fix compat types affecting struct compat_elf_prpsinfo
  arm64: Align less than PAGE_SIZE pgds naturally
  arm64: Allow 48-bits VA space without ARM_SMMU

Pull two sparc fixes from David Miller:

 1) Fix boots with gcc-4.9 compiled sparc64 kernels.

 2) Add missing __get_user_pages_fast() on sparc64 to fix hangs on
    futexes used in transparent hugepage areas.

    It's really idiotic to have a weak symbolled fallback that just
    returns zero, and causes this kind of bug.  There should be no
    backup implementation and the link should fail if the architecture
    fails to provide __get_user_pages_fast() and supports transparent
    hugepages.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc64: Implement __get_user_pages_fast().
  sparc64: Fix register corruption in top-most kernel stack frame during boot.

Pull kvm fixes from Paolo Bonzini:
 "This is a pretty large update.  I think it is roughly as big as what I
  usually had for the _whole_ rc period.

  There are a few bad bugs where the guest can OOPS or crash the host.
  We have also started looking at attack models for nested
  virtualization; bugs that usually result in the guest ring 0 crashing
  itself become more worrisome if you have nested virtualization,
  because the nested guest might bring down the non-nested guest as
  well.  For current uses of nested virtualization these do not really
  have a security impact, but you never know and bugs are bugs
  nevertheless.

  A lot of these bugs are in 3.17 too, resulting in a large number of
  stable@ Ccs.  I checked that all the patches apply there with no
  conflicts"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  kvm: vfio: fix unregister kvm_device_ops of vfio
  KVM: x86: Wrong assertion on paging_tmpl.h
  kvm: fix excessive pages un-pinning in kvm_iommu_map error path.
  KVM: x86: PREFETCH and HINT_NOP should have SrcMem flag
  KVM: x86: Emulator does not decode clflush well
  KVM: emulate: avoid accessing NULL ctxt->memopp
  KVM: x86: Decoding guest instructions which cross page boundary may fail
  kvm: x86: don't kill guest on unknown exit reason
  kvm: vmx: handle invvpid vm exit gracefully
  KVM: x86: Handle errors when RIP is set during far jumps
  KVM: x86: Emulator fixes for eip canonical checks on near branches
  KVM: x86: Fix wrong masking on relative jump/call
  KVM: x86: Improve thread safety in pit
  KVM: x86: Prevent host from panicking on shared MSR writes.
  KVM: x86: Check non-canonical addresses upon WRMSR

Merge tag 'stable/for-linus-3.18-b-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

Pull xen bug fixes from David Vrabel:

 - Fix regression in xen_clocksource_read() which caused all Xen guests
   to crash early in boot.
 - Several fixes for super rare race conditions in the p2m.
 - Assorted other minor fixes.

* tag 'stable/for-linus-3.18-b-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/pci: Allocate memory for physdev_pci_device_add's optarr
  x86/xen: panic on bad Xen-provided memory map
  x86/xen: Fix incorrect per_cpu accessor in xen_clocksource_read()
  x86/xen: avoid race in p2m handling
  x86/xen: delay construction of mfn_list_list
  x86/xen: avoid writing to freed memory after race in p2m handling
  xen/balloon: Don't continue ballooning when BP_ECANCELED is encountered

Pull sound fixes from Takashi Iwai:
 "Here are a chunk of small fixes since rc1: two PCM core fixes, one is
  a long-standing annoyance about lockdep and another is an ARM64 mmap
  fix.

  The rest are a HD-audio HDMI hotplug notification fix, a fix for
  missing NULL termination in Realtek codec quirks and a few new
  device/codec-specific quirks as usual"

* tag 'sound-3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Add missing terminating entry to SND_HDA_PIN_QUIRK macro
  ALSA: pcm: Fix false lockdep warnings
  ALSA: hda - Fix inverted LED gpio setup for Lenovo Ideapad
  ALSA: hda - hdmi: Fix missing ELD change event on plug/unplug
  ALSA: usb-audio: Add support for Steinberg UR22 USB interface
  ALSA: ALC283 codec - Avoid pop noise on headphones during suspend/resume
  ALSA: pcm: use the same dma mmap codepath both for arm and arm64