ARM: mm: implement LoUIS API for cache maintenance ops

ARM v7 architecture introduced the concept of cache levels and related
control registers. New processors like A7 and A15 embed an L2 unified cache
controller that becomes part of the cache level hierarchy. Some operations in
the kernel like cpu_suspend and __cpu_disable do not require a flush of the
entire cache hierarchy to DRAM but just the cache levels belonging to the
Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
correspond to L1.

The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.

Therefore a new kernel cache maintenance API must be added to cope with
latest ARM system requirements.

This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

This function cleans and invalidates all data cache levels up to the
Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
cache for processors that support it (> v7).

This patch also creates an alias of the cache LoUIS function to flush_kern_all
for all processor versions prior to v7, so that the current cache flushing
behaviour is unchanged for those processors.

v7 cache maintenance code implements a cache LoUIS function that cleans and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: rename jump labels in v7_flush_dcache_all function

This patch renames jump labels in v7_flush_dcache_all in order to define
a specific flush cache levels entry point.

TODO: factor out the level flushing loop if considered worthwhile and
      define the input registers requirements.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update cpu_suspend code to use cache LoUIS operations

In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.

When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.

The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.

outer_cache management remains unchanged.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API

When a CPU is hotplugged out caches that reside in its power domain
lose their contents and so must be cleaned to the next memory level.

Currently, __cpu_disable calls flush_cache_all() that for new generation
processor like A15/A7 ends up cleaning and invalidating all cache levels
up to Level of Coherency, which includes the unified L2.

This ends up being a waste of cycles since the L2 cache contents are not
lost on power down.

This patch updates __cpu_disable to use the new LoUIS API cache operations.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API

The ARMv7 processor setup function __v7_setup() cleans and invalidates the
CPU cache before enabling MMU to start the CPU with a clean CPU local cache.

But on ARMv7 architectures like Cortex-[A15/A8], this code will end
up flushing the L2 caches(up to level of Coherency) which is undesirable
and expensive. The setup functions are used in the CPU hotplug scenario too
and hence flushing all cache levels should be avoided.

This patch replaces the cache flushing call with the newly introduced
v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
invalidated when a processors executes __v7_setup which is the expected
behavior.

For processors like A9 and A5 where the L2 cache is an outer one the
behavior should be unchanged.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
Futex: Thanks for Faux123 N5 patches.

Subject: [PATCH 11/15] futex: Misc cleanups

Date	Thu, 2 Jan 2014 07:05:17 -0800

From: Jason Low <jason.low2@hp.com>

- Remove unnecessary head variables.
- Delete unused parameter in queue_unlock().

Subject: [PATCH 12/15] futex: Larger hash table

Date	Thu, 2 Jan 2014 07:05:18 -0800

From: Davidlohr Bueso <davidlohr@hp.com>

Currently, the futex global hash table suffers from it's fixed, smallish
(for today's standards) size of 256 entries, as well as its lack of NUMA
awareness. Large systems, using many futexes, can be prone to high amounts
of collisions; where these futexes hash to the same bucket and lead to
extra contention on the same hb->lock. Furthermore, cacheline bouncing is a
reality when we have multiple hb->locks residing on the same cacheline and
different futexes hash to adjacent buckets.
This patch keeps the current static size of 16 entries for small systems,
or otherwise, 256 * ncpus (or larger as we need to round the number to a
power of 2). Note that this number of CPUs accounts for all CPUs that can
ever be available in the system, taking into consideration things like
hotpluging. While we do impose extra overhead at bootup by making the hash
table larger, this is a one time thing, and does not shadow the benefits
of this patch.

Furthermore, as suggested by tglx, by cache aligning the hash buckets we can
avoid access across cacheline boundaries and also avoid massive cache line
bouncing if multiple cpus are hammering away at different hash buckets which
happen to reside in the same cache line.

Also, similar to other core kernel components (pid, dcache, tcp), by using
alloc_large_system_hash() we benefit from its NUMA awareness and thus the
table is distributed among the nodes instead of in a single one.

For a custom microbenchmark that pounds on the uaddr hashing -- making the wait
path fail at futex_wait_setup() returning -EWOULDBLOCK for large amounts of
futexes, we can see the following benefits on a 80-core, 8-socket 1Tb server:

+---------+--------------------+------------------------+-----------------------+-------------------------------+
| threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec) | large table+aligned (ops/sec) |
+---------+--------------------+------------------------+-----------------------+-------------------------------+
|     512 |		 32426 | 50531  (+55.8%)	| 255274  (+687.2%)	| 292553  (+802.2%)		|
|     256 |		 65360 | 99588  (+52.3%)	| 443563  (+578.6%)	| 508088  (+677.3%)		|
|     128 |		125635 | 200075 (+59.2%)	| 742613  (+491.1%)	| 835452  (+564.9%)		|
|      80 |		193559 | 323425 (+67.1%)	| 1028147 (+431.1%)	| 1130304 (+483.9%)		|
|      64 |		247667 | 443740 (+79.1%)	| 997300  (+302.6%)	| 1145494 (+362.5%)		|
|      32 |		628412 | 721401 (+14.7%)	| 965996  (+53.7%)	| 1122115 (+78.5%)		|
+---------+--------------------+------------------------+-----------------------+-------------------------------+

