Merge tag 'pci-v4.3-fixes-2' of git://git./linux/kernel/git/helgaas/pci

Pull PCI fix from Bjorn Helgaas:
 "Sorry for this last-minute update; it's been in -next for quite a
  while, but I forgot about it until I started getting ready for the
  merge window.

  It's small and fixes a way a user could cause a panic via sysfs, so I
  think it's worth getting it in v4.3.

  NUMA:
    - Prevent out of bounds access in sysfs numa_node override (Sasha Levin)"

* tag 'pci-v4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: Prevent out of bounds access in numa_node override

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fixes from Will Deacon:
 "Apologies for this being so late, but we've uncovered a few nasty
  issues on arm64 which didn't settle down until yesterday and the fixes
  all look suitable for 4.3.  Of the four patches, three of them are
  Cc'd to stable, with the remaining patch fixing an issue that only
  took effect during the merge window.

  Summary:

   - Fix corruption in SWP emulation when STXR fails due to contention
   - Fix MMU re-initialisation when resuming from a low-power state
   - Fix stack unwinding code to match what ftrace expects
   - Fix relocation code in the EFI stub when DRAM base is not 2MB aligned"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/efi: do not assume DRAM base is aligned to 2 MB
  Revert "ARM64: unwind: Fix PC calculation"
  arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap
  arm64: compat: fix stxr failure case in SWP emulation

Merge tag 'please-pull-syscalls' of git://git./linux/kernel/git/aegl/linux

Pull ia64 kcmp syscall from Tony Luck:
 "Missed adding the kcmp() syscall a long time ago.  Now it seems that
  it is essential to build systemd"

* tag 'please-pull-syscalls' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
  [IA64] Wire up kcmp syscall

arm64/efi: do not assume DRAM base is aligned to 2 MB

The current arm64 Image relocation code in the UEFI stub assumes that
the dram_base argument it receives is always a multiple of 2 MB. In
reality, it is simply the lowest start address of all RAM entries in
the UEFI memory map, which means it could be any multiple of 4 KB.

Since the arm64 kernel Image needs to reside TEXT_OFFSET bytes beyond
a 2 MB aligned base, or it will fail to boot, make sure we round dram_base
to 2 MB before using it to calculate the relocation address.

Fixes: e38457c361b30c5a ("arm64: efi: prefer AllocatePages() over efi_low_alloc() for vmlinux")
Reported-by: Timur Tabi <timur@codeaurora.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

[IA64] Wire up kcmp syscall

systemd > 218 fails to compile on ia64 with:

     error: ‘__NR_kcmp’ undeclared [1].

I've been told that this is because the kcmp syscall hasn't been wired up
for the ia64 arch [2].

The proposed patch thus wire up the kcmp syscall for the ia64 arch.

[1] https://bugs.gentoo.org/show_bug.cgi?id=560492
[2] https://bugs.gentoo.org/show_bug.cgi?id=560492#c17

Signed-off-by: Émeric MASCHINO <emeric.maschino@gmail.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>

Revert "ARM64: unwind: Fix PC calculation"

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Cc: <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap

Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
introduced a mechanism to extend the virtual memory map range
to support arm64 systems with system RAM located at very high offset,
where the identity mapping used to enable/disable the MMU requires
additional translation levels to map the physical memory at an equal
virtual offset.

The kernel detects at boot time the tcr_el1.t0sz value required by the
identity mapping and sets-up the tcr_el1.t0sz register field accordingly,
any time the identity map is required in the kernel (ie when enabling the
MMU).

After enabling the MMU, in the cold boot path the kernel resets the
tcr_el1.t0sz to its default value (ie the actual configuration value for
the system virtual address space) so that after enabling the MMU the
memory space translated by ttbr0_el1 is restored as expected.

Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
also added code to set-up the tcr_el1.t0sz value when the kernel resumes
from low-power states with the MMU off through cpu_resume() in order to
effectively use the identity mapping to enable the MMU but failed to add
the code required to restore the tcr_el1.t0sz to its default value, when
the core returns to the kernel with the MMU enabled, so that the kernel
might end up running with tcr_el1.t0sz value set-up for the identity
mapping which can be lower than the value required by the actual virtual
address space, resulting in an erroneous set-up.

This patchs adds code in the resume path that restores the tcr_el1.t0sz
default value upon core resume, mirroring this way the cold boot path
behaviour therefore fixing the issue.

Cc: <stable@vger.kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Fixes: dd006da21646 ("arm64: mm: increase VA range of identity map")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64: compat: fix stxr failure case in SWP emulation

If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.

This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.

Cc: <stable@vger.kernel.org>
Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang <shengjiu.wang@freescale.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Merge tag 'powerpc-4.3-6' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fix from Michael Ellerman:
 - powerpc/dma: dma_set_coherent_mask() should not be GPL only from Ben

* tag 'powerpc-4.3-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/dma: dma_set_coherent_mask() should not be GPL only

powerpc/dma: dma_set_coherent_mask() should not be GPL only

When turning this from inline to an exported function I was a bit
over-eager and made it GPL only. This prevents the use of pretty much
all non-GPL PCI driver which is a bit over the top. Let's bring it
back in line with other architecture.

Fixes: 817820b0226a ("powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask < dma_mask")
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

block: re-add discard_granularity and alignment checks

