Venkatash spake thus:

  virtio-blk set the default queue depth to 64 requests, which was
  insufficient for high-IOPS devices. Instead set the blk-queue depth to
  the device's virtqueue depth divided by two (each I/O requires at least
  two VQ entries).

But behold, Ted added a module parameter:

  Also allow the queue depth to be something which can be set at module
  load time or via a kernel boot-time parameter, for
  testing/benchmarking purposes.

And I rewrote it substantially, mainly to take
VIRTIO_RING_F_INDIRECT_DESC into account.

As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
have made a change.  This version does (since QEMU also offers
VIRTIO_RING_F_INDIRECT_DESC.
Inspired-by: "Theodore Ts'o" <tytso@mit.edu>
Based-on-the-true-story-of: Venkatesh Srinivas <venkateshs@google.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org
Cc: virtualization@lists.linux-foundation.org
Cc: Frank Swiderski <fes@google.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The OASIS virtio-dev mailing list is a good place for implementers to
discuss details of the standard, but it requires subscription to avoid
IP issues :(

It makes more sense to stick with the
virtualization@lists.linux-foundation.org mailing list for bug
reports.  We can refer to the OASIS list if it involves a question on
the standard itself.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Heinz points out that adding buffers to a broken virtqueue (which
should "never happen") still works.  Failing allows drivers to detect
and complain about broken devices.

Now drivers are robust, we can add this extra check.
Reported-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

A bad implementation of virtio might cause us to mark the virtqueue
broken: we'll dev_err() in that case, and the device is useless, but
let's not BUG().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

A bad implementation of virtio might cause us to mark the virtqueue
broken: we'll dev_err() in that case, and the device is useless, but
let's not BUG().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

A bad implementation of virtio might cause us to mark the virtqueue
broken: we'll dev_err() in that case, and the device is useless, but
let's not BUG_ON().

ENOMEM or ENOSPC implies the ring is full, and we should try again
later (-ENOMEM is documented to happen, but doesn't, as we fall
through to ENOSPC).

EIO means it's broken.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

A bad implementation of virtio might cause us to mark the virtqueue
broken: we'll dev_err() in that case, and the device is useless, but
let's not BUG_ON().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

When adding or removing 100G from a balloon:

    BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367]

We have a wait_event_interruptible(), but the condition is always true
(more ballooning to do) so we don't ever sleep.  We also have a
wait_event() for the host to ack, but that is also always true as QEMU
is synchronous for balloon operations.
Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com>
Cc: stable@kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

virtio-dev mailing list is for subscribers only according to the
returned message after trying to send to it.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Fixes the following build failure:

 cc -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign
   -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD
   -U_FORTIFY_SOURCE   -c -o virtio_test.o virtio_test.c
 virtio_test.c: In function ‘run_test’:
 virtio_test.c:176:7: error: expected ‘)’ before ‘r’
         r = -1;
         ^

Fixes: 53c18c99 (virtio_test: verify if virtqueue_kick() succeeded)
Cc: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

In commit bb478d8b virtio_ring: plug kmemleak false positive,
kmemleak_ignore was introduced. This broke compilation of virtio_test:

  cc -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign
    -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD
    -U_FORTIFY_SOURCE   -c -o virtio_ring.o ../../drivers/virtio/virtio_ring.c
  ../../drivers/virtio/virtio_ring.c: In function ‘vring_add_indirect’:
  ../../drivers/virtio/virtio_ring.c:177:2: warning: implicit declaration
  of function ‘kmemleak_ignore’ [-Wimplicit-function-declaration]
    kmemleak_ignore(desc);
    ^
  cc   virtio_test.o virtio_ring.o   -o virtio_test
  virtio_ring.o: In function `vring_add_indirect':
  tools/virtio/../../drivers/virtio/virtio_ring.c:177:
  undefined reference to `kmemleak_ignore'