Subject: [PATCH 13/15] futex: Document ordering guarantees

Date	Thu, 2 Jan 2014 07:05:19 -0800

From: Thomas Gleixner <tglx@linutronix.de>

That's essential, if you want to hack on futexes.

Subject: [PATCH 14/15] futex: Avoid taking hb lock if nothing to wakeup

Date	Thu, 2 Jan 2014 07:05:20 -0800

From: Davidlohr Bueso <davidlohr@hp.com>

In futex_wake() there is clearly no point in taking the hb->lock if we know
beforehand that there are no tasks to be woken. While the hash bucket's plist
head is a cheap way of knowing this, we cannot rely 100% on it as there is a
racy window between the futex_wait call and when the task is actually added to
the plist. To this end, we couple it with the spinlock check as tasks trying to
enter the critical region are most likely potential waiters that will be added
to the plist, thus preventing tasks sleeping forever if wakers don't acknowledge
all possible waiters.

Furthermore, the futex ordering guarantees are preserved, ensuring that waiters
either observe the changed user space value before blocking or is woken by a
concurrent waker. For wakers, this is done by relying on the barriers in
get_futex_key_refs() -- for archs that do have implicit mb in atomic_inc() we
explicitly add them through a new futex_get_mm function. For waiters we rely
on the fact that spin_lock calls already update the head counter, so spinners
are visible even if the lock hasn't been acquired yet.

For more details please refer to the updated comments in the code and related
discussion: https://lkml.org/lkml/2013/11/26/556

Special thanks to tglx for careful review and feedback.

Subject: [PATCH 15/15] kernel/futex.c: Linux 3.4 compatibility fix up
V10l
Linux 3.4.76-------> ignore msm patch

commit 94f578e6aba14bb2aeb00db2e7f6e5f704fee937
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 8 09:42:33 2014 -0800

    Linux 3.4.76

commit b7a9e22f44afe81e1252ad0aeb6b145af93103e0
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 420cc6d77fd83ab28ebed7ab1dc9018ab351ec12
Author: Paul Moore <pmoore@redhat.com>
Date:   Tue Dec 10 14:58:01 2013 -0500

    selinux: process labeled IPsec TCP SYN-ACK packets properly in selinux_ip_postroute()

    commit c0828e50485932b7e019df377a6b0a8d1ebd3080 upstream.

    Due to difficulty in arriving at the proper security label for
    TCP SYN-ACK packets in selinux_ip_postroute(), we need to check packets
    while/before they are undergoing XFRM transforms instead of waiting
    until afterwards so that we can determine the correct security label.

    Reported-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 73ec955cd6954d69540c7a761182ee84d2bad189
