cifs: always update the inode cache with the results from a FIND_*

When we get back a FIND_FIRST/NEXT result, we have some info about the
dentry that we use to instantiate a new inode. We were ignoring and
discarding that info when we had an existing dentry in the cache.

Fix this by updating the inode in place when we find an existing dentry
and the uniqueid is the same.

Cc: <stable@vger.kernel.org> # .31.x
Reported-and-Tested-by: Andrew Bartlett <abartlet@samba.org>
Reported-by: Bill Robertson <bill_robertson@debortoli.com.au>
Reported-by: Dion Edwards <dion_edwards@debortoli.com.au>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>

cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps

Jian found that when he ran fsx on a 32 bit arch with a large wsize the
process and one of the bdi writeback kthreads would sometimes deadlock
with a stack trace like this:

crash> bt
PID: 2789   TASK: f02edaa0  CPU: 3   COMMAND: "fsx"
 #0 [eed63cbc] schedule at c083c5b3
 #1 [eed63d80] kmap_high at c0500ec8
 #2 [eed63db0] cifs_async_writev at f7fabcd7 [cifs]
 #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs]
 #4 [eed63e50] do_writepages at c04f3e32
 #5 [eed63e54] __filemap_fdatawrite_range at c04e152a
 #6 [eed63ea4] filemap_fdatawrite at c04e1b3e
 #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs]
 #8 [eed63ecc] do_sync_write at c052d202
 #9 [eed63f74] vfs_write at c052d4ee
#10 [eed63f94] sys_write at c052df4c
#11 [eed63fb0] ia32_sysenter_target at c0409a98
    EAX: 00000004  EBX: 00000003  ECX: abd73b73  EDX: 012a65c6
    DS:  007b      ESI: 012a65c6  ES:  007b      EDI: 00000000
    SS:  007b      ESP: bf8db178  EBP: bf8db1f8  GS:  0033
    CS:  0073      EIP: 40000424  ERR: 00000004  EFLAGS: 00000246

Each task would kmap part of its address array before getting stuck, but
not enough to actually issue the write.

This patch fixes this by serializing the marshal_iov operations for
async reads and writes. The idea here is to ensure that cifs
aggressively tries to populate a request before attempting to fulfill
another one. As soon as all of the pages are kmapped for a request, then
we can unlock and allow another one to proceed.

There's no need to do this serialization on non-CONFIG_HIGHMEM arches
however, so optimize all of this out when CONFIG_HIGHMEM isn't set.

Cc: <stable@vger.kernel.org>
Reported-by: Jian Li <jiali@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>

cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space

We currently rely on being able to kmap all of the pages in an async
read or write request. If you're on a machine that has CONFIG_HIGHMEM
set then that kmap space is limited, sometimes to as low as 512 slots.

With 512 slots, we can only support up to a 2M r/wsize, and that's
assuming that we can get our greedy little hands on all of them. There
are other users however, so it's possible we'll end up stuck with a
size that large.

Since we can't handle a rsize or wsize larger than that currently, cap
those options at the number of kmap slots we have. We could consider
capping it even lower, but we currently default to a max of 1M. Might as
well allow those luddites on 32 bit arches enough rope to hang
themselves.

A more robust fix would be to teach the send and receive routines how
to contend with an array of pages so we don't need to marshal up a kvec
array at all. That's a fairly significant overhaul though, so we'll need
this limit in place until that's ready.

Cc: <stable@vger.kernel.org>
Reported-by: Jian Li <jiali@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>

Initialise mid_q_entry before putting it on the pending queue

A user reported a crash in cifs_demultiplex_thread() caused by an
incorrectly set mid_q_entry->callback() function. It appears that the
callback assignment made in cifs_call_async() was not flushed back to
memory suggesting that a memory barrier was required here. Changing the
code to make sure that the mid_q_entry structure was completely
initialised before it was added to the pending queue fixes the problem.

Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <smfrench@gmail.com>

Merge tag 'fixes-for-v3.5' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "Yes, this is a *LATE* GPIO pull request with fixes for v3.5.

  Grant moved across the planet and accidentally fell off the grid, so
  he asked me to take over the GPIO merges for a while 10 days ago.

  Since then I went over the archives and collected this pile of fixes,
  and pulled two of them from the TI maintainer Kevin Hilman.  Then
  waited for them to at least hit linux-next once or twice."

GPIO fixes for v3.5:
 - Invalid context restore on bank 0 for OMAP driver in runtime
   suspend/resume cycle
 - Check for NULL platform data in sta-2x11 driver
 - Constrain selection of the V1 MSM GPIO driver to applicable platforms
   (Kconfig issue)
 - Make sure the correct output value is set in the wm8994 driver
 - Export devm_gpio_request_one() so it can be used in modules.
   Apparently some in-kernel modules can be configured to use this
   leading to breakage.
 - Check that the GPIO is valid in the lantiq driver
 - Fix the flag bits introduced for v3.5, so they don't overlap
 - Fix a device tree intialization bug for imx21-compatible devices
 - Carry over the OF node to the TPS65910 GPIO chip struct

* tag 'fixes-for-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: tps65910: initialize of_node of gpio_chip
  gpio/mxc: make irqs work for fsl,imx21-gpio devices
  gpio: fix bits conflict for gpio flags
  mips: pci-lantiq: Fix check for valid gpio
  gpio: export devm_gpio_request_one
  gpiolib: wm8994: Pay attention to the value set when enabling as output
  gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs
  gpio-sta2x11: don't use pdata if null
  gpio/omap: fix invalid context restore of gpio bank-0
  gpio/omap: fix irq loss while in idle with debounce on

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fixes from Benjamin Herrenschmidt:
 "It looks like my rewrite of our lazy irq scheme is still exposing
  "interesting" issues left and right.  The previous fixes are now
  causing an occasional BUG_ON to trigger (which this patch turns into a
  WARN_ON while at it), due to another issue of disconnect of the lazy
  irq state vs the processor state in the idle loop on pseries and
  cell.

  This should fix it properly once for all moving the nasty code to a
  common helper function.

  There's also couple more fixes for some debug stuff that didn't build
  (and helped resolving those problems so it's worth having), along with
  a compile fix for newer gcc's."

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  tty/hvc_opal: Fix debug function name
  powerpc/numa: Avoid stupid uninitialized warning from gcc
  powerpc: Fix build of some debug irq code
  powerpc: More fixes for lazy IRQ vs. idle

Revert "of: match by compatible property first"

This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6.

Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100
and Sun Netra X1 sparc64 machines from booting, hanging after enabling
serial console.  He bisected it to commit 107a84e61cdd.

Rob Herring explains:
 "The problem is match combinations of compatible plus name and/or type
  fail to match correctly.  I have a fix for this, but given how late it
  is for 3.5 I think it is best to revert this for now.  There could be
  other cases that rely on the current although wrong behavior.  I will
  post an updated version for 3.6."

Bisected-and-reported-by: Meelis Roos <mroos@linux.ee>
Requested-by: Rob Herring <rob.herring@calxeda.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

tty/hvc_opal: Fix debug function name

udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as
the caller in arch/powerpc/kernel/udbg.c expects

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/numa: Avoid stupid uninitialized warning from gcc

Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc: Fix build of some debug irq code

There was a typo, checking for CONFIG_TRACE_IRQFLAG instead of
CONFIG_TRACE_IRQFLAGS causing some useful debug code to not be
built

This in turns causes a build error on BookE 64-bit due to incorrect
semicolons at the end of a couple of macros, so let's fix that too

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]

