commit acbf4c08b347d3a405319212aa6c9f85ea3edfab
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Sat Mar 22 22:02:40 2014 +0100

    Linux 3.12.16

commit 4c3280ca0ee91125e8f086d33d879065222d6daa
Author: Ilya Dryomov <ilya.dryomov@inktank.com>
Date:   Thu Jan 9 20:08:21 2014 +0200

    libceph: fix preallocation check in get_reply()
    
    commit f2be82b0058e90b5d9ac2cb896b4914276fb50ef upstream.
    
    The check that makes sure that we have enough memory allocated to read
    in the entire header of the message in question is currently busted.
    It compares front_len of the incoming message with iov_len field of
    ceph_msg::front structure, which is used primarily to indicate the
    amount of data already read in, and not the size of the allocated
    buffer.  Under certain conditions (e.g. a short read from a socket
    followed by that socket's shutdown and owning ceph_connection reset)
    this results in a warning similar to
    
    [85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0)
    
    and, through another bug, leads to forever hung tasks and forced
    reboots.  Fix this by comparing front_len with front_alloc_len field of
    struct ceph_msg, which stores the actual size of the buffer.
    
    Fixes: http://tracker.ceph.com/issues/5425
    
    Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ed0d7f08ff8b76555525a9ee61d8eed2796594c2
Author: Ilya Dryomov <ilya.dryomov@inktank.com>
Date:   Thu Jan 9 20:08:21 2014 +0200

    libceph: rename front to front_len in get_reply()
    
    commit 3f0a4ac55fe036902e3666be740da63528ad8639 upstream.
    
    Rename front local variable to front_len in get_reply() to make its
    purpose more clear.
    
    Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7335817378e3e4c3325c65b0e15b2918cc04f5c1
Author: Ilya Dryomov <ilya.dryomov@inktank.com>
Date:   Thu Jan 9 20:08:21 2014 +0200

    libceph: rename ceph_msg::front_max to front_alloc_len
    
    commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream.
    
    Rename front_max field of struct ceph_msg to front_alloc_len to make
    its purpose more clear.
    
    Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8b988a3907cc2ca7d85c4d79a2afec2914b2de0b
Author: Michele Baldessari <michele@acksyn.org>
Date:   Thu Jan 30 10:51:04 2014 +0000

    e100: Fix "disabling already-disabled device" warning
    
    commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream.
    
    In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
    https://bugzilla.redhat.com/show_bug.cgi?id=970480  we
    received different reports of e100 throwing the following
    warning:
    
     [<c06a0ba5>] ? pci_disable_device+0x85/0x90
     [<c044a153>] warn_slowpath_fmt+0x33/0x40
     [<c06a0ba5>] pci_disable_device+0x85/0x90
     [<f7fdf7e0>] __e100_shutdown+0x80/0x120 [e100]
     [<c0476ca5>] ? check_preempt_curr+0x65/0x90
     [<f7fdf8d6>] e100_suspend+0x16/0x30 [e100]
     [<c06a1ebb>] pci_legacy_suspend+0x2b/0xb0
     [<c098fc0f>] ? wait_for_completion+0x1f/0xd0
     [<c06a2d50>] ? pci_pm_poweroff+0xb0/0xb0
     [<c06a2de4>] pci_pm_freeze+0x94/0xa0
     [<c0767bb7>] dpm_run_callback+0x37/0x80
     [<c076a204>] ? pm_wakeup_pending+0xc4/0x140
     [<c0767f12>] __device_suspend+0xb2/0x1f0
     [<c076806f>] async_suspend+0x1f/0x90
     [<c04706e5>] async_run_entry_fn+0x35/0x140
     [<c0478aef>] ? wake_up_process+0x1f/0x40
     [<c0464495>] process_one_work+0x115/0x370
     [<c0462645>] ? start_worker+0x25/0x30
     [<c0464dc5>] ? manage_workers.isra.27+0x1a5/0x250
     [<c0464f6e>] worker_thread+0xfe/0x330
     [<c0464e70>] ? manage_workers.isra.27+0x250/0x250
     [<c046a224>] kthread+0x94/0xa0
     [<c0997f37>] ret_from_kernel_thread+0x1b/0x28
     [<c046a190>] ? insert_kthread_work+0x30/0x30
    
    This patch removes pci_disable_device() from __e100_shutdown().
    pci_clear_master() is enough.
    
    Signed-off-by: Michele Baldessari <michele@acksyn.org>
    Tested-by: Mark Harig <idirectscm@aim.com>
    Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1e716a5e78cb28cb004ccb58d904191f0d1cbba3
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 17 15:38:12 2014 -0800

    xhci: Fix resume issues on Renesas chips in Samsung laptops
    
    commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.
    
    Don Zickus <dzickus@redhat.com> writes:
    
    Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
    Those ports did not resume correctly (the driver would timeout communicating
    and fail).  This led to frustration as suspend/resume is a common use for
    laptops.
    
    Poking around, I applied the reset on resume quirk to this chipset and the
    resume started working.  Reloading the xhci_hcd module had been the temporary
    workaround.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Don Zickus <dzickus@redhat.com>
    Tested-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 16cf0c328d308b4bfb2baf0257bfdff47899a6ca
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Mon Nov 25 18:43:45 2013 -0800

    Input: wacom - make sure touch_max is set for touch devices
    
    commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream.
    
    Old single touch Tablet PCs do not have touch_max set at
    wacom_features. Since touch device at lease supports one
    finger, assign touch_max to 1 when touch usage is defined
    in its HID Descriptor and touch_max is not pre-defined.
    
    Tested-by: Jason Gerecke <killertofu@gmail.com>
    Signed-off-by: Ping Cheng <pingc@wacom.com>
    Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5b6325c676690b26685c55998c49cea0a437fd24
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Fri Jan 3 17:00:51 2014 -0200

    KVM: VMX: fix use after free of vmx->loaded_vmcs
    
    commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.
    
    After free_loaded_vmcs executes, the "loaded_vmcs" structure
    is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
    Subsequent free_loaded_vmcs then attempts to manipulate
    vmx->loaded_vmcs.
    
    Switch the order to avoid the problem.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1047892
    
    Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit df071bf16dc2e1d12d36f8d3861df672376d5c75
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Fri Jan 3 17:09:32 2014 -0200

    KVM: x86: handle invalid root_hpa everywhere
    
    commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream.
    
    Rom Freiman <rom@stratoscale.com> notes other code paths vulnerable to
    bug fixed by 989c6b34f6a9480e397b.
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0334c2e03c00144d2ff68c97a1ff93a640883c57
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Thu Dec 19 15:28:51 2013 -0200

    KVM: MMU: handle invalid root_hpa at __direct_map
    
    commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.
    
    It is possible for __direct_map to be called on invalid root_hpa
    (-1), two examples:
    
    1) try_async_pf -> can_do_async_pf
        -> vmx_interrupt_allowed -> nested_vmx_vmexit
    2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit
    
    Then to load_vmcs12_host_state and kvm_mmu_reset_context.
    
    Check for this possibility, let fault exception be regenerated.
    
    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1743fc6cc6a54a4fac440ce885752cee819ed25a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 16 07:09:25 2013 -0800

    Input: elantech - improve clickpad detection
    
    commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.
    
    The current assumption in the elantech driver that hw version 3 touchpads
    are never clickpads and hw version 4 touchpads are always clickpads is
    wrong.
    
    There are several bug reports for this, ie:
    https://bugzilla.redhat.com/show_bug.cgi?id=1030802
    http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux
    
    I've spend a couple of hours wading through various bugzillas, launchpads
    and forum posts to create a list of fw-versions and capabilities for
    different laptop models to find a good method to differentiate between
    clickpads and versions with separate hardware buttons.
    
    Which shows that a device being a clickpad is reliable indicated by bit 12
    being set in the fw_version. I've included the gathered list inside the
    driver, so that we've this info at hand if we need to revisit this later.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6d05cdce4fb86af309b91cc1e055e995f79c9a72