In commit b49a087("block: remove split code in
blkdev_issue_{discard,write_same}"), discard_granularity and alignment
checks were removed. Ideally, with bio late splitting, the upper layers
shouldn't need to depend on device's limits.

Christoph reported a discard regression on the HGST Ultrastar SN100 NVMe
device when mkfs.xfs. We have not found the root cause yet.

This patch re-adds discard_granularity and alignment checks by reverting
the related changes in commit b49a087. The good thing is now we can
remove the 2G discard size cap and just use UINT_MAX to avoid bi_size
overflow.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lin <ming.l@ssi.samsung.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "Two fixes for ARM and one for clkdev:

   - Fix another build issue with vdsomunge on non-glibc systems
   - Fix a randconfig build error caused by an invalid configuration
   - Fix a clkdev problem causing the Nokia n700 to no longer boot"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  clkdev: fix clk_add_alias() with a NULL alias device name
  ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h
  ARM: make RiscPC depend on MMU

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

Pull blkcg fix from Jens Axboe:
 "One final fix that should go into 4.3.  It's a simple 2x1 liner,
  fixing a blkcg accounting issue.  It was using the wrong bio member to
  look at the sync and write bits..."

* 'for-linus' of git://git.kernel.dk/linux-block:
  blkcg: fix incorrect read/write sync/async stat accounting

Merge branch 'linus' of git://git./linux/kernel/git/herbert/crypto-2.6

Pull crypto fix from Herbert Xu:
 "This fixes a problem in the Crypto API that may cause spurious errors
  when signals are received by the process that made the orignal system
  call into the kernel"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: api - Only abort operations on fatal signal

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/rusty/linux

Pull module preemption fix from Rusty Russell:
 "Turns out we should have always been disabling preemption here;
  someone finally caught it thanks to Peter Z's additional checks"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  module: Fix locking in symbol_put_addr()

blkcg: fix incorrect read/write sync/async stat accounting

While unifying how blkcg stats are collected, 77ea733884eb ("blkcg:
move io_service_bytes and io_serviced stats into blkcg_gq")
incorrectly used bio->flags instead of bio->rw to tell the IO type.
This made IOs to be accounted as the wrong type.  Fix it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 77ea733884eb ("blkcg: move io_service_bytes and io_serviced stats into blkcg_gq")
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

Merge tag 'iommu-fixes-v4.3-rc7' of git://git./linux/kernel/git/joro/iommu

Pull iommu fixes from Joerg Roedel:
 "Two late fixes for the AMD IOMMU driver:

   - add an additional check to the io page-fault handler to avoid a
     BUG_ON being hit in handle_mm_fault()

   - fix a problem with devices writing to the system management area
     and were blocked by the IOMMU because the driver wrongly cleared
     out the DTE flags allowing that access"

* tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: Don't clear DTE flags when modifying it
  iommu/amd: Fix BUG when faulting a PROT_NONE VMA

Merge tag 'md/4.3-rc6-fixes' of git://neil.brown.name/md

Pull md fixes from Neil Brown:
 "Some raid1/raid10 fixes.

  I meant to get this to you before -rc7, but what with all the travel
  plans..

  Two fixes for bugs that are in both raid1 and raid10.  Both related to
  bad-block-lists and at least one needs to be back ported to 3.1.

  Also a revision for the "new" layout in raid10.  This "new" code
  (which aims to improve robustness) actually reduces robustness in some
  cases.  It probably isn't in use at all as not public user-space code
  makes use of these new layouts.  However just in case someone has
  their own code, it would be good to get the WARNing out for them
  sooner"

* tag 'md/4.3-rc6-fixes' of git://neil.brown.name/md:
  md/raid10: fix the 'new' raid10 layout to work correctly.
  md/raid10: don't clear bitmap bit when bad-block-list write fails.
  md/raid1: don't clear bitmap bit when bad-block-list write fails.
  md/raid10: submit_bio_wait() returns 0 on success
  md/raid1: submit_bio_wait() returns 0 on success

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Last fixes from me: one amdgpu/radeon suspend resume and one leak fix,
  along with one vmware fix for some issues when command submission
  fails"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/amdgpu: don't try to recreate sysfs entries on resume
  drm/radeon: don't try to recreate sysfs entries on resume
  drm/amdgpu: stop leaking page flip fence
  drm/vmwgfx: Stabilize the command buffer submission code

Merge branch 'i2c/for-current' of git://git./linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:
 "Two driver bugfixes for the I2C subsystem"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: pnx: fix runtime warnings caused by enabling unprepared clock
  i2c: mv64xxx: really allow I2C offloading

Linux 4.3-rc7

Merge branch 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux

I'm not sure whether this patch comes in too late, but it would be good to
have it in. It stabilizes command submission in case of command buffer errors.

* 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux:
  drm/vmwgfx: Stabilize the command buffer submission code

Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux

Two regression fixes and a memory leak fix for amdgpu and radeon.

* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: don't try to recreate sysfs entries on resume
  drm/radeon: don't try to recreate sysfs entries on resume
  drm/amdgpu: stop leaking page flip fence

md/raid10: fix the 'new' raid10 layout to work correctly.

In Linux 3.9 we introduce a new 'far' layout for RAID10 which was
supposed to rotate the replicas differently and so provide better
resilience.  In particular it could survive more combinations of 2
drive failures.

Unfortunately. due to a coding error, this some did what was wanted,
sometimes improved less than we hoped, and sometimes - in very
unlikely circumstances - put multiple replicas on the same device so
the redundancy was harmed.

No public user-space tool has created arrays using this layout so it
is very unlikely that zero-redundancy arrays actually exist.  Probably
no arrays using any form of the new layout exist.  But we cannot be
certain.

So use another bit in the 'layout' number and introduce a bug-fixed
version of the layout.
Also when assembling an array, if it has a zero-redundancy layout,
give a warning.

Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>

md/raid10: don't clear bitmap bit when bad-block-list write fails.

When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data.  If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.

However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit.  Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced.  This leads to data corruption.

We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.

So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.

This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.

Backports will require at least
Commit: 95af587e95aa ("md/raid10: ensure device failure recorded before write request returns.")
as well.  I'll send that to 'stable' separately.

Note that of the two tests of R10BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed.  However doing it this way makes the
patch more obviously correct.  I will tidy the code up in a
future merge window.

Reported-by: Nate Dailey <nate.dailey@stratus.com>
Fixes: bd870a16c594 ("md/raid10:  Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <neilb@suse.com>

md/raid1: don't clear bitmap bit when bad-block-list write fails.

When a write fails and a bad-block-list is present, we can
update the bad-block-list instead of writing the data.  If
this succeeds then it is OK clear the relevant bitmap-bit as
no further 'sync' of the block is needed.

However if writing the bad-block-list fails then we need to
treat the write as failed and particularly must not clear
the bitmap bit.  Otherwise the device can be re-added (after
any hardware connection issues are resolved) and because the
relevant bit in the bitmap is clear, that block will not be
resynced.  This leads to data corruption.

We already delay the final bio_endio() on the write until
the bad-block-list is written so that when the write
returns: either that data is safe, the bad-block record is
safe, or the fact that the device is faulty is safe.
However we *don't* delay the clearing of the bitmap, so the
bitmap bit can be recorded as cleared before we know if the
bad-block-list was written safely.

So: delay that until the write really is safe.
i.e. move the call to close_write() until just before
calling bio_endio(), and recheck the 'is array degraded'
status before making that call.

This bug goes back to v3.1 when bad-block-lists were
introduced, though it only affects arrays created with
mdadm-3.3 or later as only those have bad-block lists.

Backports will require at least
Commit: 55ce74d4bfe1 ("md/raid1: ensure device failure recorded before write request returns.")
as well.  I'll send that to 'stable' separately.

Note that of the two tests of R1BIO_WriteError that this
patch adds, the first is certain to fail and the second is
certain to succeed.  However doing it this way makes the
patch more obviously correct.  I will tidy the code up in a
future merge window.

Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
Fixes: cd5ff9a16f08 ("md/raid1:  Handle write errors by updating badblock log.")
Signed-off-by: NeilBrown <neilb@suse.com>

Merge tag 'usb-4.3-rc7' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are three xhci driver fixes for reported issues for 4.3-rc7

  All have been in linux-next for a while with no problems"

* tag 'usb-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  xhci: Add spurious wakeup quirk for LynxPoint-LP controllers
  xhci: handle no ping response error properly
  xhci: don't finish a TD if we get a short transfer event mid TD

Merge tag 'tty-4.3-rc7' of git://git./linux/kernel/git/gregkh/tty

Pull tty/serial fixes from Greg KH:
 "Here are two fixes that resolve reported issues, one with the 8250
  driver, and the other with the generic fbcon driver.

  Both have been in linux-next for a while"

* tag 'tty-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  fbcon: initialize blink interval before calling fb_set_par
  Revert "serial: 8250_dma: don't bother DMA with small transfers"

Merge tag 'staging-4.3-rc7' of git://git./linux/kernel/git/gregkh/staging

Pull staging driver fixes from Greg KH:
 "Here are four iio driver fixes for 4.3-rc7, fixing some reported
  issues.  All of these have been in linux-next for a while"

* tag 'staging-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  iio: mxs-lradc: Fix temperature offset
  iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()
  iio: st_accel: fix interrupt handling on LIS3LV02
  iio: adc: twl4030: Fix ADC[3:6] readings

Merge tag 'for-linus' of git://git./linux/kernel/git/dledford/rdma

Pull infiniband fixes from Doug Ledford:
 "It's late in the game, I know, but these fixes seemed important enough
  to warrant a late pull request.  They all involve oopses or use after
  frees or corruptions.

  Six serious fixes:

   - Hold the mutex around the find and corresponding update of our gid

   - The ifa list is rcu protected, copy its contents under rcu to avoid
     using a freed structure

   - On error, netdev might be null, so check it before trying to
     release it

   - On init, if workqueue alloc fails, fail init

   - The new demux patches exposed a bug in mlx5 and ipath drivers, we
     need to use the payload P_Key to determine the P_Key the packet
     arrived on because the hardware doesn't tell us the truth

   - Due to a couple convoluted error flows, it is possible for the CM
     to trigger a use_after_free and a double_free of rb nodes.  Add two
     checks to prevent that.  This code has worked for 10+ years.  It is
     likely that some of the recent changes have caused this issue to
     surface.  The current patch will protect us from nasty events for
     now while we track down why this is just now showing up"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  IB/cm: Fix rb-tree duplicate free and use-after-free
  IB/cma: Use inner P_Key to determine netdev
  IB/ucma: check workqueue allocation before usage
  IB/cma: Potential NULL dereference in cma_id_from_event
  IB/core: Fix use after free of ifa
  IB/core: Fix memory corruption in ib_cache_gid_set_default_gid

Merge tag 'dm-4.3-fixes-4' of git://git./linux/kernel/git/device-mapper/linux-dm

Pull device mapper fixes from Mike Snitzer:
 "Three stable fixes (two in btree code used by DM thinp and one to
  properly store flags in DM cache metadata's superblock)"

* tag 'dm-4.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm cache: the CLEAN_SHUTDOWN flag was not being set
  dm btree: fix leak of bufio-backed block in btree_split_beneath error path
  dm btree remove: fix a bug when rebalancing nodes after removal

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

Pull block layer fixes from Jens Axboe:
 "A final set of fixes for 4.3.

  It is (again) bigger than I would have liked, but it's all been
  through the testing mill and has been carefully reviewed by multiple
  parties.  Each fix is either a regression fix for this cycle, or is
  marked stable.  You can scold me at KS.  The pull request contains:

   - Three simple fixes for NVMe, fixing regressions since 4.3.  From
     Arnd, Christoph, and Keith.

   - A single xen-blkfront fix from Cathy, fixing a NULL dereference if
     an error is returned through the staste change callback.

   - Fixup for some bad/sloppy code in nbd that got introduced earlier
     in this cycle.  From Markus Pargmann.

   - A blk-mq tagset use-after-free fix from Junichi.

   - A backing device lifetime fix from Tejun, fixing a crash.

   - And finally, a set of regression/stable fixes for cgroup writeback
     from Tejun"

* 'for-linus' of git://git.kernel.dk/linux-block:
  writeback: remove broken rbtree_postorder_for_each_entry_safe() usage in cgwb_bdi_destroy()
  NVMe: Fix memory leak on retried commands
  block: don't release bdi while request_queue has live references
  nvme: use an integer value to Linux errno values
  blk-mq: fix use-after-free in blk_mq_free_tag_set()
  nvme: fix 32-bit build warning
  writeback: fix incorrect calculation of available memory for memcg domains
  writeback: memcg dirty_throttle_control should be initialized with wb->memcg_completions
  writeback: bdi_writeback iteration must not skip dying ones
  writeback: fix bdi_writeback iteration in wakeup_dirtytime_writeback()
  writeback: laptop_mode_timer_fn() needs rcu_read_lock() around bdi_writeback iteration
  nbd: Add locking for tasks
  xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

Merge branch 'for-linus' of git://git./linux/kernel/git/sage/ceph-client

Pull Ceph fixes from Sage Weil:
 "Two fixes.

  One is a stopgap to prevent a stack blowout when users have a deep
  chain of image clones.  (We'll rewrite this code to be non-recursive
  for the next window, but in the meantime this is a simple fix that
  avoids a crash.)

  The second fixes a refcount underflow"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
  rbd: prevent kernel stack blow up on rbd map
  rbd: don't leak parent_spec in rbd_dev_probe_parent()

Merge branch 'for-linus-4.3' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "I have two more small fixes this week:

  Qu's fix avoids unneeded COW during fallocate, and Christian found a
  memory leak in the error handling of an earlier fix"

* 'for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: fix possible leak in btrfs_ioctl_balance()
  btrfs: Avoid truncate tailing page if fallocate range doesn't exceed inode size

i2c: pnx: fix runtime warnings caused by enabling unprepared clock

The driver can not be used on a platform with common clock framework
until clk_prepare/clk_unprepare calls are added, otherwise clk_enable
calls will fail and a WARN is generated.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

dm cache: the CLEAN_SHUTDOWN flag was not being set

If the CLEAN_SHUTDOWN flag is not set when a cache is loaded then all cache
blocks are marked as dirty and a full writeback occurs.

__commit_transaction() is responsible for setting/clearing
CLEAN_SHUTDOWN (based the flags_mutator that is passed in).

Fix this issue, of the cache's on-disk flags being wrong, by making sure
__commit_transaction() does not reset the flags after the mutator has
altered the flags in preparation for them being serialized to disk.

before:

sb_flags = mutator(le32_to_cpu(disk_super->flags));
disk_super->flags = cpu_to_le32(sb_flags);
disk_super->flags = cpu_to_le32(cmd->flags);

after:

disk_super->flags = cpu_to_le32(cmd->flags);
sb_flags = mutator(le32_to_cpu(disk_super->flags));
disk_super->flags = cpu_to_le32(sb_flags);

Reported-by: Bogdan Vasiliev <bogdan.vasiliev@gmail.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

dm btree: fix leak of bufio-backed block in btree_split_beneath error path

btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.

Fix this by releasing the previously allocated bufio block using
unlock_block().

Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <thornber@redhat.com>
Cc: stable@vger.kernel.org

dm btree remove: fix a bug when rebalancing nodes after removal

Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().

The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them.  If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.

Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.

Unit tested in userspace using this program:
https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c

Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

rbd: prevent kernel stack blow up on rbd map

Mapping an image with a long parent chain (e.g. image foo, whose parent
is bar, whose parent is baz, etc) currently leads to a kernel stack
overflow, due to the following recursion in the reply path:

  rbd_osd_req_callback()
    rbd_obj_request_complete()
      rbd_img_obj_callback()
        rbd_img_parent_read_callback()
          rbd_obj_request_complete()
            ...

Limit the parent chain to 16 images, which is ~5K worth of stack.  When
the above recursion is eliminated, this limit can be lifted.

Fixes: http://tracker.ceph.com/issues/12538

Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 4.2
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>

rbd: don't leak parent_spec in rbd_dev_probe_parent()

Currently we leak parent_spec and trigger a "parent reference
underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails.
The problem is we take the !parent out_err branch and that only drops
refcounts; parent_spec that would've been freed had we called
rbd_dev_unparent() remains and triggers rbd_warn() in
rbd_dev_parent_put() - at that point we have parent_spec != NULL and
parent_ref == 0, so counter ends up being -1 after the decrement.

Redo rbd_dev_probe_parent() to fix this.

Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 4.2
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>

drm/amdgpu: don't try to recreate sysfs entries on resume

Fixes an error on resume caused by:
fa022a9b65d2886486a022fd66b20c823cd76ad9

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: don't try to recreate sysfs entries on resume

Fixes a harmless error message caused by:
51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/amdgpu: stop leaking page flip fence

reservation_object_get_fences_rcu already takes the references.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Misc fixes: two KASAN fixes, two EFI boot fixes, two boot-delay
  optimization fixes, and a fix for a IRQ handling hang observed on
  virtual platforms"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm, kasan: Silence KASAN warnings in get_wchan()
  compiler, atomics, kasan: Provide READ_ONCE_NOCHECK()
  x86, kasan: Fix build failure on KASAN=y && KMEMCHECK=y kernels
  x86/smpboot: Fix CPU #1 boot timeout
  x86/smpboot: Fix cpu_init_udelay=10000 corner case boot parameter misbehavior
  x86/ioapic: Disable interrupts when re-routing legacy IRQs
  x86/setup: Extend low identity map to cover whole kernel range
  x86/efi: Fix multiple GOP device support

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:
 "Misc fixes all around the map: an instrumentation fix, a nohz
  usability fix, a lockdep annotation fix and two task group scheduling
  fixes"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/core: Add missing lockdep_unpin() annotations
  sched/deadline: Fix migration of SCHED_DEADLINE tasks
  nohz: Revert "nohz: Set isolcpus when nohz_full is set"
  sched/fair: Update task group's load_avg after task migration
  sched/fair: Fix overly small weight for interactive group entities
  sched, tracing: Stop/start critical timings around the idle=poll idle loop

Merge branch 'akpm' (patches from Andrew)

Merge fixes from Andrew Morton:
 "9 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  ocfs2/dlm: unlock lockres spinlock before dlm_lockres_put
  fault-inject: fix inverted interval/probability values in printk
  lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y
  mm: make sendfile(2) killable
  thp: use is_zero_pfn() only after pte_present() check
  mailmap: update Javier Martinez Canillas' email
  MAINTAINERS: add Sergey as zsmalloc reviewer
  mm: cma: fix incorrect type conversion for size during dma allocation
  kmod: don't run async usermode helper as a child of kworker thread

sched/core: Add missing lockdep_unpin() annotations

Luca and Wanpeng reported two missing annotations that led to
false lockdep complaints. Add the missing annotations.

Reported-by: Luca Abeni <luca.abeni@unitn.it>
Reported-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: cbce1a686700 ("sched,lockdep: Employ lock pinning")
Link: http://lkml.kernel.org/r/20151023095008.GY17308@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'powerpc-4.3-5' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:

 - Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on
   POWER8" from Paul
 - Handle irq_happened flag correctly in off-line loop from Paul
 - Validate rtas.entry before calling enter_rtas() from Vasant

* tag 'powerpc-4.3-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/rtas: Validate rtas.entry before calling enter_rtas()
  powerpc/powernv: Handle irq_happened flag correctly in off-line loop
  powerpc: Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8"

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Arnd Bergmann:
 "Most of the changes this time are for incorrect device nodes in
  various ways, on on imx, berlin, exynos, ux500, uniphier, omap and
  meson.

  Chen-Yu Tsai now co-maintains mach-sunxi (Allwinner).

  Other bug fixes include
   - a partial revert of a broken tegra gpio patch
   - irq affinity for arm ccn
   - suspend on one Armada 385 machine
   - enable ZONE_DMA to avoid an OMAP crash for over 2GB RAM
   - turning on a regulator on beagleboard-x15 for HDMI
   - making the omap gpmc debug code visible
   - setup of orion network switch
   - a rare build regression for pxa"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (22 commits)
  ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init
  thermal: exynos: Fix register read in TMU
  ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory
  ARM: tegra: Comment out gpio-ranges properties
  ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board
  drivers/perf: arm_pmu: avoid CPU device_node reference leak
  bus: arm-ccn: Fix irq affinity setting on CPU migration
  bus: arm-ccn: Handle correctly no-more-cpus case
  ARM: mvebu: correct a385-db-ap compatible string
  ARM: meson6: DTS: Fix wrong reg mapping and IRQ numbers
  MAINTAINERS: Update Allwinner entry and add new maintainer
  ARM: ux500: modify initial levelshifter status
  ARM: pxa: fix pxa3xx DFI lockup hack
  Documentation: ARM: List new omap MMC requirements
  memory: omap-gpmc: dump "before" state before first modification
  memory: omap-gpmc: Fix unselectable debug option for GPMC
  ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on
  ARM: dts: Fix audio card detection on Peach boards
  ARM: EXYNOS: Fix double of_node_put() when parsing child power domains
  ARM: orion: Fix DSA platform device after mvmdio conversion
  ...

Merge tag 'for-linus' of git://git./virt/kvm/kvm

Pull KVM bugfixes from Paolo Bonzini:
 "Bug fixes for ARM, mostly 4.3 regressions related to virtual interrupt
  controller changes"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  arm/arm64: KVM: Fix disabled distributor operation
  arm/arm64: KVM: Clear map->active on pend/active clear
  arm/arm64: KVM: Fix arch timer behavior for disabled interrupts
  KVM: arm: use GIC support unconditionally
  KVM: arm/arm64: Fix memory leak if timer initialization fails
  KVM: arm/arm64: Do not inject spurious interrupts

Merge tag 'trace-fixes-v4.3-rc6' of git://git./linux/kernel/git/rostedt/linux-trace

Pull tracing fixes from Steven Rostedt:
 "Running tests on other changes, the system locked up due to lots of
  warnings.  It was caused by the stack tracer triggering a warning
  about using rcu_dereference() when RCU was not watching.  This can
  happen due to the fact that the stack tracer uses the function tracer
  to check each function, and there are functions that may be called and
  traced when RCU stopped watching.  Namely when a function is called
  just before going idle or to userspace and after RCU stopped watching
  that current CPU.

  The first patch makes sure that RCU is watching when the stack tracer
  uses RCU.  The second patch is to make sure that the stack tracer does
  not get called by functions in NMI, as it's not NMI safe"

* tag 'trace-fixes-v4.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Do not allow stack_tracer to record stack in NMI
  tracing: Have stack tracer force RCU to be watching

Merge tag 'sound-4.3-rc7' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "There is nothing to worry you much, only a few small & stable patches
  are found for usual stuff, HD-audio (a Lenovo laptop quirk, a fix for
  minor error handling) and ASoC (trivial fixes for RT298 and WM
  codecs).

  The only remaining major change is the fix for ASoC SX_TLV control
  that was overseen during refactoring, but the fix itself is trivial
  and safe"

* tag 'sound-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: wm8962: mark cache_dirty flag after software reset in pm_resume
  ASoC: rt298: fix wrong setting of gpio2_en
  ASoC: wm8904: Correct number of EQ registers
  ALSA: hda - Fix deadlock at error in building PCM
  ASoC: Add info callback for SX_TLV controls
  ASoC: rt298: correct index default value
  ALSA: hda - Fix inverted internal mic on Lenovo G50-80
  ALSA: hdac: Explicitly add io.h

Merge tag 'media/v4.3-4' of git://git./linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:
 "Some regression fixes and potential security issues:

   - netup_unidvb: fix potential crash when spi is NULL
   - rtl28xxu: fix control message flaws
   - m88ds3103: fix a regression on Kernel 4.2
   - c8sectpfe: fix some issues on this new driver
   - v4l2-flash-led-class: fix a Kbuild dependency
   - si2157 and si2158: check for array boundary when uploading firmware
     files
   - horus3a and lnbh25: fix some building troubles when some options
     aren't selected
   - ir-hix5hd2: drop the use of IRQF_NO_SUSPEND"

* tag 'media/v4.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] m88ds3103: use own reg update_bits() implementation
  [media] rtl28xxu: fix control message flaws
  [media] v4l2-flash-led-class: Add missing VIDEO_V4L2 Kconfig dependency
  [media] netup_unidvb: fix potential crash when spi is NULL
  [media] si2168: Bounds check firmware
  [media] si2157: Bounds check firmware
  [media] ir-hix5hd2: drop the use of IRQF_NO_SUSPEND
  [media] c8sectpfe: fix return of garbage
  [media] c8sectpfe: fix ininitialized error return on firmware load failure
  [media] lnbh25: Fix lnbh25_attach() function return type
  [media] horus3a: Fix horus3a_attach() function parameters

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "I've been a bit slow gathering these:

   - drm/mst: one mutex leak in a fail path

   - radeon: two oops fixes, one dpm fix

   - i915: one messy set of fixes, where we revert the original fix, and
           pull back the proper set of fixes from -next on top.

   - nouveau: one fix for an illegal buffer placement.

  Doesn't look too bad, hopefully shouldn't be too much more"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/nouveau/gem: return only valid domain when there's only one
  drm: fix mutex leak in drm_dp_get_mst_branch_device
  drm/amdgpu: add missing dpm check for KV dpm late init
  drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
  drm/radeon/dpm: don't add pwm attributes if DPM is disabled
  drm/i915: Add primary plane to mask if it's visible
  drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()
  drm/i915: Assign hwmode after encoder state readout
  Revert "drm/i915: Add primary plane to mask if it's visible"
  drm/i915: Deny wrapping an userptr into a framebuffer
  drm/i915: Enable DPLL VGA mode before P1/P2 divider write
  drm/i915: Restore lost DPLL register write on gen2-4
  drm/i915: Flush pipecontrol post-sync writes
  drm/i915: Fix kerneldoc for i915_gem_shrink_all

ocfs2/dlm: unlock lockres spinlock before dlm_lockres_put

dlm_lockres_put will call dlm_lockres_release if it is the last
reference, and then it may call dlm_print_one_lock_resource and
take lockres spinlock.

So unlock lockres spinlock before dlm_lockres_put to avoid deadlock.

Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fault-inject: fix inverted interval/probability values in printk

interval displays the probability and vice versa.

Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option")
Acked-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y

When the kernel compiled with KASAN=y, GCC adds redzones for each
variable on stack.  This enlarges function's stack frame and causes:

'warning: the frame size of X bytes is larger than Y bytes'

The worst case I've seen for now is following:

   ../net/wireless/nl80211.c: In function `nl80211_send_wiphy':
   ../net/wireless/nl80211.c:1731:1: warning: the frame size of 5448 bytes is larger than 2048 bytes [-Wframe-larger-than=]

That kind of warning becomes useless with KASAN=y.  It doesn't
necessarily indicate that there is some problem in the code, thus we
should turn it off.

(The KASAN=y stack size in increased from 16k to 32k for this reason)

Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Abylay Ospan <aospan@netup.ru>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Kozlov Sergey <serjk@netup.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: make sendfile(2) killable

Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM instance.

        int fd;
        off_t off = 0;

        fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
        ftruncate(fd, 2);
        lseek(fd, 0, SEEK_END);
        sendfile(fd, fd, &off, 0xfffffff);

Now you should not ask kernel to do a stupid stuff like copying 256MB in
2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
should have a way to stop you.

We actually do have a check for fatal_signal_pending() in
generic_perform_write() which triggers in this path however because we
always succeed in writing something before the check is done, we return
value > 0 from generic_perform_write() and thus the information about
signal gets lost.

Fix the problem by doing the signal check before writing anything.  That
way generic_perform_write() returns -EINTR, the error gets propagated up
and the sendfile loop terminates early.

Signed-off-by: Jan Kara <jack@suse.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

thp: use is_zero_pfn() only after pte_present() check

Use is_zero_pfn() on pteval only after pte_present() check on pteval
(It might be better idea to introduce is_zero_pte() which checks
pte_present() first).

Otherwise when working on a swap or migration entry and if pte_pfn's
result is equal to zero_pfn by chance, we lose user's data in
__collapse_huge_page_copy().  So if you're unlucky, the application
segfaults and finally you could see below message on exit:

BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3

Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge pages")
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Mel Gorman <mgorman@suse.de>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org> [4.1+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mailmap: update Javier Martinez Canillas' email

The get_maintainer script still reports my old Collabora email based on
old commits but that address no longer exist so update mailmap to report
my current email and avoid people sending to the old address.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MAINTAINERS: add Sergey as zsmalloc reviewer

Nominate myself as a zsmalloc reviewer.

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: cma: fix incorrect type conversion for size during dma allocation

This was found during userspace fuzzing test when a large size dma cma
allocation is made by driver(like ion) through userspace.

  show_stack+0x10/0x1c
  dump_stack+0x74/0xc8
  kasan_report_error+0x2b0/0x408
  kasan_report+0x34/0x40
  __asan_storeN+0x15c/0x168
  memset+0x20/0x44
  __dma_alloc_coherent+0x114/0x18c

Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kmod: don't run async usermode helper as a child of kworker thread

call_usermodehelper_exec_sync() does fork() + wait() with "unignored"
SIGCHLD.  What we have missed is that this worker thread can have other
children previously forked by call_usermodehelper_exec_work() without
UMH_WAIT_PROC.  If such a child exits in between it becomes a zombie
because auto-reaping only works if SIGCHLD is ignored, and nobody can
reap it (unless/until this worker thread exits too).

Change the !UMH_WAIT_PROC case to use CLONE_PARENT.

Note: this is only first step.  All PF_KTHREAD tasks, even created by
kernel_thread() should have ->parent == kthreadd by default.

Fixes: bb304a5c6fc63d8506c ("kmod: handle UMH_WAIT_PROC from system unbound workqueue")
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'asoc-fix-v4.3-rc6' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.3

A bunch of driver fixes plus one core fix which fixes problems with
misreporting values from _SX controls following a recent refactoring.
This had gone unnoticed as such controls are quite rare.

Merge remote-tracking branches 'asoc/fix/rt298', 'asoc/fix/sx', 'asoc/fix/wm8904' and 'asoc/fix/wm8962' into asoc-linus

Merge remote-tracking branch 'asoc/fix/rt5645' into asoc-linus

[media] m88ds3103: use own reg update_bits() implementation

Device stopped to tuning some channels after regmap conversion.
Reason is that regmap_update_bits() works a bit differently for
partially volatile registers than old homemade routine. Return
back to old routine in order to fix issue.

Fixes: 478932b16052f5ded74685d096ae920cd17d6424

Cc: <stable@kernel.org> # 4.2+
Reported-by: Mark Clarkstone <hello@markclarkstone.co.uk>
Tested-by: Mark Clarkstone <hello@markclarkstone.co.uk>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] rtl28xxu: fix control message flaws

Add lock to prevent concurrent access for control message as control
message function uses shared buffer. Without the lock there may be
remote control polling which messes the buffer causing IO errors.
Increase buffer size and add check for maximum supported message
length.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=103391
Fixes: c56222a6b25c ("[media] rtl28xxu: move usb buffers to state")

Cc: <stable@vger.kernel.org> # 4.0+
Signed-off-by: Antti Palosaari <crope@iki.fi>

[media] v4l2-flash-led-class: Add missing VIDEO_V4L2 Kconfig dependency

Fixes the following randconfig problem:

drivers/built-in.o: In function `v4l2_flash_release':
(.text+0x12204f): undefined reference to `v4l2_async_unregister_subdev'
drivers/built-in.o: In function `v4l2_flash_release':
(.text+0x122057): undefined reference to `v4l2_ctrl_handler_free'
drivers/built-in.o: In function `v4l2_flash_close':
v4l2-flash-led-class.c:(.text+0x12208f): undefined reference to `v4l2_fh_is_singular'
v4l2-flash-led-class.c:(.text+0x1220c8): undefined reference to `__v4l2_ctrl_s_ctrl'
drivers/built-in.o: In function `v4l2_flash_open':
v4l2-flash-led-class.c:(.text+0x12227f): undefined reference to `v4l2_fh_is_singular'
drivers/built-in.o: In function `v4l2_flash_init_controls':
v4l2-flash-led-class.c:(.text+0x12274e): undefined reference to `v4l2_ctrl_handler_init_class'
v4l2-flash-led-class.c:(.text+0x122797): undefined reference to `v4l2_ctrl_new_std_menu'
v4l2-flash-led-class.c:(.text+0x1227e0): undefined reference to `v4l2_ctrl_new_std'
v4l2-flash-led-class.c:(.text+0x122826): undefined reference to `v4l2_ctrl_handler_setup'
v4l2-flash-led-class.c:(.text+0x122839): undefined reference to `v4l2_ctrl_handler_free'
drivers/built-in.o: In function `v4l2_flash_init':
(.text+0x1228e2): undefined reference to `v4l2_subdev_init'
drivers/built-in.o: In function `v4l2_flash_init':
(.text+0x12293b): undefined reference to `v4l2_async_register_subdev'
drivers/built-in.o: In function `v4l2_flash_init':
(.text+0x122949): undefined reference to `v4l2_ctrl_handler_free'
drivers/built-in.o:(.rodata+0x20ef8): undefined reference to `v4l2_subdev_queryctrl'
drivers/built-in.o:(.rodata+0x20f10): undefined reference to `v4l2_subdev_querymenu'

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Hans Verkuil <hans.verkuil@cisco.com>

[media] netup_unidvb: fix potential crash when spi is NULL

Signed-off-by: Abylay Ospan <aospan@netup.ru>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] si2168: Bounds check firmware

When reading the firmware and sending commands, the length must
be bounds checked to avoid overrunning the size of the command
buffer and smashing the stack if the firmware is not in the expected
format:

si2168 11-0064: found a 'Silicon Labs Si2168-B40'
si2168 11-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
si2168 11-0064: firmware download failed -95
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa085708f

Add the proper check.

Cc: stable@kernel.org
Reported-by: Stuart Auchterlonie <sauchter@redhat.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] si2157: Bounds check firmware

When reading the firmware and sending commands, the length
must be bounds checked to avoid overrunning the size of the command
buffer and smashing the stack if the firmware is not in the
expected format. Add the proper check.

Cc: stable@kernel.org
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] ir-hix5hd2: drop the use of IRQF_NO_SUSPEND