powerpc: More fixes for lazy IRQ vs. idle

Looks like we still have issues with pSeries and Cell idle code
vs. the lazy irq state. In fact, the reset fixes that went upstream
are exposing the problem more by causing BUG_ON() to trigger (which
this patch turns into a WARN_ON instead).

We need to be careful when using a variant of low power state that
has the side effect of turning interrupts back on, to properly set
all the SW & lazy state to look as if everything is enabled before
we enter the low power state with MSR:EE off as we will return with
MSR:EE on. If not, we have a discrepancy of state which can cause
things to go very wrong later on.

This patch moves the logic into a helper and uses it from the
pseries and cell idle code. The power4/970 idle code already got
things right (in assembly even !) so I'm not touching it. The power7
"bare metal" idle code is subtly different and correct. Remains PA6T
and some hypervisor based Cell platforms which have questionable
code in there, but they are mostly dead platforms so I'll fix them
when I manage to get final answers from the respective maintainers
about how the low power state actually works on them.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@vger.kernel.org [v3.4]

Merge tag 'regulator-3.5' of git://git./linux/kernel/git/broonie/regulator

Pull regulator fix from Mark Brown:
 "A smallish fix for a lock dependency issue which affects a bunch of
  Qualcomm boards that do unusually complicated things with their
  regulators, the API is unlikely to be called by any other system."

* tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Fix recursive mutex lockdep warning

gspca_sn9c20x: Fix NULL pointer dereference

Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question
does not have.

Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ Taken directly, since Mauro is on vacation ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

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

Pull minor virtio-balloon fix from Rusty Russell:
 "Theoretical fix, which greatly simplifies upcoming balloon patches
  which will go in via some vm tree."

* tag 'virtio-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
  virtio-balloon: fix add/get API use

Merge tag 'rpmsg-3.5-fixes' of git://git./linux/kernel/git/ohad/rpmsg

Pull rpmsg fixes from Ohad Ben-Cohen:
 "Fixing two (somewhat rare) endpoint-related race issues, both of which
  were reported by Fernando Guzman Lugo."

* tag 'rpmsg-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg:
  rpmsg: make sure inflight messages don't invoke just-removed callbacks
  rpmsg: avoid premature deallocation of endpoints

Merge tag 'remoteproc-3.5-fixes' of git://git./linux/kernel/git/ohad/remoteproc

Pull remoteproc fixes from Ohad Ben-Cohen:
 "Two build-related remoteproc fixes for 3.5."

* tag 'remoteproc-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
  remoteproc: fix missing CONFIG_FW_LOADER configurations
  remoteproc/omap: fix randconfig unmet direct dependencies

Merge tag 'hwspinlock-3.5-fixes' of git://git./linux/kernel/git/ohad/hwspinlock

Pull hwspinlock fix from Ohad Ben-Cohen:
 "A single hwspinlock core fix for multiple hwspinlock devices
  scenarios, from Shinya Kuribayashi."

* tag 'hwspinlock-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock:
  hwspinlock/core: use global ID to register hwspinlocks on multiple devices

Merge branch 'kevin' into fixes

Merge tag 'iommu-fixes-v3.5-rc5' of git://git./linux/kernel/git/joro/iommu

Pull IOMMU fixes from Joerg Roedel:
 "The patches fix several issues in the AMD IOMMU driver, the NVidia
  SMMU driver, and the DMA debug code.

  The most important fix for the AMD IOMMU solves a problem with SR-IOV
  devices where virtual functions did not work with IOMMU enabled.  The
  NVidia SMMU patch fixes a possible sleep while spin-lock situation
  (queued the small fix for v3.5, a better but more intrusive fix is
  coming for v3.6).  The DMA debug patches fix a possible data
  corruption issue due to bool vs u32 usage."

* tag 'iommu-fixes-v3.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: fix type bug in flush code
  dma-debug: debugfs_create_bool() takes a u32 pointer
  iommu/tegra: smmu: Fix unsleepable memory allocation
  iommu/amd: Initialize dma_ops for hotplug and sriov devices
  iommu/amd: Fix missing iommu_shutdown initialization in passthrough mode

virtio-balloon: fix add/get API use

Since ee7cd8981e15bcb365fc762afe3fc47b8242f630 'virtio: expose added
descriptors immediately.', in virtio balloon virtqueue_get_buf might
now run concurrently with virtqueue_kick.  I audited both and this
seems safe in practice but this is not guaranteed by the API.
Additionally, a spurious interrupt might in theory make
virtqueue_get_buf run in parallel with virtqueue_add_buf, which is
racy.

While we might try to protect against spurious callbacks it's
easier to fix the driver: balloon seems to be the only one
(mis)using the API like this, so let's just fix balloon.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (removed unused var)

Merge branch 'for-3.5-fixes' of git://git./linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:
 "The previous cgroup pull request contained a patch to fix a race
  condition during cgroup hierarchy umount.  Unfortunately, while the
  patch reduced the race window such that the test case I and Sasha were
  using didn't trigger it anymore, it wasn't complete - Shyju and Li
  could reliably trigger the race condition using a different test case.

  The problem wasn't the gap between dentry deletion and release which
  the previous patch tried to fix.  The window was between the last
  dput() of a root's child and the resulting dput() of the root.  For
  cgroup dentries, the deletion and release always happen synchronously.
  As this releases the s_active ref, the refcnt of the root dentry,
  which doesn't hold s_active, stays above zero without the
  corresponding s_active.  If umount was in progress, the last
  deactivate_super() proceeds to destory the superblock and triggers
  BUG() on the non-zero root dentry refcnt after shrinking.

  This issue surfaced because cgroup dentries are now allowed to linger
  after rmdir(2) since 3.5-rc1.  Before, rmdir synchronously drained the
  dentry refcnt and the s_active acquired by rmdir from vfs layer
  protected the whole thing.  After 3.5-rc1, cgroup may internally hold
  and put dentry refs after rmdir finishes and the delayed dput()
  doesn't have surrounding s_active ref exposing this issue.

  This pull request contains two patches - one reverting the previous
  incorrect fix and the other adding the surrounding s_active ref around
  the delayed dput().

  This is quite late in the release cycle but the change is on the safer
  side and fixes the test cases reliably, so I don't think it's too
  crazy."

* 'for-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: fix cgroup hierarchy umount race
  Revert "cgroup: superblock can't be released with active dentries"

Linux 3.5-rc6

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/linux-security

Pull security docs update from James Morris.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  security: Minor improvements to no_new_privs documentation

vfs: make O_PATH file descriptors usable for 'fchdir()'

We already use them for openat() and friends, but fchdir() also wants to
be able to use O_PATH file descriptors.  This should make it comparable
to the O_SEARCH of Solaris.  In particular, O_PATH allows you to access
(not-quite-open) a directory you don't have read persmission to, only
execute permission.

Noticed during development of multithread support for ksh93.

Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # O_PATH introduced in 3.0+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cgroup: fix cgroup hierarchy umount race