Author: Dave Jones <davej@redhat.com>
Date:   Thu Jan 23 15:55:43 2014 -0800

    fs/proc/proc_devtree.c: remove empty /proc/device-tree when no openfirmware exists.
    
    commit c1d867a54d426b45da017fbe8e585f8a3064ce8d upstream.
    
    Distribution kernels might want to build in support for /proc/device-tree
    for kernels that might end up running on hardware that doesn't support
    openfirmware.  This results in an empty /proc/device-tree existing.
    Remove it if the OFW root node doesn't exist.
    
    This situation actually confuses grub2, resulting in install failures.
    grub2 sees the /proc/device-tree and picks the wrong install target cf.
    http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/4300/util/grub-install.in#L311
    grub should be more robust, but still, leaving an empty proc dir seems
    pointless.
    
    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=818378.
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Josh Boyer <jwboyer@fedoraproject.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 20a9e39efdd640c57aa348d53a149ff0692e842a
Author: Gavin Shan <shangw@linux.vnet.ibm.com>
Date:   Wed Jan 15 13:16:11 2014 +0800

    powerpc/eeh: Handle multiple EEH errors
    
    commit 7e4e7867b1e551b7b8f326da3604c47332972bc6 upstream.
    
    For one PCI error relevant OPAL event, we possibly have multiple
    EEH errors for that. For example, multiple frozen PEs detected on
    different PHBs. Unfortunately, we didn't cover the case. The patch
    enumarates the return value from eeh_ops::next_error() and change
    eeh_handle_special_event() and eeh_ops::next_error() to handle all
    existing EEH errors.
    
    As Ben pointed out, we needn't list_for_each_entry_safe() since we
    are not deleting any PHB from the hose_list and the EEH serialized
    lock should be held while purging EEH events. The patch covers those
    suggestions as well.
    
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8ebdd122d3a30463bf10ea8120939d2f69b1608a
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Thu Feb 20 17:36:04 2014 +0100

    regulator: core: Replace direct ops->disable usage
    
    commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream.
    
    There are many places where ops->disable is called directly. Instead we
    should use _regulator_do_disable() which also handles gpio regulators.
    
    To be able to use the wrapper function from _regulator_force_disable(),
    I moved the _notifier_call_chain() call from _regulator_do_disable() to
    _regulator_disable(). This way, _regulator_force_disable() can use
    different flags for _notifier_call_chain() without calling it twice.
    
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f615b037e16b61fb9358fdd94dec9728b8df90d8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jan 13 22:05:23 2014 +0300

    p54: clamp properly instead of just truncating
    
    commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.
    
    The call to clamp_t() first truncates the variable signed 8 bit and as a
    result, the actual clamp is a no-op.
    
    Fixes: 0d78156eef1d ('p54: improve site survey')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7eb5fad9a3e737438329d1d1a4b22fa3fbf240f2
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 5 14:37:35 2013 +0000

    deb-pkg: Fix cross-building linux-headers package
    
    commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.
    
    builddeb generates a control file that says the linux-headers package
    can only be built for the build system primary architecture.  This
    breaks cross-building configurations.  We should use $debarch for this
    instead.
    
    Since $debarch is not yet set when generating the control file, set
    Architecture: any and use control file variables to fill in the
    description.
    
    Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
    Reported-and-tested-by: "Niew, Sh." <shniew@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 363103b6944721b60cf28c3531fae5cd5e1edb98
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 5 14:39:11 2013 +0000

    deb-pkg: Fix building for MIPS big-endian or ARM OABI
    
    commit c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream.
    
    These commands will mysteriously fail:
    
    $ make ARCH=arm versatile_defconfig
    [...]
    $ make ARCH=arm deb-pkg
    [...]
    make[1]: *** [deb-pkg] Error 1
    make: *** [deb-pkg] Error 2
    
    The Debian architecture selection for these kernel architectures does
    'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this
    aborts the script if grep does not find the given config symbol.
    
    Fixes: 10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE')
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 20c5552a8a399d0b4296d68d5759896d85f46acb
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Feb 17 12:24:45 2014 -0800

    printk: fix syslog() overflowing user buffer
    
    commit e4178d809fdaee32a56833fff1f5056c99e90a1a upstream.
    
    This is not a buffer overflow in the traditional sense: we don't
    overflow any *kernel* buffers, but we do mis-count the amount of data we
    copy back to user space for the SYSLOG_ACTION_READ_ALL case.
    
    In particular, if the user buffer is too small to hold everything, and
    *if* there is a continuation line at just the right place, we can end up
    giving the user more data than he asked for.
    
    The reason is that we first count up the number of bytes all the log
    records contains, then we walk the records again until we've skipped the
    records at the beginning that won't fit, and then we walk the rest of
    the records and copy them to the user space buffer.
    
    And in between that "skip the initial records that won't fit" and the
    "copy the records that *will* fit to user space", we reset the 'prev'
    variable that contained the record information for the last record not
    copied.  That meant that when we started copying to user space, we now
    had a different character count than what we had originally calculated
    in the first record walk-through.
    
    The fix is to simply not clear the 'prev' flags value (in both cases
    where we had the same logic: syslog_print_all and kmsg_dump_get_buffer:
    the latter is used for pstore-like dumping)
    
    Reported-and-tested-by: Debabrata Banerjee <dbanerje@akamai.com>
    Acked-by: Kay Sievers <kay@vrfy.org>
    Cc: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Josh Hunt <joshhunt00@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 03961b13eea339809447597c9222a87a3ee0d059
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Mon Mar 10 15:56:51 2014 -0700

    x86: bpf_jit: support negative offsets
    
    commit fdfaf64e75397567257e1051931f9a3377360665 upstream.
    
    Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
    but it couldn't be working, since at the time of the execution
    of LD+ABS or LD+IND instructions via call into
    bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
    had junk value instead of access size in bytes (1 or 2 or 4).
    
    Store size into %edx instead of %ecx (what original commit intended to do)
    
    Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Cc: Jan Seiffert <kaffeemonster@googlemail.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e9fc4074f0325b19f31bd407eb70739d49cfaf6d
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Thu Jan 23 14:35:48 2014 +0000

    sfc: Use the correct maximum TX DMA ring size for SFC9100
    
    commit d9317aea16ecec7694271ef11fb7791a0f0d9cc5 upstream.
    
    As part of a workaround for a hardware erratum in the SFC9100 family
    (SF bug 35388), the TX_DESC_UPD_DWORD register address is also used
    for communicating with the event block, and only descriptor pointer
    values < 2048 are valid.
    
    If the TX DMA ring size is increased to 4096 descriptors (which the
    firmware still allows) then we may write a descriptor pointer
    value >= 2048, which has entirely different and undesirable effects!
    
    Limit the TX DMA ring size correctly when this workaround is in
    effect.
    
    Fixes: 8127d661e77f ('sfc: Add support for Solarflare SFC9100 family')
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Shradha Shah <sshah@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9c831038cc7e6d2bc48034a6e8e328ed71cb7270
Author: Stephen Warren <swarren@nvidia.com>
Date:   Thu Feb 13 16:54:24 2014 -0700

    ASoC: max98090: make REVISION_ID readable
    
    commit e126a646f77fdd66978785cb0a3a5e46b07aee2e upstream.
    
    The REVISION_ID register is not currently marked readable. snd_soc_read()
    refuses to read the register, and hence probe() fails.
    
    Fixes: d4807ad2c4c0 ("regmap: Check readable regs in _regmap_read")
    [exposed the bug, by checking for readability]
    Fixes: 685e42154dcf ("ASoC: Replace max98090 Device Driver")
    [left out this register from the readable list]
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fcd6ba0f80c3b3fcad379e622a97477ae7065a71
Author: Josh Durgin <josh.durgin@inktank.com>
Date:   Tue Dec 10 09:35:13 2013 -0800

    libceph: resend all writes after the osdmap loses the full flag
    
    commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.
    
    With the current full handling, there is a race between osds and
    clients getting the first map marked full. If the osd wins, it will
    return -ENOSPC to any writes, but the client may already have writes
    in flight. This results in the client getting the error and
    propagating it up the stack. For rbd, the block layer turns this into
    EIO, which can cause corruption in filesystems above it.
    
    To avoid this race, osds are being changed to drop writes that came
    from clients with an osdmap older than the last osdmap marked full.
    In order for this to work, clients must resend all writes after they
    encounter a full -> not full transition in the osdmap. osds will wait
    for an updated map instead of processing a request from a client with
    a newer map, so resent writes will not be dropped by the osd unless
    there is another not full -> full transition.
    
    This approach requires both osds and clients to be fixed to avoid the
    race. Old clients talking to osds with this fix may hang instead of
    returning EIO and potentially corrupting an fs. New clients talking to
    old osds have the same behavior as before if they encounter this race.
    
    Fixes: http://tracker.ceph.com/issues/6938
    
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7388cfc1876b7caf0747d6864b74e7bef59a4ad2
Author: Josh Durgin <josh.durgin@inktank.com>
Date:   Mon Dec 2 19:11:48 2013 -0800

    libceph: block I/O when PAUSE or FULL osd map flags are set
    
    commit d29adb34a94715174c88ca93e8aba955850c9bde upstream.
    
    The PAUSEWR and PAUSERD flags are meant to stop the cluster from
    processing writes and reads, respectively. The FULL flag is set when
    the cluster determines that it is out of space, and will no longer
    process writes.  PAUSEWR and PAUSERD are purely client-side settings
    already implemented in userspace clients. The osd does nothing special
    with these flags.
    
    When the FULL flag is set, however, the osd responds to all writes
    with -ENOSPC. For cephfs, this makes sense, but for rbd the block
    layer translates this into EIO.  If a cluster goes from full to
    non-full quickly, a filesystem on top of rbd will not behave well,
    since some writes succeed while others get EIO.
    
    Fix this by blocking any writes when the FULL flag is set in the osd
    client. This is the same strategy used by userspace, so apply it by
    default.  A follow-on patch makes this configurable.
    
    __map_request() is called to re-target osd requests in case the
    available osds changed.  Add a paused field to a ceph_osd_request, and
    set it whenever an appropriate osd map flag is set.  Avoid queueing
    paused requests in __map_request(), but force them to be resent if
    they become unpaused.
    
    Also subscribe to the next osd map from the monitor if any of these
    flags are set, so paused requests can be unblocked as soon as
    possible.
    
    Fixes: http://tracker.ceph.com/issues/6079
    
    Reviewed-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d5ce3633797811aa7274d49cc13aff4d1665b22e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 22 04:51:47 2013 -0300

    media: cx18: check for allocation failure in cx18_read_eeprom()
    
    commit e351bf25fa373a3de0be2141b962c5c3c27006a2 upstream.
    
    It upsets static checkers when we don't check for allocation failure.  I
    moved the memset() of "tv" earlier so we don't use uninitialized data on
    error.
    Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Andy Walls <awalls@md.metrocast.net>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 560febde5250115f1ac28fe21ee72790e09e42d9
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 22 04:56:33 2013 -0300

    media: dw2102: some missing unlocks on error
    
    commit 324ed533bf0b23c309b805272c4ffcc5d51493a6 upstream.
    
    We recently introduced some new error paths but the unlocks are missing.
    Fixes: 0065a79a8698 ('[media] dw2102: Don't use dynamic static allocation')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fc3200dcb5db366c4acb031b644fdd6b1c37f392
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 22 04:55:43 2013 -0300

    media: cxusb: unlock on error in cxusb_i2c_xfer()
    
    commit 1cdbcc5db4e6d51ce9bb1313195167cada9aa6e9 upstream.
    
    We recently introduced some new error paths which are missing their
    unlocks.
    Fixes: 64f7ef8afbf8 ('[media] cxusb: Don't use dynamic static allocation')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1fd2acab4c32240c1df5dad22d907f68f9db15b2
Author: Christian Riesch <christian.riesch@omicron.at>
Date:   Mon Mar 24 13:46:26 2014 +0100

    net: davinci_emac: Replace devm_request_irq with request_irq
    
    commit 33b7107f59a61236d94ecd6b45e20283cd5abcc8 upstream.
    
    In commit 6892b41d9701283085b655c6086fb57a5d63fa47
    
    Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Date:   Tue Jun 25 21:24:51 2013 +0530
    net: davinci: emac: Convert to devm_* api
    
    the call of request_irq is replaced by devm_request_irq and the call
    of free_irq is removed. But since interrupts are requested in
    emac_dev_open, doing ifconfig up/down on the board requests the
    interrupts again each time, causing devm_request_irq to fail. The
    interface is dead until the device is rebooted.
    
    This patch reverts said commit partially: It changes the driver back
    to use request_irq instead of devm_request_irq, puts free_irq back in
    place, but keeps the remaining changes of the original patch.
    
    Reported-by: Jon Ringle <jon@ringle.org>
    Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
    Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c0316f975b1a29a1161f86d524150f493188e9b2
Author: Vaibhav Nagarnaik <vnagarnaik@google.com>
Date:   Thu Feb 13 19:51:48 2014 -0800

    tracing: Fix array size mismatch in format string
    
    commit 87291347c49dc40aa339f587b209618201c2e527 upstream.
    
    In event format strings, the array size is reported in two locations.
    One in array subscript and then via the "size:" attribute. The values
    reported there have a mismatch.
    
    For e.g., in sched:sched_switch the prev_comm and next_comm character
    arrays have subscript values as [32] where as the actual field size is
    16.
    
    name: sched_switch
    ID: 301
    format:
            field:unsigned short common_type;       offset:0;       size:2; signed:0;
            field:unsigned char common_flags;       offset:2;       size:1; signed:0;
            field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
            field:int common_pid;   offset:4;       size:4; signed:1;
    
            field:char prev_comm[32];       offset:8;       size:16;        signed:1;
            field:pid_t prev_pid;   offset:24;      size:4; signed:1;
            field:int prev_prio;    offset:28;      size:4; signed:1;
            field:long prev_state;  offset:32;      size:8; signed:1;
            field:char next_comm[32];       offset:40;      size:16;        signed:1;
            field:pid_t next_pid;   offset:56;      size:4; signed:1;
            field:int next_prio;    offset:60;      size:4; signed:1;
    
    After bisection, the following commit was blamed:
    92edca0 tracing: Use direct field, type and system names
    
    This commit removes the duplication of strings for field->name and
    field->type assuming that all the strings passed in
    __trace_define_field() are immutable. This is not true for arrays, where
    the type string is created in event_storage variable and field->type for
    all array fields points to event_storage.
    
    Use __stringify() to create a string constant for the type string.
    
    Also, get rid of event_storage and event_storage_mutex that are not
    needed anymore.
    
    also, an added benefit is that this reduces the overhead of events a bit more:
    
       text    data     bss     dec     hex filename
    8424787 2036472 1302528 11763787         b3804b vmlinux
    8420814 2036408 1302528 11759750         b37086 vmlinux.patched
    
    Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com
    
    Cc: Laurent Chavey <chavey@google.com>
    Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bf7cda9a0101c4a149aa5846306df9d21dd5cc2b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 18 14:50:50 2014 +0200

    drm/i915: Disable stolen memory when DMAR is active
    
    commit 0f4706d2740f2a221cd502922b22e522009041d9 upstream.
    
    We have reports of heavy screen corruption if we try to use the stolen
    memory reserved by the BIOS whilst the DMA-Remapper is active. This
    quirk may be only specific to a few machines or BIOSes, but first lets
    apply the big hammer and always disable use of stolen memory when DMAR
    is active.
    
    v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 07a2f05ccb2b392a0360653eb6f9d32906e2d516
Author: Stefan Agner <stefan@agner.ch>
Date:   Wed Mar 5 23:11:08 2014 +0100

    clocksource: vf_pit_timer: use complement for sched_clock reading
    
    commit 224aa3ed45c8735ae02bb2ecca002409fa6aa772 upstream.
    
    Vybrids PIT register is monitonic decreasing. However, sched_clock
    reading needs to be monitonic increasing. Use bitwise not to get
    the complement of the clock register. This fixes the clock going
    backward. Also, the clock now starts at 0 since we load the
    register with the maximum value at start.
    
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: daniel.lezcano@linaro.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux@arm.linux.org.uk
    Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit aaaf6019ec191283b55b257deacc4c62ed9b26fb
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Wed Mar 19 12:59:39 2014 +0000

    ALSA: compress: Pass through return value of open ops callback
    
    commit 749d32237bf39e6576dd95bfdf24e4378e51716c upstream.
    
    The snd_compr_open function would always return 0 even if the compressed
    ops open function failed, obviously this is incorrect. Looks like this
    was introduced by a small typo in:
    
    commit a0830dbd4e42b38aefdf3fb61ba5019a1a99ea85
    ALSA: Add a reference counter to card instance
    
    This patch returns the value from the compressed op as it should.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 49ae3ce036a7bbaad86c36b1f8b1cfabe005cd05
Author: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Date:   Wed Feb 26 16:51:24 2014 +0900

    HID: hidraw: fix warning destroying hidraw device files after parent
    
    commit 47587fc098451c2100dc1fb618855fc2e2d937af upstream.
    
    I noticed that after hot unplugging a Logitech unifying receiver
    (drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a
    stack trace similar to this:
    
    usb 1-1.1.2: USB disconnect, device number 7
    WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0()
    sysfs group ffffffff8187fa20 not found for kobject 'hidraw0'
    [...]
    CPU: 0 PID: 2865 Comm: upowerd Tainted: G        W 3.14.0-rc4 #7
    Hardware name: LENOVO 7783PN4/        , BIOS 9HKT43AUS 07/11/2011
     0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7
     ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8
     ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028
    Call Trace:
     [<ffffffff814cd684>] ? dump_stack+0x41/0x51
     [<ffffffff810616e7>] ? warn_slowpath_common+0x77/0x90
     [<ffffffff8106174c>] ? warn_slowpath_fmt+0x4c/0x50
     [<ffffffff81374fd0>] ? device_del+0x40/0x1b0
     [<ffffffff8137516f>] ? device_unregister+0x2f/0x50
     [<ffffffff813751fa>] ? device_destroy+0x3a/0x40
     [<ffffffffa03ca245>] ? drop_ref+0x55/0x120 [hid]
     [<ffffffffa03ca3e6>] ? hidraw_release+0x96/0xb0 [hid]
     [<ffffffff811929da>] ? __fput+0xca/0x210
     [<ffffffff8107fe17>] ? task_work_run+0x97/0xd0
     [<ffffffff810139a9>] ? do_notify_resume+0x69/0xa0
     [<ffffffff814dbd22>] ? int_signal+0x12/0x17
    ---[ end trace 63f4a46f6566d737 ]---
    
    During device removal hid_disconnect() is called via hid_hw_stop() to
    stop the device and free all its resources, including the sysfs
    files. The problem is that if a user space process, such as upowerd,
    holds a reference to a hidraw file the corresponding sysfs files will
    be kept around (drop_ref() does not call device_destroy() if the open
    counter is not 0) and it will be usb_disconnect() who, by calling
    device_del() for the USB device, will indirectly remove the sysfs
    files of the hidraw device (sysfs_remove_dir() is recursive these
    days). Because of this, by the time user space releases the last
    reference to the hidraw file and drop_ref() tries to destroy the
    device the sysfs files are already gone and the kernel will print
    the warning above.
    
    Fix this by calling device_destroy() at USB disconnect time.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 304dfba651cecbac257ecfef9b12779f0e98ff2a
Author: Stephen Warren <swarren@nvidia.com>
Date:   Tue Feb 18 16:51:58 2014 -0700

    ARM: tegra: only run PL310 init on systems with one
    
    commit 8859685785bfafadf9bc922dd3a2278e59886947 upstream.
    
    Fix tegra_init_cache() to check whether the system has a PL310 cache
    before touching the PL310 registers. This prevents access to non-existent
    registers on Tegra114 and later.
    
    Note for stable kernels:
    In <= v3.12, the file to patch is arch/arm/mach-tegra/common.c.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dffdacf81b8705d6d1a43ccb9fdf60da750f75f9
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Fri Nov 29 10:56:14 2013 +0000

    arm64: Use Normal NonCacheable memory for writecombine
    
    commit 4f00130b70e5eee813cc7bc298e0f3fdf79673cc upstream.
    
    This provides better performance compared to Device GRE and also allows
    unaligned accesses. Such memory is intended to be used with standard RAM
    (e.g. framebuffers) and not I/O.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8c992df26ee88eb93c39c1ce187c9003a997001e
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Thu Nov 14 15:15:37 2013 +0000

    arm64: dts: Reserve the memory used for secondary CPU release address
    
    commit df503ba7f653c590b475ab80bde788edf5af70d5 upstream.
    
    With the spin-table SMP booting method, secondary CPUs poll a location
    passed in the DT. The foundation-v8.dts file doesn't have this memory
    reserved and there is a risk of Linux using it before secondary CPUs are
    started.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9dd6503025b97a699c92da785eff35d66eb7358a
Author: Simon Wood <simon@mungewell.org>
Date:   Wed Nov 6 12:30:43 2013 -0700

    HID:hid-lg4ff: Initialize device properties before we touch autocentering.
    
    commit 114a55cf9dd1576e7ac56189832cd4d7dc56c218 upstream.
    
    Re-arrange code slightly to ensure that device properties are configured
    before calling auto-center command.
    
    Reported-by: Michal Malý <madcatxster@prifuk.cz>
    Signed-off-by: Simon Wood <simon@mungewell.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6bbc17f7d8d495f66556a550b69beddbd1aa438
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Thu Oct 31 13:24:28 2013 +0100

    s390/dasd: hold request queue sysfs lock when calling elevator_init()
    
    commit ef0899410ff630b2e75306da49996dbbfa318165 upstream.
    
    "elevator: Fix a race in elevator switching and md device initialization"
    changed the semantics of elevator_init() in a way that now enforces to hold
    the corresponding request queue's sysfs_lock when calling elevator_init()
    to fix a race.
    The patch did not convert the s390 dasd device driver which is the only
    device driver which also calls elevator_init(). So add the missing locking.
    
    Cc: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e35c7079f86c08cf6808f9cd3bcc5f6e944318f3
Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
Date:   Thu Oct 3 06:47:44 2013 +0100

    arm64: check for number of arguments in syscall_get/set_arguments()
    
    commit 7b22c03536a539142f931815528d55df455ffe2d upstream.
    
    In ftrace_syscall_enter(),
        syscall_get_arguments(..., 0, n, ...)
            if (i == 0) { <handle orig_x0> ...; n--;}
            memcpy(..., n * sizeof(args[0]));
    If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
    syscall_get_arguments(), none of arguments should be copied by memcpy().
    Otherwise 'n--' can be a big positive number and unexpected amount of data
    will be copied. Tracing system calls which take no argument, say sync(void),
    may hit this case and eventually make the system corrupted.
    This patch fixes the issue both in syscall_get_arguments() and
    syscall_set_arguments().
    
    Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fb5277ee5110caec1e8483b8f092e4a7de94d65c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Mar 27 09:52:01 2014 +0100

    iscsi/iser-target: fix build warning
    
    With upstream commit defd884845297fd5690594bfe89656b01f16d87e, 3.12
    commit 2f82fa987df6b060241fc760eadf5dd02c51a979, we introduced a
    warning:
      drivers/infiniband/ulp/isert/ib_isert.c: In function 'isert_cq_rx_comp_err':
      drivers/infiniband/ulp/isert/ib_isert.c:##L##: warning: unused variable 'ib_dev' [-Wunused-variable]
    
    Remove ib_dev as it is unused.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Cc: Nicholas Bellinger <nab@linux-iscsi.org>

commit e86b14ce46d56f6f84ccacec45466d9b18bef1c2
Author: Mengdong Lin <mengdong.lin@intel.com>
Date:   Wed Jan 8 15:55:32 2014 -0500

    ALSA: hda/hdmi - apply all Haswell fix-ups to Broadwell display codec
    
    commit 75dcbe4dc251ebc28cdf0797b85774cdf53a4d29 upstream.
    
    Broadwell and Haswell have the same behavior on display audio. So this patch
    defines is_haswell_plus() to include codecs for both Haswell and its successor
    Broadwell, and apply all Haswell fix-ups to Broadwell.
    
    Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a628ce56b7f1018764a0315339e2116bca965ffc
Author: Mengdong Lin <mengdong.lin@intel.com>
Date:   Wed Jan 8 15:55:24 2014 -0500

    ALSA: hda - add codec ID for Broadwell display audio codec
    
    commit 3adadd280a5a78efabdec394c1e745a3f5a1cc18 upstream.
    
    This patch adds codec ID (0x80862808) and module alias for Broadwell
    display codec.
    
    Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5de87726a1c396bc04dfaa65316e1d5eb7827561
Author: Mengdong Lin <mengdong.lin@intel.com>
Date:   Wed Jan 8 15:55:14 2014 -0500

    ALSA: hda - add device ID for Broadwell display audio controller
    
    commit 862d761818ba2cb785a0a57557f97a43bd1bc922 upstream.
    
    This patch adds the device ID for Intel Broadwell display HD-Audio controller,
    and applies Haswell properties to this device.
    
    Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ad727c5a26d6a7833471ffe06be55d296f8ce7d9
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Mar 26 11:25:37 2014 +0100

    ibmveth: Fix endian issues with MAC addresses
    
    commit d746ca9561440685edb62614d1bcbbc27ff50e66 upstream.
    
    The code to load a MAC address into a u64 for passing to the
    hypervisor via a register is broken on little endian.
    
    Create a helper function called ibmveth_encode_mac_addr
    which does the right thing in both big and little endian.
    
    We were storing the MAC address in a long in struct ibmveth_adapter.
    It's never used so remove it - we don't need another place in the
    driver where we create endian issues with MAC addresses.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Torsten Duwe <duwe@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 59d9c5f94655a3cc63e2772e847509010598b7f1
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Feb 11 16:05:46 2014 +0800

    cgroup: protect modifications to cgroup_idr with cgroup_mutex
    
    commit 0ab02ca8f887908152d1a96db5130fc661d36a1e upstream.
    
    Setup cgroupfs like this:
      # mount -t cgroup -o cpuacct xxx /cgroup
      # mkdir /cgroup/sub1
      # mkdir /cgroup/sub2
    
    Then run these two commands:
      # for ((; ;)) { mkdir /cgroup/sub1/tmp && rmdir /mnt/sub1/tmp; } &
      # for ((; ;)) { mkdir /cgroup/sub2/tmp && rmdir /mnt/sub2/tmp; } &
    
    After seconds you may see this warning:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 25243 at lib/idr.c:527 sub_remove+0x87/0x1b0()
    idr_remove called for id=6 which is not allocated.
    ...
    Call Trace:
     [<ffffffff8156063c>] dump_stack+0x7a/0x96
     [<ffffffff810591ac>] warn_slowpath_common+0x8c/0xc0
     [<ffffffff81059296>] warn_slowpath_fmt+0x46/0x50
     [<ffffffff81300aa7>] sub_remove+0x87/0x1b0
     [<ffffffff810f3f02>] ? css_killed_work_fn+0x32/0x1b0
     [<ffffffff81300bf5>] idr_remove+0x25/0xd0
     [<ffffffff810f2bab>] cgroup_destroy_css_killed+0x5b/0xc0
     [<ffffffff810f4000>] css_killed_work_fn+0x130/0x1b0
     [<ffffffff8107cdbc>] process_one_work+0x26c/0x550
     [<ffffffff8107eefe>] worker_thread+0x12e/0x3b0
     [<ffffffff81085f96>] kthread+0xe6/0xf0
     [<ffffffff81570bac>] ret_from_fork+0x7c/0xb0
    ---[ end trace 2d1577ec10cf80d0 ]---
    
    It's because allocating/removing cgroup ID is not properly synchronized.
    
    The bug was introduced when we converted cgroup_ida to cgroup_idr.
    While synchronization is already done inside ida_simple_{get,remove}(),
    users are responsible for concurrent calls to idr_{alloc,remove}().
    
    [mhocko@suse.cz: ported to 3.12]
    Fixes: 4e96ee8e981b ("cgroup: convert cgroup_ida to cgroup_idr")
    Cc: <stable@vger.kernel.org> #3.12+
    Reported-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 293639e5b70e7c19b36bf1504d09dac574b30895
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Jan 11 11:22:18 2014 +0000

    ARM: ignore memory below PHYS_OFFSET
    
    commit 571b14375019c3a66ef70d4d4a7083f4238aca30 upstream.
    
    If the kernel is loaded higher in physical memory than normal, and we
    calculate PHYS_OFFSET higher than the start of RAM, this leads to
    boot problems as we attempt to map part of this RAM into userspace.
    Rather than struggle with this, just truncate the mapping.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1e9a0925a3e8dc5705eb386cde8b7033d4fbc518
Author: Magnus Damm <damm@opensource.se>
Date:   Tue Oct 22 17:59:54 2013 +0100

    ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t
    
    commit 6d7d5da7d75c6df676c8b72d32b02ff024438f0c upstream.
    
    Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine
    if ignoring or truncating of memory banks is
    neccessary. This may be needed in the case of
    64-bit memory bank addresses but when phys_addr_t
    is kept 32-bit.
    
    Signed-off-by: Magnus Damm <damm@opensource.se>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dec2e6e6bd7cc728a9b3091075dd17aef6b4c33c
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Mar 22 10:00:50 2014 -0400

    NFSv4: Fix another nfs4_sequence corruptor
    
    commit b7e63a1079b266866a732cf699d8c4d61391bbda upstream.
    
    nfs4_release_lockowner needs to set the rpc_message reply to point to
    the nfs4_sequence_res in order to avoid another Oopsable situation
    in nfs41_assign_slot.
    
    Fixes: fbd4bfd1d9d21 (NFS: Add nfs4_sequence calls for RELEASE_LOCKOWNER)
    Cc: stable@vger.kernel.org # 3.12+
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bda870334924cbb6daa011713adfe65a24730e68
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date:   Mon Mar 24 21:40:06 2014 -0700

    ARM: 7950/1: mm: Fix stage-2 device memory attributes
    
    commit 4d9c5b89cf3605bbc39c6e274351ff25f0d83e6a upstream.
    
    The stage-2 memory attributes are distinct from the Hyp memory
    attributes and the Stage-1 memory attributes.  We were using the stage-1
    memory attributes for stage-2 mappings causing device mappings to be
    mapped as normal memory.  Add the S2 equivalent defines for memory
    attributes and fix the comments explaining the defines while at it.
    
    Add a prot_pte_s2 field to the mem_type struct and fill out the field
    for device mappings accordingly.
    
    Cc: <stable@vger.kernel.org>	[3.12]
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3d316682dc951d54ac0c9927968fdfe372d47c37
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sat Mar 22 21:35:43 2014 +0200

    iwlwifi: mvm: don't WARN when statistics are handled late
    
    commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream.
    
    Since the statistics handler is asynchrous, it can very well
    be that we will handle the statistics (hence the RSSI
    fluctuation) when we already disassociated.
    Don't WARN on this case.
    
    This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998
    
    Cc: <stable@vger.kernel.org> [3.10+]
    Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power")
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>