commit 00397abb3674a8fb3f84eff5cce6d5479c3359e8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 20 11:08:17 2014 -0800

    Linux 3.12.12

commit 592d4de3803f242aebc6ea4033f752ce1bf846a7
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Feb 4 09:07:09 2014 +0100

    pinctrl: protect pinctrl_list add
    
    commit 7b320cb1ed2dbd2c5f2a778197baf76fd6bf545a upstream.
    
    We have few fedora bug reports about list corruption on pinctrl,
    for example:
    https://bugzilla.redhat.com/show_bug.cgi?id=1051918
    
    Most likely corruption happen due lack of protection of pinctrl_list
    when adding new nodes to it. Patch corrects that.
    
    Fixes: 42fed7ba44e ("pinctrl: move subsystem mutex to pinctrl_dev struct")
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ffc4ef1c6436ac97af8a41ec01be905e4ba510
Author: Tony Prisk <linux@prisktech.co.nz>
Date:   Thu Jan 23 21:57:33 2014 +1300

    pinctrl: vt8500: Change devicetree data parsing
    
    commit f17248ed868767567298e1cdf06faf8159a81f7c upstream.
    
    Due to an assumption in the VT8500 pinctrl driver, the value passed
    from devicetree for 'wm,pull' was not explicitly translated before
    being passed to pinconf.
    
    Since v3.10, changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN)
    no longer map 1-to-1 with the expected values in devicetree.
    
    This patch adds a small translation between the devicetree values (0..2)
    and the enum pin_config_param equivalent values.
    
    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d6d1f9dd68b7690e54eb467e070d9a4ca419b7d
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Tue Jan 21 16:55:18 2014 +0100

    pinctrl: at91: use locked variant of irq_set_handler
    
    commit b0dcfd87323ea86501e93d0fa2a98d2fd3579bcf upstream.
    
    When setting the gpio irq type, use the __irq_set_handler_locked()
    variant instead of the irq_set_handler() to prevent false
    spinlock recursion warning.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b18575d94a7aa4f63e74a32332fc7cdaf344a9bf
Author: Nitin A Kamble <nitin.a.kamble@intel.com>
Date:   Thu Jan 30 16:50:10 2014 -0800

    genirq: Generic irq chip requires IRQ_DOMAIN
    
    commit 923fa4ea382f592dee2ba3b205befb90cbddf3af upstream.
    
    The generic_chip.c uses interfaces from irq_domain.c which is
    controlled by the IRQ_DOMAIN config option, but there is no Kconfig
    dependency so the build can fail:
    
    linux/kernel/irq/generic-chip.c:400:11: error:
    'irq_domain_xlate_onetwocell' undeclared here (not in a function)
    
    Select IRQ_DOMAIN when GENERIC_IRQ_CHIP is selected.
    
    Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
    Link: http://lkml.kernel.org/r/1391129410-54548-2-git-send-email-nitin.a.kamble@intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15b2a2a1a720040732a0380c73455d6c3e907123