Author: Paul Moore <pmoore@redhat.com>
Date:   Tue Dec 10 14:57:54 2013 -0500

    selinux: look for IPsec labels on both inbound and outbound packets

    commit 817eff718dca4e54d5721211ddde0914428fbb7c upstream.

    Previously selinux_skb_peerlbl_sid() would only check for labeled
    IPsec security labels on inbound packets, this patch enables it to
    check both inbound and outbound traffic for labeled IPsec security
    labels.

    Reported-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 7a12bcd95b59dcf1a715827846baa7c81d1946f9
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed Dec 18 17:08:48 2013 -0800

    sh: always link in helper functions extracted from libgcc

    commit 84ed8a99058e61567f495cc43118344261641c5f upstream.

    E.g. landisk_defconfig, which has CONFIG_NTFS_FS=m:

      ERROR: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!

    For "lib-y", if no symbols in a compilation unit are referenced by other
    units, the compilation unit will not be included in vmlinux.  This
    breaks modules that do reference those symbols.

    Use "obj-y" instead to fix this.

    http://kisskb.ellerman.id.au/kisskb/buildresult/8838077/

    This doesn't fix all cases. There are others, e.g. udivsi3.
    This is also not limited to sh, many architectures handle this in the
    same way.

    A simple solution is to unconditionally include all helper functions.
    A more complex solution is to make the choice of "lib-y" or "obj-y" depend
    on CONFIG_MODULES:

      obj-$(CONFIG_MODULES) += ...
      lib-y($CONFIG_MODULES) += ...

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Tested-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
    Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.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 dfb473b35096a0ffae221c7eeb49c34882ea6f9c
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>
    Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05bbcdd32afbfd520c71ae8104a8bf531aed9163
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Tue Dec 10 15:19:03 2013 -0800

    gpio: msm: Fix irq mask/unmask by writing bits instead of numbers

    commit 4cc629b7a20945ce35628179180329b6bc9e552b upstream.

    We should be writing bits here but instead we're writing the
    numbers that correspond to the bits we want to write. Fix it by
    wrapping the numbers in the BIT() macro. This fixes gpios acting
    as interrupts.

    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db7d85d7f0137628d24dfb3415716e96a1c11833
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Dec 8 21:12:59 2013 -0500

    jbd2: don't BUG but return ENOSPC if a handle runs out of space

    commit f6c07cad081ba222d63623d913aafba5586c1d2c upstream.

    If a handle runs out of space, we currently stop the kernel with a BUG
    in jbd2_journal_dirty_metadata().  This makes it hard to figure out
    what might be going on.  So return an error of ENOSPC, so we can let
    the file system layer figure out what is going on, to make it more
    likely we can get useful debugging information).  This should make it
    easier to debug problems such as the one which was reported by:

        https://bugzilla.kernel.org/show_bug.cgi?id=44731

    The only two callers of this function are ext4_handle_dirty_metadata()
    and ocfs2_journal_dirty().  The ocfs2 function will trigger a
    BUG_ON(), which means there will be no change in behavior.  The ext4
    function will call ext4_error_inode() which will print the useful
    debugging information and then handle the situation using ext4's error
    handling mechanisms (i.e., which might mean halting the kernel or
    remounting the file system read-only).

    Also, since both file systems already call WARN_ON(), drop the WARN_ON
    from jbd2_journal_dirty_metadata() to avoid two stack traces from
    being displayed.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: ocfs2-devel@oss.oracle.com
    Acked-by: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d23a87af40a35e7bedb349d071c4a1c5dcf050e2
Author: Steven Whitehouse <swhiteho@redhat.com>
Date:   Wed Dec 18 14:14:52 2013 +0000

    GFS2: Fix incorrect invalidation for DIO/buffered I/O

    commit dfd11184d894cd0a92397b25cac18831a1a6a5bc upstream.

    In patch 209806aba9d540dde3db0a5ce72307f85f33468f we allowed
    local deferred locks to be granted against a cached exclusive
    lock. That opened up a corner case which this patch now
    fixes.

    The solution to the problem is to check whether we have cached
    pages each time we do direct I/O and if so to unmap, flush
    and invalidate those pages. Since the glock state machine
    normally does that for us, mostly the code will be a no-op.

    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af7cf2107d3a05709799e441a55c2a646e7b5a45
Author: Steven Whitehouse <swhiteho@redhat.com>
Date:   Fri Dec 6 11:52:34 2013 +0000

    GFS2: don't hold s_umount over blkdev_put

    commit dfe5b9ad83a63180f358b27d1018649a27b394a9 upstream.

    This is a GFS2 version of Tejun's patch:
    4f331f01b9c43bf001d3ffee578a97a1e0633eac
    vfs: don't hold s_umount over close_bdev_exclusive() call

    In this case its blkdev_put itself that is the issue and this
    patch uses the same solution of dropping and retaking s_umount.

    Reported-by: Tejun Heo <tj@kernel.org>
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b01494b82bf4f46821dd4dda2bb35aa43415eeb
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Thu Dec 26 17:44:29 2013 -0800

    Input: allocate absinfo data when setting ABS capability

    commit 28a2a2e1aedbe2d8b2301e6e0e4e63f6e4177aca upstream.

    We need to make sure we allocate absinfo data when we are setting one of
    EV_ABS/ABS_XXX capabilities, otherwise we may bomb when we try to emit this
    event.

    Rested-by: Paul Cercueil <pcercuei@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2efb73fb4f0f5081ba6450e789b52f70247c80d9
Author: Jianguo Wu <wujianguo@huawei.com>
Date:   Wed Dec 18 17:08:59 2013 -0800

    mm/hugetlb: check for pte NULL pointer in __page_check_address()

    commit 98398c32f6687ee1e1f3ae084effb4b75adb0747 upstream.

    In __page_check_address(), if address's pud is not present,
    huge_pte_offset() will return NULL, we should check the return value.

    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: qiuxishi <qiuxishi@huawei.com>
    Cc: Hanjun Guo <guohanjun@huawei.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.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 1005954e40d50fbbbf48bd3c7fe4942f42f26f75
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Dec 11 17:13:10 2013 -0600

    rtlwifi: pci: Fix oops on driver unload

    commit 9278db6279e28d4d433bc8a848e10b4ece8793ed upstream.

    On Fedora systems, unloading rtl8192ce causes an oops. This patch fixes the
    problem reported at https://bugzilla.redhat.com/show_bug.cgi?id=852761.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a86f1d64f44d5e443eb0f5eb9498583f364e9f33
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 16 12:04:36 2013 +0100

    radiotap: fix bitmap-end-finding buffer overrun

    commit bd02cd2549cfcdfc57cb5ce57ffc3feb94f70575 upstream.

    Evan Huus found (by fuzzing in wireshark) that the radiotap
    iterator code can access beyond the length of the buffer if
    the first bitmap claims an extension but then there's no
    data at all. Fix this.

    Reported-by: Evan Huus <eapache@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c89c4dc7c370102ed0b5c0d90d892364d4980e37
