Squashed: Update to 3.4.80

commit a619f708a1dde96ad876cee1707c9fc066121976
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 13 13:00:25 2014 -0800

    Linux 3.4.80

commit e15c3ee308987fc224932ffba7797b212bc87dd3
Author: Colin Cross <ccross@android.com>
Date:   Mon Feb 10 13:16:29 2014 -0800

    3.4.y: timekeeping: fix 32-bit overflow in get_monotonic_boottime

    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c

    get_monotonic_boottime adds three nanonsecond values stored
    in longs, followed by an s64.  If the long values are all
    close to 1e9 the first three additions can overflow and
    become negative when added to the s64.  Cast the first
    value to s64 so that all additions are 64 bit.

    Signed-off-by: Colin Cross <ccross@android.com>
    [jstultz: Fished this out of the AOSP commong.git tree. This was
    fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Conflicts:
    	kernel/time/timekeeping.c

commit 04b74b376217de59c8bb61c8c539c5fd6ca03cb8
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Dec 10 17:18:18 2013 -0800

    timekeeping: Avoid possible deadlock from clock_was_set_delayed

    commit 6fdda9a9c5db367130cf32df5d6618d08b89f46a upstream.

    As part of normal operaions, the hrtimer subsystem frequently calls
    into the timekeeping code, creating a locking order of
      hrtimer locks -> timekeeping locks

    clock_was_set_delayed() was suppoed to allow us to avoid deadlocks
    between the timekeeping the hrtimer subsystem, so that we could
    notify the hrtimer subsytem the time had changed while holding
    the timekeeping locks. This was done by scheduling delayed work
    that would run later once we were out of the timekeeing code.

    But unfortunately the lock chains are complex enoguh that in
    scheduling delayed work, we end up eventually trying to grab
    an hrtimer lock.

    Sasha Levin noticed this in testing when the new seqlock lockdep
    enablement triggered the following (somewhat abrieviated) message:

    [  251.100221] ======================================================
    [  251.100221] [ INFO: possible circular locking dependency detected ]
    [  251.100221] 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053 Not tainted
    [  251.101967] -------------------------------------------------------
    [  251.101967] kworker/10:1/4506 is trying to acquire lock:
    [  251.101967]  (timekeeper_seq){----..}, at: [<ffffffff81160e96>] retrigger_next_event+0x56/0x70
    [  251.101967]
    [  251.101967] but task is already holding lock:
    [  251.101967]  (hrtimer_bases.lock#11){-.-...}, at: [<ffffffff81160e7c>] retrigger_next_event+0x3c/0x70
    [  251.101967]
    [  251.101967] which lock already depends on the new lock.
    [  251.101967]
    [  251.101967]
    [  251.101967] the existing dependency chain (in reverse order) is:
    [  251.101967]
    -> #5 (hrtimer_bases.lock#11){-.-...}:
    [snipped]
    -> #4 (&rt_b->rt_runtime_lock){-.-...}:
    [snipped]
    -> #3 (&rq->lock){-.-.-.}:
    [snipped]
    -> #2 (&p->pi_lock){-.-.-.}:
    [snipped]
    -> #1 (&(&pool->lock)->rlock){-.-...}:
    [  251.101967]        [<ffffffff81194803>] validate_chain+0x6c3/0x7b0
    [  251.101967]        [<ffffffff81194d9d>] __lock_acquire+0x4ad/0x580
    [  251.101967]        [<ffffffff81194ff2>] lock_acquire+0x182/0x1d0
    [  251.101967]        [<ffffffff84398500>] _raw_spin_lock+0x40/0x80
    [  251.101967]        [<ffffffff81153e69>] __queue_work+0x1a9/0x3f0
    [  251.101967]        [<ffffffff81154168>] queue_work_on+0x98/0x120
    [  251.101967]        [<ffffffff81161351>] clock_was_set_delayed+0x21/0x30
    [  251.101967]        [<ffffffff811c4bd1>] do_adjtimex+0x111/0x160
    [  251.101967]        [<ffffffff811e2711>] compat_sys_adjtimex+0x41/0x70
    [  251.101967]        [<ffffffff843a4b49>] ia32_sysret+0x0/0x5
    [  251.101967]
    -> #0 (timekeeper_seq){----..}:
    [snipped]
    [  251.101967] other info that might help us debug this:
    [  251.101967]
    [  251.101967] Chain exists of:
      timekeeper_seq --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock#11

    [  251.101967]  Possible unsafe locking scenario:
    [  251.101967]
    [  251.101967]        CPU0                    CPU1
    [  251.101967]        ----                    ----
    [  251.101967]   lock(hrtimer_bases.lock#11);
    [  251.101967]                                lock(&rt_b->rt_runtime_lock);
    [  251.101967]                                lock(hrtimer_bases.lock#11);
    [  251.101967]   lock(timekeeper_seq);
    [  251.101967]
    [  251.101967]  *** DEADLOCK ***
    [  251.101967]
    [  251.101967] 3 locks held by kworker/10:1/4506:
    [  251.101967]  #0:  (events){.+.+.+}, at: [<ffffffff81154960>] process_one_work+0x200/0x530
    [  251.101967]  #1:  (hrtimer_work){+.+...}, at: [<ffffffff81154960>] process_one_work+0x200/0x530
    [  251.101967]  #2:  (hrtimer_bases.lock#11){-.-...}, at: [<ffffffff81160e7c>] retrigger_next_event+0x3c/0x70
    [  251.101967]
    [  251.101967] stack backtrace:
    [  251.101967] CPU: 10 PID: 4506 Comm: kworker/10:1 Not tainted 3.13.0-rc2-next-20131206-sasha-00005-g8be2375-dirty #4053
    [  251.101967] Workqueue: events clock_was_set_work

    So the best solution is to avoid calling clock_was_set_delayed() while
    holding the timekeeping lock, and instead using a flag variable to
    decide if we should call clock_was_set() once we've released the locks.

    This works for the case here, where the do_adjtimex() was the deadlock
    trigger point. Unfortuantely, in update_wall_time() we still hold
    the jiffies lock, which would deadlock with the ipi triggered by
    clock_was_set(), preventing us from calling it even after we drop the
    timekeeping lock. So instead call clock_was_set_delayed() at that point.

    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c941ee32b9e966dbb18f459b01f3602a31166ad2
Author: Borislav Petkov <bp@alien8.de>
Date:   Sat Jul 20 19:00:23 2013 +0200

    rtc-cmos: Add an alarm disable quirk

    commit d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d upstream.

    41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
    functionality to disable the RTC wake alarm when shutting down the box.

    However, there are at least two b0rked BIOSes we know about:

    https://bugzilla.novell.com/show_bug.cgi?id=812592
    https://bugzilla.novell.com/show_bug.cgi?id=805740

    where, when wakeup alarm is enabled in the BIOS, the machine reboots
    automatically right after shutdown, regardless of what wakeup time is
    programmed.

    Bisecting the issue lead to this patch so disable its functionality with
    a DMI quirk only for those boxes.

    Cc: Brecht Machiels <brecht@mos6581.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Rabin Vincent <rabin.vincent@stericsson.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    [jstultz: Changed variable name for clarity, added extra dmi entry]
    Tested-by: Brecht Machiels <brecht@mos6581.org>
    Tested-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3aa7dedfc49eebb30fd82f9dcf7d67ec308593a
Author: Ying Xue <ying.xue@windriver.com>
Date:   Tue Jul 17 15:03:43 2012 +0800

    sched/rt: Avoid updating RT entry timeout twice within one tick period

    commit 57d2aa00dcec67afa52478730f2b524521af14fb upstream.

    The issue below was found in 2.6.34-rt rather than mainline rt
    kernel, but the issue still exists upstream as well.

    So please let me describe how it was noticed on 2.6.34-rt:

    On this version, each softirq has its own thread, it means there
    is at least one RT FIFO task per cpu. The priority of these
    tasks is set to 49 by default. If user launches an RT FIFO task
    with priority lower than 49 of softirq RT tasks, it's possible
    there are two RT FIFO tasks enqueued one cpu runqueue at one
    moment. By current strategy of balancing RT tasks, when it comes
    to RT tasks, we really need to put them off to a CPU that they
    can run on as soon as possible. Even if it means a bit of cache
    line flushing, we want RT tasks to be run with the least latency.

    When the user RT FIFO task which just launched before is
    running, the sched timer tick of the current cpu happens. In this
    tick period, the timeout value of the user RT task will be
    updated once. Subsequently, we try to wake up one softirq RT
    task on its local cpu. As the priority of current user RT task
    is lower than the softirq RT task, the current task will be
    preempted by the higher priority softirq RT task. Before
    preemption, we check to see if current can readily move to a
    different cpu. If so, we will reschedule to allow the RT push logic
    to try to move current somewhere else. Whenever the woken
    softirq RT task runs, it first tries to migrate the user FIFO RT
    task over to a cpu that is running a task of lesser priority. If
    migration is done, it will send a reschedule request to the found
    cpu by IPI interrupt. Once the target cpu responds the IPI
    interrupt, it will pick the migrated user RT task to preempt its
    current task. When the user RT task is running on the new cpu,
    the sched timer tick of the cpu fires. So it will tick the user
    RT task again. This also means the RT task timeout value will be
    updated again. As the migration may be done in one tick period,
    it means the user RT task timeout value will be updated twice
    within one tick.

    If we set a limit on the amount of cpu time for the user RT task
    by setrlimit(RLIMIT_RTTIME), the SIGXCPU signal should be posted
    upon reaching the soft limit.

    But exactly when the SIGXCPU signal should be sent depends on the
    RT task timeout value. In fact the timeout mechanism of sending
    the SIGXCPU signal assumes the RT task timeout is increased once
    every tick.

    However, currently the timeout value may be added twice per
    tick. So it results in the SIGXCPU signal being sent earlier
    than expected.

    To solve this issue, we prevent the timeout value from increasing
    twice within one tick time by remembering the jiffies value of
    last updating the timeout. As long as the RT task's jiffies is
    different with the global jiffies value, we allow its timeout to
    be updated.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Fan Du <fan.du@windriver.com>
    Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1342508623-2887-1-git-send-email-ying.xue@windriver.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [ lizf: backported to 3.4: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d4949d38a1594a0e4e129300ac17e2b9f3e6b9
Author: Peter Boonstoppel <pboonstoppel@nvidia.com>
Date:   Thu Aug 9 15:34:47 2012 -0700

    sched: Unthrottle rt runqueues in __disable_runtime()

    commit a4c96ae319b8047f62dedbe1eac79e321c185749 upstream.

    migrate_tasks() uses _pick_next_task_rt() to get tasks from the
    real-time runqueues to be migrated. When rt_rq is throttled
    _pick_next_task_rt() won't return anything, in which case
    migrate_tasks() can't move all threads over and gets stuck in an
    infinite loop.

    Instead unthrottle rt runqueues before migrating tasks.

    Additionally: move unthrottle_offline_cfs_rqs() to rq_offline_fair()

    Signed-off-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Turner <pjt@google.com>
    Link: http://lkml.kernel.org/r/5FBF8E85CA34454794F0F7ECBA79798F379D3648B7@HQMAIL04.nvidia.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [ lizf: backported to 3.4: adjust context ]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f034f0a05fc96332136362d15a33ba1d26f72657
Author: Mike Galbraith <efault@gmx.de>
Date:   Tue Aug 7 10:02:38 2012 +0200

    sched,rt: fix isolated CPUs leaving root_task_group indefinitely throttled

    commit e221d028bb08b47e624c5f0a31732c642db9d19a upstream.

    Root task group bandwidth replenishment must service all CPUs, regardless of
    where the timer was last started, and regardless of the isolation mechanism,
    lest 'Quoth the Raven, "Nevermore"' become rt scheduling policy.

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1344326558.6968.25.camel@marge.simpson.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77d1caaee8a7d7f94be4f69473fd5a89a7bfc8a5
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat May 18 02:38:52 2013 -0400

    hpfs: deadlock and race in directory lseek()

    commit 31abdab9c11bb1694ecd1476a7edbe8e964d94ac upstream.

    For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
    in hpfs_dir_lseek() - there's a lot of methods that grab the former with
    the caller already holding the latter, so it must take i_mutex first.

    For another, locking the damn thing, carefully validating the offset,
    then dropping locks and assigning the offset is obviously racy.

    Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
    won't modify the sucker on B-tree surgeries.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a7601bd0865d2cd53d6ec3a411b3f328338f9a5
Author: Yijing Wang <wangyijing@huawei.com>
Date:   Tue Jan 15 11:12:16 2013 +0800

    PCI: Enable ARI if dev and upstream bridge support it; disable otherwise

    commit b0cc6020e1cc62f1253215f189611b34be4a83c7 upstream.

    Currently, we enable ARI in a device's upstream bridge if the bridge and
    the device support it.  But we never disable ARI, even if the device is
    removed and replaced with a device that doesn't support ARI.

    This means that if we hot-remove an ARI device and replace it with a
    non-ARI multi-function device, we find only function 0 of the new device
    because the upstream bridge still has ARI enabled, and next_ari_fn()
    only returns function 0 for the new non-ARI device.

    This patch disables ARI in the upstream bridge if the device doesn't
    support ARI.  See the PCIe spec, r3.0, sec 6.13.

    [bhelgaas: changelog, function comment]
    [yijing: replace PCIe Cap accessor with legacy PCI accessor]
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6eda5d2b8fb01ae703052036c33e95dc29e5b8e8
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 27 18:29:35 2014 -0500

    drm/radeon/DCE4+: clear bios scratch dpms bit (v2)

    commit 6802d4bad83f50081b2788698570218aaff8d10e upstream.

    The BlankCrtc table in some DCE8 boards has some
    logic shortcuts for the vbios when this bit is set.
    Clear it for driver use.

    v2: fix typo

    Bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=73420

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe4cbd74a9340b533cdec00ef9e1135706d4e098
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 16 18:11:47 2014 -0500

    drm/radeon: set the full cache bit for fences on r7xx+

    commit d45b964a22cad962d3ede1eba8d24f5cee7b2a92 upstream.

    Needed to properly flush the read caches for fences.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4aa87df9038ad14aee42e70088b4686b16e6892a
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Wed Jan 8 18:16:26 2014 +0100

    drm/radeon: skip colorbuffer checking if COLOR_INFO.FORMAT is set to INVALID

    commit 56492e0fac2dbaf7735ffd66b206a90624917789 upstream.

    This fixes a bug which was causing rejections of valid GPU commands
    from userspace.

    Signed-off-by: Marek Olšák <marek.olsak@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bed59c5b0066b79a03a16e52fc3e8f592448dfb0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 8 11:40:20 2014 +0900

    radeon/pm: Guard access to rdev->pm.power_state array

    commit 370169516e736edad3b3c5aa49858058f8b55195 upstream.

    It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.

    Should fix an oops I encountered while resetting the GPU after a lockup
    on my PowerBook with an RV350.

    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 714d87ebf5c8d795d2473e85a5c91a61bb8082bf
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 7 10:05:02 2014 -0500

    drm/radeon: warn users when hw_i2c is enabled (v2)

    commit d195178297de9a91246519dbfa98952b70f9a9b6 upstream.

    The hw i2c engines are disabled by default as the
    current implementation is still experimental.  Print
    a warning when users enable it so that it's obvious
    when the option is enabled.

    v2: check for non-0 rather than 1

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 617a352c209eace74c4766ea614312e5161bca96
Author: Joe Thornber <ejt@redhat.com>
Date:   Tue Jan 7 15:47:59 2014 +0000

    dm space map common: make sure new space is used during extend

    commit 12c91a5c2d2a8e8cc40a9552313e1e7b0a2d9ee3 upstream.

    When extending a low level space map we should update nr_blocks at
    the start so the new space is used for the index entries.

    Otherwise extend can fail, e.g.: sm_metadata_extend call sequence
    that fails:
     -> sm_ll_extend
        -> dm_tm_new_block -> dm_sm_new_block -> sm_bootstrap_new_block
        => returns -ENOSPC because smm->begin == smm->ll.nr_blocks

    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 c84f7bbb1fa79d442d466c12dadc917b2c7fd872
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Jan 6 23:01:22 2014 -0500

    dm: wait until embedded kobject is released before destroying a device

    commit be35f486108227e10fe5d96fd42fb2b344c59983 upstream.

    There may be other parts of the kernel holding a reference on the dm
    kobject.  We must wait until all references are dropped before
    deallocating the mapped_device structure.

    The dm_kobject_release method signals that all references are dropped
    via completion.  But dm_kobject_release doesn't free the kobject (which
    is embedded in the mapped_device structure).

    This is the sequence of operations:
    * when destroying a DM device, call kobject_put from dm_sysfs_exit
    * wait until all users stop using the kobject, when it happens the
      release method is called
    * the release method signals the completion and should return without
      delay
    * the dm device removal code that waits on the completion continues
    * the dm device removal code drops the dm_mod reference the device had
    * the dm device removal code frees the mapped_device structure that
      contains the kobject

    Using kobject this way should avoid the module unload race that was
    mentioned at the beginning of this thread:
    https://lkml.org/lkml/2014/1/4/83

    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 1fef273b0eadf8de10807402c1bd6b2293fd2122
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Tue Dec 17 12:16:11 2013 -0500

    sunrpc: Fix infinite loop in RPC state machine

    commit 6ff33b7dd0228b7d7ed44791bbbc98b03fd15d9d upstream.

    When a task enters call_refreshresult with status 0 from call_refresh and
    !rpcauth_uptodatecred(task) it enters call_refresh again with no rate-limiting
    or max number of retries.

    Instead of trying forever, make use of the retry path that other errors use.

    This only seems to be possible when the crrefresh callback is gss_refresh_null,
    which only happens when destroying the context.

    To reproduce:

    1) mount with sec=krb5 (or sec=sys with krb5 negotiated for non FSID specific
       operations).

    2) reboot - the client will be stuck and will need to be hard rebooted

    BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:2:46]
    Modules linked in: rpcsec_gss_krb5 nfsv4 nfs fscache ppdev crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd serio_raw i2c_piix4 i2c_core e1000 parport_pc parport shpchp nfsd auth_rpcgss oid_registry exportfs nfs_acl lockd sunrpc autofs4 mptspi scsi_transport_spi mptscsih mptbase ata_generic floppy
    irq event stamp: 195724
    hardirqs last  enabled at (195723): [<ffffffff814a925c>] restore_args+0x0/0x30
    hardirqs last disabled at (195724): [<ffffffff814b0a6a>] apic_timer_interrupt+0x6a/0x80
    softirqs last  enabled at (195722): [<ffffffff8103f583>] __do_softirq+0x1df/0x276
    softirqs last disabled at (195717): [<ffffffff8103f852>] irq_exit+0x53/0x9a
    CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc3-branch-dros_testing+ #4
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
    Workqueue: rpciod rpc_async_schedule [sunrpc]
    task: ffff8800799c4260 ti: ffff880079002000 task.ti: ffff880079002000
    RIP: 0010:[<ffffffffa0064fd4>]  [<ffffffffa0064fd4>] __rpc_execute+0x8a/0x362 [sunrpc]
    RSP: 0018:ffff880079003d18  EFLAGS: 00000246
    RAX: 0000000000000005 RBX: 0000000000000007 RCX: 0000000000000007
    RDX: 0000000000000007 RSI: ffff88007aecbae8 RDI: ffff8800783d8900
    RBP: ffff880079003d78 R08: ffff88006e30e9f8 R09: ffffffffa005a3d7
    R10: ffff88006e30e7b0 R11: ffff8800783d8900 R12: ffffffffa006675e
    R13: ffff880079003ce8 R14: ffff88006e30e7b0 R15: ffff8800783d8900
    FS:  0000000000000000(0000) GS:ffff88007f200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f3072333000 CR3: 0000000001a0b000 CR4: 00000000001407f0
    Stack:
     ffff880079003d98 0000000000000246 0000000000000000 ffff88007a9a4830
     ffff880000000000 ffffffff81073f47 ffff88007f212b00 ffff8800799c4260
     ffff8800783d8988 ffff88007f212b00 ffffe8ffff604800 0000000000000000
    Call Trace:
     [<ffffffff81073f47>] ? trace_hardirqs_on_caller+0x145/0x1a1
     [<ffffffffa00652d3>] rpc_async_schedule+0x27/0x32 [sunrpc]
     [<ffffffff81052974>] process_one_work+0x211/0x3a5
     [<ffffffff810528d5>] ? process_one_work+0x172/0x3a5
     [<ffffffff81052eeb>] worker_thread+0x134/0x202
     [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
     [<ffffffff81052db7>] ? rescuer_thread+0x280/0x280
     [<ffffffff810584a0>] kthread+0xc9/0xd1
     [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
     [<ffffffff814afd6c>] ret_from_fork+0x7c/0xb0
     [<ffffffff810583d7>] ? __kthread_parkme+0x61/0x61
    Code: e8 87 63 fd e0 c6 05 10 dd 01 00 01 48 8b 43 70 4c 8d 6b 70 45 31 e4 a8 02 0f 85 d5 02 00 00 4c 8b 7b 48 48 c7 43 48 00 00 00 00 <4c> 8b 4b 50 4d 85 ff 75 0c 4d 85 c9 4d 89 cf 0f 84 32 01 00 00

    And the output of "rpcdebug -m rpc -s all":

    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refresh (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refresh (status 0)
    RPC:    61 call_refreshresult (status 0)
    RPC:    61 refreshing RPCSEC_GSS cred ffff88007a413cf0

    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d69b7695f31f37cb9dd624ae233d38944da71fec
Author: Weston Andros Adamson <dros@primarydata.com>
Date:   Mon Jan 13 16:54:45 2014 -0500

    nfs4.1: properly handle ENOTSUP in SECINFO_NO_NAME

    commit 78b19bae0813bd6f921ca58490196abd101297bd upstream.

    Don't check for -NFS4ERR_NOTSUPP, it's already been mapped to -ENOTSUPP
    by nfs4_stat_to_errno.

    This allows the client to mount v4.1 servers that don't support
    SECINFO_NO_NAME by falling back to the "guess and check" method of
    nfs4_find_root_sec.

    Signed-off-by: Weston Andros Adamson <dros@primarydata.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 266100ea7e0bc580eb0cc98952cf6762adce0115
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Dec 4 17:39:23 2013 -0500

    NFSv4: OPEN must handle the NFS4ERR_IO return code correctly

    commit c7848f69ec4a8c03732cde5c949bd2aa711a9f4b upstream.

    decode_op_hdr() cannot distinguish between an XDR decoding error and
    the perfectly valid errorcode NFS4ERR_IO. This is normally not a
    problem, but for the particular case of OPEN, we need to be able
    to increment the NFSv4 open sequence id when the server returns
    a valid response.

    Reported-by: J Bruce Fields <bfields@fieldses.org>
    Link: http://lkml.kernel.org/r/20131204210356.GA19452@fieldses.org
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09bbf967b37eb5212668456deebd177fc327d233
Author: Daniel Santos <daniel.santos@pobox.com>
Date:   Sun Jan 5 17:39:26 2014 -0600

    spidev: fix hang when transfer_one_message fails

    commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d upstream.

    This corrects a problem in spi_pump_messages() that leads to an spi
    message hanging forever when a call to transfer_one_message() fails.
    This failure occurs in my MCP2210 driver when the cs_change bit is set
    on the last transfer in a message, an operation which the hardware does
    not support.

    Rationale
    Since the transfer_one_message() returns an int, we must presume that it
    may fail.  If transfer_one_message() should never fail, it should return
    void.  Thus, calls to transfer_one_message() should properly manage a
    failure.

    Fixes: ffbbdd21329f3 (spi: create a message queueing infrastructure)
    Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5804f203e83f9230fa80185da21cb953aa4112ba
Author: Ira Weiny <ira.weiny@intel.com>
Date:   Wed Dec 18 08:41:37 2013 -0800

    IB/qib: Fix QP check when looping back to/from QP1

    commit 6e0ea9e6cbcead7fa8c76e3e3b9de4a50c5131c5 upstream.

    The GSI QP type is compatible with and should be allowed to send data
    to/from any UD QP.  This was found when testing ibacm on the same node
    as an SA.

    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f3336c667ba49ce3934ec8662554b8acee3c5e6
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Thu Nov 21 17:58:08 2013 +0200

    ore: Fix wrong math in allocation of per device BIO

    commit aad560b7f63b495f48a7232fd086c5913a676e6f upstream.

    At IO preparation we calculate the max pages at each device and
    allocate a BIO per device of that size. The calculation was wrong
    on some unaligned corner cases offset/length combination and would
    make prepare return with -ENOMEM. This would be bad for pnfs-objects
    that would in that case IO through MDS. And fatal for exofs were it
    would fail writes with EIO.

    Fix it by doing the proper math, that will work in all cases. (I
    ran a test with all possible offset/length combinations this time
    round).

    Also when reading we do not need to allocate for the parity units
    since we jump over them.

    Also lower the max_io_length to take into account the parity pages
    so not to allocate BIOs bigger than PAGE_SIZE

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef3ae1e6d554ba3995d5ec39ad9ad724b2435295
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Fri Nov 29 14:14:29 2013 +0100

    mtd: mxc_nand: remove duplicated ecc_stats counting

    commit 0566477762f9e174e97af347ee9c865f908a5647 upstream.

    The ecc_stats.corrected count variable will already be incremented in
    the above framework-layer just after this callback.

    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21119e14151faaa76e49bd1b3a40e921ebb7f885
Author: Mark Brown <broonie@linaro.org>
Date:   Mon Jan 27 00:32:14 2014 +0000

    ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API

    commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.

    There is currently no facility in ACPI to express the hookup of voltage
    regulators, the expectation is that the regulators that exist in the
    system will be handled transparently by firmware if they need software
    control at all. This means that if for some reason the regulator API is
    enabled on such a system it should assume that any supplies that devices
    need are provided by the system at all relevant times without any software
    intervention.

    Tell the regulator core to make this assumption by calling
    regulator_has_full_constraints(). Do this as soon as we know we are using
    ACPI so that the information is available to the regulator core as early
    as possible. This will cause the regulator core to pretend that there is
    an always on regulator supplying any supply that is requested but that has
    not otherwise been mapped which is the behaviour expected on a system with
    ACPI.

    Should the ability to specify regulators be added in future revisions of
    ACPI then once we have support for ACPI mappings in the kernel the same
    assumptions will apply. It is also likely that systems will default to a
    mode of operation which does not require any interpretation of these
    mappings in order to be compatible with existing operating system releases
    so it should remain safe to make these assumptions even if the mappings
    exist but are not supported by the kernel.

    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c44c3d5a7e5fcbad94062f778dae578d5886cfce
Author: Josh Triplett <josh@joshtriplett.org>
Date:   Tue Aug 20 17:20:14 2013 -0700

    turbostat: Use GCC's CPUID functions to support PIC

    commit 2b92865e648ce04a39fda4f903784a5d01ecb0dc upstream.

    turbostat uses inline assembly to call cpuid.  On 32-bit x86, on systems
    that have certain security features enabled by default that make -fPIC
    the default, this causes a build error:

    turbostat.c: In function ‘check_cpuid’:
    turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
      asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
      ^

    GCC provides a header cpuid.h, containing a __get_cpuid function that
    works with both PIC and non-PIC.  (On PIC, it saves and restores ebx
    around the cpuid instruction.)  Use that instead.

    Signed-off-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d60afeda7610197310faa1fa4c1adca9c2b1c515
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Sep 10 11:43:37 2013 +0800

    slub: Fix calculation of cpu slabs

    commit 8afb1474db4701d1ab80cd8251137a3260e6913e upstream.

      /sys/kernel/slab/:t-0000048 # cat cpu_slabs
      231 N0=16 N1=215
      /sys/kernel/slab/:t-0000048 # cat slabs
      145 N0=36 N1=109

    See, the number of slabs is smaller than that of cpu slabs.

    The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
    ("slub: per cpu cache for partial pages").

    We should use page->pages instead of page->pobjects when calculating
    the number of cpu partial slabs. This also fixes the mapping of slabs
    and nodes.

    As there's no variable storing the number of total/active objects in
    cpu partial slabs, and we don't have user interfaces requiring those
    statistics, I just add WARN_ON for those cases.

    Acked-by: Christoph Lameter <cl@linux.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dadd776c607bb00d64ad0b652e5361f599e1783a
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Wed Nov 20 16:01:11 2013 +0100

    mmc: atmel-mci: fix timeout errors in SDIO mode when using DMA

    commit 66b512eda74d59b17eac04c4da1b38d82059e6c9 upstream.

    With some SDIO devices, timeout errors can happen when reading data.
    To solve this issue, the DMA transfer has to be activated before sending
    the command to the device. This order is incorrect in PDC mode. So we
    have to take care if we are using DMA or PDC to know when to send the
    MMC command.

    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86175644959c7d62cf2a4280d02e282900248e11
Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
Date:   Mon Jan 13 13:33:09 2014 -0800

    audit: correct a type mismatch in audit_syscall_exit()

    commit 06bdadd7634551cfe8ce071fe44d0311b3033d9e upstream.

    audit_syscall_exit() saves a result of regs_return_value() in intermediate
    "int" variable and passes it to __audit_syscall_exit(), which expects its
    second argument as a "long" value.  This will result in truncating the
    value returned by a system call and making a wrong audit record.

    I don't know why gcc compiler doesn't complain about this, but anyway it
    causes a problem at runtime on arm64 (and probably most 64-bit archs).

    Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3854b4b4416459ec6b0ebb7fbe639fd99a0a90ab
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Jan 21 15:48:18 2014 -0800

    intel-iommu: fix off-by-one in pagetable freeing

    commit 08336fd218e087cc4fcc458e6b6dcafe8702b098 upstream.

    dma_pte_free_level() has an off-by-one error when checking whether a pte
    is completely covered by a range.  Take for example the case of
    attempting to free pfn 0x0 - 0x1ff, ie.  512 entries covering the first
    2M superpage.

    The level_size() is 0x200 and we test:

      static void dma_pte_free_level(...
    	...

    	if (!(0 > 0 || 0x1ff < 0 + 0x200)) {
    		...
    	}

    Clearly the 2nd test is true, which means we fail to take the branch to
    clear and free the pagetable entry.  As a result, we're leaking
    pagetables and failing to install new pages over the range.

    This was found with a PCI device assigned to a QEMU guest using vfio-pci
    without a VGA device present.  The first 1M of guest address space is
    mapped with various combinations of 4K pages, but eventually the range
    is entirely freed and replaced with a 2M contiguous mapping.
    intel-iommu errors out with something like:

      ERROR: DMA PTE for vPFN 0x0 already set (to 5c2b8003 not 849c00083)

    In this case 5c2b8003 is the pointer to the previous leaf page that was
    neither freed nor cleared and 849c00083 is the superpage entry that
    we're trying to replace it with.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Joerg Roedel <joro@8bytes.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 dc1327062fccef1b99302575aff4400278e22dc3
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Jan 6 21:28:15 2014 +0900

    SELinux: Fix memory leak upon loading policy

    commit 8ed814602876bec9bad2649ca17f34b499357a1c upstream.

    Hello.

    I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .

    [  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

    Below is a patch, but I don't know whether we need special handing for undoing
    ebitmap_set_bit() call.
    ----------
    >>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
    From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Date: Mon, 6 Jan 2014 16:30:21 +0900
    Subject: SELinux: Fix memory leak upon loading policy

    Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
    check return value from hashtab_insert() in filename_trans_read(). It leaks
    memory if hashtab_insert() returns error.

      unreferenced object 0xffff88005c9160d0 (size 8):
        comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
        hex dump (first 8 bytes):
          57 0b 00 00 6b 6b 6b a5                          W...kkk.
        backtrace:
          [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
          [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
          [<ffffffff812b345c>] security_load_policy+0x6c/0x500
          [<ffffffff812a623c>] sel_write_load+0xac/0x750
          [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
          [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
          [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff

    However, we should not return EEXIST error to the caller, or the systemd will
    show below message and the boot sequence freezes.

      systemd[1]: Failed to load SELinux policy. Freezing.

    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>