This driver doesn't claim the IR transmitter to be wakeup source. It
even disables the clock and the IR during suspend-resume cycle.

This patch removes yet another misuse of IRQF_NO_SUSPEND.

Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Guoxiong Yan <yanguoxiong@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] c8sectpfe: fix return of garbage

The variable err was never initialized, that means we had been checking
a garbage value in the for loop. Moreover if the segment is not outside
the firmware file then also we have been returning the garbage.
Initialize it to 0 so that on success we return the value and no need to
check in the for loop also as it is initially 0 and whenever that value
changes we have done a break from the loop.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

[media] c8sectpfe: fix ininitialized error return on firmware load failure

static analysis with cppcheck detected the following error:

[drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c:1210]:
  (error) Uninitialized variable: ret

ret is never initialised, so garbage is being returned. Instead
return the error return from the call of request_firmware_nowait

Signed-off-by: Colin Ian King <colin.king@canonical.com>

[media] lnbh25: Fix lnbh25_attach() function return type

If CONFIG_DVB_LNBH25 is disabled, a stub static inline function is
defined that just prints a warning about the driver being disabled
but the function return type was wrong which caused a build error.

Fixes: e025273b86fb ("[media] lnbh25: LNBH25 SEC controller driver")

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

[media] horus3a: Fix horus3a_attach() function parameters