Author: Michele Baldessari <michele@acksyn.org>
Date:   Mon Nov 25 19:00:14 2013 +0000

    libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8

    commit 87809942d3fa60bafb7a58d0bdb1c79e90a6821d upstream.

    We've received multiple reports in Fedora via (BZ 907193)
    that the Seagate Momentus SpinPoint M8 errors out when enabling AA:
    [    2.555905] ata2.00: failed to enable AA (error_mask=0x1)
    [    2.568482] ata2.00: failed to enable AA (error_mask=0x1)

    Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.

    Reported-by: Nicholas <arealityfarbetween@googlemail.com>
    Signed-off-by: Michele Baldessari <michele@acksyn.org>
    Tested-by: Nicholas <arealityfarbetween@googlemail.com>
    Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40fe79abb0828a085dc99827fa8588b8970788b9
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Fri Oct 11 08:45:51 2013 -0400

    cpupower: Fix segfault due to incorrect getopt_long arugments

    commit f447ef4a56dee4b68a91460bcdfe06b5011085f2 upstream.

    If a user calls 'cpupower set --perf-bias 15', the process will end with
    a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi
    call.  This is because the getopt_long structure currently has all of
    the options as having an optional_argument when they really have a
    required argument.  We change the structure to use required_argument to
    match the short options and it resolves the issue.

    This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1000439

    Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70a9450d1b854b02a0e7d19c6b18f48ed9d7b4db
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Dec 23 12:19:51 2013 +1100

    powerpc: Align p_end

    commit 286e4f90a72c0b0621dde0294af6ed4b0baddabb upstream.

    p_end is an 8 byte value embedded in the text section. This means it
    is only 4 byte aligned when it should be 8 byte aligned. Fix this
    by adding an explicit alignment.

    This fixes an issue where POWER7 little endian builds with
    CONFIG_RELOCATABLE=y fail to boot.

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e6cc83041aacf32013022d922c34230ee6e6e90
Author: Michael Neuling <mikey@neuling.org>
Date:   Mon Dec 16 15:12:43 2013 +1100

    powerpc: Fix bad stack check in exception entry

    commit 90ff5d688e61f49f23545ffab6228bd7e87e6dc7 upstream.

    In EXCEPTION_PROLOG_COMMON() we check to see if the stack pointer (r1)
    is valid when coming from the kernel.  If it's not valid, we die but
    with a nice oops message.

    Currently we allocate a stack frame (subtract INT_FRAME_SIZE) before we
    check to see if the stack pointer is negative.  Unfortunately, this
    won't detect a bad stack where r1 is less than INT_FRAME_SIZE.

    This patch fixes the check to compare the modified r1 with
    -INT_FRAME_SIZE.  With this, bad kernel stack pointers (including NULL
    pointers) are correctly detected again.

    Kudos to Paulus for finding this.

    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7110adb76087508116e4ce1496b8ca7a57e2d85d
