commit 07ecf16297bbec8d94012f2dd9d615f98093fbbe
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 29 05:06:37 2014 -0800

    Linux 3.13.1

commit e4e80e0bec9e03b6e323857e9bb2820f5bbe6287
Author: NeilBrown <neilb@suse.de>
Date:   Wed Jan 22 11:45:03 2014 +1100

    md/raid5: close recently introduced race in stripe_head management.
    
    commit 7da9d450ab2843bf1db378c156acc6304dbc1c2b upstream.
    
    As release_stripe and __release_stripe decrement ->count and then
    manipulate ->lru both under ->device_lock, it is important that
    get_active_stripe() increments ->count and clears ->lru also under
    ->device_lock.
    
    However we currently list_del_init ->lru under the lock, but increment
    the ->count outside the lock.  This can lead to races and list
    corruption.
    
    So move the atomic_inc(&sh->count) up inside the ->device_lock
    protected region.
    
    Note that we still increment ->count without device lock in the case
    where get_free_stripe() was called, and in fact don't take
    ->device_lock at all in that path.
    This is safe because if the stripe_head can be found by
    get_free_stripe, then the hash lock assures us the no-one else could
    possibly be calling release_stripe() at the same time.
    
    Fixes: 566c09c53455d7c4f1130928ef8071da1a24ea65
    Reported-and-tested-by: Ian Kumlien <ian.kumlien@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34fa7e82ec661cf54f21b1677d2e05173e5a812c