Author: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Date:   Thu Feb 6 15:58:20 2014 +0100

    x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y
    
    commit 6583327c4dd55acbbf2a6f25e775b28b3abf9a42 upstream.
    
    Commit d61931d89b, "x86: Add optimized popcnt variants" introduced
    compile flag -fcall-saved-rdi for lib/hweight.c. When combined with
    options -fprofile-arcs and -O2, this flag causes gcc to generate
    broken constructor code. As a result, a 64 bit x86 kernel compiled
    with CONFIG_GCOV_PROFILE_ALL=y prints message "gcov: could not create
    file" and runs into sproadic BUGs during boot.
    
    The gcc people indicate that these kinds of problems are endemic when
    using ad hoc calling conventions.  It is therefore best to treat any
    file compiled with ad hoc calling conventions as an isolated
    environment and avoid things like profiling or coverage analysis,
    since those subsystems assume a "normal" calling conventions.
    
    This patch avoids the bug by excluding lib/hweight.o from coverage
    profiling.
    
    Reported-by: Meelis Roos <mroos@linux.ee>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/52F3A30C.7050205@linux.vnet.ibm.com
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 782b0c125b81ebf692a58d4be712e34d7241271d
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Fri Jan 3 08:10:49 2014 -0300

    Revert "[media] videobuf_vm_{open,close} race fixes"
    
    commit cca36e2eecec2b8fc869a50ffd3bd0adeed92b8b upstream.
    
    This reverts commit a242f426108c284049a69710f871cc9f11b13e61.
    
    That commit actually caused deadlocks, rather then fixing them.
    
    If ext_lock is set to NULL (otherwise videobuf_queue_lock doesn't do
    anything), then you get this deadlock:
    
    The driver's mmap function calls videobuf_mmap_mapper which calls
    videobuf_queue_lock on q. videobuf_mmap_mapper calls  __videobuf_mmap_mapper,
    __videobuf_mmap_mapper calls videobuf_vm_open and videobuf_vm_open
    calls videobuf_queue_lock on q (introduced by above patch): deadlocked.
    
    This affects drivers using dma-contig and dma-vmalloc. Only dma-sg is
    not affected since it doesn't call videobuf_vm_open from __videobuf_mmap_mapper.
    
    Most drivers these days have a non-NULL ext_lock. Those that still use
    NULL there are all fairly obscure drivers, which is why this hasn't been
    seen earlier.
    
    Since everything worked perfectly fine for many years I prefer to just
    revert this patch rather than trying to fix it. videobuf is quite fragile
    and I rather not touch it too much. Work is (slowly) progressing to move
    everything over to vb2 or at the very least use non-NULL ext_lock in
    videobuf.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Reported-by: Pete Eberlein <pete@sensoray.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f0b9cd9a9bdb15d60b8e628f34f8641007d0b97
Author: Dave Jones <davej@fedoraproject.org>
Date:   Thu Jan 30 00:17:09 2014 -0300

    mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset
    
    commit 13e1b87c986100169b0695aeb26970943665eda9 upstream.
    
    Fix the following build error:
    
    drivers/media/usb/dvb-usb-v2/
    mxl111sf-tuner.h:72:9: error: expected ‘;’, ‘,’ or ‘)’ before ‘struct’
             struct mxl111sf_tuner_config *cfg)
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09dc446e6adfe295f677ad349f5cea2b88f5c40b
Author: Dave Jones <davej@fedoraproject.org>
Date:   Thu Jan 30 00:11:33 2014 -0300

    mxl111sf: Fix unintentional garbage stack read
    
    commit 866e8d8a9dc1ebb4f9e67197e264ac2df81f7d4b upstream.
    
    mxl111sf_read_reg takes an address of a variable to write to as an argument.
    drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c:mxl111sf_config_pin_mux_modes
    passes several uninitialized stack variables to this routine, expecting
    them to be filled in.  In the event that something unexpected happens when
    reading from the chip, we end up doing a pr_debug of the value passed in,
    revealing whatever garbage happened to be on the stack.
    
    Change the pr_debug to match what happens in the 'success' case, where we
    assign buf[1] to *data.
    
    Spotted with Coverity (Bugs 731910 through 731917)
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d7a951f2d2abd9b3c4b20e58e41875a2a74e69b
Author: Antti Palosaari <crope@iki.fi>
Date:   Thu Jan 16 08:59:30 2014 -0300

    af9035: add ID [2040:f900] Hauppauge WinTV-MiniStick 2
    
    commit f2e4c5e004691dfe37d0e4b363296f28abdb9bc7 upstream.
    
    Add USB ID [2040:f900] for Hauppauge WinTV-MiniStick 2.
    Device is build upon IT9135 chipset.
    
    Tested-by: Stefan Becker <schtefan@gmx.net>
    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 0b2adcc86a7007ec8c58bba972c709b234e7626c