Add a dummy header for tools/virtio, and add #incldue <linux/kmemleak.h>
to drivers/virtio/virtio_ring.c so it is picked up by the userspace
tools.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The virtio headers have changed recently:

 5b1bf7cb virtio_ring: let virtqueue_{kick()/notify()} return a bool
 46f9c2b9 virtio_ring: change host notification API

Update the internal copies to fix the build of virtio_test:

  cc -g -O2 -Wall -I. -I ../../usr/include/ -Wno-pointer-sign
    -fno-strict-overflow -fno-strict-aliasing -fno-common -MMD -U_FORTIFY_SOURCE
    -c -o virtio_test.o virtio_test.c
  In file included from virtio_test.c:15:0:
  ./linux/virtio.h:76:19: error: conflicting types for ‘vring_new_virtqueue’
   struct virtqueue *vring_new_virtqueue(unsigned int index,
                     ^
  In file included from ./linux/virtio_ring.h:1:0,
                   from ../../usr/include/linux/vhost.h:17,
                   from virtio_test.c:14:
  ./linux/../../../include/linux/virtio_ring.h:68:19: note: previous
  declaration of ‘vring_new_virtqueue’ was here
   struct virtqueue *vring_new_virtqueue(unsigned int index,
  virtio_test.c: In function ‘vq_info_add’:
  virtio_test.c:103:12: warning: passing argument 7 of ‘vring_new_virtqueue’
  from incompatible pointer type [enabled by default]
              vq_notify, vq_callback, "test");
              ^
  In file included from virtio_test.c:15:0:
  ./linux/virtio.h:76:19: note: expected ‘void (*)(struct virtqueue *)’ but
  argument is of type ‘_Bool (*)(struct virtqueue *)’
   struct virtqueue *vring_new_virtqueue(unsigned int index,
                     ^
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Pull CIFS fixes from Steve French:
 "A fix for the problem which Al spotted in cifs_writev and a followup
  (noticed when fixing CVE-2014-0069) patch to ensure that cifs never
  sends more than the smb frame length over the socket (as we saw with
  that cifs_iovec_write problem that Jeff fixed last month)"

* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: mask off top byte in get_rfc1002_length()
  cifs: sanity check length of data to send before sending
  CIFS: Fix wrong pos argument of cifs_find_lock_conflict

Pull audit namespace fixes from Eric Biederman:
 "Starting with 3.14-rc1 the audit code is faulty (think oopses and
  races) with respect to how it computes the network namespace of which
  socket to reply to, and I happened to notice by chance when reading
  through the code.

  My testing and the automated build bots don't find any problems with
  these fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
  audit: Update kdoc for audit_send_reply and audit_list_rules_send
  audit: Send replies in the proper network namespace.
  audit: Use struct net not pid_t to remember the network namespce to reply in

This was an optimization that made memcpy type benchmarks a little
faster on ancient (Circa 1998) IDT Winchip CPUs.  In real-life
workloads, it wasn't even noticable, and I doubt anyone is running
benchmarks on 16 year old silicon any more.

Given this code has likely seen very little use over the last decade,
let's just remove it.
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge misc fixes from Andrew Morton:
 "Nine fixes"

* emailed patches from Andrew Morton akpm@linux-foundation.org>:
  cris: convert ffs from an object-like macro to a function-like macro
  hfsplus: add HFSX subfolder count support
  tools/testing/selftests/ipc/msgque.c: handle msgget failure return correctly
  MAINTAINERS: blackfin: add git repository
  revert "kallsyms: fix absolute addresses for kASLR"
  mm/Kconfig: fix URL for zsmalloc benchmark
  fs/proc/base.c: fix GPF in /proc/$PID/map_files
  mm/compaction: break out of loop on !PageBuddy in isolate_freepages_block
  mm: fix GFP_THISNODE callers and clarify

This avoids bad interactions with code using identifiers called "ffs":

  drivers/usb/gadget/f_fs.c: In function 'ffsmod_init':
  drivers/usb/gadget/f_fs.c:2693:494: error: 'ffsusb_func' undeclared (first use in this function)
  drivers/usb/gadget/f_fs.c:2693:494: note: each undeclared identifier is reported only once for each function it appears in
  drivers/usb/gadget/f_fs.c: In function 'ffsmod_exit':
  drivers/usb/gadget/f_fs.c:2693:677: error: 'ffsusb_func' undeclared (first use in this function)
  drivers/usb/gadget/f_fs.c: At top level:
  drivers/usb/gadget/f_fs.c:2693:35: warning: 'kernel_ffsusb_func' defined but not used [-Wunused-variable]
  drivers/usb/gadget/f_fs.c: In function 'ffsmod_init':
  drivers/usb/gadget/f_fs.c:2693:15: warning: control reaches end of non-void function [-Wreturn-type]

See http://kisskb.ellerman.id.au/kisskb/buildresult/10715817/Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Adds support for HFSX 'HasFolderCount' flag and a corresponding
'folderCount' field in folder records.  (For reference see
HFS_FOLDERCOUNT and kHFSHasFolderCountBit/kHFSHasFolderCountMask in
Apple's source code.)

Ignoring subfolder count leads to fs errors found by Mac:

  ...
  Checking catalog hierarchy.
  HasFolderCount flag needs to be set (id = 105)
  (It should be 0x10 instead of 0)
  Incorrect folder count in a directory (id = 2)
  (It should be 7 instead of 6)
  ...

Steps to reproduce:
 Format with "newfs_hfs -s /dev/diskXXX".
 Mount in Linux.
 Create a new directory in root.
 Unmount.
 Run "fsck_hfs /dev/diskXXX".

The patch handles directory creation, deletion, and rename.
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

A failed msgget causes the test to return an uninitialised value in ret.
Assign ret to -errno on error exit.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add the git repository currently in use for blackfin architecture
development.

This information was obtained from Steven Miao.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: Steven Miao <realmz6@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Revert the recently applied 0f55159d ("kallsyms: fix absolute
addresses for kASLR").  Kees said

: This got NAKed, please don't apply -- this patch works for x86 and
: ARM, but may cause problems for others:
:
: https://lkml.org/lkml/2014/2/24/718

It appears that Kees will be fixing all this up for 3.15.

Cc: Andy Honig <ahonig@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Michal Marek <mmarek@suse.cz>
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>

The help text for CONFIG_PGTABLE_MAPPING has an incorrect URL.  While
we're at it, remove the unnecessary footnote notation.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The expected logic of proc_map_files_get_link() is either to return 0
and initialize 'path' or return an error and leave 'path' uninitialized.

By the time dname_to_vma_addr() returns 0 the corresponding vma may have
already be gone.  In this case the path is not initialized but the
return value is still 0.  This results in 'general protection fault'
inside d_path().

Steps to reproduce:

  CONFIG_CHECKPOINT_RESTORE=y

    fd = open(...);
    while (1) {
        mmap(fd, ...);
        munmap(fd, ...);
    }

  ls -la /proc/$PID/map_files

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991Signed-off-by: Artem Fetishev <artem_fetishev@epam.com>
Signed-off-by: Aleksandr Terekhov <aleksandr_terekhov@epam.com>
Reported-by: <wiebittewas@gmail.com>
Acked-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

We received several reports of bad page state when freeing CMA pages
previously allocated with alloc_contig_range:

    BUG: Bad page state in process Binder_A  pfn:63202
    page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf
    page flags: 0x40080068(uptodate|lru|active|swapbacked)

Based on the page state, it looks like the page was still in use.  The
page flags do not make sense for the use case though.  Further debugging
showed that despite alloc_contig_range returning success, at least one
page in the range still remained in the buddy allocator.

There is an issue with isolate_freepages_block.  In strict mode (which
CMA uses), if any pages in the range cannot be isolated,
isolate_freepages_block should return failure 0.  The current check
keeps track of the total number of isolated pages and compares against
the size of the range:

        if (strict && nr_strict_required > total_isolated)
                total_isolated = 0;

After taking the zone lock, if one of the pages in the range is not in
the buddy allocator, we continue through the loop and do not increment
total_isolated.  If in the last iteration of the loop we isolate more
than one page (e.g.  last page needed is a higher order page), the check
for total_isolated may pass and we fail to detect that a page was
skipped.  The fix is to bail out if the loop immediately if we are in
strict mode.  There's no benfit to continuing anyway since we need all
pages to be isolated.  Additionally, drop the error checking based on
nr_strict_required and just check the pfn ranges.  This matches with
what isolate_freepages_range does.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

GFP_THISNODE is for callers that implement their own clever fallback to
remote nodes.  It restricts the allocation to the specified node and
does not invoke reclaim, assuming that the caller will take care of it
when the fallback fails, e.g.  through a subsequent allocation request
without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback or
triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too, but
at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull vfs fixes from Al Viro.

Clean up file table accesses (get rid of fget_light() in favor of the
fdget() interface), add proper file position locking.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  get rid of fget_light()
  sockfd_lookup_light(): switch to fdget^W^Waway from fget_light
  vfs: atomic f_pos accesses as per POSIX
  ocfs2 syncs the wrong range...

Pull libata fixlet from Tejun Heo:
 "I merged the two blaclist entries into 'Crucial_CT???M500SSD*'"

* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  libata: use wider match for blacklisting Crucial M500

instead of returning the flags by reference, we can just have the
low-level primitive return those in lower bits of unsigned long,
with struct file * derived from the rest.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

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

Our write() system call has always been atomic in the sense that you get
the expected thread-safe contiguous write, but we haven't actually
guaranteed that concurrent writes are serialized wrt f_pos accesses, so
threads (or processes) that share a file descriptor and use "write()"
concurrently would quite likely overwrite each others data.

This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:

 "2.9.7 Thread Interactions with Regular File Operations

  All of the following functions shall be atomic with respect to each
  other in the effects specified in POSIX.1-2008 when they operate on
  regular files or symbolic links: [...]"

and one of the effects is the file position update.

This unprotected file position behavior is not new behavior, and nobody
has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
Michael Kerrisk that was due to this.

This resolves the issue with a f_pos-specific lock that is taken by
read/write/lseek on file descriptors that may be shared across threads
or processes.
Reported-by: Yongzhi Pan <panyongzhi@gmail.com>
Reported-by: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

We're now blacklisting "Crucial_CT???M500SSD1" and
"Crucial_CT???M500SSD3".  Also, "Micron_M500*" is blacklisted which is
about the same devices as the crucial branded ones.  Let's merge the
two Crucial M500 entries and widen the match to
"Crucial_CT???M500SSD*" so that we don't have to fiddle with new
entries for similar devices.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org

Pull ARM SoC fixes from from Olof Johansson:
 "A collection of fixes for ARM platforms.  A little large due to us
  missing to do one last week, but there's nothing in particular here
  that is in itself large and scary.

  Mostly a handful of smaller fixes all over the place.  The majority is
  made up of fixes for OMAP, but there are a few for others as well.  In
  particular, there was a decision to rename a binding for the Broadcom
  pinctrl block that we need to go in before the final release since we
  then treat it as ABI"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
  ARM: tegra: add LED options back into tegra_defconfig
  ARM: dts: omap3-igep: fix boot fail due wrong compatible match
  ARM: OMAP3: Fix pinctrl interrupts for core2
  pinctrl: Rename Broadcom Capri pinctrl binding
  pinctrl: refer to updated dt binding string.
  Update dtsi with new pinctrl compatible string
  ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
  ARM: OMAP2+: Add support for thumb mode on DT booted N900
  ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
  ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
  ARM: DRA7: hwmod data: correct the sysc data for spinlock
  ARM: OMAP5: PRM: Fix reboot handling
  ARM: sunxi: dt: Change the touchscreen compatibles
  ARM: sun7i: dt: Fix interrupt trigger types

Pull NFS client bugfixes from Trond Myklebust:
 "Highlights include:

   - Fix another nfs4_sequence corruptor in RELEASE_LOCKOWNER
   - Fix an Oopsable delegation callback race
   - Fix another bad stateid infinite loop
   - Fail the data server I/O is the stateid represents a lost lock
   - Fix an Oopsable sunrpc trace event"

* tag 'nfs-for-3.14-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  SUNRPC: Fix oops when trace sunrpc_task events in nfs client
  NFSv4: Fail the truncate() if the lock/open stateid is invalid
  NFSv4.1 Fail data server I/O if stateid represents a lost lock
  NFSv4: Fix the return value of nfs4_select_rw_stateid
  NFSv4: nfs4_stateid_is_current should return 'true' for an invalid stateid
  NFS: Fix a delegation callback race
  NFSv4: Fix another nfs4_sequence corruptor

Pull USB fixes from Greg KH:
 "Here are 4 USB fixes for your current tree.

  Two of them are reverts to hopefully resolve the nasty XHCI
  regressions we have been having on some types of devices.  The other
  two are quirks for some Logitech video devices"

* tag 'usb-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
  Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."
  usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
  usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e

Pull staging driver tree fix from Greg KH:
 "Here is a single staging driver fix for your tree.

  It resolves an issue with arbritary writes to memory if a specific
  driver is loaded"

* tag 'staging-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()

This fixes CVE-2014-0102.

The following command sequence produces an oops:

	keyctl new_session
	i=`keyctl newring _ses @s`
	keyctl link @s $i

The problem is that search_nested_keyrings() sees two keyrings that have
matching type and description, so keyring_compare_object() returns true.
s_n_k() then passes the key to the iterator function -
keyring_detect_cycle_iterator() - which *should* check to see whether this is
the keyring of interest, not just one with the same name.

Because assoc_array_find() will return one and only one match, I assumed that
the iterator function would only see an exact match or never be called - but
the iterator isn't only called from assoc_array_find()...

The oops looks something like this:

	kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
	invalid opcode: 0000 [#1] SMP
	...
	RIP: keyring_detect_cycle_iterator+0xe/0x1f
	...
	Call Trace:
	  search_nested_keyrings+0x76/0x2aa
	  __key_link_check_live_key+0x50/0x5f
	  key_link+0x4e/0x85
	  keyctl_keyring_link+0x60/0x81
	  SyS_keyctl+0x65/0xe4
	  tracesys+0xdd/0xe2

The fix is to make keyring_detect_cycle_iterator() check that the key it
has is the key it was actually looking for rather than calling BUG_ON().

A testcase has been included in the keyutils testsuite for this:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790bReported-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull thermal fixes from Zhang Rui:
 "Specifics:

   - Update the help text of INT3403 Thermal driver, which was not
     friendly to users.  From Zhang Rui.

   - The "type" sysfs attribute of x86_pkg_temp_thermal registered
     thermal zones includes an instance number, which makes the
     thermal-to-hwmon bridge fails to group them all in a single hwmon
     device.  Fixed by Jean Delvare.

   - The hwmon device registered by x86_pkg_temp_thermal driver is
     redundant because the temperature value reported by
     x86_pkg_temp_thermal is already reported by the coretemp driver.
     Fixed by Jean Delvare.

   - Fix a problem that the cooling device can not be updated properly
     if it is initialized at max cooling state.  From Ni Wade.

   - Fix a problem that OF registered thermal zones are running without
     thermal governors.  From Zhang Rui.

   - Commit beeb5a1e ("thermal: rcar-thermal: Enable driver
     compilation with COMPILE_TEST") broke build on archs wihout io
     memory.  Thus make it depend on HAS_IOMEM to bypass build failures.
     Fixed by Richard Weinberger"

* 'for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  Thermal: thermal zone governor fix
  Thermal: Allow first update of cooling device state
  thermal,rcar_thermal: Add dependency on HAS_IOMEM
  x86_pkg_temp_thermal: Fix the thermal zone type
  x86_pkg_temp_thermal: Do not expose as a hwmon device
  Thermal: update INT3404 thermal driver help text