48ddbe1946 "cgroup: make css->refcnt clearing on cgroup removal
optional" allowed a css to linger after the associated cgroup is
removed.  As a css holds a reference on the cgroup's dentry, it means
that cgroup dentries may linger for a while.

Destroying a superblock which has dentries with positive refcnts is a
critical bug and triggers BUG() in vfs code.  As each cgroup dentry
holds an s_active reference, any lingering cgroup has both its dentry
and the superblock pinned and thus preventing premature release of
superblock.

Unfortunately, after 48ddbe1946, there's a small window while
releasing a cgroup which is directly under the root of the hierarchy.
When a cgroup directory is released, vfs layer first deletes the
corresponding dentry and then invokes dput() on the parent, which may
recurse further, so when a cgroup directly below root cgroup is
released, the cgroup is first destroyed - which releases the s_active
it was holding - and then the dentry for the root cgroup is dput().

This creates a window where the root dentry's refcnt isn't zero but
superblock's s_active is.  If umount happens before or during this
window, vfs will see the root dentry with non-zero refcnt and trigger
BUG().

Before 48ddbe1946, this problem didn't exist because the last dentry
reference was guaranteed to be put synchronously from rmdir(2)
invocation which holds s_active around the whole process.

Fix it by holding an extra superblock->s_active reference across
dput() from css release, which is the dput() path added by 48ddbe1946
and the only one which doesn't hold an extra s_active ref across the
final cgroup dput().

Signed-off-by: Tejun Heo <tj@kernel.org>
LKML-Reference: <4FEEA5CB.8070809@huawei.com>
Reported-by: shyju pv <shyju.pv@huawei.com>
Tested-by: shyju pv <shyju.pv@huawei.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Li Zefan <lizefan@huawei.com>

Revert "cgroup: superblock can't be released with active dentries"

This reverts commit fa980ca87d15bb8a1317853f257a505990f3ffde.  The
commit was an attempt to fix a race condition where a cgroup hierarchy
may be unmounted with positive dentry reference on root cgroup.  While
the commit made the race condition slightly more difficult to trigger,
the race was still there and could be reliably triggered using a
different test case.

Revert the incorrect fix.  The next commit will describe the race and
fix it correctly.

Signed-off-by: Tejun Heo <tj@kernel.org>
LKML-Reference: <4FEEA5CB.8070809@huawei.com>
Reported-by: shyju pv <shyju.pv@huawei.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Li Zefan <lizefan@huawei.com>

hwspinlock/core: use global ID to register hwspinlocks on multiple devices

Commit 300bab9770 (hwspinlock/core: register a bank of hwspinlocks in a
single API call, 2011-09-06) introduced 'hwspin_lock_register_single()'
to register numerous (a bank of) hwspinlock instances in a single API,
'hwspin_lock_register()'.

At which time, 'hwspin_lock_register()' accidentally passes 'local IDs'
to 'hwspin_lock_register_single()', despite that ..._single() requires
'global IDs' to register hwspinlocks.

We have to convert into global IDs by supplying the missing 'base_id'.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
[ohad: fix error path of hwspin_lock_register, too]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

Pull ARM fixes from Russell King:
 "Last merge window, we had some updates from Al cleaning up the signal
  restart handling.  These have caused some problems on ARM, and while
  Al has some fixes, we have some concerns with Al's patches but we've
  been unsuccesful with discussing this.

  We have got to the point where we need to do something, and we've
  decided that the best solution is to revert the appropriate commits
  until Al is able to reply to us.

  Also included here are four patches to fix warnings that I've noticed
  in my build system, and one fix for kprobes test code."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: fix warning caused by wrongly typed arm_dma_limit
  ARM: fix warnings about atomic64_read
  ARM: 7440/1: kprobes: only test 'sub pc, pc, #1b-2b+8-2' on ARMv6
  ARM: 7441/1: perf: return -EOPNOTSUPP if requested mode exclusion is unavailable
  ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"
  ARM: 7442/1: Revert "remove unused restart trampoline"
  ARM: fix set_domain() macro
  ARM: fix mach-versatile/pci.c warning

security: Minor improvements to no_new_privs documentation

The documentation didn't actually mention how to enable no_new_privs.
This also adds a note about possible interactions between
no_new_privs and LSMs (i.e. why teaching systemd to set no_new_privs
is not necessarily a good idea), and it references the new docs
from include/linux/prctl.h.

Suggested-by: Rob Landley <rob@landley.net>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>

Merge tag 'ecryptfs-3.5-rc6-fixes' of git://git./linux/kernel/git/tyhicks/ecryptfs

Pull eCryptfs fixes from Tyler Hicks:
 "Fixes an incorrect access mode check when preparing to open a file in
  the lower filesystem.  This isn't an urgent fix, but it is simple and
  the check was obviously incorrect.

  Also fixes a couple important bugs in the eCryptfs miscdev interface.
  These changes are low risk due to the small number of users that use
  the miscdev interface.  I was able to keep the changes minimal and I
  have some cleaner, more complete changes queued up for the next merge
  window that will build on these patches."

* tag 'ecryptfs-3.5-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files
  eCryptfs: Fix lockdep warning in miscdev operations
  eCryptfs: Properly check for O_RDONLY flag before doing privileged open

Merge git://git./linux/kernel/git/nab/target-pending