Author: Mel Gorman <mgorman@suse.de>
Date:   Tue Jan 21 14:33:21 2014 -0800

    x86: mm: change tlb_flushall_shift for IvyBridge
    
    commit f98b7a772ab51b52ca4d2a14362fc0e0c8a2e0f3 upstream.
    
    There was a large performance regression that was bisected to
    commit 611ae8e3 ("x86/tlb: enable tlb flush range support for
    x86").  This patch simply changes the default balance point
    between a local and global flush for IvyBridge.
    
    In the interest of allowing the tests to be reproduced, this
    patch was tested using mmtests 0.15 with the following
    configurations
    
    	configs/config-global-dhp__tlbflush-performance
    	configs/config-global-dhp__scheduler-performance
    	configs/config-global-dhp__network-performance
    
    Results are from two machines
    
    Ivybridge   4 threads:  Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
    Ivybridge   8 threads:  Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
    
    Page fault microbenchmark showed nothing interesting.
    
    Ebizzy was configured to run multiple iterations and threads.
    Thread counts ranged from 1 to NR_CPUS*2. For each thread count,
    it ran 100 iterations and each iteration lasted 10 seconds.
    
    Ivybridge 4 threads
                        3.13.0-rc7            3.13.0-rc7
                           vanilla           altshift-v3
    Mean   1     6395.44 (  0.00%)     6789.09 (  6.16%)
    Mean   2     7012.85 (  0.00%)     8052.16 ( 14.82%)
    Mean   3     6403.04 (  0.00%)     6973.74 (  8.91%)
    Mean   4     6135.32 (  0.00%)     6582.33 (  7.29%)
    Mean   5     6095.69 (  0.00%)     6526.68 (  7.07%)
    Mean   6     6114.33 (  0.00%)     6416.64 (  4.94%)
    Mean   7     6085.10 (  0.00%)     6448.51 (  5.97%)
    Mean   8     6120.62 (  0.00%)     6462.97 (  5.59%)
    
    Ivybridge 8 threads
                         3.13.0-rc7            3.13.0-rc7
                            vanilla           altshift-v3
    Mean   1      7336.65 (  0.00%)     7787.02 (  6.14%)
    Mean   2      8218.41 (  0.00%)     9484.13 ( 15.40%)
    Mean   3      7973.62 (  0.00%)     8922.01 ( 11.89%)
    Mean   4      7798.33 (  0.00%)     8567.03 (  9.86%)
    Mean   5      7158.72 (  0.00%)     8214.23 ( 14.74%)
    Mean   6      6852.27 (  0.00%)     7952.45 ( 16.06%)
    Mean   7      6774.65 (  0.00%)     7536.35 ( 11.24%)
    Mean   8      6510.50 (  0.00%)     6894.05 (  5.89%)
    Mean   12     6182.90 (  0.00%)     6661.29 (  7.74%)
    Mean   16     6100.09 (  0.00%)     6608.69 (  8.34%)
    
    Ebizzy hits the worst case scenario for TLB range flushing every
    time and it shows for these Ivybridge CPUs at least that the
    default choice is a poor on.  The patch addresses the problem.
    
    Next was a tlbflush microbenchmark written by Alex Shi at
    http://marc.info/?l=linux-kernel&m=133727348217113 .  It
    measures access costs while the TLB is being flushed.  The
    expectation is that if there are always full TLB flushes that
    the benchmark would suffer and it benefits from range flushing
    
    There are 320 iterations of the test per thread count.  The
    number of entries is randomly selected with a min of 1 and max
    of 512.  To ensure a reasonably even spread of entries, the full
    range is broken up into 8 sections and a random number selected
    within that section.
    
    iteration 1, random number between 0-64
    iteration 2, random number between 64-128 etc
    
    This is still a very weak methodology.  When you do not know
    what are typical ranges, random is a reasonable choice but it
    can be easily argued that the opimisation was for smaller ranges
    and an even spread is not representative of any workload that
    matters.  To improve this, we'd need to know the probability
    distribution of TLB flush range sizes for a set of workloads
    that are considered "common", build a synthetic trace and feed
    that into this benchmark.  Even that is not perfect because it
    would not account for the time between flushes but there are
    limits of what can be reasonably done and still be doing
    something useful.  If a representative synthetic trace is
    provided then this benchmark could be revisited and the shift values retuned.
    
    Ivybridge 4 threads
                            3.13.0-rc7            3.13.0-rc7
                               vanilla           altshift-v3
    Mean       1       10.50 (  0.00%)       10.50 (  0.03%)
    Mean       2       17.59 (  0.00%)       17.18 (  2.34%)
    Mean       3       22.98 (  0.00%)       21.74 (  5.41%)
    Mean       5       47.13 (  0.00%)       46.23 (  1.92%)
    Mean       8       43.30 (  0.00%)       42.56 (  1.72%)
    
    Ivybridge 8 threads
                             3.13.0-rc7            3.13.0-rc7
                                vanilla           altshift-v3
    Mean       1         9.45 (  0.00%)        9.36 (  0.93%)
    Mean       2         9.37 (  0.00%)        9.70 ( -3.54%)
    Mean       3         9.36 (  0.00%)        9.29 (  0.70%)
    Mean       5        14.49 (  0.00%)       15.04 ( -3.75%)
    Mean       8        41.08 (  0.00%)       38.73 (  5.71%)
    Mean       13       32.04 (  0.00%)       31.24 (  2.49%)
    Mean       16       40.05 (  0.00%)       39.04 (  2.51%)
    
    For both CPUs, average access time is reduced which is good as
    this is the benchmark that was used to tune the shift values in
    the first place albeit it is now known *how* the benchmark was
    used.
    
    The scheduler benchmarks were somewhat inconclusive.  They
    showed gains and losses and makes me reconsider how stable those
    benchmarks really are or if something else might be interfering
    with the test results recently.
    
    Network benchmarks were inconclusive.  Almost all results were
    flat except for netperf-udp tests on the 4 thread machine.
    These results were unstable and showed large variations between
    reboots.  It is unknown if this is a recent problems but I've
    noticed before that netperf-udp results tend to vary.
    
    Based on these results, changing the default for Ivybridge seems
    like a logical choice.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Tested-by: Davidlohr Bueso <davidlohr@hp.com>
    Reviewed-by: Alex Shi <alex.shi@linaro.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/n/tip-cqnadffh1tiqrshthRj3Esge@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d99c6996957b0b8f0c0d92cea152186d518138d5
Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date:   Thu Feb 6 12:04:28 2014 -0800

    mm: __set_page_dirty uses spin_lock_irqsave instead of spin_lock_irq
    
    commit 227d53b397a32a7614667b3ecaf1d89902fb6c12 upstream.
    
    To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
    During aio buffer migration, we have a possibility to see the following
    call stack.
    
    aio_migratepage  [disable interrupt]
      migrate_page_copy
        clear_page_dirty_for_io
          set_page_dirty
            __set_page_dirty_buffers
              __set_page_dirty
                spin_lock_irq
    
    This mean, current aio migration is a deadlockable.  spin_lock_irqsave
    is a safer alternative and we should use it.
    
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reported-by: David Rientjes rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed3ac2267612458134a6a62d2a978f6c94bab870
Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date:   Thu Feb 6 12:04:24 2014 -0800

    mm: __set_page_dirty_nobuffers() uses spin_lock_irqsave() instead of spin_lock_irq()
    
    commit a85d9df1ea1d23682a0ed1e100e6965006595d06 upstream.
    
    During aio stress test, we observed the following lockdep warning.  This
    mean AIO+numa_balancing is currently deadlockable.
    
    The problem is, aio_migratepage disable interrupt, but
    __set_page_dirty_nobuffers unintentionally enable it again.
    
    Generally, all helper function should use spin_lock_irqsave() instead of
    spin_lock_irq() because they don't know caller at all.
    
       other info that might help us debug this:
        Possible unsafe locking scenario:
    
              CPU0
              ----
         lock(&(&ctx->completion_lock)->rlock);
         <Interrupt>
           lock(&(&ctx->completion_lock)->rlock);
    
        *** DEADLOCK ***
    
          dump_stack+0x19/0x1b
          print_usage_bug+0x1f7/0x208
          mark_lock+0x21d/0x2a0
          mark_held_locks+0xb9/0x140
          trace_hardirqs_on_caller+0x105/0x1d0
          trace_hardirqs_on+0xd/0x10
          _raw_spin_unlock_irq+0x2c/0x50
          __set_page_dirty_nobuffers+0x8c/0xf0
          migrate_page_copy+0x434/0x540
          aio_migratepage+0xb1/0x140
          move_to_new_page+0x7d/0x230
          migrate_pages+0x5e5/0x700
          migrate_misplaced_page+0xbc/0xf0
          do_numa_page+0x102/0x190
          handle_pte_fault+0x241/0x970
          handle_mm_fault+0x265/0x370
          __do_page_fault+0x172/0x5a0
          do_page_fault+0x1a/0x70
          page_fault+0x28/0x30
    
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <jweiner@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fe9f7abe5f08c141fac3242894504b066da9b8d
Author: Weijie Yang <weijie.yang@samsung.com>
Date:   Thu Feb 6 12:04:23 2014 -0800

    mm/swap: fix race on swap_info reuse between swapoff and swapon
    
    commit f893ab41e4dae2fe8991faf5d86d029068d1ef3a upstream.
    
    swapoff clear swap_info's SWP_USED flag prematurely and free its
    resources after that.  A concurrent swapon will reuse this swap_info
    while its previous resources are not cleared completely.
    
    These late freed resources are:
     - p->percpu_cluster
     - swap_cgroup_ctrl[type]
     - block_device setting
     - inode->i_flags &= ~S_SWAPFILE
    
    This patch clears the SWP_USED flag after all its resources are freed,
    so that swapon can reuse this swap_info by alloc_swap_info() safely.
    
    [akpm@linux-foundation.org: tidy up code comment]
    Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Krzysztof Kozlowski <k.kozlowski@samsung.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 78db0017d8f53578f88102f2f303ef57a139f0ba
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 5 08:49:41 2014 +0100

    ALSA: hda - Improve loopback path lookups for AD1983
    
    commit 276ab336b4c6e483d12fd46cbf24f97f71867710 upstream.
    
    AD1983 has flexible loopback routes and the generic parser would take
    wrong path confusingly instead of taking individual paths via NID 0x0c
    and 0x0d.  For avoiding it, limit the connections at these widgets so
    that the parser can think more straightforwardly.  This fixes the
    regression of the missing line-in loopback on Dell machine.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70011
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7cb829400a2da45591668465e56001df4dc6500
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 5 07:28:10 2014 +0100

    ALSA: hda - Add missing mixer widget for AD1983
    
    commit c7579fed1f1b2567529aea64ef19871337403ab3 upstream.
    
    The mixer widget on AD1983 at NID 0x0e was missing in the commit
    [f2f8be43c5c9: ALSA: hda - Add aamix NID to AD codecs].
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70011
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29ece20a6dbb5effd65d3255230dda8932d2304d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 4 07:39:06 2014 +0100

    ALSA: hda - Fix silent output on Toshiba Satellite L40
    
    commit 4528eb19b00d9ccd65ded6f8201eec704267edd8 upstream.
    
    Toshiba Satellite L40 with AD1986A codec requires the EAPD of NID 0x1b
    to be constantly on, otherwise the output doesn't work.
    Unlike most of other AD1986A machines, EAPD is correctly implemented
    in HD-audio manner (that is, bit set = amp on), so we need to clear
    the inv_eapd flag in the fixup, too.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=67481
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 212e372d329a43f4b124edb6ed8473bf988e4f79
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 3 11:02:10 2014 +0100

    ALSA: hda - Fix missing VREF setup for Mac Pro 1,1
    
    commit c20f31ec421ea4fabea5e95a6afd46c5f41e5599 upstream.
    
    Mac Pro 1,1 with ALC889A codec needs the VREF setup on NID 0x18 to
    VREF50, in order to make the speaker working.  The same fixup was
    already needed for MacBook Air 1,1, so we can reuse it.
    
    Reported-by: Nicolai Beuermann <mail@nico-beuermann.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29de41db3c53a901135efeb4aa8b757fec568838
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 3 09:37:59 2014 +0100

    ALSA: usb-audio: Add missing kconfig dependecy
    
    commit 4fa71c1550a857ff1dbfe9e99acc1f4cfec5f0d0 upstream.
    
    The commit 44dcbbb1cd61 introduced the usage of bitreverse helpers but
    forgot to add the dependency.  This patch adds the selection for
    CONFIG_BITREVERSE.
    
    Fixes: 44dcbbb1cd61 ('ALSA: snd-usb: add support for bit-reversed byte formats')
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5a8dbc0657dd9bf88198e0588c47b0d10d81a2e
Author: Vinayak Kale <vkale@apm.com>
Date:   Wed Feb 5 09:34:36 2014 +0000

    arm64: add DSB after icache flush in __flush_icache_all()
    
    commit 5044bad43ee573d0b6d90e3ccb7a40c2c7d25eb4 upstream.
    
    Add DSB after icache flush to complete the cache maintenance operation.
    The function __flush_icache_all() is used only for user space mappings
    and an ISB is not required because of an exception return before executing
    user instructions. An exception return would behave like an ISB.
    
    Signed-off-by: Vinayak Kale <vkale@apm.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61cdf59100deb76fc299ee8ad1fb4c9cda4ce011
Author: Nathan Lynch <nathan_lynch@mentor.com>
Date:   Wed Feb 5 05:53:04 2014 +0000

    arm64: vdso: fix coarse clock handling
    
    commit 069b918623e1510e58dacf178905a72c3baa3ae4 upstream.
    
    When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
    CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
    caller has placed in x2 ("ret x2" to return from the fast path).  Fix
    this by saving x30/LR to x2 only in code that will call
    __do_get_tspec, restoring x30 afterward, and using a plain "ret" to
    return from the routine.
    
    Also: while the resulting tv_nsec value for CLOCK_REALTIME and
    CLOCK_MONOTONIC must be computed using intermediate values that are
    left-shifted by cs_shift (x12, set by __do_get_tspec), the results for
    coarse clocks should be calculated using unshifted values
    (xtime_coarse_nsec is in units of actual nanoseconds).  The current
    code shifts intermediate values by x12 unconditionally, but x12 is
    uninitialized when servicing a coarse clock.  Fix this by setting x12
    to 0 once we know we are dealing with a coarse clock id.
    
    Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a109e893b76ac6724ff149a7a507325a21601f24
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue Feb 4 16:01:31 2014 +0000

    arm64: Invalidate the TLB when replacing pmd entries during boot
    
    commit a55f9929a9b257f84b6cc7b2397379cabd744a22 upstream.
    
    With the 64K page size configuration, __create_page_tables in head.S
    maps enough memory to get started but using 64K pages rather than 512M
    sections with a single pgd/pud/pmd entry pointing to a pte table.
    create_mapping() may override the pgd/pud/pmd table entry with a block
    (section) one if the RAM size is more than 512MB and aligned correctly.
    For the end of this block to be accessible, the old TLB entry must be
    invalidated.
    
    Reported-by: Mark Salter <msalter@redhat.com>
    Tested-by: Mark Salter <msalter@redhat.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1c8c8916e44f9bf5c787b9f2791b6fd2722e7b7
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Feb 4 14:41:26 2014 +0000

    arm64: vdso: prevent ld from aligning PT_LOAD segments to 64k
    
    commit 40507403485fcb56b83d6ddfc954e9b08305054c upstream.
    
    Whilst the text segment for our VDSO is marked as PT_LOAD in the ELF
    headers, it is mapped by the kernel and not actually subject to
    demand-paging. ld doesn't realise this, and emits a p_align field of 64k
    (the maximum supported page size), which conflicts with the load address
    picked by the kernel on 4k systems, which will be 4k aligned. This
    causes GDB to fail with "Failed to read a valid object file image from
    memory" when attempting to load the VDSO.
    
    This patch passes the -n option to ld, which prevents it from aligning
    PT_LOAD segments to the maximum page size.
    
    Reported-by: Kyle McMartin <kyle@redhat.com>
    Acked-by: Kyle McMartin <kyle@redhat.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9594784323553039e7ffbbb16b936fe49f1c3499
Author: Nathan Lynch <nathan_lynch@mentor.com>
Date:   Mon Feb 3 19:48:52 2014 +0000

    arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
    
    commit d4022a335271a48cce49df35d825897914fbffe3 upstream.
    
    Update wall-to-monotonic fields in the VDSO data page
    unconditionally.  These are used to service CLOCK_MONOTONIC_COARSE,
    which is not guarded by use_syscall.
    
    Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97ec8cd5d1535e8a6f09bf029a8013a33e32ed38
Author: Lior Amsalem <alior@marvell.com>
Date:   Mon Nov 25 17:26:44 2013 +0100

    irqchip: armada-370-xp: fix IPI race condition
    
    commit a6f089e95b1e08cdea9633d50ad20aa5d44ba64d upstream.
    
    In the Armada 370/XP driver, when we receive an IRQ 0, we read the
    list of doorbells that caused the interrupt from register
    ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that
    were generated. However, instead of acknowledging only the IPIs that
    were generated, we acknowledge *all* the IPIs, by writing
    ~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.
    
    This creates a race condition: if a new IPI that isn't part of the
    ones read into the temporary "ipimask" variable is fired before we
    acknowledge all IPIs, then we will simply loose it. This is causing
    scheduling hangs on SMP intensive workloads.
    
    It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
    register has the following behavior: "A CPU write of 0 clears the bits
    in this field. A CPU write of 1 has no effect". This is what allows us
    to simply write ~ipimask to acknoledge the handled IPIs.
    
    Notice that the same problem is present in the MSI implementation, but
    it will be fixed as a separate patch, so that this IPI fix can be
    pushed to older stable versions as appropriate (all the way to 3.8),
    while the MSI code only appeared in 3.13.
    
    Signed-off-by: Lior Amsalem <alior@marvell.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Fixes: 344e873e5657e8dc0 'arm: mvebu: Add IPI support via doorbells'
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0e72a228e55813e5555519ae7721d5cf538981d
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Feb 1 14:53:23 2014 -0500

    NFSv4: Fix memory corruption in nfs4_proc_open_confirm
    
    commit 17ead6c85c3d0ef57a14d1373f1f1cee2ce60ea8 upstream.
    
    nfs41_wake_and_assign_slot() relies on the task->tk_msg.rpc_argp and
    task->tk_msg.rpc_resp always pointing to the session sequence arguments.
    
    nfs4_proc_open_confirm tries to pull a fast one by reusing the open
    sequence structure, thus causing corruption of the NFSv4 slot table.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cdb12c3de2ed9f35872776794a59448b285e4e4
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Feb 1 13:47:06 2014 -0500

    NFSv4.1: nfs4_destroy_session must call rpc_destroy_waitqueue
    
    commit 20b9a9024540a775395d5d1f41eec0ec6ec41f9b upstream.
    
    There may still be timers active on the session waitqueues. Make sure
    that we kill them before freeing the memory.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d5e3b525d415308035071a009e0353d11d5c0ce
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Wed Jan 22 13:01:33 2014 +0100

    crypto: s390 - fix des and des3_ede ctr concurrency issue
    
    commit ee97dc7db4cbda33e4241c2d85b42d1835bc8a35 upstream.
    
    In s390 des and 3des ctr mode there is one preallocated page
    used to speed up the en/decryption. This page is not protected
    against concurrent usage and thus there is a potential of data
    corruption with multiple threads.
    
    The fix introduces locking/unlocking the ctr page and a slower
    fallback solution at concurrency situations.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6414e5ed784678a379e0f4afb023f9cc643e1b33
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Wed Jan 22 13:00:04 2014 +0100

    crypto: s390 - fix des and des3_ede cbc concurrency issue
    
    commit adc3fcf1552b6e406d172fd9690bbd1395053d13 upstream.
    
    In s390 des and des3_ede cbc mode the iv value is not protected
    against concurrency access and modifications from another running
    en/decrypt operation which is using the very same tfm struct
    instance. This fix copies the iv to the local stack before
    the crypto operation and stores the value back when done.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa1eef2bdc5187968849e5c78d8d07e567d4889a
Author: Harald Freudenberger <freude@linux.vnet.ibm.com>
Date:   Thu Jan 16 16:01:11 2014 +0100

    crypto: s390 - fix concurrency issue in aes-ctr mode
    
    commit 0519e9ad89e5cd6e6b08398f57c6a71d9580564c upstream.
    
    The aes-ctr mode uses one preallocated page without any concurrency
    protection. When multiple threads run aes-ctr encryption or decryption
    this can lead to data corruption.
    
    The patch introduces locking for the page and a fallback solution with
    slower en/decryption performance in concurrency situations.
    
    Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52a0aaf1aac536c646da7d9b4418eb6578e34769
Author: Josef Bacik <jbacik@fb.com>
Date:   Wed Jan 29 16:05:30 2014 -0500

    Btrfs: disable snapshot aware defrag for now
    
    commit 8101c8dbf6243ba517aab58d69bf1bc37d8b7b9c upstream.
    
    It's just broken and it's taking a lot of effort to fix it, so for now just
    disable it so people can defrag in peace.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81451fe1e821f3fd715d102faf6181bbfb301878
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Thu Jan 30 11:26:59 2014 -0500

    SELinux: Fix kernel BUG on empty security contexts.
    
    commit 2172fa709ab32ca60e86179dc67d0857be8e2c98 upstream.
    
    Setting an empty security context (length=0) on a file will
    lead to incorrectly dereferencing the type and other fields
    of the security context structure, yielding a kernel BUG.
    As a zero-length security context is never valid, just reject
    all such security contexts whether coming from userspace
    via setxattr or coming from the filesystem upon a getxattr
    request by SELinux.
    
    Setting a security context value (empty or otherwise) unknown to
    SELinux in the first place is only possible for a root process
    (CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
    if the corresponding SELinux mac_admin permission is also granted
    to the domain by policy.  In Fedora policies, this is only allowed for
    specific domains such as livecd for setting down security contexts
    that are not defined in the build host policy.
    
    Reproducer:
    su
    setenforce 0
    touch foo
    setfattr -n security.selinux foo
    
    Caveat:
    Relabeling or removing foo after doing the above may not be possible
    without booting with SELinux disabled.  Any subsequent access to foo
    after doing the above will also trigger the BUG.
    
    BUG output from Matthew Thode:
    [  473.893141] ------------[ cut here ]------------
    [  473.962110] kernel BUG at security/selinux/ss/services.c:654!
    [  473.995314] invalid opcode: 0000 [#6] SMP
    [  474.027196] Modules linked in:
    [  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
    3.13.0-grsec #1
    [  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
    07/29/10
    [  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
    ffff8805f50cd488
    [  474.183707] RIP: 0010:[<ffffffff814681c7>]  [<ffffffff814681c7>]
    context_struct_compute_av+0xce/0x308
    [  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
    [  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
    0000000000000100
    [  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
    ffff8805e8aaa000
    [  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
    0000000000000006
    [  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
    0000000000000006
    [  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
    0000000000000000
    [  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
    knlGS:0000000000000000
    [  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
    00000000000207f0
    [  474.556058] Stack:
    [  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
    ffff8805f1190a40
    [  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
    ffff8805e8aac860
    [  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
    ffff8805c0ac3d94
    [  474.690461] Call Trace:
    [  474.723779]  [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
    [  474.778049]  [<ffffffff81468824>] security_compute_av+0xf4/0x20b
    [  474.811398]  [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
    [  474.843813]  [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
    [  474.875694]  [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
    [  474.907370]  [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
    [  474.938726]  [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
    [  474.970036]  [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
    [  475.000618]  [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
    [  475.030402]  [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
    [  475.061097]  [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
    [  475.094595]  [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
    [  475.148405]  [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
    [  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
    8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
    75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
    [  475.255884] RIP  [<ffffffff814681c7>]
    context_struct_compute_av+0xce/0x308
    [  475.296120]  RSP <ffff8805c0ac3c38>
    [  475.328734] ---[ end trace f076482e9d754adc ]---
    
    Reported-by:  Matthew Thode <mthode@mthode.org>
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>