Author: Mathy Vanhoef <vanhoefm@gmail.com>
Date:   Thu Nov 28 12:21:45 2013 +0100

    ath9k_htc: properly set MAC address and BSSID mask

    commit 657eb17d87852c42b55c4b06d5425baa08b2ddb3 upstream.

    Pick the MAC address of the first virtual interface as the new hardware MAC
    address. Set BSSID mask according to this MAC address. This fixes CVE-2013-4579.

    Signed-off-by: Mathy Vanhoef <vanhoefm@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07632d5ce9517f0b75e4b0dbd56040072fe8bf06
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Mon Dec 16 07:04:59 2013 +0530

    ath9k: Fix interrupt handling for the AR9002 family

    commit 73f0b56a1ff64e7fb6c3a62088804bab93bcedc2 upstream.

    This patch adds a driver workaround for a HW issue.

    A race condition in the HW results in missing interrupts,
    which can be avoided by a read/write with the ISR register.
    All chips in the AR9002 series are affected by this bug - AR9003
    and above do not have this problem.

    Cc: Felix Fietkau <nbd@openwrt.org>
    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 b5e9100f23e189fb01c186ca2d830ac994bdb678
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Dec 16 11:35:35 2013 +0100

    dm9601: work around tx fifo sync issue on dm962x

    commit 4263c86dca5198da6bd3ad826d0b2304fbe25776 upstream.

    Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
    (E.G. if bulk crc mismatch) happens right after a transfer with odd or
    maxpacket length, the internal tx hardware fifo gets out of sync causing
    the interface to stop working.

    Work around it by adding up to 3 bytes of padding to ensure this situation
    cannot trigger.

    This workaround also means we never pass multiple-of-maxpacket size skb's
    to usbnet, so the length adjustment to handle usbnet's padding of those can
    be removed.

    Reported-by: Joseph Chang <joseph_chang@davicom.com.tw>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa0a506a5b3d8fe3d63469bc9a43b50601f751bc
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Dec 16 11:35:33 2013 +0100

    dm9601: fix reception of full size ethernet frames on dm9620/dm9621a

    commit 407900cfb54bdb2cfa228010b6697305f66b2948 upstream.

    dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte
    header) mode.

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0050ac1e4b0a9340e9fc3d9d918799613b72f9a
Author: Li Wang <liwang@ubuntukylin.com>
Date:   Wed Nov 13 15:22:14 2013 +0800

    ceph: Avoid data inconsistency due to d-cache aliasing in readpage()

    commit 56f91aad69444d650237295f68c195b74d888d95 upstream.

    If the length of data to be read in readpage() is exactly
    PAGE_CACHE_SIZE, the original code does not flush d-cache
    for data consistency after finishing reading. This patches fixes
    this.

    Signed-off-by: Li Wang <liwang@ubuntukylin.com>
    Signed-off-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be541ecb66d285c4135c3820113af22ff57d4a0c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Dec 23 09:31:58 2013 -0500

    drm/radeon: 0x9649 is SUMO2 not SUMO

    commit d00adcc8ae9e22eca9d8af5f66c59ad9a74c90ec upstream.

    Fixes rendering corruption due to incorrect
    gfx configuration.

    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=63599

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

commit 93fb68c0c53ce4660686cf276320e64fe68578a1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 19 19:41:46 2013 -0500

    drm/radeon: fix asic gfx values for scrapper asics

    commit e2f6c88fb903e123edfd1106b0b8310d5117f774 upstream.

    Fixes gfx corruption on certain TN/RL parts.

    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=60389

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