Pull target fixes from Nicholas Bellinger:
 "Two minor target fixes.  There is really nothing exciting and/or
  controversial this time around.

  There's one fix from MDR for a RCU debug warning message within tcm_fc
  code (CC'ed to stable), and a small AC fix for qla_target.c based upon
  a recent Coverity static report.

  Also, there is one other outstanding virtio-scsi LUN scanning bugfix
  that has been uncovered with the in-flight tcm_vhost driver over the
  last days, and that needs to make it into 3.5 final too.  This patch
  has been posted to linux-scsi again here:

    http://marc.info/?l=linux-scsi&m=134160609212542&w=2

  and I've asked James to include it in his next PULL request."

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  qla2xxx: print the right array elements in qlt_async_event
  tcm_fc: Resolve suspicious RCU usage warnings

eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files

File operations on /dev/ecryptfs would BUG() when the operations were
performed by processes other than the process that originally opened the
file. This could happen with open files inherited after fork() or file
descriptors passed through IPC mechanisms. Rather than calling BUG(), an
error code can be safely returned in most situations.

In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
release even if the last file reference is being held by a process that
didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
be successful, so a pointer to the daemon is stored in the file's
private_data. The private_data pointer is initialized when the miscdev
file is opened and only used when the file is released.

https://launchpad.net/bugs/994247

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>

qla2xxx: print the right array elements in qlt_async_event

Based upon Alan's patch from Coverity scan id 793583, these debug
messages in qlt_async_event() should be starting from byte 0, which is
always the Asynchronous Event Status Code from the parent switch statement.

Also, rename reason_code -> login_code following the language used in
2500 FW spec for Port Database Changed (0x8014) -> Port Database Changed
Event Mailbox Register for mailbox[2].

Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Chad Dupuis <chad.dupuis@qlogic.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

tcm_fc: Resolve suspicious RCU usage warnings

Use rcu_dereference_protected to tell rcu that the ft_lport_lock
is held during ft_lport_create. This resolved "suspicious RCU usage"
warnings when debugging options are turned on.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

Merge tag 'for-linus-20120706' of git://git.infradead.org/linux-mtd

Pull two MTD fixes from David Woodhouse:
 - Fix a logic error in OLPC CAFÉ NAND ready() function.
 - Fix regression due to bitflip handling changes.

* tag 'for-linus-20120706' of git://git.infradead.org/linux-mtd:
  mtd: cafe_nand: fix an & vs | mistake
  mtd: nand: initialize bitflip_threshold prior to BBT scanning

mm: Hold a file reference in madvise_remove

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'fixes' of git://git./linux/kernel/git/jlbec/ocfs2

Pull ocfs2 fixes from Joel Becker.

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
  aio: make kiocb->private NUll in init_sync_kiocb()
  ocfs2: Fix bogus error message from ocfs2_global_read_info
  ocfs2: for SEEK_DATA/SEEK_HOLE, return internal error unchanged if ocfs2_get_clusters_nocache() or ocfs2_inode_lock() call failed.
  ocfs2: use spinlock irqsave for downconvert lock.patch
  ocfs2: Misplaced parens in unlikley
  ocfs2: clear unaligned io flag when dio fails

Merge git://git.samba.org/sfrench/cifs-2.6

Pull cifs fixes from Steve French.

* git://git.samba.org/sfrench/cifs-2.6:
  cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize
  cifs: fix parsing of password mount option

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input layer fixes from Dmitry Torokhov:
 "Two fixes for regressions in Wacom driver and fixes for drivers using
  threaded IRQ framework without specifying IRQF_ONESHOT."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: request threaded-only IRQs with IRQF_ONESHOT
  Input: wacom - don't retrieve touch_max when it is predefined
  Input: wacom - fix retrieving touch_max bug
  Input: fix input.h kernel-doc warning

mtd: cafe_nand: fix an & vs | mistake

The intent here was clearly to set result to true if the 0x40000000 flag
was set.  But instead there was a | vs & typo and we always set result
to true.

Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

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

Pull ARM SoC fixes from Arnd Bergmann:
 "Small fixes on multiple ARM platforms
   - A build regression from a previous fix on dove and mv78xx0
   - Two fixes for recently (3.5-rc1) changed mmp/pxa code
   - multiple omap2+ bug fixes
   - two trivial fixes for i.MX
   - one v3.5 regression for mxs"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: apx4devkit: fix FEC enabling PHY clock
  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
  ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks
  ARM: Orion: Fix WDT compile for Dove and MV78xx0
  ARM: mmp: remove mach/gpio-pxa.h
  ARM: imx: assert SCC gate stays enabled
  ARM: OMAP4: TWL6030: ensure sys_nirq1 is mux'd and wakeup enabled
  ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume failure
  ARM: imx27_visstrim_m10: Do not include <asm/system.h>
  ARM: pxa: hx4700: Fix basic suspend/resume

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull KVM fix from Marcelo Tosatti:
 "Memory leak and oops on the x86 mmu code, and sanitization of the
  KVM_IRQFD ioctl."

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: MMU: fix shrinking page from the empty mmu
  KVM: fix fault page leak
  KVM: Sanitize KVM_IRQFD flags
  KVM: Add missing KVM_IRQFD API documentation
  KVM: Pass kvm_irqfd to functions

Merge branch 'fixes-for-3.5' of git://git./linux/kernel/git/cooloney/linux-leds

Pull leds fix from Bryan Wu:
 "Fix for heartbeat led trigger driver"

* 'fixes-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
  leds: heartbeat: fix bug on panic

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

Pull btrfs updates from Chris Mason:
 "I held off on my rc5 pull because I hit an oops during log recovery
  after a crash.  I wanted to make sure it wasn't a regression because
  we have some logging fixes in here.

  It turns out that a commit during the merge window just made it much
  more likely to trigger directory logging instead of full commits,
  which exposed an old bug.

  The new backref walking code got some additional fixes.  This should
  be the final set of them.

  Josef fixed up a corner where our O_DIRECT writes and buffered reads
  could expose old file contents (not stale, just not the most recent).
  He and Liu Bo fixed crashes during tree log recover as well.

  Ilya fixed errors while we resume disk balancing operations on
  readonly mounts."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: run delayed directory updates during log replay
  Btrfs: hold a ref on the inode during writepages
  Btrfs: fix tree log remove space corner case
  Btrfs: fix wrong check during log recovery
  Btrfs: use _IOR for BTRFS_IOC_SUBVOL_GETFLAGS
  Btrfs: resume balance on rw (re)mounts properly
  Btrfs: restore restriper state on all mounts
  Btrfs: fix dio write vs buffered read race
  Btrfs: don't count I/O statistic read errors for missing devices
  Btrfs: resolve tree mod log locking issue in btrfs_next_leaf
  Btrfs: fix tree mod log rewind of ADD operations
  Btrfs: leave critical region in btrfs_find_all_roots as soon as possible
  Btrfs: always put insert_ptr modifications into the tree mod log
  Btrfs: fix tree mod log for root replacements at leaf level
  Btrfs: support root level changes in __resolve_indirect_ref
  Btrfs: avoid waiting for delayed refs when we must not

Merge branch 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux

Pull DT fixes from Rob Herring:
 "Mainly some documentation updates and 2 fixes:

   - An export symbol fix for of_platform_populate from Stephen W.
   - A fix for the order compatible entries are matched to ensure the
     first compatible string is matched when there are multiple matches."

Normally these would go through Grant Likely (thus the "fixes-for-grant"
branch name), but Grant is in the middle of moving to Scotland, and is
practically offline until sometime in August. So pull directly from Rob.

* 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux:
  of: match by compatible property first
  dt: mc13xxx.txt: Fix gpio number assignment
  dt: fsl-fec.txt: Fix gpio number assignment
  dt: fsl-mma8450.txt: Add missing 'reg' description
  dt: fsl-imx-esdhc.txt: Fix gpio number assignment
  dt: fsl-imx-cspi.txt: Fix comment about GPIOs used for chip selects
  of: Add Avionic Design vendor prefix
  of: export of_platform_populate()

gpio: tps65910: initialize of_node of gpio_chip

Initialize the gpio chip's of_node to the device's node
to work with DT based system.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/mxc: make irqs work for fsl,imx21-gpio devices

The chained handler was set for the platform device with id == 0.
When the gpio devices are instantiated by a device tree, all have id ==
-1 and so the handler was unset resulting in unusable gpio irqs on
i.MX21 and i.MX27 (when using oftree).

Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: fix bits conflict for gpio flags

The bit 2 and 3 in GPIO flag are allocated for the
flag OPEN_DRAIN/OPEN_SOURCE. These bits are reused
for the flag EXPORT/EXPORT_CHANGEABLE and so creating
conflict.
Fix this conflict by assigning bit 4 and 5 for the
flag EXPORT/EXPORT_CHANGEABLE.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

mips: pci-lantiq: Fix check for valid gpio

This patch fixes two checks for valid gpio number, formerly (wrongly)
considering zero as invalid, now using gpio_is_valid().

Signed-off-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio: export devm_gpio_request_one

Without this, modules can't use this API, leading to build failures.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpiolib: wm8994: Pay attention to the value set when enabling as output

Not paying attention to the value being set is a bad thing because it
means that we'll not set the hardware up to reflect what was requested.
Not setting the hardware up to reflect what was requested means that the
caller won't get the results they wanted.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs

The feature GPIO_MSM_V1 is only available on three SoCs. On all other MSM SoCs
the INT_GPIO_GROUP{1,2} is undeclared, but Kconfig does allow such
configurations. Therefore the produced configuration is valid, but does not
compile. The problem is fixed by adding the missing Kconfig constraints.

drivers/gpio/gpio-msm-v1.c: In function â\80\98msm_init_gpioâ\80\99:
drivers/gpio/gpio-msm-v1.c:629:26: error: 'INT_GPIO_GROUP1' undeclared
drivers/gpio/gpio-msm-v1.c:630:26: error: 'INT_GPIO_GROUP2' undeclared

Signed-off-by: Christian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

gpio-sta2x11: don't use pdata if null

If there is no platform data available, the driver shouldn't use the
pointer or it will oops.  Since things will mostly work nonetheless,
(the BIOS may have set up the pins properly), I'd better not fail the
probe even in this case.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

ARM: fix warning caused by wrongly typed arm_dma_limit

arch/arm/mm/init.c: In function 'arm_memblock_init':
arch/arm/mm/init.c:380: warning: comparison of distinct pointer types lacks a cast

by fixing the typecast in its definition when DMA_ZONE is disabled.
This was missed in 4986e5c7c (ARM: mm: fix type of the arm_dma_limit
global variable).

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: fix warnings about atomic64_read

Fix:
net/netfilter/xt_connbytes.c: In function 'connbytes_mt':
net/netfilter/xt_connbytes.c:43: warning: passing argument 1 of 'atomic64_read' discards qualifiers from pointer target type
...

by adding the missing const.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7440/1: kprobes: only test 'sub pc, pc, #1b-2b+8-2' on ARMv6

'sub pc, pc, #1b-2b+8-2' results in address<1:0> == '10'.

sub pc, pc, #const (== ADR pc, #const) performs an interworking branch
(BXWritePC()) on ARMv7+ and a simple branch (BranchWritePC()) on earlier
versions.

In ARM state, BXWritePC() is UNPREDICTABLE when address<1:0> == '10'.

In ARM state on ARMv6+, BranchWritePC() ignores address<1:0>.  Before
ARMv6, BranchWritePC() is UNPREDICTABLE if address<1:0> != '00'

So the instruction is UNPREDICTABLE both before and after v6.

Acked-by: Jon Medhurst <tixy@yxit.co.uk>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Merge tag 'omap-fixes-for-v3.5-rc5' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

PM related fixes for omaps mostly to get suspend/resume
working again.

* tag 'omap-fixes-for-v3.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4
  ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks
  ARM: OMAP4: TWL6030: ensure sys_nirq1 is mux'd and wakeup enabled
  ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume failure

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge branch 'mxs/fixes-for-3.5' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

* 'mxs/fixes-for-3.5' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: apx4devkit: fix FEC enabling PHY clock

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

ARM: 7441/1: perf: return -EOPNOTSUPP if requested mode exclusion is unavailable

We currently return -EPERM if the user requests mode exclusion that is
not supported by the CPU. This looks pretty confusing from userspace
and is inconsistent with other architectures (ppc, x86).

This patch returns -EOPNOTSUPP instead.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"

This reverts commit 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252.

Conflicts:

arch/arm/kernel/ptrace.c

The new syscall restarting code can lead to problems if we take an
interrupt in userspace just before restarting the svc instruction. If
a signal is delivered when returning from the interrupt, the
TIF_SYSCALL_RESTARTSYS will remain set and cause any syscalls executed
from the signal handler to be treated as a restart of the previously
interrupted system call. This includes the final sigreturn call, meaning
that we may fail to exit from the signal context. Furthermore, if a
system call made from the signal handler requires a restart via the
restart_block, it is possible to clear the thread flag and fail to
restart the originally interrupted system call.

The right solution to this problem is to perform the restarting in the
kernel, avoiding the possibility of handling a further signal before the
restart is complete. Since we're almost at -rc6, let's revert the new
method for now and aim for in-kernel restarting at a later date.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7442/1: Revert "remove unused restart trampoline"

This reverts commit fa18484d0947b976a769d15c83c50617493c81c1.

We need the restart trampoline back so that we can revert a related
problematic patch 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252 ("arm: new
way of handling ERESTART_RESTARTBLOCK").

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: fix set_domain() macro

Avoid polluting drivers with a set_domain() macro, which interferes with
structure member names:

drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c:294:33: error: macro "set_domain" passed 2 arguments, but takes just 1

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

aio: make kiocb->private NUll in init_sync_kiocb()

Ocfs2 uses kiocb.*private as a flag of unsigned long size. In
commit a11f7e6 ocfs2: serialize unaligned aio, the unaligned
io flag is involved in it to serialize the unaligned aio. As
*private is not initialized in init_sync_kiocb() of do_sync_write(),
this unaligned io flag may be unexpectly set in an aligned dio.
And this will cause OCFS2_I(inode)->ip_unaligned_aio decreased
to -1 in ocfs2_dio_end_io(), thus the following unaligned dio
will hang forever at ocfs2_aiodio_wait() in ocfs2_file_aio_write().

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: stable@vger.kernel.org
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

Merge tag 'omap-fixes-b-for-3.5rc' of git://git./linux/kernel/git/pjw/omap-pending into fixes

A few more OMAP fixes for 3.5-rc.  These fix some bugs with power
management and McBSP.

ARM: apx4devkit: fix FEC enabling PHY clock

Ethernet stopped to work after mxs clk framework change.

Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

Input: request threaded-only IRQs with IRQF_ONESHOT

Since commit 1c6c69525b ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail. This patch adds the
IRQF_ONESHOT to input drivers where it is missing. Not modified by
this patch are those drivers where the requested IRQ will always be a
nested IRQ (e.g. because it's part of an MFD), since for this special
case IRQF_ONESHOT is not required to be specified when requesting the
IRQ.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

ARM: fix mach-versatile/pci.c warning

arch/arm/mach-versatile/pci.c: In function 'versatile_map_irq':
arch/arm/mach-versatile/pci.c:342: warning: unused variable 'devslot'

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4

The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb
  ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks

added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using "prcm_fck".

It thus lead to the following warning.

[   47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck

Fix that by changing the opt_clk role to prcm_fck.

Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks

The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle.  Without this programming, they
will prevent the rest of the chip from entering full chip idle.

To implement the idle programming cleanly, this will take some
coordination between maintainers.  This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7.  So, in the
meantime, prevent these IP blocks from being registered.

Later, once the appropriate support is available, this patch can be
reverted.

This second version comments out the IP block data since Benoît didn't
like removing it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Merge branch 'fixes' of git://github.com/hzhuang1/linux into fixes

From Haojian Zhuang <haojian.zhuang@gmail.com>:

* 'fixes' of git://github.com/hzhuang1/linux:
  ARM: mmp: remove mach/gpio-pxa.h

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6 into fixes

From Sascha Hauer <s.hauer@pengutronix.de>:

ARM i.MX fixes for v3.5-rc5

* tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6:
  ARM: imx: assert SCC gate stays enabled
  ARM: imx27_visstrim_m10: Do not include <asm/system.h>

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

rpmsg: make sure inflight messages don't invoke just-removed callbacks

When inbound messages arrive, rpmsg core looks up their associated
endpoint (by destination address) and then invokes their callback.

We've made sure that endpoints will never be de-allocated after they
were found by rpmsg core, but we also need to protect against the
(rare) scenario where the rpmsg driver was just removed, and its
callback function isn't available anymore.

This is achieved by introducing a callback mutex, which must be taken
before the callback is invoked, and, obviously, before it is removed.

Cc: stable <stable@vger.kernel.org>
Reported-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

rpmsg: avoid premature deallocation of endpoints

When an inbound message arrives, the rpmsg core looks up its
associated endpoint and invokes the registered callback.

If a message arrives while its endpoint is being removed (because
the rpmsg driver was removed, or a recovery of a remote processor
has kicked in) we must ensure atomicity, i.e.:

- Either the ept is removed before it is found

or

- The ept is found but will not be freed until the callback returns

This is achieved by maintaining a per-ept reference count, which,
when drops to zero, will trigger deallocation of the ept.

With this in hand, it is now forbidden to directly deallocate
epts once they have been added to the endpoints idr.

Cc: stable <stable@vger.kernel.org>
Reported-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

ARM: Orion: Fix WDT compile for Dove and MV78xx0

Commit 0fa1f0609a0c1fe8b2be3c0089a2cb48f7fda521 (ARM: Orion: Fix
Virtual/Physical mixup with watchdog) broke the Dove & MV78xx0
build. Although these two SoC don't use the watchdog, the shared
platform code still needs to build. Add the necessary defines.

Cc: stable@vger.kernel.org
Reported-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

remoteproc: fix missing CONFIG_FW_LOADER configurations

Remoteproc requires user space firmware loading support, so
let's select FW_LOADER explicitly to avoid painful misconfigurations
(which only show up in runtime).

Cc: stable <stable@vger.kernel.org>
Reported-by: Mark Grosen <mgrosen@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

ARM: mmp: remove mach/gpio-pxa.h

Commit 157d2644cb0c1e71a18baaffca56d2b1d0ebf10f ("ARM: pxa: change gpio
to platform device") removed all includes of mach/gpio-pxa.h. It kept
this unused header in the tree. Using it can't work, as it itself
includes the non-existent header plat/gpio-pxa.h. This header can safely
be removed.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>

leds: heartbeat: fix bug on panic

With commit 49dca5aebfdeadd4bf27b6cb4c60392147dc35a4 I introduced
a bug (visible if CONFIG_PROVE_RCU is enabled) which occures when a panic
has happened:

[ 1526.520230] ===============================
[ 1526.520230] [ INFO: suspicious RCU usage. ]
[ 1526.520230] 3.5.0-rc1+ #12 Not tainted
[ 1526.520230] -------------------------------
[ 1526.520230] /c/kernel-tests/mm/include/linux/rcupdate.h:436 Illegal context switch in RCU read-side critical section!
[ 1526.520230]
[ 1526.520230] other info that might help us debug this:
[ 1526.520230]
[ 1526.520230]
[ 1526.520230] rcu_scheduler_active = 1, debug_locks = 0
[ 1526.520230] 3 locks held by net.agent/3279:
[ 1526.520230]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff82f85962>] do_page_fault+0x193/0x390
[ 1526.520230]  #1:  (panic_lock){+.+...}, at: [<ffffffff82ed2830>] panic+0x37/0x1d3
[ 1526.520230]  #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff810b9b28>] rcu_lock_acquire+0x0/0x29
[ 1526.520230]
[ 1526.520230] stack backtrace:
[ 1526.520230] Pid: 3279, comm: net.agent Not tainted 3.5.0-rc1+ #12
[ 1526.520230] Call Trace:
[ 1526.520230]  [<ffffffff810e1570>] lockdep_rcu_suspicious+0x109/0x112
[ 1526.520230]  [<ffffffff810bfe3a>] rcu_preempt_sleep_check+0x45/0x47
[ 1526.520230]  [<ffffffff810bfe5a>] __might_sleep+0x1e/0x19a
[ 1526.520230]  [<ffffffff82f8010e>] down_write+0x26/0x81
[ 1526.520230]  [<ffffffff8276a966>] led_trigger_unregister+0x1f/0x9c
[ 1526.520230]  [<ffffffff8276def5>] heartbeat_reboot_notifier+0x15/0x19
[ 1526.520230]  [<ffffffff82f85bf5>] notifier_call_chain+0x96/0xcd
[ 1526.520230]  [<ffffffff82f85cba>] __atomic_notifier_call_chain+0x8e/0xff
[ 1526.520230]  [<ffffffff81094b7c>] ? kmsg_dump+0x37/0x1eb
[ 1526.520230]  [<ffffffff82f85d3f>] atomic_notifier_call_chain+0x14/0x16
[ 1526.520230]  [<ffffffff82ed28e1>] panic+0xe8/0x1d3
[ 1526.520230]  [<ffffffff811473e2>] out_of_memory+0x15d/0x1d3

So in case of a panic, now just turn of the LED. Other approaches like
scheduling a work to unregister the trigger aren't working because there
isn't much which still runs after a panic occured (except timers).

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>

remoteproc/omap: fix randconfig unmet direct dependencies

OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend
on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPERIMENTAL
too, in order to avoid the below randconfig warnings.

warning: (OMAP_REMOTEPROC) selects REMOTEPROC which has unmet direct dependencies (EXPERIMENTAL)
warning: (OMAP_REMOTEPROC) selects RPMSG which has unmet direct dependencies (EXPERIMENTAL)

Cc: stable <stable@vger.kernel.org>
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>

ARM: imx: assert SCC gate stays enabled

The SCC clock is needed in internal boot mode and so must keep enabled.
This same issue was fixed for the pre-common-clk code in commit

3d6e614 (mx35: Fix boot ROM hang in internal boot mode)

Cc: John Ogness <jogness@linutronix.de>
Cc: Hans J. Koch <hjk@hansjkoch.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ocfs2: Fix bogus error message from ocfs2_global_read_info

'status' variable in ocfs2_global_read_info() is always != 0 when leaving the
function because it happens to contain number of read bytes. Thus we always log
error message although everything is OK. Since all error cases properly call
mlog_errno() before jumping to out_err, there's no reason to call mlog_errno()
on exit at all. This is a fallout of c1e8d35e (conversion of mlog_exit()
calls).

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

ocfs2: for SEEK_DATA/SEEK_HOLE, return internal error unchanged if ocfs2_get_clusters_nocache() or ocfs2_inode_lock() call failed.

Hello,

Since ENXIO only means "offset beyond EOF" for SEEK_DATA/SEEK_HOLE,
Hence we should return the internal error unchanged if ocfs2_inode_lock() or
ocfs2_get_clusters_nocache() call failed rather than ENXIO.
Otherwise, it will confuse the user applications when they trying to understand the root cause.

Thanks Dave for pointing this out.

Thanks,
-Jeff

Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

ocfs2: use spinlock irqsave for downconvert lock.patch

When ocfs2dc thread holds dc_task_lock spinlock and receives soft IRQ it
deadlock itself trying to get same spinlock in ocfs2_wake_downconvert_thread.
Below is the stack snippet.

The patch disables interrupts when acquiring dc_task_lock spinlock.

ocfs2_wake_downconvert_thread
ocfs2_rw_unlock
ocfs2_dio_end_io
dio_complete
.....
bio_endio
req_bio_endio
....
scsi_io_completion
blk_done_softirq
__do_softirq
do_softirq
irq_exit
do_IRQ
ocfs2_downconvert_thread
[kthread]

Signed-off-by: Srinivas Eeda <srinivas.eeda@oracle.com>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

ocfs2: Misplaced parens in unlikley

Fix misplaced parentheses

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Joel Becker <jlbec@evilplan.org>

ocfs2: clear unaligned io flag when dio fails

The unaligned io flag is set in the kiocb when an unaligned
dio is issued, it should be cleared even when the dio fails,
or it may affect the following io which are using the same
kiocb.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Joel Becker <jlbec@evilplan.org>

Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux

Pull fix to common clk framework from Michael Turquette:
 "The previous set of common clk fixes for -rc5 left an uninitialized
  int which could lead to bad array indexing when switching clock
  parents.  The issue is fixed with a trivial change to the code flow in
  __clk_set_parent."

* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
  clk: fix parent validation in __clk_set_parent()

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

Pull raid10 build failure fix from NeilBrown:
 "I really shouldn't do important things late in the day.  It seems that
  I get careless."

* tag 'md-3.5-fixes' of git://neil.brown.name/md:
  md/raid10: fix careless build error

Merge git://git./linux/kernel/git/davem/net

Pull networking update from David Miller:

 1) Fix RX sequence number handling in mwifiex, from Stone Piao.

 2) Netfilter ipset mis-compares device names, fix from Florian
    Westphal.

 3) Fix route leak in ipv6 IPVS, from Eric Dumazet.

 4) NFS fixes.  Several buffer overflows in NCI layer from Dan
    Rosenberg, and release sock OOPS'er fix from Eric Dumazet.

 5) Fix WEP handling ath9k, we started using a bit the chip provides to
    indicate undecrypted packets but that bit turns out to be unreliable
    in certain configurations.  Fix from Felix Fietkau.

 6) Fix Kconfig dependency bug in wlcore, from Randy Dunlap.

 7) New USB IDs for rtlwifi driver from Larry Finger.

 8) Fix crashes in qmi_wwan usbnet driver when disconnecting, from Bjørn
    Mork.

 9) Gianfar driver programs coalescing settings properly in single queue
    mode, but does not do so in multi-queue mode.  Fix from Claudiu
    Manoil.