If CONFIG_DVB_HORUS3A is disabled a stub static inline function is
defined that just prints a warning about the driver being disabled
but the function parameters were wrong which caused a build error.

Fixes: a5d32b358254f ("[media] horus3a: Sony Horus3A DVB-S/S2 tuner driver")

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

i2c: mv64xxx: really allow I2C offloading

Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but left a
debugging-related "return false" at the beginning of the
mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
that offloading is in fact never used, which wasn't really the
intention.

This commit fixes that problem by removing the bogus "return false".

Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems")
Signed-off-by: Hezi Shahmoon <hezi@marvell.com>
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: <stable@vger.kernel.org>

ASoC: wm8962: mark cache_dirty flag after software reset in pm_resume

By doing software reset of wm8962 in pm_resume, all registers which
have already been set will be reset to default value without regmap
interface be involved, thus driver need to mark cache_dirty flag,
to let regcache can be updated by regcache_sync().

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

btrfs: fix possible leak in btrfs_ioctl_balance()

Commit 8eb934591f8b ("btrfs: check unsupported filters in balance
arguments") adds a jump to exit label out_bargs in case the argument
check fails. At this point in addition to the bargs memory, the
memory for struct btrfs_balance_control has already been allocated.
Ownership of bctl is passed to btrfs_balance() in the good case,
thus the memory is not freed due to the introduced jump. Make sure
that the memory gets freed in any case as necessary. Detected by
Coverity CID 1328378.

Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>

Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

Just a crash fix for radeon and amdgpu if the user has forcibly disabled
dpm and tries to access the pwm sysfs controls.

* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: add missing dpm check for KV dpm late init
  drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
  drm/radeon/dpm: don't add pwm attributes if DPM is disabled

Merge tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel into drm-fixes

The revert dance could use some explanation: we had stuff fixed in
-next, and initially backported one commit to v4.3. Now, turns out we
need more fixes, and we could cherry-pick them all without conflicts if
we reverted the backported one first. So did that to not have to edit
and backport them all.

* tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Add primary plane to mask if it's visible
  drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()
  drm/i915: Assign hwmode after encoder state readout
  Revert "drm/i915: Add primary plane to mask if it's visible"
  drm/i915: Deny wrapping an userptr into a framebuffer
  drm/i915: Enable DPLL VGA mode before P1/P2 divider write
  drm/i915: Restore lost DPLL register write on gen2-4
  drm/i915: Flush pipecontrol post-sync writes
  drm/i915: Fix kerneldoc for i915_gem_shrink_all

powerpc/rtas: Validate rtas.entry before calling enter_rtas()

Currently we do not validate rtas.entry before calling enter_rtas(). This
leads to a kernel oops when user space calls rtas system call on a powernv
platform (see below). This patch adds code to validate rtas.entry before
making enter_rtas() call.

  Oops: Exception in kernel mode, sig: 4 [#1]
  SMP NR_CPUS=1024 NUMA PowerNV
  task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
  NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
  REGS: c0000007e1a7b920 TRAP: 0e40   Not tainted  (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
  MSR: 1000000000081000 <HV,ME>  CR: 00000000  XER: 00000000
  CFAR: c000000000009c0c SOFTE: 0
  NIP [0000000000000000]           (null)
  LR [0000000000009c14] 0x9c14
  Call Trace:
  [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
  [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
  [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98

Cc: stable@vger.kernel.org # v3.2+
Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
Reported-by: NAGESWARA R. SASTRY <nasastry@in.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[mpe: Reword change log, trim oops, and add stable + fixes]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Merge branch 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixes

Just one fix from Ilia to resolve various issues that have resulted from
buffer eviction.

* 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6:
  drm/nouveau/gem: return only valid domain when there's only one

drm/nouveau/gem: return only valid domain when there's only one

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm: fix mutex leak in drm_dp_get_mst_branch_device

In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later.  This patch
changes the error to "goto out" to unlock the mutex before returning.

[airlied: grabbed from drm-next as it fixes something we've seen]

Signed-off-by: Adam J. Richter <adam_richter2004@yahoo.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'for-linus-20151021' of git://git.infradead.org/intel-iommu

Pull intel-iommu bugfix from David Woodhouse:
 "This contains a single fix, for when the IOMMU API is used to overlay
  an existing mapping comprised of 4KiB pages, with a mapping that can
  use superpages.

  For the *first* superpage in the new mapping, we were correctly¹
  freeing the old bottom-level page table page and clearing the link to
  it, before installing the superpage.  For subsequent superpages,
  however, we weren't.  This causes a memory leak, and a warning about
  setting a PTE which is already set.

  ¹ Well, not *entirely* correctly.  We just free the page table pages
    right there and then, which is wrong.  In fact they should only be
    freed *after* the IOTLB is flushed so we know the hardware will no
    longer be looking at them....  and in fact I note that the IOTLB
    flush is completely missing from the intel_iommu_map() code path,
    although it needs to be there if it's permitted to overwrite
    existing mappings.

    Fixing those is somewhat more intrusive though, and will probably
    need to wait for 4.4 at this point"

* tag 'for-linus-20151021' of git://git.infradead.org/intel-iommu:
  iommu/vt-d: fix range computation when making room for large pages

Merge tag 'mmc-v4.3-rc5' of git://git.linaro.org/people/ulf.hansson/mmc

Pull MMC bugfix from Ulf Hansson:
 "Here's yet another MMC fix intended for v4.3 rc7.  I don't expect to
  send any further pull requests for 4.3 rc[n].

  MMC core:
   - Don't re-tune in the reset sequence to allow re-init of the card"

* tag 'mmc-v4.3-rc5' of git://git.linaro.org/people/ulf.hansson/mmc:
  mmc: core: Fix init_card in 52Mhz

IB/cm: Fix rb-tree duplicate free and use-after-free

ib_send_cm_sidr_rep could sometimes erase the node from the sidr
(depending on errors in the process). Since ib_send_cm_sidr_rep is
called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
could be either erased from the rb_tree twice or not erased at all.
Fixing that by making sure it's erased only once before freeing
cm_id_priv.

Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
Signed-off-by: Doron Tsur <doront@mellanox.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>

drm/vmwgfx: Stabilize the command buffer submission code

This commit addresses some stability problems with the command buffer
submission code recently introduced:

1) Make the vmw_cmdbuf_man_process() function handle reruns internally to
avoid losing interrupts if the caller forgets to rerun on -EAGAIN.
2) Handle default command buffer allocations using inline command buffers.
This avoids rare allocation deadlocks.
3) In case of command buffer errors we might lose fence submissions.
Therefore send a new fence after each command buffer error. This will help
avoid lengthy fence waits.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

Merge tag 'kvm-arm-for-v4.3-rc7' of git://git./linux/kernel/git/kvmarm/kvmarm into kvm-master

A late round of KVM/ARM fixes for v4.3-rc7, fixing:
 - A bug where level-triggered interrupts lowered from userspace
   are still routed to the guest
 - A memory leak an a failed initialization path
 - A build error under certain configurations
 - Several timer bugs introduced with moving the timer to the active
   state handling instead of the masking trick.

Merge tag 'mvebu-fixes-4.3-2' of git://git.infradead.org/linux-mvebu into fixes

Merge "mvebu fixes for 4.3 (part 2)" from Gregory CLEMENT:

Fix wrong compatible for A385 DB AP preventing using suspend

* tag 'mvebu-fixes-4.3-2' of git://git.infradead.org/linux-mvebu:
  ARM: mvebu: correct a385-db-ap compatible string

Merge tag 'samsung-fixes-2' of git://git./linux/kernel/git/kgene/linux-samsung into fixes

Merge "Samsung 2nd fixes for v4.3" from Kukjin Kim:

- fix SOC detection of exynos thermal on exynos5260
- fix audio card detection on Peach boards
- fix double of_node_put() when parsing child power domains

* tag 'samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  thermal: exynos: Fix register read in TMU
  ARM: dts: Fix audio card detection on Peach boards
  ARM: EXYNOS: Fix double of_node_put() when parsing child power domains

Merge tag 'omap-for-v4.3/fixes-rc6' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

Merge "Fixes for omaps for v4.3-rc cycle" from Tony Lindgren:

- Fix oops with LPAE and moew than 2GB of memory by enabling
  ZONE_DMA for LPAE. Probably no need for stable on this one as we
  only recently ran into this with the mainline kernel

- Fix imprecise external abort caused by bogus SRAM init. This affects
  dm814x recently merged, so no need for stable on this one AFAIK

* tag 'omap-for-v4.3/fixes-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init
  ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

writeback: remove broken rbtree_postorder_for_each_entry_safe() usage in cgwb_bdi_destroy()

a20135ffbc44 ("writeback: don't drain bdi_writeback_congested on bdi
destruction") added rbtree_postorder_for_each_entry_safe() which is
used to remove all entries; however, according to Cody, the iterator
isn't safe against operations which may rebalance the tree.  Fix it by
switching to repeatedly removing rb_first() until empty.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Cody P Schafer <dev@codyps.com>
Fixes: a20135ffbc44 ("writeback: don't drain bdi_writeback_congested on bdi destruction")
Link: http://lkml.kernel.org/g/1443997973-1700-1-git-send-email-dev@codyps.com
Signed-off-by: Jens Axboe <axboe@fb.com>

ASoC: rt298: fix wrong setting of gpio2_en

The register value to enable gpio2 was incorrect. So fix it.

Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

powerpc/powernv: Handle irq_happened flag correctly in off-line loop

This fixes a bug where it is possible for an off-line CPU to fail to go
into a low-power state (nap/sleep/winkle), and to become unresponsive to
requests from the KVM subsystem to wake up and run a VCPU. What can
happen is that a maskable interrupt of some kind (external, decrementer,
hypervisor doorbell, or HMI) after we have called local_irq_disable() at
the beginning of pnv_smp_cpu_kill_self() and before interrupts are
hard-disabled inside power7_nap/sleep/winkle(). In this situation, the
pending event is marked in the irq_happened flag in the PACA. This
pending event prevents power7_nap/sleep/winkle from going to the
requested low-power state; instead they return immediately. We don't
deal with any of these pending event flags in the off-line loop in
pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case,
so we will have srr1 == 0, and none of the processing to clear
interrupts or doorbells will be done.

Usually, the most obvious symptom of this is that a KVM guest will fail
with a console message saying "KVM: couldn't grab cpu N".

This fixes the problem by making sure we handle the irq_happened flags
properly. First, we hard-disable before the off-line loop. Once we have
hard-disabled, the irq_happened flags can't change underneath us. We
unconditionally clear the DEC and HMI flags: there is no processing of
timer interrupts while off-line, and the necessary HMI processing is all
done in lower-level code. We leave the EE and DBELL flags alone for the
first iteration of the loop, so that we won't fail to respond to a
split-core request that came in just before hard-disabling. Within the
loop, we handle external interrupts if the EE bit is set in irq_happened
as well as if the low-power state was interrupted by an external
interrupt. (We don't need to do the msgclr for a pending doorbell in
irq_happened, because doorbells are edge-triggered and don't remain
pending in hardware.) Then we clear both the EE and DBELL flags, and
once clear, they cannot be set again (until this CPU comes online again,
that is).

This also fixes the debug check to not be done when we just ran a KVM
guest or when the sleep didn't happen because of a pending event in
irq_happened.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

powerpc: Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8"

This reverts commit 9678cdaae939 ("Use the POWER8 Micro Partition
Prefetch Engine in KVM HV on POWER8") because the original commit had
multiple, partly self-cancelling bugs, that could cause occasional
memory corruption.

In fact the logmpp instruction was incorrectly using register r0 as the
source of the buffer address and operation code, and depending on what
was in r0, it would either do nothing or corrupt the 64k page pointed to
by r0.

The logmpp instruction encoding and the operation code definitions could
be corrected, but then there is the problem that there is no clearly
defined way to know when the hardware has finished writing to the
buffer.

The original commit attempted to work around this by aborting the
write-out before starting the prefetch, but this is ineffective in the
case where the virtual core is now executing on a different physical
core from the one where the write-out was initiated.

These problems plus advice from the hardware designers not to use the
function (since the measured performance improvement from using the
feature was actually mostly negative), mean that reverting the code is
the best option.

Fixes: 9678cdaae939 ("Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8")
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

iommu/amd: Don't clear DTE flags when modifying it

During device assignment/deassignment the flags in the DTE
get lost, which might cause spurious faults, for example
when the device tries to access the system management range.
Fix this by not clearing the flags with the rest of the DTE.

Reported-by: G. Richard Bellamy <rbellamy@pteradigm.com>
Tested-by: G. Richard Bellamy <rbellamy@pteradigm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>

mmc: core: Fix init_card in 52Mhz

Suppose that we got a data crc error, and it triggers the mmc_reset.
mmc_reset will call mmc_send_status to see if HW reset was supported.
before issue CMD13, it will do retune, and if EMMC was in HS400 mode,
it will reduce frequency to 52Mhz firstly, then results in card init
was doing at 52Mhz.
The mmc_send_status was originally only done for mmc_test, should drop
it. And, rename the "eMMC hardware reset" to "Reset test", as we would
also be able to use the test for SD-cards.

Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>