commit 628706b739d6fdf0942030c75e301234f0c72d52
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Dec 17 10:09:32 2013 -0800

    net_dma: mark broken

    commit 77873803363c9e831fc1d1e6895c084279090c22 upstream.

    net_dma can cause data to be copied to a stale mapping if a
    copy-on-write fault occurs during dma.  The application sees missing
    data.

    The following trace is triggered by modifying the kernel to WARN if it
    ever triggers copy-on-write on a page that is undergoing dma:

     WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
     ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
     Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
     CPU: 24 PID: 2529 Comm: linbug Tainted: G        W    3.13.0-rc1+ #353
      00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
      ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
      ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
     Call Trace:
      [<ffffffff81751041>] dump_stack+0x46/0x58
      [<ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
      [<ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
      [<ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
      [<ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
      [<ffffffff81154a40>] do_wp_page+0xd0/0x790
      [<ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
      [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
      [<ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
      [<ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
      [<ffffffff810f3539>] ? trace_clock_local+0x9/0x10
      [<ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
      [<ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
      [<ffffffff8175ffce>] do_page_fault+0xe/0x10
      [<ffffffff8175c862>] page_fault+0x22/0x30
      [<ffffffff81643991>] ? __kfree_skb+0x51/0xd0
      [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
      [<ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
      [<ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
      [<ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
      [<ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
      [..]
     ---[ end trace e30e3b01191b7617 ]---
     Mapped at:
      [<ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
      [<ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
      [<ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
      [<ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
      [<ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:

    ...the problem is that the receive path falls back to cpu-copy in
    several locations and this trace is just one of the areas.  A few
    options were considered to fix this:

    1/ sync all dma whenever a cpu copy branch is taken

    2/ modify the page fault handler to hold off while dma is in-flight

    Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
    with cpu-copy.  Option 2 adds checks for behavior that is already documented as
    broken when using get_user_pages().  At a minimum a debug mode is warranted to
    catch and flag these violations of the dma-api vs get_user_pages().

    Thanks to David for his reproducer.

    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Vinod Koul <vinod.koul@intel.com>
    Cc: Alexander Duyck <alexander.h.duyck@intel.com>
    Reported-by: David Whipple <whipple@securedatainnovations.ch>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b266405d3fb1b41af54c762247da92cf9083d98e
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Sat Dec 7 13:22:42 2013 +0100

    drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook

    commit 49d45a31b71d7d9da74485922bdb63faf3dc9684 upstream.

    This bug in EDID was exposed by:

    commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66
    Author: Alex Deucher <alexander.deucher@amd.com>
    Date:   Mon Mar 26 15:12:54 2012 -0400

        drm/radeon/kms: improve bpc handling (v2)

    Which resulted in kind of regression in 3.5. This fixes
    https://bugs.freedesktop.org/show_bug.cgi?id=70934

    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f8878956c833443d6c6e498e9ed6a18ee30e0f5
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Wed Nov 27 19:59:13 2013 +0400

    sched/rt: Fix rq's cpupri leak while enqueue/dequeue child RT entities

    commit 757dfcaa41844595964f1220f1d33182dae49976 upstream.

    This patch touches the RT group scheduling case.

    Functions inc_rt_prio_smp() and dec_rt_prio_smp() change (global) rq's
    priority, while rt_rq passed to them may be not the top-level rt_rq.
    This is wrong, because changing of priority on a child level does not
    guarantee that the priority is the highest all over the rq. So, this
    leak makes RT balancing unusable.

    The short example: the task having the highest priority among all rq's
    RT tasks (no one other task has the same priority) are waking on a
    throttle rt_rq.  The rq's cpupri is set to the task's priority
    equivalent, but real rq->rt.highest_prio.curr is less.

    The patch below fixes the problem.

    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    CC: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/49231385567953@web4m.yandex.ru
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1192c0e5d037def6763f3873d3340615c241fe7
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Tue Dec 3 21:22:21 2013 -0500

    ext4: check for overlapping extents in ext4_valid_extent_entries()

    commit 5946d089379a35dda0e531710b48fca05446a196 upstream.

    A corrupted ext4 may have out of order leaf extents, i.e.

    extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT
    extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT
                 ^^^^ overlap with previous extent

    Reading such extent could hit BUG_ON() in ext4_es_cache_extent().

    	BUG_ON(end < lblk);

    The problem is that __read_extent_tree_block() tries to cache holes as
    well but assumes 'lblk' is greater than 'prev' and passes underflowed
    length to ext4_es_cache_extent(). Fix it by checking for overlapping
    extents in ext4_valid_extent_entries().

    I hit this when fuzz testing ext4, and am able to reproduce it by
    modifying the on-disk extent by hand.

    Also add the check for (ee_block + len - 1) in ext4_valid_extent() to
    make sure the value is not overflow.

    Ran xfstests on patched ext4 and no regression.

    Cc: Lukáš Czerner <lczerner@redhat.com>
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510e024d1e74bb0f574d14ee19436a56ed4fc476
Author: Junho Ryu <jayr@google.com>
Date:   Tue Dec 3 18:10:28 2013 -0500

    ext4: fix use-after-free in ext4_mb_new_blocks

    commit 4e8d2139802ce4f41936a687f06c560b12115247 upstream.

    ext4_mb_put_pa should hold pa->pa_lock before accessing pa->pa_count.
    While ext4_mb_use_preallocated checks pa->pa_deleted first and then
    increments pa->count later, ext4_mb_put_pa decrements pa->pa_count
    before holding pa->pa_lock and then sets pa->pa_deleted.

    * Free sequence
    ext4_mb_put_pa (1):		atomic_dec_and_test pa->pa_count
    ext4_mb_put_pa (2):		lock pa->pa_lock
    ext4_mb_put_pa (3):			check pa->pa_deleted
    ext4_mb_put_pa (4):			set pa->pa_deleted=1
    ext4_mb_put_pa (5):		unlock pa->pa_lock
    ext4_mb_put_pa (6):		remove pa from a list
    ext4_mb_pa_callback:		free pa

    * Use sequence
    ext4_mb_use_preallocated (1):	iterate over preallocation
    ext4_mb_use_preallocated (2):	lock pa->pa_lock
    ext4_mb_use_preallocated (3):		check pa->pa_deleted
    ext4_mb_use_preallocated (4):		increase pa->pa_count
    ext4_mb_use_preallocated (5):	unlock pa->pa_lock
    ext4_mb_release_context:	access pa

    * Use-after-free sequence
    [initial status]		<pa->pa_deleted = 0, pa_count = 1>
    ext4_mb_use_preallocated (1):	iterate over preallocation
    ext4_mb_use_preallocated (2):	lock pa->pa_lock
    ext4_mb_use_preallocated (3):		check pa->pa_deleted
    ext4_mb_put_pa (1):		atomic_dec_and_test pa->pa_count
    [pa_count decremented]		<pa->pa_deleted = 0, pa_count = 0>
    ext4_mb_use_preallocated (4):		increase pa->pa_count
    [pa_count incremented]		<pa->pa_deleted = 0, pa_count = 1>
    ext4_mb_use_preallocated (5):	unlock pa->pa_lock
    ext4_mb_put_pa (2):		lock pa->pa_lock
    ext4_mb_put_pa (3):			check pa->pa_deleted
    ext4_mb_put_pa (4):			set pa->pa_deleted=1
    [race condition!]		<pa->pa_deleted = 1, pa_count = 1>
    ext4_mb_put_pa (5):		unlock pa->pa_lock
    ext4_mb_put_pa (6):		remove pa from a list
    ext4_mb_pa_callback:		free pa
    ext4_mb_release_context:	access pa

    AddressSanitizer has detected use-after-free in ext4_mb_new_blocks
    Bug report: http://goo.gl/rG1On3

    Signed-off-by: Junho Ryu <jayr@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be19dd5258a26cfe1d90a22132784c2ba836039
Author: Len Brown <len.brown@intel.com>
Date:   Wed Sep 26 22:28:21 2012 -0400

    intel_idle: enable IVB Xeon support

    commit 23795e580cad5d6b73d47d51b9074ce3e58bf334 upstream.

    IVB Xeon currently shares the same parameters IVB client.

    Signed-off-by: Len Brown <len.brown@intel.com>
    Cc: Vinson Lee <vlee@twopensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5806153a870c8b6557423e495f6d79ac9ec87197
Author: Len Brown <len.brown@intel.com>
Date:   Fri Jun 1 19:45:32 2012 -0400

    intel_idle: initial IVB support

    commit 6edab08c24f9141d69cfa4683a0a027d86ab303e upstream.

    From an OS point of view, IVB looks like SNB, but quicker.

    Signed-off-by: Len Brown <len.brown@intel.com>
    Cc: Vinson Lee <vlee@twopensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09951c9b33f8cfdc0e8c4e03fe83bc66c9d908dc
Author: Miao Xie <miaox@cn.fujitsu.com>
Date:   Mon Dec 16 15:20:01 2013 +0800

    ftrace: Initialize the ftrace profiler for each possible cpu

    commit c4602c1c818bd6626178d6d3fcc152d9f2f48ac0 upstream.

    Ftrace currently initializes only the online CPUs. This implementation has
    two problems:
    - If we online a CPU after we enable the function profile, and then run the
      test, we will lose the trace information on that CPU.
      Steps to reproduce:
      # echo 0 > /sys/devices/system/cpu/cpu1/online
      # cd <debugfs>/tracing/
      # echo <some function name> >> set_ftrace_filter
      # echo 1 > function_profile_enabled
      # echo 1 > /sys/devices/system/cpu/cpu1/online
      # run test
    - If we offline a CPU before we enable the function profile, we will not clear
      the trace information when we enable the function profile. It will trouble
      the users.
      Steps to reproduce:
      # cd <debugfs>/tracing/
      # echo <some function name> >> set_ftrace_filter
      # echo 1 > function_profile_enabled
      # run test
      # cat trace_stat/function*
      # echo 0 > /sys/devices/system/cpu/cpu1/online
      # echo 0 > function_profile_enabled
      # echo 1 > function_profile_enabled
      # cat trace_stat/function*
      # run test
      # cat trace_stat/function*

    So it is better that we initialize the ftrace profiler for each possible cpu
    every time we enable the function profile instead of just the online ones.

    Link: http://lkml.kernel.org/r/1387178401-10619-1-git-send-email-miaox@cn.fujitsu.com

    Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58c2314ac41e8f24a2a594bd866915e38de9648e
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Mon Dec 23 17:45:01 2013 -0500

    selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()

    commit c0c1439541f5305b57a83d599af32b74182933fe upstream.

    selinux_setprocattr() does ptrace_parent(p) under task_lock(p),
    but task_struct->alloc_lock doesn't pin ->parent or ->ptrace,
    this looks confusing and triggers the "suspicious RCU usage"
    warning because ptrace_parent() does rcu_dereference_check().

    And in theory this is wrong, spin_lock()->preempt_disable()
    doesn't necessarily imply rcu_read_lock() we need to access
    the ->parent.

    Reported-by: Evan McNabb <emcnabb@redhat.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 351381d8cea3036cfe021eb29994584d0e5c0e73
Author: Chad Hanson <chanson@trustedcs.com>
Date:   Mon Dec 23 17:45:01 2013 -0500

    selinux: fix broken peer recv check

    commit 46d01d63221c3508421dd72ff9c879f61053cffc upstream.

    Fix a broken networking check. Return an error if peer recv fails.  If
    secmark is active and the packet recv succeeds the peer recv error is
    ignored.

    Signed-off-by: Chad Hanson <chanson@trustedcs.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc8a3912facbd66e2b88d10922aae74548b86606
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Nov 29 20:17:45 2013 +0100

    usb: cdc-wdm: manage_power should always set needs_remote_wakeup

    commit 4144bc861ed7934d56f16d2acd808d44af0fcc90 upstream.

    Reported-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b86d86822526d0be85d41cca71242fba6ac3c2c7
Author: JongHo Kim <furmuwon@gmail.com>
Date:   Tue Dec 17 23:02:24 2013 +0900

    ALSA: Add SNDRV_PCM_STATE_PAUSED case in wait_for_avail function

    commit ed697e1aaf7237b1a62af39f64463b05c262808d upstream.

    When the process is sleeping at the SNDRV_PCM_STATE_PAUSED
    state from the wait_for_avail function, the sleep process will be woken by
    timeout(10 seconds). Even if the sleep process wake up by timeout, by this
    patch, the process will continue with sleep and wait for the other state.

    Signed-off-by: JongHo Kim <furmuwon@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a183811472052b849d74d4fb2674265c6f874610
Author: Bo Shen <voice.shen@atmel.com>
Date:   Wed Dec 18 11:26:23 2013 +0800

    ASoC: wm8904: fix DSP mode B configuration

    commit f0199bc5e3a3ec13f9bc938556517ec430b36437 upstream.

    When wm8904 work in DSP mode B, we still need to configure it to
    work in DSP mode. Or else, it will work in Right Justified mode.

    Signed-off-by: Bo Shen <voice.shen@atmel.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34ee0e8ad09ec1e58858bd3c8756a31a2b3c46bf
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Nov 22 16:47:26 2013 +0100

    TTY: pmac_zilog, check existence of ports in pmz_console_init()

    commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.

    When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
    on the kernel command line, it crashes with:

    Unable to handle kernel NULL pointer dereference at virtual address   (null)
    Oops: 00000000
    PC: [<0013ad28>] __pmz_startup+0x32/0x2a0
    ...
    Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4

    The normal tty driver doesn't crash, because init_pmz() checks
    pmz_ports_count again after calling pmz_probe().

    In the serial console initialization path, pmz_console_init() doesn't do
    this, causing the driver to crash later.

    Add a check for pmz_ports_count to fix this.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Finn Thain <fthain@telegraphics.com.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7898047084bed6716bbc2c08b969ddf364ca36fd
Author: pingfan liu <qemulist@gmail.com>
Date:   Fri Nov 15 16:35:00 2013 +0800

    powerpc: kvm: fix rare but potential deadlock scene

    commit 91648ec09c1ef69c4d840ab6dab391bfb452d554 upstream.

    Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
    realmode, so it can trigger the deadlock.

    Suppose the following scene:

    Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
    vcpus.

    If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched
    out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be
    caught in realmode for a long time.

    What makes things even worse if the following happens,
      On cpuM, bitlockX is hold, on cpuN, Y is hold.
      vcpu_B_2 try to lock Y on cpuM in realmode
      vcpu_A_2 try to lock X on cpuN in realmode

    Oops! deadlock happens

    Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
    Reviewed-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4e90afb0b16996ff921762ab4212db0f40535f
Author: Yan, Zheng <zheng.z.yan@intel.com>
Date:   Thu Oct 31 09:10:47 2013 +0800

    ceph: wake up 'safe' waiters when unregistering request

    commit fc55d2c9448b34218ca58733a6f51fbede09575b upstream.

    We also need to wake up 'safe' waiters if error occurs or request
    aborted. Otherwise sync(2)/fsync(2) may hang forever.

    Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
    Signed-off-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1461d4c794c2f98ebdd9d60f47a08c09dc4ce453
Author: Yan, Zheng <zheng.z.yan@intel.com>
Date:   Thu Sep 26 14:25:36 2013 +0800

    ceph: cleanup aborted requests when re-sending requests.

    commit eb1b8af33c2e42a9a57fc0a7588f4a7b255d2e79 upstream.

    Aborted requests usually get cleared when the reply is received.
    If MDS crashes, no reply will be received. So we need to cleanup
    aborted requests when re-sending requests.

    Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
    Reviewed-by: Greg Farnum <greg@inktank.com>
    Signed-off-by: Sage Weil <sage@inktank.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc845e5405b033fadd398c5ca2884a568313c875
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sat Nov 9 12:38:09 2013 +0100

    USB: serial: fix race in generic write

    commit 6f6485463aada1ec6a0f3db6a03eb8e393d6bb55 upstream.

    Fix race in generic write implementation, which could lead to
    temporarily degraded throughput.

    The current generic write implementation introduced by commit
    27c7acf22047 ("USB: serial: reimplement generic fifo-based writes") has
    always had this bug, although it's fairly hard to trigger and the
    consequences are not likely to be noticed.

    Specifically, a write() on one CPU while the completion handler is
    running on another could result in only one of the two write urbs being
    utilised to empty the remainder of the write fifo (unless there is a
    second write() that doesn't race during that time).

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tspp: Protect against buffer overflow

Change filter->priority to unsigned int. Since it was defined as integer,
it may have had negative value and cause accessing an array outside
of its region

CRs-Fixed: 561802, 561825
Change-Id: Ie72aa09b07e79b0b67081b74e3b2057de30f03d0
Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>
Merge branch 'my_dev_kernel_exp_3.4.x' into my_dev_kernel_exp_3.4.x_jb43