10) Missing module.h include in davinci_cpdma.c, from Daniel Mack.

11) Need dummy handler for IPSET_CMD_NONE otherwise we crash in ipset if
    we get this via nfnetlink, fix from Tomasz Bursztyka.

12) Missing RCU unlock in nfnetlink error path, also from Tomasz.

13) Fix divide by zero in igbvf when the user tries to set an RX
    coalescing value of 0 usecs, from Mitch A Williams.

14) We can process SCTP sacks for the wrong transport, oops.  Fix from
    Neil Horman.

15) Remove hw IP payload checksumming from e1000e driver.  This has zery
    value in our stack, and turning it on creates a very unintuitive
    restriction for users when using jumbo MTUs.

    Specifically, when IP payload checksums are on you cannot use both
    receive hashing offload and jumbo MTU.  Fix from Bruce Allan.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
  e1000e: remove use of IP payload checksum
  sctp: be more restrictive in transport selection on bundled sacks
  igbvf: fix divide by zero
  netfilter: nfnetlink: fix missing rcu_read_unlock in nfnetlink_rcv_msg
  netfilter: ipset: fix crash if IPSET_CMD_NONE command is sent
  davinci_cpdma: include linux/module.h
  gianfar: Fix RXICr/TXICr programming for multi-queue mode
  net: Downgrade CAP_SYS_MODULE deprecated message from error to warning.
  net: qmi_wwan: fix Oops while disconnecting
  mwifiex: fix memory leak associated with IE manamgement
  ath9k: fix panic caused by returning a descriptor we have queued for reuse
  mac80211: correct behaviour on unrecognised action frames
  ath9k: enable serialize_regmode for non-PCIE AR9287
  rtlwifi: rtl8192cu: New USB IDs
  NFC: Return from rawsock_release when sk is NULL
  iwlwifi: fix activating inactive stations
  wlcore: drop INET dependency
  ath9k: fix dynamic WEP related regression
  NFC: Prevent multiple buffer overflows in NCI
  netfilter: update location of my trees
  ...

