commit d0266db287d492abe63e19859ad99dd232bc0e89
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Dec 20 07:51:33 2013 -0800

    Linux 3.12.6

commit 8dc40be171d20d92795f7f4f6cc53cb6eb57920d
Author: Roger Quadros <rogerq@ti.com>
Date:   Sun Dec 8 18:39:02 2013 -0700

    ARM: OMAP2+: hwmod: Fix SOFTRESET logic
    
    commit 313a76ee11cda6700548afe68499ef174a240688 upstream.
    
    In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
    the hwmod's sysc_cache will always contain SOFTRESET bit set
    so all further writes to sysconfig using this cache will initiate
    a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
    platforms that have RESET_DONE status in the SYSSTATUS register and
    so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
    It is not a problem for OMAP4 like platforms that indicate RESET
    completion by clearing the SOFTRESET bit in the SYSCONFIG register.
    
    This repeated SOFTRESET is undesired and was the root cause of
    USB host issues on OMAP3 platforms when hwmod was allowed to do the
    SOFTRESET for the USB Host module.
    
    To fix this we clear the SOFTRESET bit and update the sysconfig
    register + sysc_cache using write_sysconfig().
    
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
    [paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd7a5ac9b59e74544181598fba54fd843b878db4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 25 14:24:01 2013 -0700

    drm/i915/vlv: fix up broken precision in vlv_crtc_clock_get
    
    commit 662c6ecbcdca1fe8a5402f6c83d98d242917a043 upstream.
    
    With some divider values we end up with the wrong result.  So remove the
    intermediates (like Ville suggested in the first place) to get the right
    answer.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7870bfa3a3516aa89db7c7260fa0e524850b2a56
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Sep 20 11:29:32 2013 -0700

    drm/i915/vlv: add VLV specific clock_get function v3
    
    commit acbec814a27f233b5ddb88a1bcaa2ac20daf64e0 upstream.
    
    Calculation is a little different than other platforms.
    
    v2: update to use port_clock instead
        rebase on top of Ville's changes
    v3: update to new port_clock semantics - don't divide by
        pixel_multiplier (Ville)
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=67345
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 132f0f7878670e74b20699037b6f79919491a228
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Oct 1 10:41:38 2013 -0700

    i915/vlv: untangle integrated clock source handling v4
    
    commit f60711666bcab6df2c6c91d851e07ed54088453c upstream.
    
    The global integrated clock source bit resides in DPLL B on VLV, but we
    were treating it as a per-pipe resource.  It needs to be set whenever
    any PLL is active, so pull setting the bit out of vlv_update_pll and
    into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
    when pipe B shuts down.
    
    I'm guessing on the references here, I expect this to bite any config
    where multiple displays are active or displays are moved from pipe to
    pipe.
    
    v2: re-add bits in vlv_update_pll to keep from confusing the state checker
    v3: use enum pipe checks (Daniel)
        set CRI clock source early (Ville)
        consistently set CRI clock source everywhere (Ville)
    v4: drop unnecessary setting of bit in vlv enable pll (Ville)
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
    References: https://bugs.freedesktop.org/show_bug.cgi?id=69693
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    [danvet: s/1/PIPE_B/]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5298b6d3c8abeee370055238d1ede81ec4daebc5
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Nov 6 16:57:55 2013 +0800

    Btrfs: fix lockdep error in async commit
    
    commit b1a06a4b574996692b72b742bf6e6aa0c711a948 upstream.
    
    Lockdep complains about btrfs's async commit:
    
    [ 2372.462171] [ BUG: bad unlock balance detected! ]
    [ 2372.462191] 3.12.0+ #32 Tainted: G        W
    [ 2372.462209] -------------------------------------
    [ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at:
    [ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
    [ 2372.462305] but there are no more locks to release!
    [ 2372.462324]
    [ 2372.462324] other info that might help us debug this:
    [ 2372.462349] no locks held by ceph-osd/14048.
    [ 2372.462367]
    [ 2372.462367] stack backtrace:
    [ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G        W    3.12.0+ #32
    [ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015  11/09/2011
    [ 2372.462455]  ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320
    [ 2372.462491]  ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650
    [ 2372.462526]  ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000
    [ 2372.462562] Call Trace:
    [ 2372.462584]  [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
    [ 2372.462619]  [<ffffffff816f094a>] dump_stack+0x45/0x56
    [ 2372.462642]  [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100
    [ 2372.462677]  [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
    [ 2372.462710]  [<ffffffff810b01ee>] lock_release+0x18e/0x210
    [ 2372.462742]  [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs]
    [ 2372.462783]  [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs]
    [ 2372.462822]  [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs]
    [ 2372.462849]  [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0
    [ 2372.462873]  [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0
    [ 2372.462897]  [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100
    [ 2372.462922]  [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0
    [ 2372.462946]  [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0
    [ 2372.462969]  [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0
    [ 2372.462991]  [<ffffffff817045a4>] tracesys+0xdd/0xe2
    
    ====================================================
    
    It's because that we don't do the right thing when checking if it's ok to
    tell lockdep that we're trying to release the rwsem.
    
    If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but
    as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze
    rwsem, which makes lockdep complains a lot.
    
    Reported-by: Ma Jianpeng <majianpeng@gmail.com>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f01df1850af8131a45bcd8f87b58d937af5140c
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Oct 30 13:25:24 2013 +0800

    Btrfs: fix a crash when running balance and defrag concurrently
    
    commit 48ec47364b6d493f0a9cdc116977bf3f34e5c3ec upstream.
    
    Running balance and defrag concurrently can end up with a crash:
    
    kernel BUG at fs/btrfs/relocation.c:4528!
    RIP: 0010:[<ffffffffa01ac33b>]  [<ffffffffa01ac33b>] btrfs_reloc_cow_block+ 0x1eb/0x230 [btrfs]
    Call Trace:
      [<ffffffffa01398c1>] ? update_ref_for_cow+0x241/0x380 [btrfs]
      [<ffffffffa0180bad>] ? copy_extent_buffer+0xad/0x110 [btrfs]
      [<ffffffffa0139da1>] __btrfs_cow_block+0x3a1/0x520 [btrfs]
      [<ffffffffa013a0b6>] btrfs_cow_block+0x116/0x1b0 [btrfs]
      [<ffffffffa013ddad>] btrfs_search_slot+0x43d/0x970 [btrfs]
      [<ffffffffa0153c57>] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
      [<ffffffffa0172a5e>] __btrfs_drop_extents+0x11e/0xae0 [btrfs]
      [<ffffffffa013b3fd>] ? generic_bin_search.constprop.39+0x8d/0x1a0 [btrfs]
      [<ffffffff8117d14a>] ? kmem_cache_alloc+0x1da/0x200
      [<ffffffffa0138e7a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
      [<ffffffffa0173ef0>] btrfs_drop_extents+0x60/0x90 [btrfs]
      [<ffffffffa016b24d>] relink_extent_backref+0x2ed/0x780 [btrfs]
      [<ffffffffa0162fe0>] ? btrfs_submit_bio_hook+0x1e0/0x1e0 [btrfs]
      [<ffffffffa01b8ed7>] ? iterate_inodes_from_logical+0x87/0xa0 [btrfs]
      [<ffffffffa016b909>] btrfs_finish_ordered_io+0x229/0xac0 [btrfs]
      [<ffffffffa016c3b5>] finish_ordered_fn+0x15/0x20 [btrfs]
      [<ffffffffa018cbe5>] worker_loop+0x125/0x4e0 [btrfs]
      [<ffffffffa018cac0>] ? btrfs_queue_worker+0x300/0x300 [btrfs]
      [<ffffffff81075ea0>] kthread+0xc0/0xd0
      [<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40
      [<ffffffff8164796c>] ret_from_fork+0x7c/0xb0
      [<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40
    ----------------------------------------------------------------------
    
    It turns out to be that balance operation will bump root's @last_snapshot,
    which enables snapshot-aware defrag path, and backref walking stuff will
    find data reloc tree as refs' parent, and hit the BUG_ON() during COW.
    
    As data reloc tree's data is just for relocation purpose, and will be deleted right
    after relocation is done, it's unnecessary to walk those refs belonged to data reloc
    tree, it'd be better to skip them.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e5787dec9c785cc58e27c03d9c3e5536d18698a
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Tue Oct 29 10:45:05 2013 +0800

    Btrfs: do not run snapshot-aware defragment on error
    
    commit 6f519564d7d978c00351d9ab6abac3deeac31621 upstream.
    
    If something wrong happens in write endio, running snapshot-aware defragment
    can end up with undefined results, maybe a crash, so we should avoid it.
    
    In order to share similar code, this also adds a helper to free the struct for
    snapshot-aware defrag.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486d1e163be2d32150a053c7ac3fc853ba6fd998
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Mon Oct 28 09:13:25 2013 -0400

    Btrfs: take ordered root lock when removing ordered operations inode
    
    commit 93858769172c4e3678917810e9d5de360eb991cc upstream.
    
    A user reported a list corruption warning from btrfs_remove_ordered_extent, it
    is because we aren't taking the ordered_root_lock when we remove the inode from
    the ordered operations list.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 222ae8bfd4c3796335d2aa1aa6a4dbeccb497b00
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri Oct 25 11:36:01 2013 -0400

    Btrfs: stop using vfs_read in send
    
    commit ed2590953bd06b892f0411fc94e19175d32f197a upstream.
    
    Apparently we don't actually close the files until we return to userspace, so
    stop using vfs_read in send.  This is actually better for us since we can avoid
    all the extra logic of holding the file we're sending open and making sure to
    clean it up.  This will fix people who have been hitting too many files open
    errors when trying to send.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7673c22871fdd914cdb61c9c1cd273ad59f614af
Author: Filipe David Borba Manana <fdmanana@gmail.com>
Date:   Tue Oct 15 18:44:00 2013 +0100

    Btrfs: fix incorrect inode acl reset
    
    commit 8185554d3eb09d23a805456b6fa98dcbb34aa518 upstream.
    
    When a directory has a default ACL and a subdirectory is created
    under that directory, btrfs_init_acl() is called when the
    subdirectory's inode is created to initialize the inode's ACL
    (inherited from the parent directory) but it was clearing the ACL
    from the inode after setting it if posix_acl_create() returned
    success, instead of clearing it only if it returned an error.
    
    To reproduce this issue:
    
    $ mkfs.btrfs -f /dev/loop0
    $ mount /dev/loop0 /mnt
    $ mkdir /mnt/acl
    $ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl
    $ getfacl /mnt/acl
    user::rwx
    group::rwx
    other::r-x
    default:user::rwx
    default:group::rwx
    default:other::---
    
    $ mkdir /mnt/acl/dir1
    $ getfacl /mnt/acl/dir1
    user::rwx
    group::rwx
    other::---
    
    After unmounting and mounting again the filesystem, fgetacl returned the
    expected ACL:
    
    $ umount /mnt/acl
    $ mount /dev/loop0 /mnt
    $ getfacl /mnt/acl/dir1
    user::rwx
    group::rwx
    other::---
    default:user::rwx
    default:group::rwx
    default:other::---
    
    Meaning that the underlying xattr was persisted.
    
    Reported-by: Giuseppe Fierro <giuseppe@fierro.org>
    Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63e431def463a8c620d1b03c77d440c6903917d1
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Mon Oct 14 17:23:08 2013 -0400

    Btrfs: fix hole check in log_one_extent
    
    commit ed9e8af88e2551aaa6bf51d8063a2493e2d71597 upstream.
    
    I added an assert to make sure we were looking up aligned offsets for csums and
    I tripped it when running xfstests.  This is because log_one_extent was checking
    if block_start == 0 for a hole instead of EXTENT_MAP_HOLE.  This worked out fine
    in practice it seems, but it adds a lot of extra work that is uneeded.  With
    this fix I'm no longer tripping my assert.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ae8656075c351ba3a3aefc923550ef2b7280164
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Sun Sep 29 10:33:16 2013 +0800

    Btrfs: fix memory leak of chunks' extent map
    
    commit 7d3d1744f8a7d62e4875bd69cc2192a939813880 upstream.
    
    As we're hold a ref on looking up the extent map, we need to drop the ref
    before returning to callers.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15c7298ad21e91b0ac7e3fcf753b036d178f8c7e
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri Sep 20 22:26:29 2013 -0400

    Btrfs: reset intwrite on transaction abort
    
    commit e0228285a8cad70e4b7b4833cc650e36ecd8de89 upstream.
    
    If we abort a transaction in the middle of a commit we weren't undoing the
    intwrite locking.  This patch fixes that problem.
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 794d0e92d22e8dd6495d22674272e17fd3cc33fa
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Tue Sep 24 14:09:34 2013 -0400

    Btrfs: do a full search everytime in btrfs_search_old_slot
    
    commit d4b4087c43cc00a196c5be57fac41f41309f1d56 upstream.
    
    While running some snashot aware defrag tests I noticed I was panicing every
    once and a while in key_search.  This is because of the optimization that says
    if we find a key at slot 0 it will be at slot 0 all the way down the rest of the
    tree.  This isn't the case for btrfs_search_old_slot since it will likely replay
    changes to a buffer if something has changed since we took our sequence number.
    So short circuit this optimization by setting prev_cmp to -1 every time we call
    key_search so we will do our normal binary search.  With this patch I am no
    longer seeing the panics I was seeing before.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd1bb90a43e858e478d71079877f5df1d6758f08
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 18 12:40:45 2013 -0800

    Revert "net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST"
    
    It turns out that commit: d3f7d56a7a4671d395e8af87071068a195257bf6 was
    applied to the tree twice, which didn't hurt anything, but it's good to
    fix this up.
    
    Reported-by: Veaceslav Falico <veaceslav@falico.eu>
    
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Shawn Landden <shawnlandden@gmail.com>
    Cc: Tom Herbert <therbert@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6011dbc33e40c04c0f5088d973c81ff49644678
Author: Matt Walker <matt.g.d.walker@gmail.com>
Date:   Thu Dec 5 12:39:02 2013 -0800

    Input: elantech - add support for newer (August 2013) devices
    
    commit 9cb80b965eaf7af1369f6e16f48a05fbaaccc021 upstream.
    
    Added detection for newer Elantech touchpads, so that kernel doesn't
    fall-back to default PS/2 driver. Supports touchpads released after
    ~August 2013.  Fixes bug:
    https://lists.launchpad.net/kernel-packages/msg18481.html
    
    Tested on an Acer Aspire S7-392-6302.
    
    Signed-off by: Matt Walker <matt.g.d.walker@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32f00afd67da7ba8b99cdd07e7ffeacda7f4dd1b
Author: Andy Adamson <andros@netapp.com>
Date:   Fri Nov 15 16:36:16 2013 -0500

    NFSv4 wait on recovery for async session errors
    
    commit 4a82fd7c4e78a1b7a224f9ae8bb7e1fd95f670e0 upstream.
    
    When the state manager is processing the NFS4CLNT_DELEGRETURN flag, session
    draining is off, but DELEGRETURN can still get a session error.
    The async handler calls nfs4_schedule_session_recovery returns -EAGAIN, and
    the DELEGRETURN done then restarts the RPC task in the prepare state.
    With the state manager still processing the NFS4CLNT_DELEGRETURN flag with
    session draining off, these DELEGRETURNs will cycle with errors filling up the
    session slots.
    
    This prevents OPEN reclaims (from nfs_delegation_claim_opens) required by the
    NFS4CLNT_DELEGRETURN state manager processing from completing, hanging the
    state manager in the __rpc_wait_for_completion_task in nfs4_run_open_task
    as seen in this kernel thread dump:
    
    kernel: 4.12.32.53-ma D 0000000000000000     0  3393      2 0x00000000
    kernel: ffff88013995fb60 0000000000000046 ffff880138cc5400 ffff88013a9df140
    kernel: ffff8800000265c0 ffffffff8116eef0 ffff88013fc10080 0000000300000001
    kernel: ffff88013a4ad058 ffff88013995ffd8 000000000000fbc8 ffff88013a4ad058
    kernel: Call Trace:
    kernel: [<ffffffff8116eef0>] ? cache_alloc_refill+0x1c0/0x240
    kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
    kernel: [<ffffffffa0358152>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc]
    kernel: [<ffffffff8152914f>] __wait_on_bit+0x5f/0x90
    kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
    kernel: [<ffffffff815291f8>] out_of_line_wait_on_bit+0x78/0x90
    kernel: [<ffffffff8109b520>] ? wake_bit_function+0x0/0x50
    kernel: [<ffffffffa035810d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc]
    kernel: [<ffffffffa040d44c>] nfs4_run_open_task+0x11c/0x160 [nfs]
    kernel: [<ffffffffa04114e7>] nfs4_open_recover_helper+0x87/0x120 [nfs]
    kernel: [<ffffffffa0411646>] nfs4_open_recover+0xc6/0x150 [nfs]
    kernel: [<ffffffffa040cc6f>] ? nfs4_open_recoverdata_alloc+0x2f/0x60 [nfs]
    kernel: [<ffffffffa0414e1a>] nfs4_open_delegation_recall+0x6a/0xa0 [nfs]
    kernel: [<ffffffffa0424020>] nfs_end_delegation_return+0x120/0x2e0 [nfs]
    kernel: [<ffffffff8109580f>] ? queue_work+0x1f/0x30
    kernel: [<ffffffffa0424347>] nfs_client_return_marked_delegations+0xd7/0x110 [nfs]
    kernel: [<ffffffffa04225d8>] nfs4_run_state_manager+0x548/0x620 [nfs]
    kernel: [<ffffffffa0422090>] ? nfs4_run_state_manager+0x0/0x620 [nfs]
    kernel: [<ffffffff8109b0f6>] kthread+0x96/0xa0
    kernel: [<ffffffff8100c20a>] child_rip+0xa/0x20
    kernel: [<ffffffff8109b060>] ? kthread+0x0/0xa0
    kernel: [<ffffffff8100c200>] ? child_rip+0x0/0x20
    
    The state manager can not therefore process the DELEGRETURN session errors.
    Change the async handler to wait for recovery on session errors.
    
    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e50aa26054196975ecbccdc65b65fd8f73fdb6e2
Author: Alan <gnomes@lxorguk.ukuu.org.uk>
Date:   Wed Dec 4 15:31:52 2013 +0000

    sc1200_wdt: Fix oops
    
    commit dace8bbfccfd9e4fcccfffcfbd82881fda3e756f upstream.
    
    If loaded with isapnp = 0 the driver explodes. This is catching
    people out now and then. What should happen in the working case is
    a complete mystery and the code appears terminally confused, but we
    can at least make the error path work properly.
    
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Partially-Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=53991
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7c1c86614a9207fbeb5312497024adb8e06f222
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Fri Aug 30 11:08:50 2013 -0700

    staging: comedi: ssv_dnp: use comedi_dio_update_state()
    
    commit f6b316bcd8c421acd6fa5a6e18b4c846ecb9d965 upstream.
    
    Use comedi_dio_update_state() to handle the boilerplate code to update
    the subdevice s->state.
    
    Also, fix a bug where the state of the channels is returned in data[0].
    The comedi core expects it to be returned in data[1].
    
    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 dd8533bb013a03dd4290c6dee078602c37b9c40d
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Fri Aug 30 11:05:58 2013 -0700

    staging: comedi: drivers: use comedi_dio_update_state() for simple cases
    
    commit 97f4289ad08cffe55de06d4ac4f89ac540450aee upstream.
    
    [Split from original patch subject: "staging: comedi: drivers: use
    comedi_dio_update_state() for simple cases"]
    
    Use comedi_dio_update_state() to handle the boilerplate code to update
    the subdevice s->state for simple cases where the hardware is updated
    when any channel is modified.
    
    Also, fix a bug in the amplc_pc263 and amplc_pci263 drivers where the
    current state is not returned in data[1].
    
    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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8e21dd5461293632406cc705c9ee85dd0f4156e
Author: Ben Segall <bsegall@google.com>
Date:   Wed Oct 16 11:16:32 2013 -0700

    sched: Avoid throttle_cfs_rq() racing with period_timer stopping
    
    commit f9f9ffc237dd924f048204e8799da74f9ecf40cf upstream.
    
    throttle_cfs_rq() doesn't check to make sure that period_timer is running,
    and while update_curr/assign_cfs_runtime does, a concurrently running
    period_timer on another cpu could cancel itself between this cpu's
    update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running
    in the tg to restart the timer, this causes the cfs_rq to be stranded
    forever.
    
    Fix this by calling __start_cfs_bandwidth() in throttle if the timer is
    inactive.
    
    (Also add some sched_debug lines for cfs_bandwidth.)
    
    Tested: make a run/sleep task in a cgroup, loop switching the cgroup
    between 1ms/100ms quota and unlimited, checking for timer_active=0 and
    throttled=1 as a failure. With the throttle_cfs_rq() change commented out
    this fails, with the full patch it passes.
    
    Signed-off-by: Ben Segall <bsegall@google.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: pjt@google.com
    Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Chris J Arges <chris.j.arges@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f77a54b7791510a85932b4a5f67dc54c6f84d82
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Fri Oct 4 11:01:43 2013 -0300

    cxd2820r_core: fix sparse warnings
    
    commit 0db3fa2741ad8371c21b3a6785416a4afc0cc1d4 upstream.
    
    drivers/media/dvb-frontends/cxd2820r_core.c:34:32: error: cannot size expression
    drivers/media/dvb-frontends/cxd2820r_core.c:68:32: error: cannot size expression
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Antti Palosaari <crope@iki.fi>
    Reviewed-by: Antti Palosaari <crope@iki.fi>
    Reviewed-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Cc: Frederik Himpe <fhimpe@telenet.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5feaf1a1615d46aa5ba877f38d590eaa8f8cdf78
Author: Helge Deller <deller@gmx.de>
Date:   Mon Dec 2 19:59:31 2013 +0100

    nfs: fix do_div() warning by instead using sector_div()
    
    commit 3873d064b8538686bbbd4b858dc8a07db1f7f43a upstream.
    
    When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like
    shown below.  Fix this warning by instead using sector_div() which is provided
    by the kernel.h header file.
    
    fs/nfs/blocklayout/extents.c: In function ‘normalize’:
    include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
    fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’
    nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default]
    fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default]
    include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’
     extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c6d8565e19d345426179f693e46226cad5a5b60
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Nov 30 19:12:27 2013 +0000

    HID: kye: Fix missing break in kye_report_fixup()
    
    commit 0a5f99cfff2297f6c350b7f54878cbbf1b1253d5 upstream.
    
    The change to support Genius Manticore Keyboard also changed behaviour
    for Genius Gx Imperator Keyboard, as there is no break between the
    cases.  This is presumably a mistake.
    
    Reported by Coverity as CID 1134029.
    
    Fixes: 4a2c94c9b6c0 ('HID: kye: Add report fixup for Genius Manticore Keyboard')
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e1dc5e33de343976c870510a854b98bf1b4ead7
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Nov 20 09:49:41 2013 -0500

    HID: kye: Add report fixup for Genius Manticore Keyboard
    
    commit 4a2c94c9b6c03af61b04993340bd9559e2277de4 upstream.
    
    Genius Manticore Keyboard presents the same problem in its report
    descriptors than Genius Gila Gaming Mouse and Genius Imperator Keyboard.
    Use the same fixup.
    
    Reported-and-tested-by: Adam Kulagowski <fidor@fidor.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33183a41e950ce144765dd79ca385798932f4c6e
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Sep 10 11:41:12 2013 -0400

    exportfs: fix 32-bit nfsd handling of 64-bit inode numbers
    
    commit 950ee9566a5b6cc45d15f5fe044bab4f1e8b62cb upstream.
    
    Symptoms were spurious -ENOENTs on stat of an NFS filesystem from a
    32-bit NFS server exporting a very large XFS filesystem, when the
    server's cache is cold (so the inodes in question are not in cache).
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Trevor Cordes <trevor@tecnopolis.ca>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fb3424be9050805c8282f5e2d3f35c10b6b57e1
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Oct 2 17:01:18 2013 -0400

    vfs: split out vfs_getattr_nosec
    
    commit b7a6ec52dd4eced4a9bcda9ca85b3c8af84d3c90 upstream.
    
    The filehandle lookup code wants this version of getattr.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e9c394744efc5d872bce0762637e31d7f54cda6
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 4 16:58:19 2013 -0500

    dm thin: allow pool in read-only mode to transition to read-write mode
    
    commit 9b7aaa64f96f7ca280d75326fca42f42017b89ef upstream.
    
    A thin-pool may be in read-only mode because the pool's data or metadata
    space was exhausted.  To allow for recovery, by adding more space to the
    pool, we must allow a pool to transition from PM_READ_ONLY to PM_WRITE
    mode.  Otherwise, running out of space will render the pool permanently
    read-only.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aa06206adee5208abb1f2313fa0017e099ec9a4
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 4 16:30:01 2013 -0500

    dm thin: re-establish read-only state when switching to fail mode
    
    commit 5383ef3a929a1366e2ced45cd6d74be7aa2a2281 upstream.
    
    If the thin-pool transitioned to fail mode and the thin-pool's table
    were reloaded for some reason: the new table's default pool mode would
    be read-write, though it will transition to fail mode during resume.
    
    When the pool mode transitions directly from PM_WRITE to PM_FAIL we need
    to re-establish the intermediate read-only state in both the metadata
    and persistent-data block manager (as is usually done with the normal
    pool mode transition sequence: PM_WRITE -> PM_READ_ONLY -> PM_FAIL).
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a016a0dfee64bcf6f08cb0129574b91a280b092e
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Dec 4 15:05:36 2013 -0500

    dm thin: always fallback the pool mode if commit fails
    
    commit 020cc3b5e28c2e24f59f53a9154faf08564f308e upstream.
    
    Rename commit_or_fallback() to commit().  Now all previous calls to
    commit() will trigger the pool mode to fallback if the commit fails.
    
    Also, check the error returned from commit() in alloc_data_block().
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c591d1144c46b18f026e06e59fc0e916c739c973
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Tue Dec 3 12:20:57 2013 -0500

    dm thin: switch to read-only mode if metadata space is exhausted
    
    commit 4a02b34e0cf1d0d0dd3737702841da4bf615a50a upstream.
    
    Switch the thin pool to read-only mode in alloc_data_block() if
    dm_pool_alloc_data_block() fails because the pool's metadata space is
    exhausted.
    
    Differentiate between data and metadata space in messages about no
    free space available.
    
    This issue was noticed with the device-mapper-test-suite using:
    dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
    
    The quantity of errors logged in this case must be reduced.
    
    before patch:
    
    device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    <snip ... these repeat for a _very_ long while ... >
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: 253:4: commit failed: error = -28
    device-mapper: thin: 253:4: switching pool to read-only mode
    
    after patch:
    
    device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: 253:4: no free metadata space available.
    device-mapper: thin: 253:4: switching pool to read-only mode
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3494a874e9fd664452bb70571a9a89b9ba819803
Author: Joe Thornber <ejt@redhat.com>
Date:   Mon Dec 2 17:57:42 2013 -0500

    dm thin: switch to read only mode if a mapping insert fails
    
    commit fafc7a815e40255d24e80a1cb7365892362fa398 upstream.
    
    Switch the thin pool to read-only mode when dm_thin_insert_block() fails
    since there is little reason to expect the cause of the failure to be
    resolved without further action by user space.
    
    This issue was noticed with the device-mapper-test-suite using:
    dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
    
    The quantity of errors logged in this case must be reduced.
    
    before patch:
    
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: dm_thin_insert_block() failed
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map metadata: unable to allocate new metadata block
    <snip ... these repeat for a long while ... >
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: space map common: dm_tm_shadow_block() failed
    device-mapper: thin: 253:4: no free metadata space available.
    device-mapper: thin: 253:4: switching pool to read-only mode
    
    after patch:
    
    device-mapper: space map metadata: unable to allocate new metadata block
    device-mapper: thin: 253:4: dm_thin_insert_block() failed: error = -28
    device-mapper: thin: 253:4: switching pool to read-only mode
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce73a302c1afca60e23b176a87edfdfaa3485f61
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Nov 22 19:52:06 2013 -0500

    dm table: fail dm_table_create on dm_round_up overflow
    
    commit 5b2d06576c5410c10d95adfd5c4d8b24de861d87 upstream.
    
    The dm_round_up function may overflow to zero.  In this case,
    dm_table_create() must fail rather than go on to allocate an empty array
    with alloc_targets().
    
    This fixes a possible memory corruption that could be caused by passing
    too large a number in "param->target_count".
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb4d254628bb8f74d9034eb701600555939c6143
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Dec 13 12:31:08 2013 +0000

    dm space map: disallow decrementing a reference count below zero
    
    commit 5b564d80f8bc21094c0cd2b19b679d983aabcc29 upstream.
    
    The old behaviour, returning -EINVAL if a ref_count of 0 would be
    decremented, was removed in commit f722063 ("dm space map: optimise
    sm_ll_dec and sm_ll_inc").  To fix this regression we return an error
    code from the mutator function pointer passed to sm_ll_mutate() and have
    dec_ref_count() return -EINVAL if the old ref_count is 0.
    
    Add a DMERR to reflect the potential seriousness of this error.
    
    Also, add missing dm_tm_unlock() to sm_ll_mutate()'s error path.
    
    With this fix the following dmts regression test now passes:
     dmtest run --suite cache -n /metadata_use_kernel/
    
    The next patch fixes the higher-level dm-array code that exposed this
    regression.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc09538e4813d30b98dc1aae91c6e2345626f2bd
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Mon Dec 2 16:47:01 2013 -0500

    dm space map metadata: return on failure in sm_metadata_new_block
    
    commit f62b6b8f498658a9d537c7d380e9966f15e1b2a1 upstream.
    
    Commit 2fc48021f4afdd109b9e52b6eef5db89ca80bac7 ("dm persistent
    metadata: add space map threshold callback") introduced a regression
    to the metadata block allocation path that resulted in errors being
    ignored.  This regression was uncovered by running the following
    device-mapper-test-suite test:
    dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
    
    The ignored error codes in sm_metadata_new_block() could crash the
    kernel through use of either the dm-thin or dm-cache targets, e.g.:
    
    device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
    device-mapper: space map metadata: unable to allocate new metadata block
    general protection fault: 0000 [#1] SMP
    ...
    Workqueue: dm-thin do_worker [dm_thin_pool]
    task: ffff880035ce2ab0 ti: ffff88021a054000 task.ti: ffff88021a054000
    RIP: 0010:[<ffffffffa0331385>]  [<ffffffffa0331385>] metadata_ll_load_ie+0x15/0x30 [dm_persistent_data]
    RSP: 0018:ffff88021a055a68  EFLAGS: 00010202
    RAX: 003fc8243d212ba0 RBX: ffff88021a780070 RCX: ffff88021a055a78
    RDX: ffff88021a055a78 RSI: 0040402222a92a80 RDI: ffff88021a780070
    RBP: ffff88021a055a68 R08: ffff88021a055ba4 R09: 0000000000000010
    R10: 0000000000000000 R11: 00000002a02e1000 R12: ffff88021a055ad4
    R13: 0000000000000598 R14: ffffffffa0338470 R15: ffff88021a055ba4
    FS:  0000000000000000(0000) GS:ffff88033fca0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00007f467c0291b8 CR3: 0000000001a0b000 CR4: 00000000000007e0
    Stack:
     ffff88021a055ab8 ffffffffa0332020 ffff88021a055b30 0000000000000001
     ffff88021a055b30 0000000000000000 ffff88021a055b18 0000000000000000
     ffff88021a055ba4 ffff88021a055b98 ffff88021a055ae8 ffffffffa033304c
    Call Trace:
     [<ffffffffa0332020>] sm_ll_lookup_bitmap+0x40/0xa0 [dm_persistent_data]
     [<ffffffffa033304c>] sm_metadata_count_is_more_than_one+0x8c/0xc0 [dm_persistent_data]
     [<ffffffffa0333825>] dm_tm_shadow_block+0x65/0x110 [dm_persistent_data]
     [<ffffffffa0331b00>] sm_ll_mutate+0x80/0x300 [dm_persistent_data]
     [<ffffffffa0330e60>] ? set_ref_count+0x10/0x10 [dm_persistent_data]
     [<ffffffffa0331dba>] sm_ll_inc+0x1a/0x20 [dm_persistent_data]
     [<ffffffffa0332270>] sm_disk_new_block+0x60/0x80 [dm_persistent_data]
     [<ffffffff81520036>] ? down_write+0x16/0x40
     [<ffffffffa001e5c4>] dm_pool_alloc_data_block+0x54/0x80 [dm_thin_pool]
     [<ffffffffa001b23c>] alloc_data_block+0x9c/0x130 [dm_thin_pool]
     [<ffffffffa001c27e>] provision_block+0x4e/0x180 [dm_thin_pool]
     [<ffffffffa001fe9a>] ? dm_thin_find_block+0x6a/0x110 [dm_thin_pool]
     [<ffffffffa001c57a>] process_bio+0x1ca/0x1f0 [dm_thin_pool]
     [<ffffffff8111e2ed>] ? mempool_free+0x8d/0xa0
     [<ffffffffa001d755>] process_deferred_bios+0xc5/0x230 [dm_thin_pool]
     [<ffffffffa001d911>] do_worker+0x51/0x60 [dm_thin_pool]
     [<ffffffff81067872>] process_one_work+0x182/0x3b0
     [<ffffffff81068c90>] worker_thread+0x120/0x3a0
     [<ffffffff81068b70>] ? manage_workers+0x160/0x160
     [<ffffffff8106eb2e>] kthread+0xce/0xe0
     [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
     [<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0
     [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
     [<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0
     [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c13daf691a8469d3cacaa7391330fbad8995317
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Nov 15 16:12:20 2013 -0500

    dm delay: fix a possible deadlock due to shared workqueue
    
    commit 718822c1c112dc99e0c72c8968ee1db9d9d910f0 upstream.
    
    The dm-delay target uses a shared workqueue for multiple instances.  This
    can cause deadlock if two or more dm-delay targets are stacked on the top
    of each other.
    
    This patch changes dm-delay to use a per-instance workqueue.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a3b9049fe0fa103b836bb706077de0e2a9c01aa
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Dec 13 14:55:55 2013 +0000

    dm array: fix a reference counting bug in shadow_ablock
    
    commit ed9571f0cf1fe09d3506302610f3ccdfa1d22c4a upstream.
    
    An old array block could have its reference count decremented below
    zero when it is being replaced in the btree by a new array block.
    
    The fix is to increment the old ablock's reference count just before
    inserting a new ablock into the btree.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f4ed02192c0bdf3559999e92f51a2ce588fa0df
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Dec 5 17:34:19 2013 -0500

    dm stats: initialize read-only module parameter
    
    commit 76f5bee5c3b45c617f91243e85547fc8f67bc678 upstream.
    
    The module parameter stats_current_allocated_bytes in dm-mod is
    read-only.  This parameter informs the user about memory
    consumption.  It is not supposed to be changed by the user.
    
    However, despite being read-only, this parameter can be set on
    modprobe or insmod command line:
    modprobe dm-mod stats_current_allocated_bytes=12345
    
    The kernel doesn't expect that this variable can be non-zero at module
    initialization and if the user sets it, it results in warning.
    
    This patch initializes the variable in the module init routine, so
    that user-supplied value is ignored.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aff61a9e1151f0d09bc3aaec6613813ddc3eeef2
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Nov 29 18:13:37 2013 -0500

    dm snapshot: avoid snapshot space leak on crash
    
    commit 230c83afdd9cd384348475bea1e14b80b3b6b1b8 upstream.
    
    There is a possible leak of snapshot space in case of crash.
    
    The reason for space leaking is that chunks in the snapshot device are
    allocated sequentially, but they are finished (and stored in the metadata)
    out of order, depending on the order in which copying finished.
    
    For example, supposed that the metadata contains the following records
    SUPERBLOCK
    METADATA (blocks 0 ... 250)
    DATA 0
    DATA 1
    DATA 2
    ...
    DATA 250
    
    Now suppose that you allocate 10 new data blocks 251-260. Suppose that
    copying of these blocks finish out of order (block 260 finished first
    and the block 251 finished last). Now, the snapshot device looks like
    this:
    SUPERBLOCK
    METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
    DATA 0
    DATA 1
    DATA 2
    ...
    DATA 250
    DATA 251
    DATA 252
    DATA 253
    DATA 254
    DATA 255
    METADATA (blocks 255, 254, 253, 252, 251)
    DATA 256
    DATA 257
    DATA 258
    DATA 259
    DATA 260
    
    Now, if the machine crashes after writing the first metadata block but
    before writing the second metadata block, the space for areas DATA 250-255
    is leaked, it contains no valid data and it will never be used in the
    future.
    
    This patch makes dm-snapshot complete exceptions in the same order they
    were allocated, thus fixing this bug.
    
    Note: when backporting this patch to the stable kernel, change the version
    field in the following way:
    * if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
    * if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
      to {1, 10, 2}
    Userspace reads the version to determine if the bug was fixed, so the
    version change is needed.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 377613d8aafeb381ddaa0020445e4602e2596c2c
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Dec 5 17:33:29 2013 -0500

    dm bufio: initialize read-only module parameters
    
    commit 4cb57ab4a2e61978f3a9b7d4f53988f30d61c27f upstream.
    
    Some module parameters in dm-bufio are read-only. These parameters
    inform the user about memory consumption. They are not supposed to be
    changed by the user.
    
    However, despite being read-only, these parameters can be set on
    modprobe or insmod command line, for example:
    modprobe dm-bufio current_allocated_bytes=12345
    
    The kernel doesn't expect that these variables can be non-zero at module
    initialization and if the user sets them, it results in BUG.
    
    This patch initializes the variables in the module init routine, so that
    user-supplied values are ignored.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5efc91cb9ff638c11ae3fd9c6b810b6d1940a1a1
Author: David Sterba <dsterba@suse.cz>
Date:   Fri Dec 6 17:51:32 2013 +0100

    btrfs: call mnt_drop_write after interrupted subvol deletion
    
    commit e43f998e47bae27e37e159915625e8d4b130153b upstream.
    
    If btrfs_ioctl_snap_destroy blocks on the mutex and the process is
    killed, mnt_write count is unbalanced and leads to unmountable
    filesystem.
    
    Signed-off-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93ecac1d5fad38f8a04e9bcdfaa181ad8ff23681
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 10 03:57:25 2013 -0500

    Btrfs: fix access_ok() check in btrfs_ioctl_send()
    
    commit 700ff4f095d78af0998953e922e041d75254518b upstream.
    
    The closing parenthesis is in the wrong place.  We want to check
    "sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of
    "sizeof(*arg->clone_sources * arg->clone_sources_count)".
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jie Liu <jeff.liu@oracle.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c010ea5d9d0c8caaf37d02d0294e925a0ccf1f5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Nov 22 04:50:46 2013 -0300

    media: af9035: unlock on error in af9035_i2c_master_xfer()
    
    commit 3189ef0290dcc9f44782672fade35847cb30da00 upstream.
    
    We introduced a couple new error paths which are missing unlocks.
    Fixes: 7760e148350b ('[media] af9035: Don't use dynamic static allocation')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7046d0cbc40a06312abfa46362b4681f3ced7016
Author: Antti Palosaari <crope@iki.fi>
Date:   Thu Aug 8 19:41:06 2013 -0300

    media: af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual
    
    commit 0c413d10515feae02cee967b31bb8afea8aa0d29 upstream.
    
    It is IT9135 dual design.
    Thanks to Michael Piko for reporting that!
    
    Reported-by: Michael Piko <michael@piko.com.au>
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e9254ef7800e1be9977ae4bf258a0124208f2d1
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Nov 11 11:02:52 2013 -0300

    media: wm8775: fix broken audio routing
    
    commit 3af41a337a5b270de3e65466a07f106ad97ad0c6 upstream.
    
    Commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 inverted the mute control
    state test in s_routing which caused the audio routing to fail. This broke
    ivtv support for the Hauppauge video/audio input bracket (which adds additional
    video and audio inputs) all the way back in kernel 2.6.36.
    This fix fixes the condition and it also removes a nonsense check on the
    balance control.
    Bisected-by: Rajil Saraswat <rajil.s@gmail.com>
    
    Signed-off-by: Andy Walls <awalls@md.metrocast.net>
    Reported-by: Rajil Saraswat <rajil.s@gmail.com>
    Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32c901a429f7f9d25737a719f1bf11cbdd4cdb6a
Author: Antti Palosaari <crope@iki.fi>
Date:   Wed Nov 27 17:17:43 2013 -0300

    media: af9033: fix broken I2C
    
    commit d18a88b1f535d627412b2a265d71b2f7d464860e upstream.
    
    Driver did not work anymore since I2C has gone broken due
    to recent commit:
    commit 37ebaf6891ee81687bb558e8375c0712d8264ed8
    [media] dvb-frontends: Don't use dynamic static allocation
    
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4897de99f2482c96f830cfe23ce9ece2c41f4c25
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Nov 11 08:16:03 2013 -0300

    media: bttv: don't setup the controls if there are no video devices
    
    commit f8e1b699a5504a2da05834c7cfdddb125a8ce088 upstream.
    
    The no_video flag was checked in all other cases except one. Calling
    v4l2_ctrl_handler_setup() if no_video is 1 will crash.
    This wasn't noticed before since there are only two card types that
    set no_video to 1, so this type of hardware is quite rare.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reported-by: Lorenz Röhrl <sheepshit@gmx.de>
    Tested-by: Lorenz Röhrl <sheepshit@gmx.de>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c7f417e105f068687191589219155bffda2e68b
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Mon Nov 4 06:28:57 2013 -0300

    media: tef6862/radio-tea5764: actually assign clamp result
    
    commit 9ba6a91f19b8c118d11c549495fa4f7a20505d80 upstream.
    
    When adding frequency clamping to the tef6862 and radio-tea5764 drivers
    I forgot to actually *assign* the clamp result to the frequency.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reported-by: Hans Petter Selasky <hps@bitfrost.no>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5c50a6bf38af2c90995f20bf10196d0487d19a5
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Oct 25 06:34:03 2013 -0300

    media: saa7164: fix return value check in saa7164_initdev()
    
    commit 89f4d45b2752df5d222b5f63919ce59e2d8afaf4 upstream.
    
    In case of error, the function kthread_run() returns ERR_PTR()
    and never returns NULL. The NULL test in the return value check
    should be replaced with IS_ERR().
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc36893fd834c95cacc524e0015ef67b54c9f804
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Tue Dec 10 14:56:06 2013 -0800

    x86, build, icc: Remove uninitialized_var() from compiler-intel.h
    
    commit 503cf95c061a0551eb684da364509297efbe55d9 upstream.
    
    When compiling with icc, <linux/compiler-gcc.h> ends up included
    because the icc environment defines __GNUC__.  Thus, we neither need
    nor want to have this macro defined in both compiler-gcc.h and
    compiler-intel.h, and the fact that they are inconsistent just makes
    the compiler spew warnings.
    
    Reported-by: Sunil K. Pandey <sunil.k.pandey@intel.com>
    Cc: Kevin B. Smith <kevin.b.smith@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fec4a0d9c7b17279553712f9b2da37254edf514e
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Mon Dec 9 15:43:38 2013 -0800

    x86, build: Pass in additional -mno-mmx, -mno-sse options
    
    commit 8b3b005d675726e38bc504d2e35a991e55819155 upstream.
    
    In checkin
    
        5551a34e5aea x86-64, build: Always pass in -mno-sse
    
    we unconditionally added -mno-sse to the main build, to keep newer
    compilers from generating SSE instructions from autovectorization.
    However, this did not extend to the special environments
    (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
    Add -mno-sse to the compiler command line for these environments, and
    add -mno-mmx to all the environments as well, as we don't want a
    compiler to generate MMX code either.
    
    This patch also removes a $(cc-option) call for -m32, since we have
    long since stopped supporting compilers too old for the -m32 option,
    and in fact hardcode it in other places in the Makefiles.
    
    Reported-by: Kevin B. Smith <kevin.b.smith@intel.com>
    Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: H. J. Lu <hjl.tools@gmail.com>
    Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a4204b8c03b92947d338c804132ac782a24cc7d
Author: cpw <cpw@sgi.com>
Date:   Tue Dec 3 17:15:30 2013 -0600

    x86/UV: Fix NULL pointer dereference in uv_flush_tlb_others() if the 'nobau' boot option is used
    
    commit 3eae49ca8954f958b2001ab5643ef302cb7b67c7 upstream.
    
    The SGI UV tlb shootdown code panics the system with a NULL
    pointer deference if 'nobau' is specified on the boot
    commandline.
    
    uv_flush_tlb_other() gets called for every flush, whether the
    BAU is disabled or not.  It should not be keeping the s_enters
    statistic while the BAU is disabled.
    
    The panic occurs because during initialization
    init_per_cpu_tunables() does not set the bcp->statp pointer if
    'nobau' was specified.
    
    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/E1VnzBi-0005yF-MU@eag09.americas.sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9952005841964ea98f24bd402e22b13fd8398368
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date:   Fri Nov 29 14:44:43 2013 -0500

    x86, efi: Don't use (U)EFI time services on 32 bit
    
    commit 04bf9ba720fcc4fa313fa122b799ae0989b6cd50 upstream.
    
    UEFI time services are often broken once we're in virtual mode. We were
    already refusing to use them on 64-bit systems, but it turns out that
    they're also broken on some 32-bit firmware, including the Dell Venue.
    Disable them for now, we can revisit once we have the 1:1 mappings code
    incorporated.
    
    Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    Link: http://lkml.kernel.org/r/1385754283-2464-1-git-send-email-matthew.garrett@nebula.com
    Cc: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9dd3d675ffd26a58af0200f3d43705328a66043
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 3 17:16:49 2013 -0500

    drm/radeon/atom: fix bus probes when hw_i2c is set (v2)
    
    commit ffd3d3361d583cb73fa65a5fed3a196ba6f261bb upstream.
    
    When probing the bus, we need to set the byte count
    to 0 rather than 1.
    
    v2: Don't count the first byte.
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=66241
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 377d33fb858c8358cd096239f7eab6106c45c9e1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Dec 3 09:24:30 2013 -0500

    drm/radeon: fixup bad vram size on SI
    
    commit 0ca223b029a261e82fb2f50c52eb85d510f4260e upstream.
    
    Some boards seem to have garbage in the upper
    16 bits of the vram size register.  Check for
    this and clamp the size properly.  Fixes
    boards reporting bogus amounts of vram.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88aed624bbc70b87bb066fbce655d879d937b4a3
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 25 13:20:59 2013 -0500

    drm/radeon: program DCE2 audio dto just like DCE3
    
    commit 55d4e020fb8ddd3896a8cd3351028f5c3a2c4bd3 upstream.
    
    Seems to work like the DCE3 version despite what
    the register spec says.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=71975
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f19c24df53670ee08cab6b8ac0a6c1fd6ca2ef8f
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Nov 21 09:52:01 2013 -0500

    drm/radeon: fix typo in fetching mpll params
    
    commit 180f805f4f03b2894701f9831b4e96a308330b22 upstream.
    
    Copy-paste typo.  Value should be 0-2, not 0-1.
    
    Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3c874515c58584bb728923398d7e6b330292354
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Nov 21 13:47:16 2013 -0200

    drm/i915: use the correct force_wake function at the PC8 code
    
    commit a1216444283e81fd904593a4a77c90adfe5d14d1 upstream.
    
    When I submitted the first patch adding these force wake functions,
    Chris Wilson observed that I was using the wrong functions, so I sent
    a second version of the patch to correct this problem. The problem is
    that v1 was merged instead of v2.
    
    I was able to notice the problem when running the
    debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.
    
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0f9268694020091449449fe4e58d422aacce48b
Author: Carolyn Wyborny <carolyn.wyborny@intel.com>
Date:   Sat Dec 14 03:26:46 2013 -0800

    igb: Fix for issue where values could be too high for udelay function.
    
    commit df29df92adda751ac04ca5149d30014b5199db81 upstream.
    
    This patch changes the igb_phy_has_link function to check the value of the
    parameter before deciding to use udelay or mdelay in order to be sure that
    the value is not too high for udelay function.
    
    Signed-off-by: Sunil K Pandey <sunil.k.pandey@intel.com>
    Signed-off-by: Kevin B Smith <kevin.b.smith@intel.com>
    Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 028d3234cb84a11c6c183bbffcecc726d45c8cfd
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Dec 10 19:40:43 2013 +0100

    net: allwinner: emac: Add missing free_irq
    
    commit e9c56f8d2f851fb6d6ce6794c0f5463b862a878e upstream.
    
    The sun4i-emac driver uses devm_request_irq at .ndo_open time, but relies on
    the managed device mechanism to actually free it. This causes an issue whenever
    someone wants to restart the interface, the interrupt still being held, and not
    yet released.
    
    Fall back to using the regular request_irq at .ndo_open time, and introduce a
    free_irq during .ndo_stop.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0d64a5e19ffc678c156454bab9ae0a46771159f
Author: Ujjal Roy <royujjal@gmail.com>
Date:   Thu Nov 21 11:08:56 2013 -0800

    mwifiex: fix memory leak issue for ibss join
    
    commit 517543fd72d577dde2ebd9505dc4abf26d589f9a upstream.
    
    For IBSS join if the requested SSID matches current SSID,
    it returns without freeing the allocated beacon IE buffer.
    
    Signed-off-by: Ujjal Roy <royujjal@gmail.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d87f36045d9b040bcad76cf35a49ea7300e6ce6
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Oct 25 13:06:06 2013 +0200

    iwlwifi: mvm: check sta_id/drain values in debugfs
    
    commit 60765a47a433d54e4744c285ad127f182dcd80aa upstream.
    
    The station ID must be valid, if it's out of range then
    the array access may crash. Validate the station ID to
    the array length, and also validate the drain value even
    if that doesn't matter all that much.
    
    Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 049afbc51058ad48b99f72b4c1bc26431dbc60e3
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Nov 20 11:28:27 2013 +0100

    mac80211: don't attempt to reorder multicast frames
    
    commit 051a41fa4ee14f5c39668f0980973b9a195de560 upstream.
    
    Multicast frames can't be transmitted as part of an aggregation
    session (such a session couldn't even be set up) so don't try to
    reorder them. Trying to do so would cause the reorder to stop
    working correctly since multicast QoS frames (as transmitted by
    the Aruba APs this was found with) would cause sequence number
    confusion in the buffer.
    
    Reported-by: Blaise Gassend <blaise@suitabletech.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054337f572579ef69f5aaf06fff683c007eeffda
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Nov 6 10:34:36 2013 +0100

    mac80211: fix scheduled scan rtnl deadlock
    
    commit 18db594a1005d908d995a2fc8f5a7bf4286fdca0 upstream.
    
    When changing cfg80211 to use RTNL locking, this caused a
    deadlock in mac80211 as it calls cfg80211_sched_scan_stopped()
    from a work item that's on a workqueue that is flushed with
    the RTNL held.
    
    Fix this by simply using schedule_work(), the work only needs
    to finish running before the wiphy is unregistered, no other
    synchronisation (e.g. with suspend) is really required since
    for suspend userspace is already blocked anyway when we flush
    the workqueue so will only pick up the event after resume.
    
    Fixes: 5fe231e87372 ("cfg80211: vastly simplify locking")
    Reported-and-tested-by: Eliad Peller <eliadx.peller@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 262c7d201e13b54808bf6dc5bd8b0d3bd0230b97
Author: Bob Copeland <me@bobcopeland.com>
Date:   Tue Oct 29 18:11:59 2013 -0400

    Revert "mac80211: allow disable power save in mesh"
    
    commit 2d3db210860f1df099a35b1dd54cca35454e0361 upstream.
    
    This reverts commit ee1f668136b2fb6640ee2d54c2a525ea41f98211.
    
    The aformentioned commit added a check to allow
    'iw wlan0 set power_save off' to work for mesh interfaces.
    
    However, this is problematic because it also allows
    'iw wlan0 set power_save on', which will crash in short order
    because all of the subsequent code manipulates sdata->u.mgd.
    
    The power-saving states for mesh interfaces can be manipulated
    through the mesh config, e.g:
    'iw wlan0 set mesh_param mesh_power_save=active' (which,
    despite the name, actualy disables power saving since the
    setting refers to the type of sleep the interface undergoes).
    
    Fixes: ee1f668136b2 ("mac80211: allow disable power save in mesh")
    Signed-off-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a19895494f08db7e19951deae53359d9a1a74160
Author: Paul Moore <pmoore@redhat.com>
Date:   Wed Dec 4 16:10:51 2013 -0500

    selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute()
    
    commit 446b802437f285de68ffb8d6fac3c44c3cab5b04 upstream.
    
    In selinux_ip_postroute() we perform access checks based on the
    packet's security label.  For locally generated traffic we get the
    packet's security label from the associated socket; this works in all
    cases except for TCP SYN-ACK packets.  In the case of SYN-ACK packet's
    the correct security label is stored in the connection's request_sock,
    not the server's socket.  Unfortunately, at the point in time when
    selinux_ip_postroute() is called we can't query the request_sock
    directly, we need to recreate the label using the same logic that
    originally labeled the associated request_sock.
    
    See the inline comments for more explanation.
    
    Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
    Tested-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569ee4bda2ca11dffe1fc5594ee3787715cdb9d5
Author: Paul Moore <pmoore@redhat.com>
Date:   Wed Dec 4 16:10:45 2013 -0500

    selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output()
    
    commit 47180068276a04ed31d24fe04c673138208b07a9 upstream.
    
    In selinux_ip_output() we always label packets based on the parent
    socket.  While this approach works in almost all cases, it doesn't
    work in the case of TCP SYN-ACK packets when the correct label is not
    the label of the parent socket, but rather the label of the larval
    socket represented by the request_sock struct.
    
    Unfortunately, since the request_sock isn't queued on the parent
    socket until *after* the SYN-ACK packet is sent, we can't lookup the
    request_sock to determine the correct label for the packet; at this
    point in time the best we can do is simply pass/NF_ACCEPT the packet.
    It must be said that simply passing the packet without any explicit
    labeling action, while far from ideal, is not terrible as the SYN-ACK
    packet will inherit any IP option based labeling from the initial
    connection request so the label *should* be correct and all our
    access controls remain in place so we shouldn't have to worry about
    information leaks.
    
    Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
    Tested-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0bd0fc173635c3d98aa2530a25e73e4041fcc22
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Nov 17 10:37:34 2013 +0100

    cfg80211: disable 5/10 MHz support for all drivers
    
    commit 9f16d84ad73ea04145a5dc85c8f1067915b37eea upstream.
    
    Due to nl80211 API breakage, 5/10 MHz support is broken for
    all drivers. Fixing it requires adding new API, but that
    can't be done as a bugfix commit since that would require
    either updating all APIs in the trees needing the bugfix or
    cause different kernels to have incompatible API.
    
    Therefore, just disable 5/10 MHz support for all drivers.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f79e506a4521b58fcba80b49cd40c2037de6d2b
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Thu Dec 5 15:20:53 2013 +0100

    ath9k: fix duration calculation for non-aggregated packets
    
    commit bbf807bc0697e577c137a5fffb30fca7c6a45da1 upstream.
    
    When not aggregating packets, fi->framelen should be passed in as length
    to calculate the duration. Before the tx path rework, ath_tx_fill_desc
    was called for either one aggregate, or one single frame, with the
    length of the packet or the aggregate as a parameter.
    After the rework, ath_tx_sched_aggr can pass a burst of single frames to
    ath_tx_fill_desc and sets len=0.
    Fix broken duration calculation by overriding the length in ath_tx_fill_desc
    before passing it to ath_buf_set_rate.
    
    Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c8eac0555fdfd33d0039ac27da9fdfb3ae775b1
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Tue Nov 26 07:21:39 2013 +0530

    ath9k: Fix XLNA bias strength
    
    commit a1783a7b0846fc6414483e6caf646db72023fffd upstream.
    
    The EEPROM parameter to determine whether the bias
    strength values for XLNA have to be applied is part
    of the miscConfiguration field and not featureEnable.
    
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4edfe34cca9f16624ff91df203c2322ed20279e2
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Tue Nov 26 07:21:08 2013 +0530

    ath9k: Fix QuickDrop usage
    
    commit 93c1cfbe598f72cfa7be49e4a7d2a1d482e15119 upstream.
    
    Bit 5 in the miscConfiguration field of the base EEPROM
    header denotes whether QuickDrop is enabled or not. Fix
    the incorrect usage of BIT(1) and also make sure that
    this is done only for the required chips.
    
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3b9c9ba488cdbedba8dd4b93eebb85153466965
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Nov 28 22:10:38 2013 +0200

    drm/i915: Fix pipe CSC post offset calculation
    
    commit 32cf0cb0294814cb1ee5d8727e9aac0e9aa80d2e upstream.
    
    We were miscalculating the pipe CSC post offset for the full->limited
    range conversion. The resulting post offset was double what it was
    supposed to be, which caused blacks to come out grey when using
    limited range output on HSW+.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769
    Tested-by: Lauri Mylläri <lauri.myllari@gmail.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4f16060b6e48a04487d1becf52d4acb2b3f69b0
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Nov 7 18:47:50 2013 +0000

    iommu/arm-smmu: use mutex instead of spinlock for locking page tables
    
    commit a44a9791e778d9ccda50d5534028ed4057a9a45b upstream.
    
    When creating IO mappings, we lazily allocate our page tables using the
    standard, non-atomic allocator functions. This presents us with a
    problem, since our page tables are protected with a spinlock.
    
    This patch reworks the smmu_domain lock to use a mutex instead of a
    spinlock. iova_to_phys is then reworked so that it only reads the page
    tables, and can run in a lockless fashion, leaving the mutex to guard
    against concurrent mapping threads.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a3008e850fc5b06595f3d850aea38c16213900
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date:   Mon Dec 9 18:36:26 2013 -0300

    Partially revert "mtd: nand: pxa3xx: Introduce 'marvell,armada370-nand' compatible string"
    
    commit 9c59ac616137fb62f6cb3f1219201b09cbcf30be upstream.
    
    This partially reverts c0f3b8643a6fa2461d70760ec49d21d2b031d611.
    
    The "armada370-nand" compatible support is not complete, and it was mistake
    to add it. Revert it and postpone the support until the infrastructure is
    in place.
    
    Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f02a127dd7b35ebe3df64320347c6ee904a8338
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon Dec 9 15:24:19 2013 +0800

    regulator: pfuze100: Fix address of FABID
    
    commit a1b6fa85c639ad0d5447d1a5e7d1463bbe29fcd3 upstream.
    
    According to the datasheet, the address of FABID is 0x4. Fix it.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Robin Gong <b38343@freescale.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbe63ac787193844217e30596ce9addf84dafa8e
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Dec 12 17:12:34 2013 -0800

    mm: memcg: fix race condition between memcg teardown and swapin
    
    commit 96f1c58d853497a757463e0b57fed140d6858f3a upstream.
    
    There is a race condition between a memcg being torn down and a swapin
    triggered from a different memcg of a page that was recorded to belong
    to the exiting memcg on swapout (with CONFIG_MEMCG_SWAP extension).  The
    result is unreclaimable pages pointing to dead memcgs, which can lead to
    anything from endless loops in later memcg teardown (the page is charged
    to all hierarchical parents but is not on any LRU list) or crashes from
    following the dangling memcg pointer.
    
    Memcgs with tasks in them can not be torn down and usually charges don't
    show up in memcgs without tasks.  Swapin with the CONFIG_MEMCG_SWAP
    extension is the notable exception because it charges the cgroup that
    was recorded as owner during swapout, which may be empty and in the
    process of being torn down when a task in another memcg triggers the
    swapin:
    
      teardown:                 swapin:
    
                                lookup_swap_cgroup_id()
                                rcu_read_lock()
                                mem_cgroup_lookup()
                                css_tryget()
                                rcu_read_unlock()
      disable css_tryget()
      call_rcu()
        offline_css()
          reparent_charges()
                                res_counter_charge() (hierarchical!)
                                css_put()
                                  css_free()
                                pc->mem_cgroup = dead memcg
                                add page to dead lru
    
    Add a final reparenting step into css_free() to make sure any such raced
    charges are moved out of the memcg before it's finally freed.
    
    In the longer term it would be cleaner to have the css_tryget() and the
    res_counter charge under the same RCU lock section so that the charge
    reparenting is deferred until the last charge whose tryget succeeded is
    visible.  But this will require more invasive changes that will be
    harder to evaluate and backport into stable, so better defer them to a
    separate change set.
    
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: 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 e9710e26511bd44af8f797dc773d3d81b0933a49
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Dec 12 17:12:35 2013 -0800

    mm: memcg: do not allow task about to OOM kill to bypass the limit
    
    commit 1f14c1ac19aa45118054b6d5425873c5c7fc23a1 upstream.
    
    Commit 4942642080ea ("mm: memcg: handle non-error OOM situations more
    gracefully") allowed tasks that already entered a memcg OOM condition to
    bypass the memcg limit on subsequent allocation attempts hoping this
    would expedite finishing the page fault and executing the kill.
    
    David Rientjes is worried that this breaks memcg isolation guarantees
    and since there is no evidence that the bypass actually speeds up fault
    processing just change it so that these subsequent charge attempts fail
    outright.  The notable exception being __GFP_NOFAIL charges which are
    required to bypass the limit regardless.
    
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: David Rientjes <rientjes@google.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Acked-bt: David Rientjes <rientjes@google.com>
    Cc: <stable@kernel.org>
    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 3594bd7a05cb04a2459f4fadf0dc8f6685f2e952
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Dec 12 17:12:20 2013 -0800

    mm: memcg: do not declare OOM from __GFP_NOFAIL allocations
    
    commit a0d8b00a3381f9d75764b3377590451cb0b4fe41 upstream.
    
    Commit 84235de394d9 ("fs: buffer: move allocation failure loop into the
    allocator") started recognizing __GFP_NOFAIL in memory cgroups but
    forgot to disable the OOM killer.
    
    Any task that does not fail allocation will also not enter the OOM
    completion path.  So don't declare an OOM state in this case or it'll be
    leaked and the task be able to bypass the limit until the next
    userspace-triggered page fault cleans up the OOM state.
    
    Reported-by: William Dauchy <wdauchy@gmail.com>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: 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 1b69f2d75bd32f0d2254538f4fb948a673bd9c08
Author: Linus Pizunski <linus@narrativeteam.com>
Date:   Thu Dec 12 17:12:23 2013 -0800

    drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap
    
    commit eb3c227289840eed95ddfb0516046f08d8993940 upstream.
    
    Update month and day of month to the alarm month/day instead of current
    day/month when setting the RTC alarm mask.
    
    Signed-off-by: Linus Pizunski <linus@narrativeteam.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.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 4723e4275b53715982c58f1cc0f0b27f278314d3
Author: Hong H. Pham <hong.pham@windriver.com>
Date:   Sat Dec 7 09:06:33 2013 -0500

    powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
    
    commit cf77ee54362a245f9a01f240adce03a06c05eb68 upstream.
    
    In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
    not been converted by page_address() to the newly allocated PTE page.
    
    When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
    with an address to the PTE page that has been converted by page_address().
    The mismatch in the PTE's page address causes pgtable_page_dtor() to access
    invalid memory, so resources for that PTE (such as the page lock) is not
    properly cleaned up.
    
    On PPC32, only SMP kernels are affected.
    
    On PPC64, only SMP kernels with 4K page size are affected.
    
    This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
    "powerpc: Move the pte free routines from common header".
    
    On a preempt-rt kernel, a spinlock is dynamically allocated for each
    PTE in pgtable_page_ctor().  When the PTE is freed, calling
    pgtable_page_dtor() with a mismatched page address causes a memory leak,
    as the pointer to the PTE's spinlock is bogus.
    
    On mainline, there isn't any immediately obvious symptoms, but the
    problem still exists here.
    
    Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b819d39754f900d1c079b205a17f0a8bf047ce49
Author: Antti Palosaari <crope@iki.fi>
Date:   Wed Nov 27 17:23:00 2013 -0300

    media: af9035: fix broken I2C and USB I/O
    
    commit 9323297dc0ea9141f8099e474657391bb3ad98f8 upstream.
    
    There was three small buffer len calculation bugs which caused
    driver non-working. These are coming from recent commit:
    commit 7760e148350bf6df95662bc0db3734e9d991cb03
    [media] af9035: Don't use dynamic static allocation
    
    Signed-off-by: Antti Palosaari <crope@iki.fi>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c01e68d000d1210d4dc68810014db4edc3af969
Author: Christian Engelmayer <christian.engelmayer@frequentis.com>
Date:   Tue Nov 26 18:16:17 2013 -0800

    Input: usbtouchscreen - separate report and transmit buffer size handling
    
    commit 4ef38351d770cc421f4a0c7a849fd13207fc5741 upstream.
    
    This patch supports the separate handling of the USB transfer buffer length
    and the length of the buffer used for multi packet support. For devices
    supporting multiple report or diagnostic packets, the USB transfer size is now
    limited to the USB endpoints wMaxPacketSize - otherwise it defaults to the
    configured report packet size as before.
    
    This fixes an issue where event reporting can be delayed for an arbitrary
    time for multi packet devices. For instance the report size for eGalax devices
    is defined to the 16 byte maximum diagnostic packet size as opposed to the 5
    byte report packet size. In case the driver requests 16 byte from the USB
    interrupt endpoint, the USB host controller driver needs to split up the
    request into 2 accesses according to the endpoints wMaxPacketSize of 8 byte.
    When the first transfer is answered by the eGalax device with not less than
    the full 8 byte requested, the host controller has got no way of knowing
    whether the touch controller has got additional data queued and will issue
    the second transfer. If per example a liftoff event finishes at such a
    wMaxPacketSize boundary, the data will not be available to the usbtouch driver
    until a further event is triggered and transfered to the host. From user
    perspective the BTN_TOUCH release event in this case is stuck until the next
    touch down event.
    
    Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d93dae88cedd47e58f4e34126420a80a521998d
Author: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Date:   Mon Dec 2 09:00:11 2013 +0000

    USB: option: support new huawei devices
    
    commit 2bf308d7bc5e8cdd69672199f59532f35339133c upstream.
    
    Add new supporting declarations to option.c, to support Huawei new
    devices with new bInterfaceProtocol value.
    
    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 588cd6b701fed893d55a5aec76b06fa2aa445147
Author: Gustavo Zacarias <gustavo@zacarias.com.ar>
Date:   Mon Nov 11 09:59:15 2013 -0300

    USB: serial: option: blacklist interface 1 for Huawei E173s-6
    
    commit 8f173e22abf2258ddfa73f46eadbb6a6c29f1631 upstream.
    
    Interface 1 on this device isn't for option to bind to otherwise an oops
    on usb_wwan with log flooding will happen when accessing the port:
    
    tty_release: ttyUSB1: read/write wait queue active!
    
    It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
    it there - it's likely used by the card reader.
    
    Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5227e3f59f34958e666308334fd83b7966fcb950
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Nov 12 16:37:47 2013 +0100

    usb: musb: musb_cppi41: handle pre-mature TX complete interrupt
    
    commit a655f481d83d6d37bec0a2ddfdd24c30ff8f541f upstream.
    
    The TX-complete interrupt of the CPPI41 on AM335x fires too early.
    Adding a loop and counting how long it takes until the
    MUSB_TXCSR_TXPKTRDY bit is cleared I see
    FS:
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadc54002, len=1514 is_tx=1
    |cppi41_dma_callback() 74 loops
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8802, len=1514 is_tx=1
    |cppi41_dma_callback() 66 loops
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8002, len=1514 is_tx=1
    |cppi41_dma_callback() 136 loops
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadf55802, len=1514 is_tx=1
    |cppi41_dma_callback() 136 loops
    
    avg: 110 - 150us
    
    HS:
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xaca6f002, len=1514 is_tx=1
    |cppi41_dma_callback() 0 loops
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f802, len=1514 is_tx=1
    |cppi41_dma_callback() 2 loops
    |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f002, len=1514 is_tx=1
    |cppi41_dma_callback() 13 loops
    
    avg: 2us
    
    for the same test case. One loop means a udelay(1). The delay seems to
    depend on the packet size. On HS the bit is always cleared for small
    packet sizes while on FS it is never the case, it mostly around 110us.
    This testing has been performed with g_ether (musb as device) and using BULK
    transfers.
    
    INTR transfers are way more fun: during init the gadget sends a INT
    packet to the host and cppi41 says "transfer done" shortly after. The
    MUSB_TXCSR_TXPKTRDY bit is set even seconds later. The reason is that the host
    did not try to receive it, it does so after the interface (on host side) has
    been configured. Until this happens, that packet remains in musb's FIFO.
    
    To fix this, two things are done:
    - No DMA transfers for INT based endpoints. These transfer are usually
      very small and rare so it is likely better to skip the DMA engine and
      stuff the four bytes directly into the FIFO
    - on HS we poll up to 25us and hope that bit goes away. If not we setup
      a hrtimer to poll for it. The 140us delay is a rule of thumb. In FS
      the command
      | ping 10.10.10.10 -c1 -s65130
      creates about 44 1514bytes transfers. About 19 of them need a second
      timer to complete.
    
    Reported-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5f4d64674beb372148365dee51bba99728505e5
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Nov 12 16:37:46 2013 +0100

    usb: musb: musb_cppi41: factor most of cppi41_dma_callback() into cppi41_trans_done()
    
    commit d373a8534d5e1e7a350e40d3c11961a7cd8d530b upstream.
    
    This patch moves most of the logic in cppi41_dma_callback() into
    cppi41_trans_done() where it can be called from another function.
    Instead of computing "transferred" (the number of bytes transferred in
    the last transaction) in cppi41_trans_done() the member
    "cppi41_channel->prog_len" is now set to 0 if the transfer as a whole
    can be considered as done. If it is != 0 then the next iteration is
    assumed.
    This is a preparation for a workaround.
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 459d3c14611784bc5155cc622536b2b0f0740aa2
Author: David Laight <David.Laight@ACULAB.COM>
Date:   Mon Nov 11 12:26:54 2013 +0000

    usb: xhci: Link TRB must not occur within a USB payload burst
    
    commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
    
    Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
    can only occur at a boundary between underlying USB frames (512 bytes for
    high speed devices).
    
    If this isn't done the USB frames aren't formatted correctly and, for example,
    the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
    when running a netperf tcp transmit test with (say) and 8k buffer.
    
    This should be a candidate for stable, the ax88179_178a driver defaults to
    gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
    
    Notes from Sarah:
    
    Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
    
    This patch fixes a long-standing xHCI driver bug that was revealed by a
    change in 3.12 in the usb-net driver.  Commit
    638c5115a794981441246fa8fa5d95c1875af5ba "USBNET: support DMA SG" added
    support to use bulk endpoint scatter-gather (urb->sg).  Only the USB
    ethernet drivers trigger this bug, because the mass storage driver sends
    sg list entries in page-sized chunks.
    
    This patch only fixes the issue for bulk endpoint scatter-gather.  The
    problem will still occur for periodic endpoints, because hosts will
    interpret no-op transfers as a request to skip a service interval, which
    is not what we want.
    
    Luckily, the USB core isn't set up for scatter-gather on isochronous
    endpoints, and no USB drivers use scatter-gather for interrupt
    endpoints.  Document this known limitation so that developers won't try
    to use urb->sg for interrupt endpoints until this issue is fixed.  The
    more comprehensive fix would be to allow link TRBs in the middle of the
    endpoint ring and revert this patch, but that fix would touch too much
    code to be allowed in for stable.
    
    This patch should be backported to kernels as old as 3.12, that contain
    the commit 638c5115a794981441246fa8fa5d95c1875af5ba "USBNET: support DMA
    SG".  Without this patch, the USB network device gets wedged, and stops
    sending packets.  Mark Lord confirms this patch fixes the regression:
    
    http://marc.info/?l=linux-netdev&m=138487107625966&w=2
    
    Signed-off-by: David Laight <david.laight@aculab.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Mark Lord <mlord@pobox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68c4e50ee15f1095be85ff2c670ed005a26c51c5
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Mon Nov 11 23:43:32 2013 +0100

    usb: gadget: composite: reset delayed_status on reset_config
    
    commit 2bac51a1827a18821150ed8c9f9752c02f9c2b02 upstream.
    
    The delayed_status value is used to keep track of status response
    packets on ep0. It needs to be reset or the set_config function would
    still delay the answer, if the usb device got unplugged while waiting
    for setup_continue to be called.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14d9ceaf84edebb520b2b7c1f8800fef5364ccbf
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Nov 1 12:05:12 2013 -0400

    usb: dwc3: fix implementation of endpoint wedge
    
    commit a535d81c92615b8ffb99b7e1fd1fb01effaed1af upstream.
    
    The dwc3 UDC driver doesn't implement endpoint wedging correctly.
    When an endpoint is wedged, the gadget driver should be allowed to
    clear the wedge by calling usb_ep_clear_halt().  Only the host is
    prevented from resetting the endpoint.
    
    This patch fixes the implementation.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Pratyush Anand <pratyush.anand@st.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb4e47f9e933441aa17bb7aa8f505444927ea10b
Author: Julius Werner <jwerner@chromium.org>
Date:   Thu Nov 7 10:59:14 2013 -0800

    usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
    
    commit 2d51f3cd11f414c56a87dc018196b85fd50b04a4 upstream.
    
    This patch adds a check for USB_STATE_NOTATTACHED to the
    hub_port_warm_reset_required() workaround for ports that end up in
    Compliance Mode in hub_events() when trying to decide which reset
    function to use. Trying to call usb_reset_device() with a NOTATTACHED
    device will just fail and leave the port broken.
    
    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99391a829fb2045a3f3d159a66a438fa4cd70bb2
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Dec 2 15:26:19 2013 -0500

    nfsd: when reusing an existing repcache entry, unhash it first
    
    commit 781c2a5a5f75eacc04663aced0f0f1a648d4f308 upstream.
    
    The DRC code will attempt to reuse an existing, expired cache entry in
    preference to allocating a new one. It'll then search the cache, and if
    it gets a hit it'll then free the cache entry that it was going to
    reuse.
    
    The cache code doesn't unhash the entry that it's going to reuse
    however, so it's possible for it end up designating an entry for reuse
    and then subsequently freeing the same entry after it finds it.  This
    leads it to a later use-after-free situation and usually some list
    corruption warnings or an oops.
    
    Fix this by simply unhashing the entry that we intend to reuse. That
    will mean that it's not findable via a search and should prevent this
    situation from occurring.
    
    Reported-by: Christoph Hellwig <hch@infradead.org>
    Reported-by: g. artim <gartim@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60820b2b4fb34a19075ce3562fe948ee9a5b366f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Dec 12 09:38:42 2013 -0800

    futex: fix handling of read-only-mapped hugepages
    
    commit f12d5bfceb7e1f9051563381ec047f7f13956c3c upstream.
    
    The hugepage code had the exact same bug that regular pages had in
    commit 7485d0d3758e ("futexes: Remove rw parameter from
    get_futex_key()").
    
    The regular page case was fixed by commit 9ea71503a8ed ("futex: Fix
    regression with read only mappings"), but the transparent hugepage case
    (added in a5b338f2b0b1: "thp: update futex compound knowledge") case
    remained broken.
    
    Found by Dave Jones and his trinity tool.
    
    Reported-and-tested-by: Dave Jones <davej@fedoraproject.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Darren Hart <dvhart@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ab0ff9b179aadf1f30f2dfa9db2b9404324e135
Author: Khalid Aziz <khalid.aziz@oracle.com>
Date:   Wed Nov 27 15:19:25 2013 -0700

    PCI: Disable Bus Master only on kexec reboot
    
    commit 4fc9bbf98fd66f879e628d8537ba7c240be2b58e upstream.
    
    Add a flag to tell the PCI subsystem that kernel is shutting down in
    preparation to kexec a kernel.  Add code in PCI subsystem to use this flag
    to clear Bus Master bit on PCI devices only in case of kexec reboot.
    
    This fixes a power-off problem on Acer Aspire V5-573G and likely other
    machines and avoids any other issues caused by clearing Bus Master bit on
    PCI devices in normal shutdown path.  The problem was introduced by
    b566a22c2332 ("PCI: disable Bus Master on PCI device shutdown").
    
    This patch is based on discussion at
    http://marc.info/?l=linux-pci&m=138425645204355&w=2
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=63861
    Reported-by: Chang Liu <cl91tp@gmail.com>
    Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 755ca0109f973f23fced94f8dcd8c60e013f270a
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Nov 11 15:23:01 2013 +0200

    iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160
    
    commit 6960a059b2c618f32fe549f13287b3d2278c09e9 upstream.
    
    We changed the timeout for the interrupt coealescing for
    calibration, but that wasn't effective since we changed
    that value back before loading the firmware. Since
    calibrations are notification from firmware and not Rx
    packets, this doesn't change anyway - the firmware will
    fire an interrupt straight away regardless of the interrupt
    coalescing value.
    Also, a HW issue has been discovered in 7000 devices series.
    The work around is to disable the new interrupt coalescing
    timeout feature - do this by setting bit 31 in
    CSR_INT_COALESCING.
    This has been fixed in 7265 which means that we can't rely
    on the device family and must have a hint in the iwl_cfg
    structure.
    
    Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5e6d588f847fba87394926284cc4a7a3b79c6bf
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 31 21:00:10 2013 +0300

    xfs: underflow bug in xfs_attrlist_by_handle()
    
    commit 31978b5cc66b8ba8a7e8eef60b12395d41b7b890 upstream.
    
    If we allocate less than sizeof(struct attrlist) then we end up
    corrupting memory or doing a ZERO_PTR_SIZE dereference.
    
    This can only be triggered with CAP_SYS_ADMIN.
    
    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b115360756c00867dfeb633daaf092c0a3996ba
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Nov 21 15:41:06 2013 +1100

    xfs: growfs overruns AGFL buffer on V4 filesystems
    
    commit f94c44573e7c22860e2c3dfe349c45f72ba35ad3 upstream.
    
    This loop in xfs_growfs_data_private() is incorrect for V4
    superblocks filesystems:
    
    		for (bucket = 0; bucket < XFS_AGFL_SIZE(mp); bucket++)
    			agfl->agfl_bno[bucket] = cpu_to_be32(NULLAGBLOCK);
    
    For V4 filesystems, we don't have a agfl header structure, and so
    XFS_AGFL_SIZE() returns an entire sector's worth of entries, which
    we then index from an offset into the sector. Hence: buffer overrun.
    
    This problem was introduced in 3.10 by commit 77c95bba ("xfs: add
    CRC checks to the AGFL") which changed the AGFL structure but failed
    to update the growfs code to handle the different structures.
    
    Fix it by using the correct offset into the buffer for both V4 and
    V5 filesystems.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Jie Liu <jeff.liu@oracle.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51f3ae937ca288978ab3c63ec2ae48d687cb3347
Author: Jean Delvare <khali@linux-fr.org>
Date:   Thu Dec 12 08:05:32 2013 +0100

    hwmon: (w83l768ng) Fix fan speed control range
    
    commit 33a7ab91d509fa33b4bcd3ce0038cc80298050da upstream.
    
    The W83L786NG stores the fan speed on 4 bits while the sysfs interface
    uses a 0-255 range. Thus the driver should scale the user input down
    to map it to the device range, and scale up the value read from the
    device before presenting it to the user. The reserved register nibble
    should be left unchanged.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edf0afdbe45326982177055e7551b3b7e7d1e8eb
Author: Brian Carnes <bmcarnes@gmail.com>
Date:   Thu Dec 12 08:05:32 2013 +0100

    hwmon: (w83l786ng) Fix fan speed control mode setting and reporting
    
    commit cf7559bc053471f32373d71d04a9aa19e0b48d59 upstream.
    
    The wrong mask is used, which causes some fan speed control modes
    (pwmX_enable) to be incorrectly reported, and some modes to be
    impossible to set.
    
    [JD: add subject and description.]
    
    Signed-off-by: Brian Carnes <bmcarnes@gmail.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45e569b558a59837f88d8eda7527d7c50154d75d
Author: José Miguel Gonçalves <jose.goncalves@inov.pt>
Date:   Wed Dec 11 11:11:13 2013 +0000

    hwmon: HIH-6130: Support I2C bus drivers without I2C_FUNC_SMBUS_QUICK
    
    commit efabcc2123f0ed47870033b8d6fc73b50d76d635 upstream.
    
    Some I2C bus drivers do not allow zero-length data transfers which are
    required to start a measurement with the HIH6130/1 sensor. Nevertheless,
    we can overcome this limitation by writing a zero dummy byte. This byte
    is ignored by the sensor and was verified to be working with the OMAP
    I2C bus driver in a BeagleBone board.
    
    Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt>
    [Guenter Roeck: Simplified complexity of write_length initialization]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6ddcefc7e3694fdf85703b366d35b4bdb1b89fd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 12 08:05:33 2013 +0100

    hwmon: Prevent some divide by zeros in FAN_TO_REG()
    
    commit 3806b45ba4655147a011df03242cc197ab986c43 upstream.
    
    The "rpm * div" operations can overflow here, so this patch adds an
    upper limit to rpm to prevent that.  Jean Delvare helped me with this
    patch.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Roger Lucas <vt8231@hiddenengine.co.uk>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48849efc2e3c58d170e32d081f83f6c070dfd0a3
Author: Gleb Natapov <gleb@redhat.com>
Date:   Thu Dec 12 21:20:08 2013 +0100

    KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376)
    
    commit 17d68b763f09a9ce824ae23eb62c9efc57b69271 upstream.
    
    A guest can cause a BUG_ON() leading to a host kernel crash.
    When the guest writes to the ICR to request an IPI, while in x2apic
    mode the following things happen, the destination is read from
    ICR2, which is a register that the guest can control.
    
    kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
    cluster id.  A BUG_ON is triggered, which is a protection against
    accessing map->logical_map with an out-of-bounds access and manages
    to avoid that anything really unsafe occurs.
    
    The logic in the code is correct from real HW point of view. The problem
    is that KVM supports only one cluster with ID 0 in clustered mode, but
    the code that has the bug does not take this into account.
    
    Reported-by: Lars Bull <larsbull@google.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0149f684726ef4a5e91b8ba1d408a64dfb40385
Author: Andy Honig <ahonig@google.com>
Date:   Wed Nov 20 10:23:22 2013 -0800

    KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)
    
    commit fda4e2e85589191b123d31cdc21fd33ee70f50fd upstream.
    
    In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
    potential to corrupt kernel memory if userspace provides an address that
    is at the end of a page.  This patches concerts those functions to use
    kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
    vapic_address specified by userspace during ioctl processing and returns
    an error to userspace if the address is not a valid GPA.
    
    This is generally not guest triggerable, because the required write is
    done by firmware that runs before the guest.  Also, it only affects AMD
    processors and oldish Intel that do not have the FlexPriority feature
    (unless you disable FlexPriority, of course; then newer processors are
    also affected).
    
    Fixes: b93463aa59d6 ('KVM: Accelerated apic support')
    
    Reported-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10958718b005e046244d2b4a1f1bb9a3ab6e3d29
Author: Andy Honig <ahonig@google.com>
Date:   Tue Nov 19 14:12:18 2013 -0800

    KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367)
    
    commit b963a22e6d1a266a67e9eecc88134713fd54775c upstream.
    
    Under guest controllable circumstances apic_get_tmcct will execute a
    divide by zero and cause a crash.  If the guest cpuid support
    tsc deadline timers and performs the following sequence of requests
    the host will crash.
    - Set the mode to periodic
    - Set the TMICT to 0
    - Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
    - Set the TMICT to non-zero.
    Then the lapic_timer.period will be 0, but the TMICT will not be.  If the
    guest then reads from the TMCCT then the host will perform a divide by 0.
    
    This patch ensures that if the lapic_timer.period is 0, then the division
    does not occur.
    
    Reported-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41fe7fa8fdeaa5a2a9f3ecaa9a47e2d2afa1b2b1
Author: Andy Honig <ahonig@google.com>
Date:   Mon Nov 18 16:09:22 2013 -0800

    KVM: Improve create VCPU parameter (CVE-2013-4587)
    
    commit 338c7dbadd2671189cec7faf64c84d01071b3f96 upstream.
    
    In multiple functions the vcpu_id is used as an offset into a bitfield.  Ag
    malicious user could specify a vcpu_id greater than 255 in order to set or
    clear bits in kernel memory.  This could be used to elevate priveges in the
    kernel.  This patch verifies that the vcpu_id provided is less than 255.
    The api documentation already specifies that the vcpu_id must be less than
    max_vcpus, but this is currently not checked.
    
    Reported-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2925f142d855585427a63da50744766a47659e0f
Author: Jon Medhurst <tixy@linaro.org>
Date:   Mon Dec 9 13:45:46 2013 +0100

    ARM: 7917/1: cacheflush: correctly limit range of memory region being flushed
    
    commit b31459adeab018b297541e288ac88873011da82a upstream.
    
    The __do_cache_op function operates with a 'chunk' size of one page
    but fails to limit the size of the final chunk so as to not exceed
    the specified memory region. Fix this.
    
    Reported-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jon Medhurst <tixy@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56e975068d0f09c870ffb117c690919531e18294
Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Date:   Thu Dec 5 14:23:48 2013 +0100

    ARM: 7913/1: fix framepointer check in unwind_frame
    
    commit 3abb6671a9c04479c4bd026798a05f857393b7e2 upstream.
    
    This patch fixes corner case when (fp + 4) overflows unsigned long,
    for example: fp = 0xFFFFFFFF -> fp + 4 == 3.
    
    Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55727f26e32962c2e516bbebae1640feb3bc5b20
Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Date:   Thu Dec 5 14:21:36 2013 +0100

    ARM: 7912/1: check stack pointer in get_wchan
    
    commit 1b15ec7a7427d4188ba91b9bbac696250a059d22 upstream.
    
    get_wchan() is lockless. Task may wakeup at any time and change its own stack,
    thus each next stack frame may be overwritten and filled with random stuff.
    
    /proc/$pid/stack interface had been disabled for non-current tasks, see [1]
    But 'wchan' still allows to trigger stack frame unwinding on volatile stack.
    
    This patch fixes oops in unwind_frame() by adding stack pointer validation on
    each step (as x86 code do), unwind_frame() already checks frame pointer.
    
    Also I've found another report of this oops on stackoverflow (irony).
    
    Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1]
    Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error
    
    Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c14b0b4d0553f2bd1325bce20a551d6e9350a26
Author: Roger Quadros <rogerq@ti.com>
Date:   Sun Dec 8 18:39:02 2013 -0700

    ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module
    
    commit 7f4d3641e2548d1ac5dee837ff434df668a2810c upstream.
    
    Unlike what the comment states, errata i660 does not state that we
    can't RESET the USB host module. Instead it states that RESET is the
    only way to recover from a deadlock situation.
    
    RESET ensures that the module is in a known good state irrespective
    of what bootloader does with the module, so it must be done at boot.
    
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
    Fixes: de231388cb80 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
    Signed-off-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df86d901aba21bba9f047e170cb773caa1070f3d
Author: Sergei Ianovich <ynvich@gmail.com>
Date:   Tue Dec 10 08:39:15 2013 +0400

    ARM: pxa: prevent PXA270 occasional reboot freezes
    
    commit ff88b4724fde18056a4c539f7327389aec0f4c2d upstream.
    
    Erratum 71 of PXA270M Processor Family Specification Update
    (April 19, 2010) explains that watchdog reset time is just
    8us insead of 10ms in EMTS.
    
    If SDRAM is not reset, it causes memory bus congestion and
    the device hangs. We put SDRAM in selfresh mode before watchdog
    reset, removing potential freezes.
    
    Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40
    reboots. With this patch it has successfully rebooted 500 times.
    
    Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
    Tested-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc232e5d934b60e8467ebf3d30a0fd4e01a0dd75
Author: Maxime Ripard <maxime.ripard@free-electrons.com>
Date:   Tue Dec 10 19:37:22 2013 +0100

    ARM: sun6i: dt: Fix interrupt trigger types
    
    commit 6f97dc8d4663abed96fa30e3ea4a1d4cfd1c4276 upstream.
    
    The Allwinner A31 uses the ARM GIC as its internal interrupts controller. The
    GIC can work on several interrupt triggers, and the A31 was actually setting it
    up to use a rising edge as a trigger, while it was actually a level high
    trigger, leading to some interrupts that would be completely ignored if the
    edge was missed.
    
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2941bdd12f8071e40c0036e1c2218fa41804aa9b
Author: Rob Herring <rob.herring@calxeda.com>
Date:   Wed Dec 4 11:05:17 2013 -0600

    ARM: highbank: handle soft poweroff and reset key events
    
    commit 3843114856728075d0a80e7151197c19fb3a9e08 upstream.
    
    Graceful reboot and poweroff via IPMI commands to the management
    processor don't work. Power and reset keys are events from the
    management processor which are generated via IPC messages. Passing
    the keys to userspace does not work as neither acpid nor a desktop
    environment are present.
    
    This adds a notifier handler for the IPC messages so the kernel can
    handle the key events directly and IPMI graceful shutdown will work.
    
    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 448211a1b4bc6acb54de470d7205e9efb4374b55
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Sat Nov 16 16:47:50 2013 +0400

    ARM: pxa: tosa: fix keys mapping
    
    commit 506cac15ac86f204b83e3cfccde73eeb4e7c5f34 upstream.
    
    When converting from tosa-keyboard driver to matrix keyboard, tosa keys
    received extra 1 column shift. Replace that with correct values to make
    keyboard work again.
    
    Fixes: f69a6548c9d5 ('[ARM] pxa/tosa: make use of the matrix keypad driver')
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c9e85a419e20fdf65053575ffe72ac4f1b7dfb4
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Tue Dec 10 22:46:34 2013 +0200

    ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices
    
    commit c9a6338aecdb92f9d015ecc26d203e54250bebbb upstream.
    
    In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
    outputs will have their IEC958 controls created starting from index 16
    and the HDMI controls will be created starting from index 0.
    
    However, HDMI simple_playback_build_controls() as used by old VIA and
    NVIDIA codecs incorrectly requests the IEC958 controls to be created
    with an S/PDIF type instead of HDMI.
    In case the card has other codecs that have HDMI outputs, the controls
    will be created with wrong index=16, causing them to e.g. be unreachable
    by the ALSA "hdmi" alias.
    
    Fix that by making simple_playback_build_controls() request controls
    with HDMI indexes.
    
    Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
    contains an integrated NVIDIA HDA "card" with:
    - a VIA codec that has, among others, an S/PDIF pin incorrectly
      labelled as an HDMI pin, and
    - an NVIDIA MCP7x HDMI codec.
    
    Reported-by: MysterX on #openelec
    Tested-by: MysterX on #openelec
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2051cf938acbdc23072ed12f5eb92faab75f994f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 10 17:33:49 2013 +0100

    ALSA: hda - Mute all aamix inputs as default
    
    commit ebb93c057dda376414fbc499ad6ace9b527dff5a upstream.
    
    Not all channels have been initialized, so far, especially when aamix
    NID itself doesn't have amps but its leaves have.  This patch fixes
    these holes.  Otherwise you might get unexpected loopback inputs,
    e.g. from surround channels.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2c1cf61df06f1f9ec07f9091b0e9810324cc84f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 10 17:29:26 2013 +0100

    ALSA: hda - Add static DAC/pin mapping for AD1986A codec
    
    commit 3690739b013504d33fe9348dd45f6b126aa370fb upstream.
    
    AD1986A codec is a pretty old codec and has really many hidden
    restrictions.  One of such is that each DAC is dedicated to certain
    pin although there are possible connections.  Currently, the generic
    parser tries to assign individual DACs as much as possible, and this
    lead to two bad situations: connections where the sound actually
    doesn't work, and connections conflicting other channels.
    
    We may fix this by trying to find the best connections more harder,
    but as of now, it's easier to give some hints for paired DAC/pin
    connections and honor them if available, since such a hint is needed
    only for specific codecs (right now only AD1986A, and there will be
    unlikely any others in future).
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 922826da9d0c3fff415aa5fad0abbc015c2a7669
Author: Stefano Panella <stefano.panella@citrix.com>
Date:   Tue Dec 10 14:20:28 2013 +0000

    ALSA: memalloc.h - fix wrong truncation of dma_addr_t
    
    commit 932e9dec380c67ec15ac3eb073bb55797d8b4801 upstream.
    
    When running a 32bit kernel the hda_intel driver is still reporting
    a 64bit dma_mask if the HW supports it.
    
    From sound/pci/hda/hda_intel.c:
    
            /* allow 64bit DMA address if supported by H/W */
            if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
                    pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
            else {
                    pci_set_dma_mask(pci, DMA_BIT_MASK(32));
                    pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
            }
    
    which means when there is a call to dma_alloc_coherent from
    snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
    This can be true in particular if running  the 32bit kernel as a pv dom0
    under the Xen Hypervisor or PAE on bare metal.
    
    The problem is that when calling setup_bdle to program the BLE the
    dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
    from snd_sgbuf_get_addr if running a 32bit kernel:
    
    static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
                                               size_t offset)
    {
            struct snd_sg_buf *sgbuf = dmab->private_data;
            dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
            addr &= PAGE_MASK;
            return addr + offset % PAGE_SIZE;
    }
    
    where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
    
    Without this patch the HW will fetch the 32bit truncated address,
    which is not the one obtained from dma_alloc_coherent and will result
    to a non working audio but can corrupt host memory at a random location.
    
    The current patch apply to v3.13-rc3-74-g6c843f5
    
    Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
    Reviewed-by: Frediano Ziglio <frediano.ziglio@citrix.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60d80867eb231385a7a05eb249d03b5f313dac5b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Dec 10 12:15:52 2013 +0100

    ALSA: compress: Fix 64bit ABI incompatibility
    
    commit 6733cf572a9e20db2b7580a5dd39d5782d571eec upstream.
    
    snd_pcm_uframes_t is defined as unsigned long so it would take
    different sizes depending on 32 or 64bit architectures.  As we don't
    want this ABI incompatibility, and there is no real 64bit user yet,
    let's make it the fixed size with __u32.
    
    Also bump the protocol version number to 0.1.2.
    
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02552ad06e442e48082dbb51a32e5228a1b64f48
Author: Rob Clark <robdclark@gmail.com>
Date:   Wed Dec 4 08:45:43 2013 -0500

    udl: fix issue with imported prime buffers
    
    commit 1d507b3af40a60e03a3bbc4c897fc2709c075d24 upstream.
    
    5dc9e1e8 was a bit over-ambitious, and accidentially removed handling
    for imported prime buffers.
    
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 707ac20e933383174419cbc739915cb0fcebe063
Author: Steve Capper <steve.capper@linaro.org>
Date:   Thu Dec 5 12:04:51 2013 +0000

    arm64: mm: Fix PMD_SECT_PROT_NONE definition
    
    commit db4ed53cfe9f5a00355891a631d47dfa3fd4541f upstream.
    
    Modify the value of PMD_SECT_PROT_NONE to match that of PTE_NONE. This
    should have been in commit 3676f9ef5481 (Move PTE_PROT_NONE higher up).
    
    Signed-off-by: Steve Capper <steve.capper@linaro.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>