commit 816b571ac0e9eb9700df1ebc99702f9ad04e8607
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 30 09:35:42 2014 -0700

    Linux 3.10.59

commit f52c88e8e124f72eca2dc700c476b2b38f288f28
Author: Chao Yu <chao2.yu@samsung.com>
Date:   Thu Jul 24 17:25:42 2014 +0800

    ecryptfs: avoid to access NULL pointer when write metadata in xattr
    
    commit 35425ea2492175fd39f6116481fe98b2b3ddd4ca upstream.
    
    Christopher Head 2014-06-28 05:26:20 UTC described:
    "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo"
    in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:
    
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
    PGD d7840067 PUD b2c3c067 PMD 0
    Oops: 0002 [#1] SMP
    Modules linked in: nvidia(PO)
    CPU: 3 PID: 3566 Comm: bash Tainted: P           O 3.12.21-gentoo-r1 #2
    Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010
    task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000
    RIP: 0010:[<ffffffff8110eb39>]  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
    RSP: 0018:ffff8800bad71c10  EFLAGS: 00010246
    RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000
    RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000
    RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000
    R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40
    FS:  00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0
    Stack:
    ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a
    ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c
    00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220
    Call Trace:
    [<ffffffff811826e8>] ? ecryptfs_setxattr+0x40/0x52
    [<ffffffff81185fd5>] ? ecryptfs_write_metadata+0x1b3/0x223
    [<ffffffff81082c2c>] ? should_resched+0x5/0x23
    [<ffffffff8118322b>] ? ecryptfs_initialize_file+0xaf/0xd4
    [<ffffffff81183344>] ? ecryptfs_create+0xf4/0x142
    [<ffffffff810f8c0d>] ? vfs_create+0x48/0x71
    [<ffffffff810f9c86>] ? do_last.isra.68+0x559/0x952
    [<ffffffff810f7ce7>] ? link_path_walk+0xbd/0x458
    [<ffffffff810fa2a3>] ? path_openat+0x224/0x472
    [<ffffffff810fa7bd>] ? do_filp_open+0x2b/0x6f
    [<ffffffff81103606>] ? __alloc_fd+0xd6/0xe7
    [<ffffffff810ee6ab>] ? do_sys_open+0x65/0xe9
    [<ffffffff8157d022>] ? system_call_fastpath+0x16/0x1b
    RIP  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
    RSP <ffff8800bad71c10>
    CR2: 0000000000000000
    ---[ end trace df9dba5f1ddb8565 ]---"
    
    If we create a file when we mount with ecryptfs_xattr_metadata option, we will
    encounter a crash in this path:
    ->ecryptfs_create
      ->ecryptfs_initialize_file
        ->ecryptfs_write_metadata
          ->ecryptfs_write_metadata_to_xattr
            ->ecryptfs_setxattr
              ->fsstack_copy_attr_all
    It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it
    will be initialized when ecryptfs_initialize_file finish.
    
    So we should skip copying attr from lower inode when the value of ->d_inode is
    invalid.
    
    Signed-off-by: Chao Yu <chao2.yu@samsung.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26aca22946dc127ee5f72d031aa6dfe7f1328b44
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Mon Sep 22 15:51:33 2014 +0200

    ARM: at91/PMC: don't forget to write PMC_PCDR register to disable clocks
    
    commit cfa1950e6c6b72251e80adc736af3c3d2907ab0e upstream.
    
    When introducing support for sama5d3, the write to PMC_PCDR register has
    been accidentally removed.
    
    Reported-by: Nathalie Cyrille <nathalie.cyrille@atmel.com>
    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4148f813c2ef303eb500a6b9a360783c3217e810
Author: Vlad Catoi <vladcatoi@gmail.com>
Date:   Sat Oct 18 17:45:41 2014 -0500

    ALSA: usb-audio: Add support for Steinberg UR22 USB interface
    
    commit f0b127fbfdc8756eba7437ab668f3169280bd358 upstream.
    
    Adding support for Steinberg UR22 USB interface via quirks table patch
    
    See Ubuntu bug report:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317244
    Also see threads:
    http://linux-audio.4202.n7.nabble.com/Support-for-Steinberg-UR22-Yamaha-USB-chipset-0499-1509-tc82888.html#a82917
    http://www.steinberg.net/forums/viewtopic.php?t=62290
    
    Tested by at least 4 people judging by the threads.
    Did not test MIDI interface, but audio output and capture both are
    functional. Built 3.17 kernel with this driver on Ubuntu 14.04 & tested with mpg123
    Patch applied to 3.13 Ubuntu kernel works well enough for daily use.
    
    Signed-off-by: Vlad Catoi <vladcatoi@gmail.com>
    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8205fae0f07db86ca05108a478d5f8b7e5fe2737
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 13 23:18:02 2014 +0200

    ALSA: emu10k1: Fix deadlock in synth voice lookup
    
    commit 95926035b187cc9fee6fb61385b7da9c28123f74 upstream.
    
    The emu10k1 voice allocator takes voice_lock spinlock.  When there is
    no empty stream available, it tries to release a voice used by synth,
    and calls get_synth_voice.  The callback function,
    snd_emu10k1_synth_get_voice(), however, also takes the voice_lock,
    thus it deadlocks.
    
    The fix is simply removing the voice_lock holds in
    snd_emu10k1_synth_get_voice(), as this is always called in the
    spinlock context.
    
    Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aff3c48530a9bd58edf42d94684234244c957a6b
Author: Anatol Pomozov <anatol.pomozov@gmail.com>
Date:   Fri Oct 17 12:43:34 2014 -0700

    ALSA: pcm: use the same dma mmap codepath both for arm and arm64
    
    commit a011e213f3700233ed2a676f1ef0a74a052d7162 upstream.
    
    This avoids following kernel crash when try to playback on arm64
    
    [  107.497203] [<ffffffc00046b310>] snd_pcm_mmap_data_fault+0x90/0xd4
    [  107.503405] [<ffffffc0001541ac>] __do_fault+0xb0/0x498
    [  107.508565] [<ffffffc0001576a0>] handle_mm_fault+0x224/0x7b0
    [  107.514246] [<ffffffc000092640>] do_page_fault+0x11c/0x310
    [  107.519738] [<ffffffc000081100>] do_mem_abort+0x38/0x98
    
    Tested: backported to 3.14 and tried to playback on arm64 machine
    
    Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f81e4deb5a6807fc2495e61ce080df7de51e3b8
Author: Victor Kamensky <victor.kamensky@linaro.org>
Date:   Tue Oct 14 06:55:05 2014 +0100

    arm64: compat: fix compat types affecting struct compat_elf_prpsinfo
    
    commit 971a5b6fe634bb7b617d8c5f25b6a3ddbc600194 upstream.
    
    The compat_elf_prpsinfo structure does not match the arch/arm struct
    elf_pspsinfo definition. As result NT_PRPSINFO note in core file
    created by arm64 kernel for aarch32 (compat) process has wrong size.
    So gdb cannot display command that caused process crash.
    
    Fix is to change size of __compat_uid_t, __compat_gid_t so it would
    match size of similar fields in arch/arm case.
    
    Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fa1d75bead1cfe2718d4e81fd039ea4006da745
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Sep 18 20:08:53 2014 +0300

    spi: dw-mid: terminate ongoing transfers at exit
    
    commit 8e45ef682cb31fda62ed4eeede5d9745a0a1b1e2 upstream.
    
    Do full clean up at exit, means terminate all ongoing DMA transfers.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42abc5125d0cd1abba9d21133010dcea1f3a0e8f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Oct 13 15:51:05 2014 -0700

    kernel: add support for gcc 5
    
    commit 71458cfc782eafe4b27656e078d379a34e472adf upstream.
    
    We're missing include/linux/compiler-gcc5.h which is required now
    because gcc branched off to v5 in trunk.
    
    Just copy the relevant bits out of include/linux/compiler-gcc4.h,
    no new code is added as of now.
    
    This fixes a build error when using gcc 5.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9345b4559ec8826ec13dd91d95a8cab81748c307
Author: Yann Droneaud <ydroneaud@opteya.com>
Date:   Thu Oct 9 15:24:40 2014 -0700

    fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
    
    commit 0b37e097a648aa71d4db1ad108001e95b69a2da4 upstream.
    
    According to commit 80af258867648 ("fanotify: groups can specify their
    f_flags for new fd"), file descriptors created as part of file access
    notification events inherit flags from the event_f_flags argument passed
    to syscall fanotify_init(2)[1].
    
    Unfortunately O_CLOEXEC is currently silently ignored.
    
    Indeed, event_f_flags are only given to dentry_open(), which only seems to
    care about O_ACCMODE and O_PATH in do_dentry_open(), O_DIRECT in
    open_check_o_direct() and O_LARGEFILE in generic_file_open().
    
    It's a pity, since, according to some lookup on various search engines and
    http://codesearch.debian.net/, there's already some userspace code which
    use O_CLOEXEC:
    
    - in systemd's readahead[2]:
    
        fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
    
    - in clsync[3]:
    
        #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
    
        int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
    
    - in examples [4] from "Filesystem monitoring in the Linux
      kernel" article[5] by Aleksander Morgado:
    
        if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
                                          O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0)
    
    Additionally, since commit 48149e9d3a7e ("fanotify: check file flags
    passed in fanotify_init").  having O_CLOEXEC as part of fanotify_init()
    second argument is expressly allowed.
    
    So it seems expected to set close-on-exec flag on the file descriptors if
    userspace is allowed to request it with O_CLOEXEC.
    
    But Andrew Morton raised[6] the concern that enabling now close-on-exec
    might break existing applications which ask for O_CLOEXEC but expect the
    file descriptor to be inherited across exec().
    
    In the other hand, as reported by Mihai Dontu[7] close-on-exec on the file
    descriptor returned as part of file access notify can break applications
    due to deadlock.  So close-on-exec is needed for most applications.
    
    More, applications asking for close-on-exec are likely expecting it to be
    enabled, relying on O_CLOEXEC being effective.  If not, it might weaken
    their security, as noted by Jan Kara[8].
    
    So this patch replaces call to macro get_unused_fd() by a call to function
    get_unused_fd_flags() with event_f_flags value as argument.  This way
    O_CLOEXEC flag in the second argument of fanotify_init(2) syscall is
    interpreted and close-on-exec get enabled when requested.
    
    [1] http://man7.org/linux/man-pages/man2/fanotify_init.2.html
    [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c?id=v208#n294
    [3] https://github.com/xaionaro/clsync/blob/v0.2.1/sync.c#L1631
        https://github.com/xaionaro/clsync/blob/v0.2.1/configuration.h#L38
    [4] http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c
    [5] http://www.lanedo.com/2013/filesystem-monitoring-linux-kernel/
    [6] http://lkml.kernel.org/r/20141001153621.65e9258e65a6167bf2e4cb50@linux-foundation.org
    [7] http://lkml.kernel.org/r/20141002095046.3715eb69@mdontu-l
    [8] http://lkml.kernel.org/r/20141002104410.GB19748@quack.suse.cz
    
    Link: http://lkml.kernel.org/r/cover.1411562410.git.ydroneaud@opteya.com
    Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Cc: Mihai Don\u021bu <mihai.dontu@gmail.com>
    Cc: Pádraig Brady <P@draigBrady.com>
    Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
    Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com>
    Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>
    Cc: Richard Guy Briggs <rgb@redhat.com>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e8fee8128715f3d250f92ef8d12a06c23a15101
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Oct 9 15:28:23 2014 -0700

    mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
    
    commit 934f3072c17cc8886f4c043b47eeeb1b12f8de33 upstream.
    
    commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
    during memory allocation") introduces PF_MEMALLOC_NOIO flag to avoid doing
    I/O inside memory allocation, __GFP_IO is cleared when this flag is set,
    but __GFP_FS implies __GFP_IO, it should also be cleared.  Or it may still
    run into I/O, like in superblock shrinker.  And this will make the kernel
    run into the deadlock case described in that commit.
    
    See Dave Chinner's comment about io in superblock shrinker:
    
    Filesystem shrinkers do indeed perform IO from the superblock shrinker and
    have for years.  Even clean inodes can require IO before they can be freed
    - e.g.  on an orphan list, need truncation of post-eof blocks, need to
    wait for ordered operations to complete before it can be freed, etc.
    
    IOWs, Ext4, btrfs and XFS all can issue and/or block on arbitrary amounts
    of IO in the superblock shrinker context.  XFS, in particular, has been
    doing transactions and IO from the VFS inode cache shrinker since it was
    first introduced....
    
    Fix this by clearing __GFP_FS in memalloc_noio_flags(), this function has
    masked all the gfp_mask that will be passed into fs for the processes
    setting PF_MEMALLOC_NOIO in the direct reclaim path.
    
    v1 thread at: https://lkml.org/lkml/2014/9/3/32
    
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: joyce.xue <xuejiufei@huawei.com>
    Cc: Ming Lei <ming.lei@canonical.com>
    Cc: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ba8fa07c9aa5c18ba3fd14917b53c4367d3ea7
Author: Champion Chen <champion_chen@realsil.com.cn>
Date:   Sat Sep 6 14:06:08 2014 -0500

    Bluetooth: Fix issue with USB suspend in btusb driver
    
    commit 85560c4a828ec9c8573840c9b66487b6ae584768 upstream.
    
    Suspend could fail for some platforms because
    btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs.
    
    When btusb_bulk_complete returns before system suspend and resubmits
    an URB, the system cannot enter suspend state.
    
    Signed-off-by: Champion Chen <champion_chen@realsil.com.cn>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90f9a6a427abd19c8d304ecbac034deb39d0737c
Author: Loic Poulain <loic.poulain@intel.com>
Date:   Fri Aug 8 19:07:16 2014 +0200

    Bluetooth: Fix HCI H5 corrupted ack value
    
    commit 4807b51895dce8aa650ebebc51fa4a795ed6b8b8 upstream.
    
    In this expression: seq = (seq - 1) % 8
    seq (u8) is implicitly converted to an int in the arithmetic operation.
    So if seq value is 0, operation is ((0 - 1) % 8) => (-1 % 8) => -1.
    The new seq value is 0xff which is an invalid ACK value, we expect 0x07.
    It leads to frequent dropped ACK and retransmission.
    Fix this by using '&' binary operator instead of '%'.
    
    Signed-off-by: Loic Poulain <loic.poulain@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28330aa4e0dc1232ecfb18c7456a5c456f5c6e97
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Sep 24 11:24:54 2014 +0200

    rt2800: correct BBP1_TX_POWER_CTRL mask
    
    commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.
    
    Two bits control TX power on BBP_R1 register. Correct the mask,
    otherwise we clear additional bit on BBP_R1 register, what can have
    unknown, possible negative effect.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 359772477cc4c410a6d785a3de51d85cd0b6aeba
Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Date:   Wed Aug 27 14:57:57 2014 +0200

    PCI: Generate uppercase hex for modalias interface class
    
    commit 89ec3dcf17fd3fa009ecf8faaba36828dd6bc416 upstream.
    
    Some implementations of modprobe fail to load the driver for a PCI device
    automatically because the "interface" part of the modalias from the kernel
    is lowercase, and the modalias from file2alias is uppercase.
    
    The "interface" is the low-order byte of the Class Code, defined in PCI
    r3.0, Appendix D.  Most interface types defined in the spec do not use
    alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
    20h, etc. are unaffected.
    
    Print the "interface" byte of the Class Code in uppercase hex, as we
    already do for the Vendor ID, Device ID, Class, etc.
    
    [bhelgaas: changelog]
    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08037263178349a06d05da0c437b0be54ae05d8b
Author: Douglas Lehr <dllehr@us.ibm.com>
Date:   Thu Aug 21 09:26:52 2014 +1000

    PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size
    
    commit 9fe373f9997b48fcd6222b95baf4a20c134b587a upstream.
    
    The Crocodile chip occasionally comes up with 4k and 8k BAR sizes.  Due to
    an erratum, setting the SR-IOV page size causes the physical function BARs
    to expand to the system page size.  Since ppc64 uses 64k pages, when Linux
    tries to assign the smaller resource sizes to the now 64k BARs the address
    will be truncated and the BARs will overlap.
    
    Force Linux to allocate the resource as a full page, which avoids the
    overlap.
    
    [bhelgaas: print expanded resource, too]
    Signed-off-by: Douglas Lehr <dllehr@us.ibm.com>
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Milton Miller <miltonm@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75f43e3bf1fc500716b81a5f82a428fdc84c1cf8
Author: Oren Givon <oren.givon@intel.com>
Date:   Wed Sep 17 10:31:56 2014 +0300

    iwlwifi: Add missing PCI IDs for the 7260 series
    
    commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream.
    
    Add 4 missing PCI IDs for the 7260 series.
    
    Signed-off-by: Oren Givon <oren.givon@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2368dcc930680343e06848cc09689f7b8e8a0b9
Author: Andy Adamson <andros@netapp.com>
Date:   Mon Sep 29 12:31:57 2014 -0400

    NFSv4.1: Fix an NFSv4.1 state renewal regression
    
    commit d1f456b0b9545f1606a54cd17c20775f159bd2ce upstream.
    
    Commit 2f60ea6b8ced ("NFSv4: The NFSv4.0 client must send RENEW calls if it holds a delegation") set the NFS4_RENEW_TIMEOUT flag in nfs4_renew_state, and does
    not put an nfs41_proc_async_sequence call, the NFSv4.1 lease renewal heartbeat
    call, on the wire to renew the NFSv4.1 state if the flag was not set.
    
    The NFS4_RENEW_TIMEOUT flag is set when "now" is after the last renewal
    (cl_last_renewal) plus the lease time divided by 3. This is arbitrary and
    sometimes does the following:
    
    In normal operation, the only way a future state renewal call is put on the
    wire is via a call to nfs4_schedule_state_renewal, which schedules a
    nfs4_renew_state workqueue task. nfs4_renew_state determines if the
    NFS4_RENEW_TIMEOUT should be set, and the calls nfs41_proc_async_sequence,
    which only gets sent if the NFS4_RENEW_TIMEOUT flag is set.
    Then the nfs41_proc_async_sequence rpc_release function schedules
    another state remewal via nfs4_schedule_state_renewal.
    
    Without this change we can get into a state where an application stops
    accessing the NFSv4.1 share, state renewal calls stop due to the
    NFS4_RENEW_TIMEOUT flag _not_ being set. The only way to recover
    from this situation is with a clientid re-establishment, once the application
    resumes and the server has timed out the lease and so returns
    NFS4ERR_BAD_SESSION on the subsequent SEQUENCE operation.
    
    An example application:
    open, lock, write a file.
    
    sleep for 6 * lease (could be less)
    
    ulock, close.
    
    In the above example with NFSv4.1 delegations enabled, without this change,
    there are no OP_SEQUENCE state renewal calls during the sleep, and the
    clientid is recovered due to lease expiration on the close.
    
    This issue does not occur with NFSv4.1 delegations disabled, nor with
    NFSv4.0, with or without delegations enabled.
    
    Signed-off-by: Andy Adamson <andros@netapp.com>
    Link: http://lkml.kernel.org/r/1411486536-23401-1-git-send-email-andros@netapp.com
    Fixes: 2f60ea6b8ced (NFSv4: The NFSv4.0 client must send RENEW calls...)
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb7105c3d5b128542239f2eff1e399e26959bcc7
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Sep 27 17:41:51 2014 -0400

    NFSv4: fix open/lock state recovery error handling
    
    commit df817ba35736db2d62b07de6f050a4db53492ad8 upstream.
    
    The current open/lock state recovery unfortunately does not handle errors
    such as NFS4ERR_CONN_NOT_BOUND_TO_SESSION correctly. Instead of looping,
    just proceeds as if the state manager is finished recovering.
    This patch ensures that we loop back, handle higher priority errors
    and complete the open/lock state recovery.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60eefed4786cbefa0f4d206dfcd7e3c87c992ded
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Sep 27 17:02:26 2014 -0400

    NFSv4: Fix lock recovery when CREATE_SESSION/SETCLIENTID_CONFIRM fails
    
    commit a4339b7b686b4acc8b6de2b07d7bacbe3ae44b83 upstream.
    
    If a NFSv4.x server returns NFS4ERR_STALE_CLIENTID in response to a
    CREATE_SESSION or SETCLIENTID_CONFIRM in order to tell us that it rebooted
    a second time, then the client will currently take this to mean that it must
    declare all locks to be stale, and hence ineligible for reboot recovery.
    
    RFC3530 and RFC5661 both suggest that the client should instead rely on the
    server to respond to inelegible open share, lock and delegation reclaim
    requests with NFS4ERR_NO_GRACE in this situation.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96894152592785638ba49e3a55c5bc218aafc49e
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat Sep 27 12:31:37 2014 +0200

    lzo: check for length overrun in variable length encoding.
    
    commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream.
    
    This fix ensures that we never meet an integer overflow while adding
    255 while parsing a variable length encoding. It works differently from
    commit 206a81c ("lzo: properly check for overruns") because instead of
    ensuring that we don't overrun the input, which is tricky to guarantee
    due to many assumptions in the code, it simply checks that the cumulated
    number of 255 read cannot overflow by bounding this number.
    
    The MAX_255_COUNT is the maximum number of times we can add 255 to a base
    count without overflowing an integer. The multiply will overflow when
    multiplying 255 by more than MAXINT/255. The sum will overflow earlier
    depending on the base count. Since the base count is taken from a u8
    and a few bits, it is safe to assume that it will always be lower than
    or equal to 2*255, thus we can always prevent any overflow by accepting
    two less 255 steps.
    
    This patch also reduces the CPU overhead and actually increases performance
    by 1.1% compared to the initial code, while the previous fix costs 3.1%
    (measured on x86_64).
    
    The fix needs to be backported to all currently supported stable kernels.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Cc: "Don A. Bailey" <donb@securitymouse.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7939e1eb8de872933fc2e3fa9934aa55567a541
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat Sep 27 12:31:36 2014 +0200

    Revert "lzo: properly check for overruns"
    
    commit af958a38a60c7ca3d8a39c918c1baa2ff7b6b233 upstream.
    
    This reverts commit 206a81c ("lzo: properly check for overruns").
    
    As analysed by Willem Pinckaers, this fix is still incomplete on
    certain rare corner cases, and it is easier to restart from the
    original code.
    
    Reported-by: Willem Pinckaers <willem@lekkertech.net>
    Cc: "Don A. Bailey" <donb@securitymouse.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c60cd0d07d35b42b5e30ed4d5155bd68605a0f2d
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat Sep 27 12:31:35 2014 +0200

    Documentation: lzo: document part of the encoding
    
    commit d98a0526434d27e261f622cf9d2e0028b5ff1a00 upstream.
    
    Add a complete description of the LZO format as processed by the
    decompressor. I have not found a public specification of this format
    hence this analysis, which will be used to better understand the code.
    
    Cc: Willem Pinckaers <willem@lekkertech.net>
    Cc: "Don A. Bailey" <donb@securitymouse.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 394359bd95c76762ee2919f6bcec47f241e80e77
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun Sep 28 10:50:06 2014 +0200

    m68k: Disable/restore interrupts in hwreg_present()/hwreg_write()
    
    commit e4dc601bf99ccd1c95b7e6eef1d3cf3c4b0d4961 upstream.
    
    hwreg_present() and hwreg_write() temporarily change the VBR register to
    another vector table. This table contains a valid bus error handler
    only, all other entries point to arbitrary addresses.
    
    If an interrupt comes in while the temporary table is active, the
    processor will start executing at such an arbitrary address, and the
    kernel will crash.
    
    While most callers run early, before interrupts are enabled, or
    explicitly disable interrupts, Finn Thain pointed out that macsonic has
    one callsite that doesn't, causing intermittent boot crashes.
    There's another unsafe callsite in hilkbd.
    
    Fix this for good by disabling and restoring interrupts inside
    hwreg_present() and hwreg_write().
    
    Explicitly disabling interrupts can be removed from the callsites later.
    
    Reported-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd6174827fa6862fc2b59c2e0eeee5e5329befa2
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Wed Aug 27 16:25:35 2014 -0700

    Drivers: hv: vmbus: Fix a bug in vmbus_open()
    
    commit 45d727cee9e200f5b351528b9fb063b69cf702c8 upstream.
    
    Fix a bug in vmbus_open() and properly propagate the error. I would
    like to thank Dexuan Cui <decui@microsoft.com> for identifying the
    issue.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5e03dd7bfe9a3a9cdeb160f869b3c264d51706f
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Wed Aug 27 16:25:34 2014 -0700

    Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl()
    
    commit 72c6b71c245dac8f371167d97ef471b367d0b66b upstream.
    
    Eliminate the call to BUG_ON() by waiting for the host to respond. We are
    trying to reclaim the ownership of memory that was given to the host and so
    we will have to wait until the host responds.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a443461e9e0068d13ca632610f1bcb300f7f8768
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Wed Aug 27 16:25:32 2014 -0700

    Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl()
    
    commit 66be653083057358724d56d817e870e53fb81ca7 upstream.
    
    Eliminate calls to BUG_ON() by properly handling errors. In cases where
    rollback is possible, we will return the appropriate error to have the
    calling code decide how to rollback state. In the case where we are
    transferring ownership of the guest physical pages to the host,
    we will wait for the host to respond.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55a5b2114b4783803cd5dfb6d237be2158329b6b
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Wed Aug 27 16:25:31 2014 -0700

    Drivers: hv: vmbus: Cleanup vmbus_post_msg()
    
    commit fdeebcc62279119dbeafbc1a2e39e773839025fd upstream.
    
    Posting messages to the host can fail because of transient resource
    related failures. Correctly deal with these failures and increase the
    number of attempts to post the message before giving up.
    
    In this version of the patch, I have normalized the error code to
    Linux error code.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71e82363fbf9b4c90bd70fc3b19fd4cea58b16a9
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Sep 18 11:25:37 2014 -0700

    firmware_class: make sure fw requests contain a name
    
    commit 471b095dfe0d693a8d624cbc716d1ee4d74eb437 upstream.
    
    An empty firmware request name will trigger warnings when building
    device names. Make sure this is caught earlier and rejected.
    
    The warning was visible via the test_firmware.ko module interface:
    
    echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request
    
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e166c65c41b14aa35a1bd2dcbd4da08958321a3b
Author: Arun Easi <arun.easi@qlogic.com>
Date:   Thu Sep 25 06:14:45 2014 -0400

    qla2xxx: Use correct offset to req-q-out for reserve calculation
    
    commit 75554b68ac1e018bca00d68a430b92ada8ab52dd upstream.
    
    Signed-off-by: Arun Easi <arun.easi@qlogic.com>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6f0636b610650b66849476f0de8663f9cf5ff15
Author: Chris J Arges <chris.j.arges@canonical.com>
Date:   Tue Sep 23 09:22:25 2014 -0500

    mptfusion: enable no_write_same for vmware scsi disks
    
    commit 4089b71cc820a426d601283c92fcd4ffeb5139c2 upstream.
    
    When using a virtual SCSI disk in a VMWare VM if blkdev_issue_zeroout is used
    data can be improperly zeroed out using the mptfusion driver. This patch
    disables write_same for this driver and the vmware subsystem_vendor which
    ensures that manual zeroing out is used instead.
    
    BugLink: http://bugs.launchpad.net/bugs/1371591
    Reported-by: Bruce Lucas <bruce.lucas@mongodb.com>
    Tested-by: Chris J Arges <chris.j.arges@canonical.com>
    Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39d6457473676ef1ceeec2f384bbabb32adbd888
Author: Mike Christie <michaelc@cs.wisc.edu>
Date:   Mon Sep 29 13:55:41 2014 -0500

    be2iscsi: check ip buffer before copying
    
    commit a41a9ad3bbf61fae0b6bfb232153da60d14fdbd9 upstream.
    
    Dan Carpenter found a issue where be2iscsi would copy the ip
    from userspace to the driver buffer before checking the len
    of the data being copied:
    http://marc.info/?l=linux-scsi&m=140982651504251&w=2
    
    This patch just has us only copy what we the driver buffer
    can support.
    
    Tested-by: John Soni Jose <sony.john-n@emulex.com>
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a110e6d6ebac622c30c9d219b5b154d3d3167a20
Author: Pankaj Dubey <pankaj.dubey@samsung.com>
Date:   Sat Sep 27 09:47:55 2014 +0530

    regmap: fix NULL pointer dereference in _regmap_write/read
    
    commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream.
    
    If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL
    pointer dereference. This patch fixes this issue by adding check for
    dev->NULL in all such places in regmap.c
    
    Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9aa4aecb2e94ca383789147769291e8723ecf86
Author: Xiubo Li <Li.Xiubo@freescale.com>
Date:   Sun Sep 28 11:35:25 2014 +0800

    regmap: debugfs: fix possbile NULL pointer dereference
    
    commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream.
    
    If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer
    dereference. So before dev_name(), we need to have check of the map->dev
    pionter.
    
    We also should make sure that the 'name' pointer shouldn't be NULL for
    debugfs_create_dir(). So here using one default "dummy" debugfs name when
    the 'name' pointer and 'map->dev' are both NULL.
    
    Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ee097ac8eebdef530c6757d09bd82e08b455a08
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Sep 12 15:11:58 2014 +0300

    spi: dw-mid: check that DMA was inited before exit
    
    commit fb57862ead652454ceeb659617404c5f13bc34b5 upstream.
    
    If the driver was compiled with DMA support, but DMA channels weren't acquired
    by some reason, mid_spi_dma_exit() will crash the kernel.
    
    Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f8ae85b8ab60e025c806305f95e262d451831ac
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Sep 18 20:08:51 2014 +0300

    spi: dw-mid: respect 8 bit mode
    
    commit b41583e7299046abdc578c33f25ed83ee95b9b31 upstream.
    
    In case of 8 bit mode and DMA usage we end up with every second byte written as
    0. We have to respect bits_per_word settings what this patch actually does.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75b6cf03dd5cae671b84f60e018a6c08e5f6d4b7
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date:   Wed Sep 24 00:26:24 2014 +0100

    x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead
    
    commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de upstream.
    
    Quark x1000 advertises PGE via the standard CPUID method
    PGE bits exist in Quark X1000's PTEs. In order to flush
    an individual PTE it is necessary to reload CR3 irrespective
    of the PTE.PGE bit.
    
    See Quark Core_DevMan_001.pdf section 6.4.11
    
    This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to
    crash and burn on this platform.
    
    Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
    Cc: Borislav Petkov <bp@alien8.de>
    Link: http://lkml.kernel.org/r/1411514784-14885-1-git-send-email-pure.logic@nexus-software.ie
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7889ddde2798154828d49da8d7c8863b7573e62d
Author: David Matlack <dmatlack@google.com>
Date:   Fri Sep 19 16:03:25 2014 -0700

    kvm: don't take vcpu mutex for obviously invalid vcpu ioctls
    
    commit 2ea75be3219571d0ec009ce20d9971e54af96e09 upstream.
    
    vcpu ioctls can hang the calling thread if issued while a vcpu is running.
    However, invalid ioctls can happen when userspace tries to probe the kind
    of file descriptors (e.g. isatty() calls ioctl(TCGETS)); in that case,
    we know the ioctl is going to be rejected as invalid anyway and we can
    fail before trying to take the vcpu mutex.
    
    This patch does not change functionality, it just makes invalid ioctls
    fail faster.
    
    Signed-off-by: David Matlack <dmatlack@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68249f03d07ff212ee1b0170450985d896378f88
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Wed Sep 3 16:21:32 2014 +0200

    KVM: s390: unintended fallthrough for external call
    
    commit f346026e55f1efd3949a67ddd1dcea7c1b9a615e upstream.
    
    We must not fallthrough if the conditions for external call are not met.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Thomas Huth <thuth@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 973af5283c036d199360a4f82ce442815bf5378b
Author: David Matlack <dmatlack@google.com>
Date:   Mon Aug 18 15:46:07 2014 -0700

    kvm: x86: fix stale mmio cache bug
    
    commit 56f17dd3fbc44adcdbc3340fe3988ddb833a47a7 upstream.
    
    The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
    up to userspace:
    
    (1) Guest accesses gpa X without a memory slot. The gfn is cached in
    struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
    the SPTE write-execute-noread so that future accesses cause
    EPT_MISCONFIGs.
    
    (2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
    covering the page just accessed.
    
    (3) Guest attempts to read or write to gpa X again. On Intel, this
    generates an EPT_MISCONFIG. The memory slot generation number that
    was incremented in (2) would normally take care of this but we fast
    path mmio faults through quickly_check_mmio_pf(), which only checks
    the per-vcpu mmio cache. Since we hit the cache, KVM passes a
    KVM_EXIT_MMIO up to userspace.
    
    This patch fixes the issue by using the memslot generation number
    to validate the mmio cache.
    
    Signed-off-by: David Matlack <dmatlack@google.com>
    [xiaoguangrong: adjust the code to make it simpler for stable-tree fix.]
    Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
    Reviewed-by: David Matlack <dmatlack@google.com>
    Reviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
    Tested-by: David Matlack <dmatlack@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7dbb3e347aa3916f681b10cfbc7d12ed6ae7b34
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed Oct 8 12:32:47 2014 -0700

    fs: Add a missing permission check to do_umount
    
    commit a1480dcc3c706e309a88884723446f2e84fedd5b upstream.
    
    Accessing do_remount_sb should require global CAP_SYS_ADMIN, but
    only one of the two call sites was appropriately protected.
    
    Fixes CVE-2014-7975.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aea9dd519b41025500e678587908705ad499ac38
Author: Sage Weil <sage@redhat.com>
Date:   Fri Sep 26 08:30:06 2014 -0700

    Btrfs: fix race in WAIT_SYNC ioctl
    
    commit 42383020beb1cfb05f5d330cc311931bc4917a97 upstream.
    
    We check whether transid is already committed via last_trans_committed and
    then search through trans_list for pending transactions.  If
    last_trans_committed is updated by btrfs_commit_transaction after we check
    it (there is no locking), we will fail to find the committed transaction
    and return EINVAL to the caller.  This has been observed occasionally by
    ceph-osd (which uses this ioctl heavily).
    
    Fix by rechecking whether the provided transid <= last_trans_committed
    after the search fails, and if so return 0.
    
    Signed-off-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5525f742eb55f40c1080c5ffb39a09978d5c50ba
Author: Josef Bacik <jbacik@fb.com>
Date:   Fri Sep 19 15:43:34 2014 -0400

    Btrfs: fix build_backref_tree issue with multiple shared blocks
    
    commit bbe9051441effce51c9a533d2c56440df64db2d7 upstream.
    
    Marc Merlin sent me a broken fs image months ago where it would blow up in the
    upper->checked BUG_ON() in build_backref_tree.  This is because we had a
    scenario like this
    
    block a -- level 4 (not shared)
       |
    block b -- level 3 (reloc block, shared)
       |
    block c -- level 2 (not shared)
       |
    block d -- level 1 (shared)
       |
    block e -- level 0 (shared)
    
    We go to build a backref tree for block e, we notice block d is shared and add
    it to the list of blocks to lookup it's backrefs for.  Now when we loop around
    we will check edges for the block, so we will see we looked up block c last
    time.  So we lookup block d and then see that the block that points to it is
    block c and we can just skip that edge since we've already been up this path.
    The problem is because we clear need_check when we see block d (as it is shared)
    we never add block b as needing to be checked.  And because block c is in our
    path already we bail out before we walk up to block b and add it to the backref
    check list.
    
    To fix this we need to reset need_check if we trip over a block that doesn't
    need to be checked.  This will make sure that any subsequent blocks in the path
    as we're walking up afterwards are added to the list to be processed.  With this
    patch I can now mount Marc's fs image and it'll complete the balance without
    panicing.  Thanks,
    
    Reported-by: Marc MERLIN <marc@merlins.org>
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d619a776f8885f626c831e49bb8858597cf8b3fa
Author: Josef Bacik <jbacik@fb.com>
Date:   Thu Sep 18 11:30:44 2014 -0400

    Btrfs: try not to ENOSPC on log replay
    
    commit 1d52c78afbbf80b58299e076a159617d6b42fe3c upstream.
    
    When doing log replay we may have to update inodes, which traditionally goes
    through our delayed inode stuff.  This will try to move space over from the
    trans handle, but we don't reserve space in our trans handle on replay since we
    don't know how much we will need, so instead we try to flush.  But because we
    have a trans handle open we won't flush anything, so if we are out of reserve
    space we will simply return ENOSPC.  Since we know that if an operation made it
    into the log then we definitely had space before the box bought the farm then we
    don't need to worry about doing this space reservation.  Use the
    fs_info->log_root_recovering flag to skip the delayed inode stuff and update the
    item directly.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>