Author: NeilBrown <neilb@suse.de>
Date:   Thu Jan 16 09:35:38 2014 +1100

    md/raid5: fix long-standing problem with bitmap handling on write failure.
    
    commit 9f97e4b128d2ea90a5f5063ea0ee3b0911f4c669 upstream.
    
    Before a write starts we set a bit in the write-intent bitmap.
    When the write completes we clear that bit if the write was successful
    to all devices.  However if the write wasn't fully successful we
    should not clear the bit.  If the faulty drive is subsequently
    re-added, the fact that the bit is still set ensure that we will
    re-write the data that is missing.
    
    This logic is mediated by the STRIPE_DEGRADED flag - we only clear the
    bitmap bit when this flag is not set.
    Currently we correctly set the flag if a write starts when some
    devices are failed or missing.  But we do *not* set the flag if some
    device failed during the write attempt.
    This is wrong and can result in clearing the bit inappropriately.
    
    So: set the flag when a write fails.
    
    This bug has been present since bitmaps were introduces, so the fix is
    suitable for any -stable kernel.
    
    Reported-by: Ethan Wilson <ethan.wilson@shiftmail.org>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d112bace4521ff50b40b68bf1375fb5e8feed217
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Dec 18 10:46:04 2013 +0100

    ALSA: hda - Explicitly keep codec powered up in hdmi_present_sense
    
    commit da4a7a3926d09c13ae052ede67feb7285e01e3f5 upstream.
    
    This should help us avoid the following mutex deadlock:
    
    [] mutex_lock+0x2a/0x50
    [] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi]
    [] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi]
    [] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec]
    [] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec]
    [] codec_exec_verb+0x5f/0x290 [snd_hda_codec]
    [] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec]
    [] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi]
    [] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi]
    [] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi]
    [] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi]
    
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Fixes: cbbaa603a03c ('ALSA: hda - Fix possible races in HDMI driver')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4d566d8de432c1bf94f8f26dd99871601775203
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Nov 22 09:26:01 2013 -0800

    extcon: gpio: Request gpio pin before modifying its state
    
    commit 4288d9b8edcec7289e00eecdad44f14c9ea1ba0e upstream.
    
    Commit 338de0ca (extcon: gpio: Use gpio driver/chip debounce if supported)
    introduced a call to gpio_set_debounce() before actually requesting the
    respective gpio pin from the gpio subsystem.
    
    The gpio subsystem expects that a gpio pin was requested before modifying its
    state. Not doing so results in a warning from gpiolib, and the gpio pin is
    auto-requested. This in turn causes the subsequent devm_gpio_request_one()
    to fail. So devm_gpio_request_one() must be called prior to calling
    gpio_set_debounce().
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfb158e133d338823eec0c55dbe2be9f685f9739
Author: Jon Medhurst <tixy@linaro.org>
Date:   Tue Dec 10 10:18:58 2013 +0000

    serial: amba-pl011: use port lock to guard control register access
    
    commit fe43390702a1b5741fdf217063b05c7612b38303 upstream.
    
    When the pl011 is being used for a console, pl011_console_write forces
    the control register (CR) to enable the UART for transmission and then
    restores this to the original value afterwards. It does this while
    holding the port lock.
    
    Unfortunately, when the uart is started or shutdown - say in response to
    userland using the serial device for a terminal - then this updates the
    control register without any locking.
    
    This means we can have
    
      pl011_console_write   Save CR
      pl011_startup         Initialise CR, e.g. enable receive
      pl011_console_write   Restore old CR with receive not enabled
    
    this result is a serial port which doesn't respond to any input.
    
    A similar race in reverse could happen when the device is shutdown.
    
    We can fix these problems by taking the port lock when updating CR.
    
    Signed-off-by: Jon Medhurst <tixy@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6e23916a2d35a4236b43d9ac6c19c0359148b11
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jan 21 15:48:47 2014 -0800

    mm: Make {,set}page_address() static inline if WANT_PAGE_VIRTUAL
    
    commit f92f455f67fef27929e6043499414605b0c94872 upstream.
    
    {,set}page_address() are macros if WANT_PAGE_VIRTUAL.  If
    !WANT_PAGE_VIRTUAL, they're plain C functions.
    
    If someone calls them with a void *, this pointer is auto-converted to
    struct page * if !WANT_PAGE_VIRTUAL, but causes a build failure on
    architectures using WANT_PAGE_VIRTUAL (arc, m68k and sparc64):
    
      drivers/md/bcache/bset.c: In function `__btree_sort':
      drivers/md/bcache/bset.c:1190: warning: dereferencing `void *' pointer
      drivers/md/bcache/bset.c:1190: error: request for member `virtual' in something not a structure or union
    
    Convert them to static inline functions to fix this.  There are already
    plenty of users of struct page members inside <linux/mm.h>, so there's
    no reason to keep them as macros.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: David Rientjes <rientjes@google.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 924678c5d32e2259e6b261bcd45007bae9349ad4
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Thu Dec 5 13:43:28 2013 -0700

    staging: comedi: adl_pci9111: fix incorrect irq passed to request_irq()
    
    commit 48108fe3daa0d142f9b97178fdb23704ea3a407b upstream.
    
    The dev->irq passed to request_irq() will always be 0 when the auto_attach
    function is called. The pcidev->irq should be used instead to get the correct
    irq number.
    
    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 323a088a4d9905415825e451372ad7b71fe256fc
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Mon Dec 9 16:06:41 2013 -0700

    staging: comedi: addi_apci_1032: fix subdevice type/flags bug
    
    commit 90daf69a7a3f1d1a41018c799968a0bb896d65e0 upstream.
    
    The SDF_CMD_READ should be one of the s->subdev_flags not part of
    the s->type.
    
    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af7b2d49ef7b4171ef416b7ca2810834993afbca
Author: Bernd Porr <mail@berndporr.me.uk>
Date:   Wed Dec 11 16:06:15 2013 +0000

    staging: comedi: fix result of memdup_user for user chanlist
    
    commit e56b1401056288a725d50942ef300dcbed5e519a upstream.
    
    If the channel list is not set in userspace we get an error at
    PTR_ERR(async->cmd.chanlist). However, do_become_nonbusy(dev, s) cleans
    up this pointer which causes a kernel ooops. Setting the channel list in
    async to NULL and checking this in do_become_nonbusy prevents the oops.
    
    [Ian Abbott] Also do the same for the chanlist allocated in
    do_cmdtest_ioctl().
    
    Signed-off-by: Bernd Porr <mail@berndporr.me.uk>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b8c5f8b4b57c574f6cf2047e80e1565b2a07f09
Author: Bob Peterson <rpeterso@redhat.com>
Date:   Mon Jan 6 17:16:01 2014 -0500

    GFS2: Increase i_writecount during gfs2_setattr_chown
    
    commit 62e96cf81988101fe9e086b2877307b6adda5197 upstream.
    
    This patch calls get_write_access in function gfs2_setattr_chown,
    which merely increases inode->i_writecount for the duration of the
    function. That will ensure that any file closes won't delete the
    inode's multi-block reservation while the function is running.
    It also ensures that a multi-block reservation exists when needed
    for quota change operations during the chown.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>