md/raid10: fix careless build error

build error introduced by commit b357f04a67c2aeee8

That function doesn't get extra args until a later patch.  Bother.

Reported-by: Fengguang Wu <wfg@linux.intel.com>
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: NeilBrown <neilb@suse.de>

eCryptfs: Fix lockdep warning in miscdev operations

Don't grab the daemon mutex while holding the message context mutex.
Addresses this lockdep warning:

 ecryptfsd/2141 is trying to acquire lock:
  (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]

 but task is already holding lock:
  (&(*daemon)->mux){+.+...}, at: [<ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&(*daemon)->mux){+.+...}:
        [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
        [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
        [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
        [<ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
        [<ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
        [<ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
        [<ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
        [<ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs]
        [<ffffffff811963a4>] vfs_create+0xb4/0x120
        [<ffffffff81197865>] do_last+0x8c5/0xa10
        [<ffffffff811998f9>] path_openat+0xd9/0x460
        [<ffffffff81199da2>] do_filp_open+0x42/0xa0
        [<ffffffff81187998>] do_sys_open+0xf8/0x1d0
        [<ffffffff81187a91>] sys_open+0x21/0x30
        [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b

 -> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
        [<ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50
        [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
        [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
        [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
        [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
        [<ffffffff811887d3>] vfs_read+0xb3/0x180
        [<ffffffff811888ed>] sys_read+0x4d/0x90
        [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

eCryptfs: Properly check for O_RDONLY flag before doing privileged open

If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.

The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>

floppy: cancel any pending fd_timeouts before adding a new one

In commit 070ad7e793dc ("floppy: convert to delayed work and
single-thread wq") the 'fd_timeout' timer was converted to a delayed
work.  However, the "del_timer(&fd_timeout)" was lost in the process,
and any previous pending timeouts would stay active when we then
re-queued the timeout.

This resulted in the floppy probe sequence having a (stale) 20s timeout
rather than the intended 3s timeout, and thus made booting with the
floppy driver (but no actual floppy controller) take much longer than it
should.

Of course, there's little reason for most people to compile the floppy
driver into the kernel at all, which is why most people never noticed.

Canceling the delayed work where we used to do the del_timer() fixes the
issue, and makes the floppy probing use the proper new timeout instead.
The three second timeout is still very wasteful, but better than the 20s
one.

Reported-and-tested-by: Andi Kleen <ak@linux.intel.com>
Reported-and-tested-by: Calvin Walton <calvin.walton@kepstin.ca>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

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

Pull block bits from Jens Axboe:
 "As vacation is coming up, thought I'd better get rid of my pending
  changes in my for-linus branch for this iteration.  It contains:

   - Two patches for mtip32xx.  Killing a non-compliant sysfs interface
     and moving it to debugfs, where it belongs.

   - A few patches from Asias.  Two legit bug fixes, and one killing an
     interface that is no longer in use.

   - A patch from Jan, making the annoying partition ioctl warning a bit
     less annoying, by restricting it to !CAP_SYS_RAWIO only.

   - Three bug fixes for drbd from Lars Ellenberg.

   - A fix for an old regression for umem, it hasn't really worked since
     the plugging scheme was changed in 3.0.

   - A few fixes from Tejun.

   - A splice fix from Eric Dumazet, fixing an issue with pipe
     resizing."

* 'for-linus' of git://git.kernel.dk/linux-block:
  scsi: Silence unnecessary warnings about ioctl to partition
  block: Drop dead function blk_abort_queue()
  block: Mitigate lock unbalance caused by lock switching
  block: Avoid missed wakeup in request waitqueue
  umem: fix up unplugging
  splice: fix racy pipe->buffers uses
  drbd: fix null pointer dereference with on-congestion policy when diskless
  drbd: fix list corruption by failing but already aborted reads
  drbd: fix access of unallocated pages and kernel panic
  xen/blkfront: Add WARN to deal with misbehaving backends.
  blkcg: drop local variable @q from blkg_destroy()
  mtip32xx: Create debugfs entries for troubleshooting
  mtip32xx: Remove 'registers' and 'flags' from sysfs
  blkcg: fix blkg_alloc() failure path
  block: blkcg_policy_cfq shouldn't be used if !CONFIG_CFQ_GROUP_IOSCHED
  block: fix return value on cfq_init() failure
  mtip32xx: Remove version.h header file inclusion
  xen/blkback: Copy id field when doing BLKIF_DISCARD.

KVM: MMU: fix shrinking page from the empty mmu

Fix:

 [ 3190.059226] BUG: unable to handle kernel NULL pointer dereference at           (null)
 [ 3190.062224] IP: [<ffffffffa02aac66>] mmu_page_zap_pte+0x10/0xa7 [kvm]
 [ 3190.063760] PGD 104f50067 PUD 112bea067 PMD 0
 [ 3190.065309] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
 [ 3190.066860] CPU 1
[ ...... ]
 [ 3190.109629] Call Trace:
 [ 3190.111342]  [<ffffffffa02aada6>] kvm_mmu_prepare_zap_page+0xa9/0x1fc [kvm]
 [ 3190.113091]  [<ffffffffa02ab2f5>] mmu_shrink+0x11f/0x1f3 [kvm]
 [ 3190.114844]  [<ffffffffa02ab25d>] ? mmu_shrink+0x87/0x1f3 [kvm]
 [ 3190.116598]  [<ffffffff81150c9d>] ? prune_super+0x142/0x154
 [ 3190.118333]  [<ffffffff8110a4f4>] ? shrink_slab+0x39/0x31e
 [ 3190.120043]  [<ffffffff8110a687>] shrink_slab+0x1cc/0x31e
 [ 3190.121718]  [<ffffffff8110ca1d>] do_try_to_free_pages

This is caused by shrinking page from the empty mmu, although we have
checked n_used_mmu_pages, it is useless since the check is out of mmu-lock

Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

KVM: fix fault page leak

fault_page is forgot to be freed

Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

regulator: Fix recursive mutex lockdep warning

A recursive lockdep warning occurs if you call
regulator_set_optimum_mode() on a regulator with a supply because
there is no nesting annotation for the rdev->mutex. To avoid this
warning, get the supply's load before locking the regulator's
mutex to avoid grabbing the same class of lock twice.

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #3257 Tainted: G        W
---------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38

but task is already holding lock:
 (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&rdev->mutex);
  lock(&rdev->mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by swapper/0/1:
 #0:  (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c
 #1:  (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c
 #2:  (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224

stack backtrace:
[<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080)
[<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10)
[<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8)
[<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4)
[<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38)
[<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224)
...

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

clk: fix parent validation in __clk_set_parent()

The below commit introduced a bug in __clk_set_parent()
which could cause it to *skip* the parent validation
which makes sure the parent passed to the api is a valid
one.

    commit 7975059db572eb47f0fb272a62afeae272a4b209
    Author: Rajendra Nayak <rnayak@ti.com>
    Date:   Wed Jun 6 14:41:31 2012 +0530

        clk: Allow late cache allocation for clk->parents

This was identified by the following compiler warning..

    drivers/clk/clk.c: In function '__clk_set_parent':
    drivers/clk/clk.c:1083:5: warning: 'i' may be used uninitialized in this function [-Wuninitialized]

.. as reported by Marc Kleine-Budde.

There were various options discussed on how to fix this, one
being initing 'i' to clk->num_parents, but the below approach
was found to be more appropriate as it also makes the 'parent
validation' code simpler to read.

Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Cc: stable@kernel.org

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

Pull sound fixes from Takashi Iwai:
 "Just a few driver-specific fixes for ASoC and HD-audio."

* tag 'sound-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix no sound from ALC662 after Windows reboot
  ASoC: tlv320aic3x: Fix codec pll configure bug
  ASoC: wm2200: Add missing BCLK rate

Merge tag 'dm-3.5-fixes' of git://git./linux/kernel/git/agk/linux-dm

Pull device-mapper fixes from Alasdair G Kergon:
 "Four minor thin provisioning fixes and correct and update dm-verity
  documentation."

* tag 'dm-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm: verity fix documentation
  dm persistent data: fix allocation failure in space map checker init
  dm persistent data: handle space map checker creation failure
  dm persistent data: fix shadow_info_leak on dm_tm_destroy
  dm thin: commit metadata before creating metadata snapshot

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

Pull drm fixes from Dave Airlie:
 "One regression fix, two radeon fixes (one for an oops), and an i915
  fix to unload framebuffers earlier.

  We originally were going to leave the i915 fix until -next, but grub2
  in some situations causes vesafb/efifb to be loaded now, and this
  causes big slowdowns, and I have reports in rawhide I'd like to have
  fixed."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: kick any firmware framebuffers before claiming the gtt
  drm: edid: Don't add inferred modes with higher resolution
  drm/radeon: fix rare segfault
  drm/radeon: fix VM page table setup on SI

cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize

When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states
that you must cap the size of the read at the client's MaxBufferSize.
Unfortunately, testing with many older servers shows that they often
can't service a read larger than their own MaxBufferSize.

Since we can't assume what the server will do in this situation, we must
be conservative here for the default. When the server can't do large
reads, then assume that it can't satisfy any read larger than its
MaxBufferSize either.

Luckily almost all modern servers can do large reads, so this won't
affect them. This is really just for older win9x and OS/2 era servers.
Also, note that this patch just governs the default rsize. The admin can
always override this if he so chooses.

Cc: <stable@vger.kernel.org> # 3.2
Reported-by: David H. Durgee <dhdurgee@acm.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steven French <sfrench@w500smf.(none)>