random: entropy tweaks are all the rage nowadays

use nonblocking for all.  Read this web page:
http://lwn.net/Articles/489734/

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:

	drivers/char/random.c

Change-Id: Icceab0cbc0c71d05e1627663758382525bc998ca
sched_features: Disable GENTLE_FAIR_SLEEPERS

Change-Id: Iae9cf359c6f1bc0a7b289a2eedf05218e545954b
msm: cpufreq: Break out early if target frequency is the same as the current

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>

Conflicts:

	arch/arm/mach-msm/cpufreq.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Updated 7x30-smd
7x30-smd: cb_list_lock is now a spinlock

Most (if not all) files in */mach-msm/7x30-smd rely on this header.
Everything using cb_list_lock has been updated for what should be
a spinlock, yet this remained a mutex.

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mach-msm: board-spade-audio.c remove pm8xxx config

Removed from Evervolv and Andromadus kernels. Let's follow.
Also duplicate entry, wtf.

Change-Id: I527616beaf0447fb9d7cb364eb3eaf4abcba30f1
Linux 3.0.97

commit 3c7f3084a5583637e668a80457b18f90a8743f0d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 26 16:53:10 2013 -0700

    Linux 3.0.97

commit 59e272211a96b1a4aee7ca1c328353f6c9b7e92e
Author: Anand Avati <avati@redhat.com>
Date:   Tue Aug 20 02:21:07 2013 -0400

    fuse: invalidate inode attributes on xattr modification

    commit d331a415aef98717393dda0be69b7947da08eba3 upstream.

    Calls like setxattr and removexattr result in updation of ctime.
    Therefore invalidate inode attributes to force a refresh.

    Signed-off-by: Anand Avati <avati@redhat.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f35b12e6453f12bb65f7d492b751f05cdeb41518
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Mon Aug 12 20:39:30 2013 +0400

    fuse: postpone end_page_writeback() in fuse_writepage_locked()

    commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream.

    The patch fixes a race between ftruncate(2), mmap-ed write and write(2):

    1) An user makes a page dirty via mmap-ed write.
    2) The user performs shrinking truncate(2) intended to purge the page.
    3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
       writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
       the original page by end_page_writeback.
    4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
       is free.
    5) Ordinary write(2) extends i_size back to cover the page. Note that
       fuse_send_write_pages do wait for fuse writeback, but for another
       page->index.
    6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
       fuse_send_writepage is supposed to crop inarg->size of the request,
       but it doesn't because i_size has already been extended back.

    Moving end_page_writeback to the end of fuse_writepage_locked fixes the
    race because now the fact that truncate_pagecache is successfully returned
    infers that fuse_writepage_locked has already called end_page_writeback.
    And this, in turn, infers that fuse_flush_writepages has already called
    fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
    could not extend it because of i_mutex held by ftruncate(2).

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd76cc4459ac83aa17226ceac9058abbfe8385c8
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jul 25 11:49:11 2013 +0200

    isofs: Refuse RW mount of the filesystem instead of making it RO

    commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream.

    Refuse RW mount of isofs filesystem. So far we just silently changed it
    to RO mount but when the media is writeable, block layer won't notice
    this change and thus will think device is used RW and will block eject
    button of the drive. That is unexpected by users because for
    non-writeable media eject button works just fine.

    Userspace mount(8) command handles this just fine and retries mounting
    with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
    tool mounting isofs is likely confronted with the case of read-only
    media where block layer already refuses to mount the filesystem without
    MS_RDONLY set so our behavior shouldn't be anything new for it.

    Reported-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85a39b77027438bec7f1a1ebbbc46925d22f7b5c
Author: Libin <huawei.libin@huawei.com>
Date:   Wed Sep 11 14:20:38 2013 -0700

    mm/huge_memory.c: fix potential NULL pointer dereference

    commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream.

    In collapse_huge_page() there is a race window between releasing the
    mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
    return NULL.  So check the return value to avoid NULL pointer dereference.

    collapse_huge_page
        khugepaged_alloc_page
            up_read(&mm->mmap_sem)
        down_write(&mm->mmap_sem)
        vma = find_vma(mm, address)

    Signed-off-by: Libin <huawei.libin@huawei.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    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 49fa5f65bff58a34362e3a29733cbec7a866871d
Author: Greg Thelen <gthelen@google.com>
Date:   Wed Sep 11 14:23:08 2013 -0700

    memcg: fix multiple large threshold notifications

    commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream.

    A memory cgroup with (1) multiple threshold notifications and (2) at least
    one threshold >=2G was not reliable.  Specifically the notifications would
    either not fire or would not fire in the proper order.

    The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
    thresholds in sorted order.  mem_cgroup_usage_register_event() sorts them
    with compare_thresholds(), which returns the difference of two 64 bit
    thresholds as an int.  If the difference is positive but has bit[31] set,
    then sort() treats the difference as negative and breaks sort order.

    This fix compares the two arbitrary 64 bit thresholds returning the
    classic -1, 0, 1 result.

    The test below sets two notifications (at 0x1000 and 0x81001000):
      cd /sys/fs/cgroup/memory
      mkdir x
      for x in 4096 2164264960; do
        cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
      done
      echo $$ > x/cgroup.procs
      anon_leaker 500M

    v3.11-rc7 fails to signal the 4096 event listener:
      Leaking...
      Done leaking pages.

    Patched v3.11-rc7 properly notifies:
      Leaking...
      4096 listener:2013:8:31:14:13:36
      Done leaking pages.

    The fixed bug is old.  It appears to date back to the introduction of
    memcg threshold notifications in v2.6.34-rc1-116-g2e72b6347c94 "memcg:
    implement memory thresholds"

    Signed-off-by: Greg Thelen <gthelen@google.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.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 6becb5ec6dbf34850e39fd97860206c1628ccb94
Author: Jie Liu <jeff.liu@oracle.com>
Date:   Wed Sep 11 14:20:05 2013 -0700

    ocfs2: fix the end cluster offset of FIEMAP

    commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream.

    Call fiemap ioctl(2) with given start offset as well as an desired mapping
    range should show extents if possible.  However, we somehow figure out the
    end offset of mapping via 'mapping_end -= cpos' before iterating the
    extent records which would cause problems if the given fiemap length is
    too small to a cluster size, e.g,

    Cluster size 4096:
    debugfs.ocfs2 1.6.3
            Block Size Bits: 12   Cluster Size Bits: 12

    The extended fiemap test utility From David:
    https://gist.github.com/anonymous/6172331

    # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
    # ./fiemap /ocfs2/test_file 4096 10
    start: 4096, length: 10
    File /ocfs2/test_file has 0 extents:
    #   Logical          Physical         Length           Flags
        ^^^^^ <-- No extent is shown

    In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
    loop of searching extent records was not executed at all.

    This patch remove the in question 'mapping_end -= cpos', and loops
    until the cpos is larger than the mapping_end as usual.

    # ./fiemap /ocfs2/test_file 4096 10
    start: 4096, length: 10
    File /ocfs2/test_file has 1 extents:
    #   Logical          Physical         Length           Flags
    0:  0000000000000000 0000000056a01000 0000000006a00000 0000

    Signed-off-by: Jie Liu <jeff.liu@oracle.com>
    Reported-by: David Weber <wb@munzinger.de>
    Tested-by: David Weber <wb@munzinger.de>
    Cc: Sunil Mushran <sunil.mushran@gmail.com>
    Cc: Mark Fashen <mfasheh@suse.de>
    Cc: Joel Becker <jlbec@evilplan.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 fc4a8fd8746dcd6ff011bc61c06fe9cf5ed2015a
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:32:01 2013 +0200

    HID: check for NULL field when setting values

    commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream.

    Defensively check that the field to be worked on is not NULL.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d564bb5984ae5b94233bc0bdb0e38073fc1b038
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:31:28 2013 +0200

    HID: ntrig: validate feature report details

    commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream.

    A HID device could send a malicious feature report that would cause the
    ntrig HID driver to trigger a NULL dereference during initialization:

    [57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
    ...
    [57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
    [57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]

    CVE-2013-2896

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 645c9dcabb2c234e6d4a546125830d04988a1f90
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:29:55 2013 +0200

    HID: validate HID report id size

    commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream.

    The "Report ID" field of a HID report is used to build indexes of
    reports. The kernel's index of these is limited to 256 entries, so any
    malicious device that sets a Report ID greater than 255 will trigger
    memory corruption on the host:

    [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878
    [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b

    CVE-2013-2888

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c993386d8c99c60ffb1161076040f3ffb46c0794
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Aug 28 22:30:49 2013 +0200

    HID: pantherlord: validate output report details

    commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream.

    A HID device could send a malicious output report that would cause the
    pantherlord HID driver to write beyond the output report allocation
    during initialization, causing a heap overflow:

    [  310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003
    ...
    [  315.980774] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2892

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8600be1d3927e177b80c7ee9263ef3b28a0ba115
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Aug 13 12:33:28 2013 +0200

    ath9k: avoid accessing MRC registers on single-chain devices

    commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.

    They are not implemented, and accessing them might trigger errors

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be84480edb2b552c2fb9ca940c6bb07464306108
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Aug 6 14:18:10 2013 +0200

    ath9k: always clear ps filter bit on new assoc

    commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.

    Otherwise in some cases, EAPOL frames might be filtered during the
    initial handshake, causing delays and assoc failures.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bea7e186543344d62c3a2f04032f494a59c8fc6e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 9 10:20:48 2013 +0200

    ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist

    commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream.

    Toshiba Satellite C870 shows interrupt problems occasionally when
    certain mixer controls like "Mic Switch" is toggled.  This seems
    worked around by not using MSI.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee7ad6684665dfe84977c4cfb076c4b7b73a68fc
Author: Mike Dyer <mike.dyer@md-soft.co.uk>
Date:   Fri Aug 16 18:36:28 2013 +0100

    ASoC: wm8960: Fix PLL register writes

    commit 85fa532b6ef920b32598df86b194571a7059a77c upstream.

    Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part
    should be split across each register in 8bit chunks.

    Signed-off-by: Mike Dyer <mike.dyer@md-soft.co.uk>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c97081c634fdee51845ca8a30f394cf06125a509
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Jun 28 10:34:48 2013 -0700

    rculist: list_first_or_null_rcu() should use list_entry_rcu()

    commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream.

    list_first_or_null() should test whether the list is empty and return
    pointer to the first entry if not in a RCU safe manner.  It's broken
    in several ways.

    * It compares __kernel @__ptr with __rcu @__next triggering the
      following sparse warning.

      net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)

    * It doesn't perform rcu_dereference*() and computes the entry address
      using container_of() directly from the __rcu pointer which is
      inconsitent with other rculist interface.  As a result, all three
      in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
      dereference the pointer w/o going through read barrier.

    * While ->next dereference passes through list_next_rcu(), the
      compiler is still free to fetch ->next more than once and thus
      nullify the "__ptr != __next" condition check.

    Fix it by making list_first_or_null_rcu() dereference ->next directly
    using ACCESS_ONCE() and then use list_entry_rcu() on it like other
    rculist accessors.

    v2: Paul pointed out that the compiler may fetch the pointer more than
        once nullifying the condition check.  ACCESS_ONCE() added on
        ->next dereference.

    v3: Restored () around macro param which was accidentally removed.
        Spotted by Paul.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Dipankar Sarma <dipankar@in.ibm.com>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff819a0c7f12179d197aa06841087964dd2be7d3
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Aug 3 16:37:48 2013 +0200

    usb: config->desc.bLength may not exceed amount of data returned by the device

    commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream.

    While reading the config parsing code I noticed this check is missing, without
    this check config->desc.wTotalLength can end up with a value larger then the
    dev->rawdescriptors length for the config, and when userspace then tries to
    get the rawdescriptors bad things may happen.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe3efa501f32fc05483a095334573799a954d1ab
Author: Oliver Neukum <oneukum@suse.de>
Date:   Tue Aug 6 14:22:59 2013 +0200

    USB: cdc-wdm: fix race between interrupt handler and tasklet

    commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream.

    Both could want to submit the same URB. Some checks of the flag
    intended to prevent that were missing.

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f8ce0764bb3d54090856cca1c8562c0435003ca
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Aug 19 13:05:45 2013 +0200

    USB: mos7720: fix big-endian control requests

    commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream.

    Fix endianess bugs in parallel-port code which caused corrupt
    control-requests to be issued on big-endian machines.

    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d723c89020d4f5f54b42997ae5e90f13bc620d8b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 16 10:16:59 2013 +0300

    USB: mos7720: use GFP_ATOMIC under spinlock

    commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream.

    The write_parport_reg_nonblock() function shouldn't sleep because it's
    called with spinlocks held.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71d5f63763f01e5577c465d6752b7060ba105fa6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Aug 20 11:57:35 2013 +0300

    staging: comedi: dt282x: dt282x_ai_insn_read() always fails

    commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream.

    In dt282x_ai_insn_read() we call this macro like:
    wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
    Because the if statement doesn't have curly braces it means we always
    return -ETIME and the function never succeeds.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 186ad2276339b0fc63f06146627b6d15c5058c4f
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Sep 5 08:38:10 2013 -0400

    cifs: ensure that srv_mutex is held when dealing with ssocket pointer

    commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.

    Oleksii reported that he had seen an oops similar to this:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
    IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
    PGD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
     loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
    CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G        W  O 3.10.1SIGN #28
    Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
    Workqueue: cifsiod cifs_echo_request [cifs]
    task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
    RIP: 0010:[<ffffffff814dcc13>]  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
    RSP: 0000:ffff880148745b00  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
    RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
    RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
    R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
    FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
    Oops#2 Part7
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
     ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
     ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
    Call Trace:
     [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
     [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
     [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
     [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
     [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
     [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
     [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
     [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
     [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
     [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
    Oops#2 Part6
     [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
     [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
     [<ffffffff810b45b3>] process_one_work+0x173/0x4a0
     [<ffffffff810b52a1>] worker_thread+0x121/0x3a0
     [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
     [<ffffffff810bae00>] kthread+0xc0/0xd0
     [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
     [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
     [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
    Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
     RIP  [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
     RSP <ffff880148745b00>
    CR2: 0000000000000088

    The client was in the middle of trying to send a frame when the
    server->ssocket pointer got zeroed out. In most places, that we access
    that pointer, the srv_mutex is held. There's only one spot that I see
    that the server->ssocket pointer gets set and the srv_mutex isn't held.
    This patch corrects that.

    The upstream bug report was here:

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

    Reported-by: Oleksii Shevchuk <alxchk@gmail.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fa24717e9b3e4d50f5dd912270613d5887f361c
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date:   Mon Aug 19 10:36:13 2013 -0700

    usb: xhci: Disable runtime PM suspend for quirky controllers

    commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.

    If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
    a reset will be performed upon runtime resume. Any previously suspended
    devices attached to the controller will be re-enumerated at this time.
    This will cause problems, for example, if an open system call on the
    device triggered the resume (the open call will fail).

    Note that this change is only relevant when persist_enabled is not set
    for USB devices.

    This patch should be backported to kernels as old as 3.0, that
    contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
    reset on resume quirk for asrock p67 host".

    Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4595b6def019ab1324b3948dfbaa959963a132e8
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Thu Aug 22 17:47:50 2013 +0100

    ARM: PCI: versatile: Fix SMAP register offsets

    commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.

    The SMAP register offsets in the versatile PCI controller code were
    all off by four.  (This didn't have any observable bad effects
    because on this board PHYS_OFFSET is zero, and (a) writing zero to
    the flags register at offset 0x10 has no effect and (b) the reset
    value of the SMAP register is zero anyway, so failing to write SMAP2
    didn't matter.)

    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit def5a30f1a9766eb269234971f45736d67326925
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Jul 31 17:00:42 2013 +0200

    xen-gnt: prevent adding duplicate gnt callbacks

    commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.

    With the current implementation, the callback in the tail of the list
    can be added twice, because the check done in
    gnttab_request_free_callback is bogus, callback->next can be NULL if
    it is the last callback in the list. If we add the same callback twice
    we end up with an infinite loop, were callback == callback->next.

    Replace this check with a proper one that iterates over the list to
    see if the callback has already been added.

    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Matt Wilson <msw@amazon.com>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b900d1daf22341794f5fd7a0ec1fe97966b8590
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Aug 7 02:01:19 2013 +1000

    powerpc: Handle unaligned ldbrx/stdbrx

    commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream.

    Normally when we haven't implemented an alignment handler for
    a load or store instruction the process will be terminated.

    The alignment handler uses the DSISR (or a pseudo one) to locate
    the right handler. Unfortunately ldbrx and stdbrx overlap lfs and
    stfs so we incorrectly think ldbrx is an lfs and stdbrx is an
    stfs.

    This bug is particularly nasty - instead of terminating the
    process we apply an incorrect fixup and continue on.

    With more and more overlapping instructions we should stop
    creating a pseudo DSISR and index using the instruction directly,
    but for now add a special case to catch ldbrx/stdbrx.

    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 162c7c77893520b95698d6a7d146295aab1397c2
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sun Sep 8 14:33:50 2013 +1000

    crypto: api - Fix race condition in larval lookup

    commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream.

    crypto_larval_lookup should only return a larval if it created one.
    Any larval created by another entity must be processed through
    crypto_larval_wait before being returned.

    Otherwise this will lead to a larval being killed twice, which
    will most likely lead to a crash.

    Reported-by: Kees Cook <keescook@chromium.org>
    Tested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173798ef2abbec8faf2a4397a24bd357fecfe008
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Sep 6 11:49:51 2013 -0400

    SCSI: sd: Fix potential out-of-bounds access

    commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.

    This patch fixes an out-of-bounds error in sd_read_cache_type(), found
    by Google's AddressSanitizer tool.  When the loop ends, we know that
    "offset" lies beyond the end of the data in the buffer, so no Caching
    mode page was found.  In theory it may be present, but the buffer size
    is limited to 512 bytes.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.98

commit f45b5c1b0301e144f2096dfe2745e93a8cb2b172
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 1 08:55:54 2013 -0700

    Linux 3.0.98

commit bfe3887cc200ec2b63e6137c682602e31bb33fa1
Author: Daniel Santos <daniel.santos@pobox.com>
Date:   Thu Oct 4 17:15:05 2012 -0700

    kernel-doc: bugfix - multi-line macros

    commit 654784284430bf2739985914b65e09c7c35a7273 upstream.

    Prior to this patch the following code breaks:

    /**
     * multiline_example - this breaks kernel-doc
     */
     #define multiline_example( \
    myparam)

    Producing this error:

    Error(somefile.h:983): cannot understand prototype: 'multiline_example( \ '

    This patch fixes the issue by appending all lines ending in a blackslash
    (optionally followed by whitespace), removing the backslash and any
    whitespace after it prior to appending (just like the C pre-processor
    would).

    This fixes a break in kerel-doc introduced by the additions to rbtree.h.

    Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
    Cc: Randy Dunlap <rdunlap@xenotime.net>
    Cc: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f77b78d931314d3e066266c23b44f90807ee5774
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Fri Sep 6 22:39:20 2013 +0100

    sfc: Fix efx_rx_buf_offset() for recycled pages

    This bug fix is only for stable branches older than 3.10.  The bug was
    fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
    mapping/unmapping costs'), but that change is totally unsuitable for
    stable.

    Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
    swiotlb') added an explicit page_offset member to struct
    efx_rx_buffer, which must be set consistently with the u.page and
    dma_addr fields.  However, it failed to add the necessary assignment
    in efx_resurrect_rx_buffer().  It also did not correct the calculation
    of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
    that DMA-mapping a page will result in a page-aligned DMA address
    (exactly what swiotlb violates).

    Add the assignment of efx_rx_buffer::page_offset and change the
    calculation of dma_addr to make use of it.

    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe826cd4ead9e72cdb0815660a306e267eab34d1
Author: Andi Kleen <ak@linux.intel.com>
Date:   Wed Apr 24 17:03:02 2013 -0700

    perf tools: Handle JITed code in shared memory

    commit 89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream.

    Need to check for /dev/zero.

    Most likely more strings are missing too.

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Vinson Lee <vlee@freedesktop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07d351b5f618e5be5bd97443d25db41eb1bb8244
Author: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date:   Fri Mar 23 02:42:23 2012 +0100

    fanotify: dont merge permission events

    commit 03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b upstream.

    Boyd Yang reported a problem for the case that multiple threads of the same
    thread group are waiting for a reponse for a permission event.
    In this case it is possible that some of the threads are never woken up, even
    if the response for the event has been received
    (see http://marc.info/?l=linux-kernel&m=131822913806350&w=2).

    The reason is that we are currently merging permission events if they belong to
    the same thread group. But we are not prepared to wake up more than one waiter
    for each event. We do

    wait_event(group->fanotify_data.access_waitq, event->response ||
                atomic_read(&group->fanotify_data.bypass_perm));
    and after that
      event->response = 0;

    which is the reason that even if we woke up all waiters for the same event
    some of them may see event->response being already set 0 again, then go back to
    sleep and block forever.

    With this patch we avoid that more than one thread is waiting for a response
    by not merging permission events for the same thread group any more.

    Reported-by: Boyd Yang <boyd.yang@gmail.com>
    Signed-off-by: Lino Sanfilippo <LinoSanfilipp@gmx.de>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Cc: Mihai Donțu <mihai.dontu@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f722a400afccaa0fac2ff010ba337ba428bd78b
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Tue Oct 2 15:41:23 2012 +0200

    perf: Fix perf_cgroup_switch for sw-events

    commit 95cf59ea72331d0093010543b8951bb43f262cac upstream.

    Jiri reported that he could trigger the WARN_ON_ONCE() in
    perf_cgroup_switch() using sw-events. This is because sw-events share
    a cpuctx with multiple PMUs.

    Use the ->unique_pmu pointer to limit the pmu iteration to unique
    cpuctx instances.

    Reported-and-Tested-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-so7wi2zf3jjzrwcutm2mkz0j@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38770b82bdd3523d92596a0807d3751bb7d25224
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Tue Oct 2 15:38:52 2012 +0200

    perf: Clarify perf_cpu_context::active_pmu usage by renaming it to ::unique_pmu

    commit 3f1f33206c16c7b3839d71372bc2ac3f305aa802 upstream.

    Stephane thought the perf_cpu_context::active_pmu name confusing and
    suggested using 'unique_pmu' instead.

    This pointer is a pointer to a 'random' pmu sharing the cpuctx
    instance, therefore limiting a for_each_pmu loop to those where
    cpuctx->unique_pmu matches the pmu we get a loop over unique cpuctx
    instances.

    Suggested-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-kxyjqpfj2fn9gt7kwu5ag9ks@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e129d3e2ecef34372ccf2f2ea0002e0ec72998e8
Author: Li Zefan <lizefan@huawei.com>
Date:   Mon Feb 18 14:13:35 2013 +0800

    cgroup: fail if monitored file and event_control are in different cgroup

    commit f169007b2773f285e098cb84c74aac0154d65ff7 upstream.

    If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control
    of cgroup B, then we won't get memory usage notification from A but B!

    What's worse, if A and B are in different mount hierarchy, we'll end up
    accessing NULL pointer!

    Disallow this kind of invalid usage.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Weng Meiling <wengmeiling.weng@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a454fd0a92af12ab465b88a25a7089e65eb8420
Author: Sasha Levin <levinsasha928@gmail.com>
Date:   Wed Jan 25 22:16:16 2012 -0500

    SCSI: iscsi: don't hang in endless loop if no targets present

    commit 46a7c17d26967922092f3a8291815ffb20f6cabe upstream.

    iscsi_if_send_reply() may return -ESRCH if there were no targets to send
    data to. Currently we're ignoring this value and looping in attempt to do it
    over and over, which will usually lead in a hung task like this one:

    [ 4920.817298] INFO: task trinity:9074 blocked for more than 120 seconds.
    [ 4920.818527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 4920.819982] trinity         D 0000000000000000  5504  9074   2756 0x00000004
    [ 4920.825374]  ffff880003961a98 0000000000000086 ffff8800001aa000 ffff8800001aa000
    [ 4920.826791]  00000000001d4340 ffff880003961fd8 ffff880003960000 00000000001d4340
    [ 4920.828241]  00000000001d4340 00000000001d4340 ffff880003961fd8 00000000001d4340
    [ 4920.833231]
    [ 4920.833519] Call Trace:
    [ 4920.834010]  [<ffffffff826363fa>] schedule+0x3a/0x50
    [ 4920.834953]  [<ffffffff82634ac9>] __mutex_lock_common+0x209/0x5b0
    [ 4920.836226]  [<ffffffff81af805d>] ? iscsi_if_rx+0x2d/0x990
    [ 4920.837281]  [<ffffffff81053943>] ? sched_clock+0x13/0x20
    [ 4920.838305]  [<ffffffff81af805d>] ? iscsi_if_rx+0x2d/0x990
    [ 4920.839336]  [<ffffffff82634eb0>] mutex_lock_nested+0x40/0x50
    [ 4920.840423]  [<ffffffff81af805d>] iscsi_if_rx+0x2d/0x990
    [ 4920.841434]  [<ffffffff810dffed>] ? sub_preempt_count+0x9d/0xd0
    [ 4920.842548]  [<ffffffff82637bb0>] ? _raw_read_unlock+0x30/0x60
    [ 4920.843666]  [<ffffffff821f71de>] netlink_unicast+0x1ae/0x1f0
    [ 4920.844751]  [<ffffffff821f7997>] netlink_sendmsg+0x227/0x350
    [ 4920.845850]  [<ffffffff821857bd>] ? sock_update_netprioidx+0xdd/0x1b0
    [ 4920.847060]  [<ffffffff82185732>] ? sock_update_netprioidx+0x52/0x1b0
    [ 4920.848276]  [<ffffffff8217f226>] sock_aio_write+0x166/0x180
    [ 4920.849348]  [<ffffffff810dfe41>] ? get_parent_ip+0x11/0x50
    [ 4920.850428]  [<ffffffff811d0d9a>] do_sync_write+0xda/0x120
    [ 4920.851465]  [<ffffffff810dffed>] ? sub_preempt_count+0x9d/0xd0
    [ 4920.852579]  [<ffffffff810dfe41>] ? get_parent_ip+0x11/0x50
    [ 4920.853608]  [<ffffffff81791887>] ? security_file_permission+0x27/0xb0
    [ 4920.854821]  [<ffffffff811d0f4c>] vfs_write+0x16c/0x180
    [ 4920.855781]  [<ffffffff811d104f>] sys_write+0x4f/0xa0
    [ 4920.856798]  [<ffffffff82638e79>] system_call_fastpath+0x16/0x1b
    [ 4920.877487] 1 lock held by trinity/9074:
    [ 4920.878239]  #0:  (rx_queue_mutex){+.+...}, at: [<ffffffff81af805d>] iscsi_if_rx+0x2d/0x990
    [ 4920.880005] Kernel panic - not syncing: hung_task: blocked tasks

    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2864d3c11eced6708234b92186149f70748a85c4
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 27 12:36:01 2013 -0400

    drm/radeon: fix handling of variable sized arrays for router objects

    commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.

    The table has the following format:

    typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT         //usSrcDstTableOffset pointing to this structure
    {
      UCHAR               ucNumberOfSrc;
      USHORT              usSrcObjectID[1];
      UCHAR               ucNumberOfDst;
      USHORT              usDstObjectID[1];
    }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

    usSrcObjectID[] and usDstObjectID[] are variably sized, so we
    can't access them directly.  Use pointers and update the offset
    appropriately when accessing the Dst members.

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

commit d8dcb2c6f47bab3dfd8059e58a3641b37ca70c30
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 26 17:52:12 2013 -0400

    drm/radeon: fix resume on some rs4xx boards (v2)

    commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream.

    Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
    some boards on resume.  The systems seem to work fine
    without touching this bit so leave it as is.

    v2: read-modify-write the GART_INDEX_REG_EN bit.
    I suspect the problem is that we are losing the other
    settings in the register.

    fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=52952

    Reported-by: Ondrej Zary <linux@rainbow-software.org>
    Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea0f1f563576a598112cd64308ddb461379d85a9
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 19 11:06:50 2013 -0400

    drm/radeon: update line buffer allocation for dce4.1/5

    commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.

    We need to allocate line buffer to each display when
    setting up the watermarks.  Failure to do so can lead
    to a blank screen.  This fixes blank screen problems
    on dce4.1/5 asics.

    Based on an initial fix from:
    Jay Cornwall <jay.cornwall@amd.com>

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

commit 3df0155c467f982d4c06078b74d042d7a5c2a743
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 20 14:59:01 2013 -0400

    drm/radeon: fix LCD record parsing

    commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream.

    If the LCD table contains an EDID record, properly account
    for the edid size when walking through the records.

    This should fix error messages about unknown LCD records.

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

commit 69e5a58ed3cdfa6a4a708f6f00ec0ee79e2fe6cd
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 11 21:56:51 2013 +0200

    HID: zeroplus: validate output report details

    commit 78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream.

    The zeroplus HID driver was not checking the size of allocated values
    in fields it used. A HID device could send a malicious output report
    that would cause the driver to write beyond the output report allocation
    during initialization, causing a heap overflow:

    [ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005
    ...
    [ 1466.243173] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2889

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7247e66f07168b28410549634ea5d29a84602f81
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 11 21:56:50 2013 +0200

    HID: provide a helper for validating hid reports

    commit 331415ff16a12147d57d5c953f3a961b7ede348b upstream.

    Many drivers need to validate the characteristics of their HID report
    during initialization to avoid misusing the reports. This adds a common
    helper to perform validation of the report exisitng, the field existing,
    and the expected number of values within the field.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d46f78f18ccd208c5325357bfe108f5e02044b6b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Aug 26 15:18:53 2013 +0200

    rt2800: fix wrong TX power compensation

    commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream.

    We should not do temperature compensation on devices without
    EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver).
    Such devices can have totally bogus TSSI parameters on the EEPROM,
    but still threaded by us as valid and result doing wrong TX power
    calculations.

    This fix inability to connect to AP on slightly longer distance on
    some Ralink chips/devices.

    Reported-and-tested-by: Fabien ADAM <id2ndr@crocobox.org>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43423691a01dcee991ba1cf4111bb82b2aa0e677
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Mon Sep 16 11:47:50 2013 +0200

    net: usb: cdc_ether: Use wwan interface for Telit modules

    commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream.

    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Acked-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88d1fdb41513e68a6a11d1ee8c2d23ef9fdf63a5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 27 08:34:49 2013 -0700

    Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()"

    This reverts commit b23270416da409bd4e637a5acbe31a1126235fb6 which is
    commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec.

    Michal writes:
        Mainline commit f6e80abe was introduced in v3.7-rc2 as a
        follow-up fix to commit

          edfee033  sctp: check src addr when processing SACK to update transport state

        (from v3.7-rc1) which changed the interpretation of third
        argument to sctp_cmd_process_sack() and sctp_outq_sack(). But as
        commit edfee033 has never been backported to stable branches,
        backport of commit f6e80abe actually breaks the code rather than
        fixing it.

    Reported-by: Michal Kubecek <mkubecek@suse.cz>
    Cc: Zijie Pan <zijie.pan@6wind.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Cc: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.99

commit 5b31202a3604ef905d0433402aaf8aadf4660774
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 5 07:00:59 2013 -0700

    Linux 3.0.99

commit 2e4e7cb96933d2c9794125b038bd9ea9cba9bcfc
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 12 15:24:40 2012 +0200

    splice: fix racy pipe->buffers uses

    commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream.

    Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
    by splice_shrink_spd() called from vmsplice_to_pipe()

    commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes)
    added capability to adjust pipe->buffers.

    Problem is some paths don't hold pipe mutex and assume pipe->buffers
    doesn't change for their duration.

    Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
    use it in place of pipe->buffers where appropriate.

    splice_shrink_spd() loses its struct pipe_inode_info argument.

    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tom Herbert <therbert@google.com>
    Cc: stable <stable@vger.kernel.org> # 2.6.35
    Tested-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96ec909de79e2cc422126fdeb427fe8d0ffb4b95
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Thu Jan 26 06:08:41 2012 -0500

    hwmon: (applesmc) Silence uninitialized warnings

    commit 0fc86eca1b338d06ec500b34ef7def79c32b602b upstream.

    Some error paths do not set a result, leading to the (false)
    assumption that the value may be used uninitialized. Set results for
    those paths as well.

    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c7268325e30ecb4767b9c080e8cec9c92d6689
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Thu Sep 26 08:33:16 2013 +0200

    hwmon: (applesmc) Check key count before proceeding

    commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.

    After reports from Chris and Josh Boyer of a rare crash in applesmc,
    Guenter pointed at the initialization problem fixed below. The patch
    has not been verified to fix the crash, but should be applied
    regardless.

    Reported-by: <jwboyer@fedoraproject.org>
    Suggested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0d0e6c36f6d9fdf0df50c4d1877156b7bcff565
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 20 16:42:15 2013 +0300

    drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

    commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.

    There is no clear cut rules or specs for the retry interval, as there
    are many factors that affect overall response time. Increase the
    interval, and even more so on branch devices which may have limited i2c
    bit rates.

    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
    Tested-by: Nicolas Suzor <nic@suzor.com>
    Reviewed-by: Todd Previte <tprevite@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f6014d357c7884e176c9d78c321ded23bdbd985
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Sep 18 19:40:42 2013 -0400

    dm-snapshot: fix performance degradation due to small hash size

    commit 60e356f381954d79088d0455e357db48cfdd6857 upstream.

    LVM2, since version 2.02.96, creates origin with zero size, then loads
    the snapshot driver and then loads the origin.  Consequently, the
    snapshot driver sees the origin size zero and sets the hash size to the
    lower bound 64.  Such small hash table causes performance degradation.

    This patch changes it so that the hash size is determined by the size of
    snapshot volume, not minimum of origin and snapshot size.  It doesn't
    make sense to set the snapshot size significantly larger than the origin
    size, so we do not need to take origin size into account when
    calculating the hash size.

    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 434b9ee66a512e9b91b9e1687b8183cd48a353fb
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Sep 18 19:14:22 2013 -0400

    dm snapshot: workaround for a false positive lockdep warning

    commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream.

    The kernel reports a lockdep warning if a snapshot is invalidated because
    it runs out of space.

    The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87
    ("workqueue: Catch more locking problems with flush_work()") in v3.5.

    The warning is false positive.  The real cause for the warning is that
    the lockdep engine treats different instances of md->lock as a single
    lock.

    This patch is a workaround - we use flush_workqueue instead of flush_work.
    This code path is not performance sensitive (it is called only on
    initialization or invalidation), thus it doesn't matter that we flush the
    whole workqueue.

    The real fix for the problem would be to teach the lockdep engine to treat
    different instances of md->lock as separate locks.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c61d8a1d51e6f701ee17af5fa33bdeefaa02b75
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Sep 24 14:13:48 2013 +0200

    usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit

    commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.

    Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
    [1] with the Windows App (EasyNote) works natively but fails when
    Windows is running under KVM (and the USB device handed to KVM).

    The reason is a USB control message
     usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
    This goes to endpoint address 0x01 (wIndex); however, endpoint address
    0x01 does not exist. There is an endpoint 0x81 though (same number,
    but other direction); the app may have meant that endpoint instead.

    The kernel thus rejects the IO and thus we see the failure.

    Apparently, Linux is more strict here than Windows ... we can't change
    the Win app easily, so that's a problem.

    It seems that the Win app/driver is buggy here and the driver does not
    behave fully according to the USB HID class spec that it claims to
    belong to.  The device seems to happily deal with that though (and
    seems to not really care about this value much).

    So the question is whether the Linux kernel should filter here.
    Rejecting has the risk that somewhat non-compliant userspace apps/
    drivers (most likely in a virtual machine) are prevented from working.
    Not rejecting has the risk of confusing an overly sensitive device with
    such a transfer. Given the fact that Windows does not filter it makes
    this risk rather small though.

    The patch makes the kernel more tolerant: If the endpoint address in
    wIndex does not exist, but an endpoint with toggled direction bit does,
    it will let the transfer through. (It does NOT change the message.)

    With attached patch, the app in Windows in KVM works.
     usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81

    I suspect this will mostly affect apps in virtual environments; as on
    Linux the apps would have been adapted to the stricter handling of the
    kernel. I have done that for mine[2].

    [1] http://www.pegatech.com/
    [2] https://sourceforge.net/projects/notetakerpen/

    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314bb48ec028ae62cec4a1371cdd84b672d5a759
Author: Florian Wolter <wolly84@web.de>
Date:   Wed Aug 14 10:33:16 2013 +0200

    xhci: Fix race between ep halt and URB cancellation

    commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.

    The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
    user process, because the stopped_td variable was overwritten in the
    handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
    refuse the reset and communication with device can not run over this endpoint.
    https://bugzilla.kernel.org/show_bug.cgi?id=60699

    Signed-off-by: Florian Wolter <wolly84@web.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a86384dbc0bf86e10301eb8eaafb9d49c90e3183
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Sep 5 11:01:20 2013 +0300

    xhci: Fix oops happening after address device timeout

    commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream.

    When a command times out, the command ring is first aborted,
    and then stopped. If the command ring is empty when it is stopped
    the stop event will point to next command which is not yet set.
    xHCI tries to handle this next event often causing an oops.

    Don't handle command completion events on stopped cmd ring if ring is
    empty.

    This patch should be backported to kernels as old as 3.7, that contain
    the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
    command ring function"

    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Reported-by: Giovanni <giovanni.nervi@yahoo.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79e1fc8a531ebe5da1078d765fadf6662edad612
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Sun Sep 22 19:48:54 2013 +0100

    staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier.

    commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream.

    The vt6656 is prone to resetting on the usb bus.

    It seems there is a race condition and wpa supplicant is
    trying to open the device via iw_handlers before its actually
    closed at a stage that the buffers are being removed.

    The device is longer considered open when the
    buffers are being removed. So move ~DEVICE_FLAGS_OPENED
    flag to before freeing the device buffers.

    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8cf7dd6baa2ac1817ab4a8ef92f2b6791254870
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Thu Apr 18 07:51:34 2013 -0700

    x86, efi: Don't map Boot Services on i386

    commit 700870119f49084da004ab588ea2b799689efaf7 upstream.

    Add patch to fix 32bit EFI service mapping (rhbz 726701)

    Multiple people are reporting hitting the following WARNING on i386,

      WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
      Modules linked in:
      Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
      Call Trace:
       [<c102b6af>] warn_slowpath_common+0x5f/0x80
       [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
       [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
       [<c102b6ed>] warn_slowpath_null+0x1d/0x20
       [<c1023fb3>] __ioremap_caller+0x3d3/0x440
       [<c106007b>] ? get_usage_chars+0xfb/0x110
       [<c102d937>] ? vprintk_emit+0x147/0x480
       [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
       [<c102406a>] ioremap_cache+0x1a/0x20
       [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
       [<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
       [<c1407984>] start_kernel+0x286/0x2f4
       [<c1407535>] ? repair_env_string+0x51/0x51
       [<c1407362>] i386_start_kernel+0x12c/0x12f

    Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
    boot service code until after switching to virtual mode") EFI Boot
    Service regions are mapped for a period during boot. Unfortunately, with
    the limited size of the i386 direct kernel map it's possible that some
    of the Boot Service regions will not be directly accessible, which
    causes them to be ioremap()'d, triggering the above warning as the
    regions are marked as E820_RAM in the e820 memmap.

    There are currently only two situations where we need to map EFI Boot
    Service regions,

      1. To workaround the firmware bug described in 916f676f8
      2. To access the ACPI BGRT image

    but since we haven't seen an i386 implementation that requires either,
    this simple fix should suffice for now.

    [ Added to changelog - Matt ]

    Reported-by: Bryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
    Acked-by: Tom Zanussi <tom.zanussi@intel.com>
    Acked-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58f5bc0c124fb8338e91c8a4110ad64259632dd9
Author: Masoud Sharbiani <msharbiani@twitter.com>
Date:   Fri Sep 20 15:59:07 2013 -0700

    x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically

    commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream.

    Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.

    Signed-off-by: Masoud Sharbiani <msharbiani@twitter.com>
    Signed-off-by: Vinson Lee <vlee@twitter.com>
    Cc: Robin Holt <holt@sgi.com>
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.100

commit dccc509a2c4ddf1568a4a6f3e8d4406270fb5307
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 13 15:07:28 2013 -0700

    Linux 3.0.100

commit fd819bdaa91422cf6b568bb76c40d0e5d8fbddaf
Author: Olaf Hering <olaf@aepfle.de>
Date:   Thu May 31 16:40:06 2012 +0200

    Tools: hv: verify origin of netlink connector message

    commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.

    The SuSE security team suggested to use recvfrom instead of recv to be
    certain that the connector message is originated from kernel.

    CVE-2012-2669

    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Marcus Meissner <meissner@suse.de>
    Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7b3c1a8576716d825c73ac1739b2b3f0d7226dcf
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Mar 27 06:40:50 2013 +0000

    tg3: fix length overflow in VPD firmware parsing

    commit 715230a44310a8cf66fbfb5a46f9a62a9b2de424 upstream.

    Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
    when present") introduced VPD parsing that contained a potential length
    overflow.

    Limit the hardware's reported firmware string length (max 255 bytes) to
    stay inside the driver's firmware string length (32 bytes). On overflow,
    truncate the formatted firmware string instead of potentially overwriting
    portions of the tg3 struct.

    http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf

    -js: This fixes CVE-2013-1929.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Oded Horovitz <oded@privatecore.com>
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: stable@vger.kernel.org
    Cc: Matt Carlson <mcarlson@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ac3a550f14a5b4a24417097cd6abcb8c79a0d5a
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Dec 27 01:42:50 2012 -0500

    ext4: avoid hang when mounting non-journal filesystems with orphan list

    commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream.

    When trying to mount a file system which does not contain a journal,
    but which does have a orphan list containing an inode which needs to
    be truncated, the mount call with hang forever in
    ext4_orphan_cleanup() because ext4_orphan_del() will return
    immediately without removing the inode from the orphan list, leading
    to an uninterruptible loop in kernel code which will busy out one of
    the CPU's on the system.

    This can be trivially reproduced by trying to mount the file system
    found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
    source tree.  If a malicious user were to put this on a USB stick, and
    mount it on a Linux desktop which has automatic mounts enabled, this
    could be considered a potential denial of service attack.  (Not a big
    deal in practice, but professional paranoids worry about such things,
    and have even been known to allocate CVE numbers for such problems.)

    -js: This is a fix for CVE-2013-2015.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3609e1162ce723d3269924e95f2663d8bd72a537
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Tue Jul 30 16:30:30 2013 -0400

    Btrfs: change how we queue blocks for backref checking

    commit b6c60c8018c4e9beb2f83fc82c09f9d033766571 upstream.

    Previously we only added blocks to the list to have their backrefs checked if
    the level of the block is right above the one we are searching for.  This is
    because we want to make sure we don't add the entire path up to the root to the
    lists to make sure we process things one at a time.  This assumes that if any
    blocks in the path to the root are going to be not checked (shared in other
    words) then they will be in the level right above the current block on up.  This
    isn't quite right though since we can have blocks higher up the list that are
    shared because they are attached to a reloc root.  But we won't add this block
    to be checked and then later on we will BUG_ON(!upper->checked).  So instead
    keep track of wether or not we've queued a block to be checked in this current
    search, and if we haven't go ahead and queue it to be checked.  This patch fixed
    the panic I was seeing where we BUG_ON(!upper->checked).  Thanks,

    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9f1434b8e47776e2b6d42a5556516209f5ba3ae
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Thu Sep 26 13:24:53 2013 -0400

    tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT

    commit f862eefec0b68e099a9fa58d3761ffb10bad97e1 upstream.

    It turns out the kernel relies on barrier() to force a reload of the
    percpu offset value.  Since we can't easily modify the definition of
    barrier() to include "tp" as an output register, we instead provide a
    definition of __my_cpu_offset as extended assembly that includes a fake
    stack read to hazard against barrier(), forcing gcc to know that it
    must reread "tp" and recompute anything based on "tp" after a barrier.

    This fixes observed hangs in the slub allocator when we are looping
    on a percpu cmpxchg_double.

    A similar fix for ARMv7 was made in June in change 509eb76ebf97.

    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a3fdb8cfff87da926b868c3263a8a51c02af47
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Fri Sep 13 13:13:23 2013 +0800

    ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()

    commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.

    This patch fixes the issues indicated by the test results that
    ipmi_msg_handler() is invoked in atomic context.

    BUG: scheduling while atomic: kipmi0/18933/0x10000100
    Modules linked in: ipmi_si acpi_ipmi ...
    CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
    Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
     ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
     ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
     0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
    Call Trace:
     <IRQ>  [<ffffffff814c4a1e>] dump_stack+0x19/0x1b
     [<ffffffff814bfbab>] __schedule_bug+0x46/0x54
     [<ffffffff814c73e0>] __schedule+0x83/0x59c
     [<ffffffff81058853>] __cond_resched+0x22/0x2d
     [<ffffffff814c794b>] _cond_resched+0x14/0x1d
     [<ffffffff814c6d82>] mutex_lock+0x11/0x32
     [<ffffffff8101e1e9>] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
     [<ffffffffa09e3f9c>] ipmi_msg_handler+0x23/0x166 [ipmi_si]
     [<ffffffff812bf6e4>] deliver_response+0x55/0x5a
     [<ffffffff812c0fd4>] handle_new_recv_msgs+0xb67/0xc65
     [<ffffffff81007ad1>] ? read_tsc+0x9/0x19
     [<ffffffff814c8620>] ? _raw_spin_lock_irq+0xa/0xc
     [<ffffffffa09e1128>] ipmi_thread+0x5c/0x146 [ipmi_si]
     ...

    Also Tony Camuso says:

     We were getting occasional "Scheduling while atomic" call traces
     during boot on some systems. Problem was first seen on a Cisco C210
     but we were able to reproduce it on a Cisco c220m3. Setting
     CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
     tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.

     =================================
     [ INFO: inconsistent lock state ]
     2.6.32-415.el6.x86_64-debug-splck #1
     ---------------------------------
     inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
     ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
      (&ipmi_device->tx_msg_lock){+.?...}, at: [<ffffffff81337a27>] ipmi_msg_handler+0x71/0x126
     {SOFTIRQ-ON-W} state was registered at:
       [<ffffffff810ba11c>] __lock_acquire+0x63c/0x1570
       [<ffffffff810bb0f4>] lock_acquire+0xa4/0x120
       [<ffffffff815581cc>] __mutex_lock_common+0x4c/0x400
       [<ffffffff815586ea>] mutex_lock_nested+0x4a/0x60
       [<ffffffff8133789d>] acpi_ipmi_space_handler+0x11b/0x234
       [<ffffffff81321c62>] acpi_ev_address_space_dispatch+0x170/0x1be

    The fix implemented by this change has been tested by Tony:

     Tested the patch in a boot loop with lockdep debug enabled and never
     saw the problem in over 400 reboots.

    Reported-and-tested-by: Tony Camuso <tcamuso@redhat.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Reviewed-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c724d4f0439a7af388de3929d80a933137168db5
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Thu Oct 10 10:53:46 2013 +0100

    staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice

    commit 677a31565692d596ef42ea589b53ba289abf4713 upstream.

    The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
    currently writes (optionally) and reads back up to 5 "ports" consisting
    of 8 channels each.  It reads up to 32 1-bit channels but can only read
    and write a whole port at once - it needs to handle up to 5 ports as the
    first channel it reads might not be aligned on a port boundary.  It
    breaks out of the loop early if the next port it handles is beyond the
    final port on the card.  It also breaks out early on the 5th port in the
    loop if the first channel was aligned.  Unfortunately, it doesn't check
    that the current port it is dealing with belongs to the comedi subdevice
    the `insn_bits` handler is acting on.  That's a bug.

    Redo the `for` loop to terminate after the final port belonging to the
    subdevice, changing the loop variable in the process to simplify things
    a bit.  The `for` loop could now try and handle more than 5 ports if the
    subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
    ensures it will break out early after 4 or 5 ports (depending on whether
    the first channel is aligned on a port boundary).  (`bitshift` will be
    between -7 and 7 inclusive on the first iteration, increasing by 8 for
    each subsequent operation.)

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e0e2535ad3cdcd6e17d11ac52b5fb6487679e6c
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Tue Sep 24 21:56:46 2013 +0200

    p54usb: add USB ID for Corega WLUSB2GTST USB adapter

    commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.

    Added USB ID for Corega WLUSB2GTST USB adapter.

    Reported-by: Joerg Kalisch <the_force@gmx.de>
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3f0cca5d5a167a7e154a7e4065f7e858539df4c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Sep 18 21:21:35 2013 -0500

    rtlwifi: Align private space in rtl_priv struct

    commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream.

    The private array at the end of the rtl_priv struct is not aligned.
    On ARM architecture, this causes an alignment trap and is fixed by aligning
    that array with __align(sizeof(void *)). That should properly align that
    space according to the requirements of all architectures.

    Reported-by: Jason Andrews <jasona@cadence.com>
    Tested-by: Jason Andrews <jasona@cadence.com>
    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 6a89ff9ebd1f81f6449b4c3c7a5e8861a0a6edf1
Author: Michal Malý <madcatxster@prifuk.cz>
Date:   Sat Sep 28 19:50:27 2013 +0200

    USB: serial: option: Ignore card reader interface on Huawei E1750

    commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream.

    Hi,

    my Huawei 3G modem has an embedded Smart Card reader which causes
    trouble when the modem is being detected (a bunch of "<warn>  (ttyUSBx):
    open blocked by driver for more than 7 seconds!" in messages.log). This
    trivial patch corrects the problem for me. The modem identifies itself
    as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
    description on the body says "Model E173u-1"

    Signed-off-by: Michal Malý <madcatxster@prifuk.cz>
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5391cb09f10c98af52458b4fd6e331a6465797f7
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Jul 26 01:17:15 2013 +0400

    sparc32: Fix exit flag passed from traced sys_sigreturn

    [ Upstream commit 7a3b0f89e3fea680f93932691ca41a68eee7ab5e ]

    Pass 1 in %o1 to indicate that syscall_trace accounts exit.

    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee0ab40d6810a03cbd74715889dad558c5f9f02d
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Jul 26 17:21:12 2013 +0400

    sparc64: Fix not SRA'ed %o5 in 32-bit traced syscall

    [ Upstream commit ab2abda6377723e0d5fbbfe5f5aa16a5523344d1 ]

    (From v1 to v2: changed comment)

    On the way linux_sparc_syscall32->linux_syscall_trace32->goto 2f,
    register %o5 doesn't clear its second 32-bit.

    Fix that.

    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6114d1d56548014e6f5323d8c71e9de61486786
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 22 16:38:46 2013 -0700

    sparc64: Fix off by one in trampoline TLB mapping installation loop.

    [ Upstream commit 63d499662aeec1864ec36d042aca8184ea6a938e ]

    Reported-by: Kirill Tkhai <tkhai@yandex.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca0bd2082f83ccf6abbb2db2e4475bb81b415118
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Mon Aug 12 16:02:24 2013 +0400

    sparc64: Remove RWSEM export leftovers

    [ Upstream commit 61d9b9355b0d427bd1e732bd54628ff9103e496f ]

    The functions

                __down_read
                __down_read_trylock
                __down_write
                __down_write_trylock
                __up_read
                __up_write
                __downgrade_write

    are implemented inline, so remove corresponding EXPORT_SYMBOLs
    (They lead to compile errors on RT kernel).

    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8107520ccf6a1f88d2139ba99e831ca8eeca8a77
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Aug 2 19:23:18 2013 +0400

    sparc64: Fix ITLB handler of null page

    [ Upstream commit 1c2696cdaad84580545a2e9c0879ff597880b1a9 ]

    1)Use kvmap_itlb_longpath instead of kvmap_dtlb_longpath.

    2)Handle page #0 only, don't handle page #1: bleu -> blu

     (KERNBASE is 0x400000, so #1 does not exist too. But everything
      is possible in the future. Fix to not to have problems later.)

    3)Remove unused kvmap_itlb_nonlinear.

    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffc8f511cbea2ff61941c26a243c70136994094d
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 1 18:08:34 2013 -0700

    esp_scsi: Fix tag state corruption when autosensing.

    [ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ]

    Meelis Roos reports a crash in esp_free_lun_tag() in the presense
    of a disk which has died.

    The issue is that when we issue an autosense command, we do so by
    hijacking the original command that caused the check-condition.

    When we do so we clear out the ent->tag[] array when we issue it via
    find_and_prep_issuable_command().  This is so that the autosense
    command is forced to be issued non-tagged.

    That is problematic, because it is the value of ent->tag[] which
    determines whether we issued the original scsi command as tagged
    vs. non-tagged (see esp_alloc_lun_tag()).

    And that, in turn, is what trips up the sanity checks in
    esp_free_lun_tag().  That function needs the original ->tag[] values
    in order to free up the tag slot properly.

    Fix this by remembering the original command's tag values, and
    having esp_alloc_lun_tag() and esp_free_lun_tag() use them.

    Reported-by: Meelis Roos <mroos@linux.ee>
    Tested-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a821af3f7d73022d45550200241e6e671127ec81
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 16:54:05 2013 +1000

    powerpc: Fix parameter clobber in csum_partial_copy_generic()

    commit d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream.

    The csum_partial_copy_generic() uses register r7 to adjust the remaining
    bytes to process.  Unfortunately, r7 also holds a parameter, namely the
    address of the flag to set in case of access exceptions while reading
    the source buffer.  Lacking a quantum implementation of PowerPC, this
    commit instead uses register r9 to do the adjusting, leaving r7's
    pointer uncorrupted.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    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 46779b3c9f75cb80573a1ceb82b16b831bfb349c
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Sep 23 09:33:36 2013 -0400

    powerpc/vio: Fix modalias_show return values

    commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 upstream.

    modalias_show() should return an empty string on error, not -ENODEV.

    This causes the following false and annoying error:

    > find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
    cat: /sys/devices/vio/4000/modalias: No such device
    cat: /sys/devices/vio/4001/modalias: No such device
    cat: /sys/devices/vio/4002/modalias: No such device
    cat: /sys/devices/vio/4004/modalias: No such device
    cat: /sys/devices/vio/modalias: No such device

    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4067bddb238b1f8d91add21ea38ae2cd32c1acac
Author: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Date:   Tue Oct 1 14:04:53 2013 -0700

    powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table()

    commit 1cf389df090194a0976dc867b7fffe99d9d490cb upstream.

    Under heavy (DLPAR?) stress, we tripped this panic() in
    arch/powerpc/kernel/iommu.c::iommu_init_table():

        page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
        if (!page)
            panic("iommu_init_table: Can't allocate %ld bytes\n", sz);

    Before the panic() we got a page allocation failure for an order-2
    allocation. There appears to be memory free, but perhaps not in the
    ATOMIC context. I looked through all the call-sites of
    iommu_init_table() and didn't see any obvious reason to need an ATOMIC
    allocation. Most call-sites in fact have an explicit GFP_KERNEL
    allocation shortly before the call to iommu_init_table(), indicating we
    are not in an atomic context. There is some indirection for some paths,
    but I didn't see any locks indicating that GFP_KERNEL is inappropriate.

    With this change under the same conditions, we have not been able to
    reproduce the panic.

    Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4de33238bdb4664288000a1a5592fd1f3a1455b7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 13 10:52:49 2013 +0300

    ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st()

    commit d967967e8d1116fb38bad25e58714b5dddd03cca upstream.

    This is called from snd_ctl_elem_write() with user supplied data so we
    need to add some bounds checking.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7abc25bd4142a45bbcd90281a1869850a922876
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 13 10:52:14 2013 +0300

    ASoC: max98095: a couple array underflows

    commit f8d7b13e14357ed19d2ca2799539600418dc3939 upstream.

    The ->put() function are called from snd_ctl_elem_write() with user
    supplied data.  The limit checks here could underflow leading to a
    crash.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67a8bceeb8f58b365104b0b35285205bff488727
Author: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Date:   Tue Oct 1 08:17:10 2013 +0200

    ll_temac: Reset dma descriptors indexes on ndo_open

    [ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]

    The dma descriptors indexes are only initialized on the probe function.

    If a packet is on the buffer when temac_stop is called, the dma
    descriptors indexes can be left on a incorrect state where no other
    package can be sent.

    So an interface could be left in an usable state after ifdow/ifup.

    This patch makes sure that the descriptors indexes are in a proper
    status when the device is open.

    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbe48e5b8c4f5f3096102d98cc53441178e67aa2
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Fri Sep 27 12:22:15 2013 -0400

    bonding: Fix broken promiscuity reference counting issue

    [ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ]

    Recently grabbed this report:
    https://bugzilla.redhat.com/show_bug.cgi?id=1005567

    Of an issue in which the bonding driver, with an attached vlan encountered the
    following errors when bond0 was taken down and back up:

    dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
    device might be broken.

    The error occurs because, during __bond_release_one, if we release our last
    slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
    notification.  With an attached vlan, the vlan may see that the vlan and bond
    mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
    and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
    we complete __bond_release_one, we use the current state of the bond flags to
    determine if we should decrement the promiscuity of the releasing slave.  But
    since the bond changed promiscuity state during the release operation, we
    incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
    to begin with, causing the above error

    Fix is pretty simple, just cache the bonding flags at the start of the function
    and use those when determining the need to set promiscuity.

    This is also needed for the ALLMULTI flag

    Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>
    CC: Jay Vosburgh <fubar@us.ibm.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: Mark Wu <wudxw@linux.vnet.ibm.com>
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edd423cc3e80c43ca95c8a8ad292dc1f29d8a936
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Sep 30 23:28:20 2013 +0200

    dm9601: fix IFF_ALLMULTI handling

    [ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ]

    Pass-all-multicast is controlled by bit 3 in RX control, not bit 2
    (pass undersized frames).

    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 6838208d0662ff90eab0df3e36c481644083e888
Author: Roger Luethi <rl@hellgate.ch>
Date:   Sat Sep 21 14:24:11 2013 +0200

    via-rhine: fix VLAN priority field (PCP, IEEE 802.1p)

    [ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ]

    Outgoing packets sent by via-rhine have their VLAN PCP field off by one
    (when hardware acceleration is enabled). The TX descriptor expects only VID
    and PCP (without a CFI/DEI bit).

    Peter Boström noticed and reported the bug.

    Signed-off-by: Roger Luethi <rl@hellgate.ch>
    Cc: Peter Boström <peter.bostrom@netrounds.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daf468318a3a1548bf5cf8b1be493af104f5868f
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Sat Sep 21 06:27:00 2013 +0200

    ipv6: udp packets following an UFO enqueued packet need also be handled by UFO

    [ Upstream commit 2811ebac2521ceac84f2bdae402455baa6a7fb47 ]

    In the following scenario the socket is corked:
    If the first UDP packet is larger then the mtu we try to append it to the
    write queue via ip6_ufo_append_data. A following packet, which is smaller
    than the mtu would be appended to the already queued up gso-skb via
    plain ip6_append_data. This causes random memory corruptions.

    In ip6_ufo_append_data we also have to be careful to not queue up the
    same skb multiple times. So setup the gso frame only when no first skb
    is available.

    This also fixes a shortcoming where we add the current packet's length to
    cork->length but return early because of a packet > mtu with dontfrag set
    (instead of sutracting it again).

    Found with trinity.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9092e91e01a1f1902c24d1d55cad8a472c282d0
Author: Salam Noureddine <noureddine@aristanetworks.com>
Date:   Sun Sep 29 13:39:42 2013 -0700

    ipv4 igmp: use in_dev_put in timer handlers instead of __in_dev_put

    [ Upstream commit e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ]

    It is possible for the timer handlers to run after the call to
    ip_mc_down so use in_dev_put instead of __in_dev_put in the handler
    function in order to do proper cleanup when the refcnt reaches 0.
    Otherwise, the refcnt can reach zero without the in_device being
    destroyed and we end up leaking a reference to the net_device and
    see messages like the following,

    unregister_netdevice: waiting for eth0 to become free. Usage count = 1

    Tested on linux-3.4.43.

    Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8964c6487cf14fa5f00cedceab256b9aaab69acc
Author: Salam Noureddine <noureddine@aristanetworks.com>
Date:   Sun Sep 29 13:41:34 2013 -0700

    ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put

    [ Upstream commit 9260d3e1013701aa814d10c8fc6a9f92bd17d643 ]

    It is possible for the timer handlers to run after the call to
    ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the
    handler function in order to do proper cleanup when the refcnt
    reaches 0. Otherwise, the refcnt can reach zero without the
    inet6_dev being destroyed and we end up leaking a reference to
    the net_device and see messages like the following,

    unregister_netdevice: waiting for eth0 to become free. Usage count = 1

    Tested on linux-3.4.43.

    Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a6a2791b1e6ebd7ad29f137a309471f92d71c55
Author: Ansis Atteka <aatteka@nicira.com>
Date:   Wed Sep 18 15:29:53 2013 -0700

    ip: generate unique IP identificator if local fragmentation is allowed

    [ Upstream commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 ]

    If local fragmentation is allowed, then ip_select_ident() and
    ip_select_ident_more() need to generate unique IDs to ensure
    correct defragmentation on the peer.

    For example, if IPsec (tunnel mode) has to encrypt large skbs
    that have local_df bit set, then all IP fragments that belonged
    to different ESP datagrams would have used the same identificator.
    If one of these IP fragments would get lost or reordered, then
    peer could possibly stitch together wrong IP fragments that did
    not belong to the same datagram. This would lead to a packet loss
    or data corruption.

    Signed-off-by: Ansis Atteka <aatteka@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20218d3d355cb32bdf1d737438958aa75f6ab21a
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Sep 12 17:12:05 2013 +1000

    bridge: Clamp forward_delay when enabling STP

    [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]

    At some point limits were added to forward_delay.  However, the
    limits are only enforced when STP is enabled.  This created a
    scenario where you could have a value outside the allowed range
    while STP is disabled, which then stuck around even after STP
    is enabled.

    This patch fixes this by clamping the value when we enable STP.

    I had to move the locking around a bit to ensure that there is
    no window where someone could insert a value outside the range
    while we're in the middle of enabling STP.

    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9f7cfdfc708c1c323e7e02e3ba067ddc96b671
Author: Chris Healy <cphealy@gmail.com>
Date:   Wed Sep 11 21:37:47 2013 -0700

    resubmit bridge: fix message_age_timer calculation

    [ Upstream commit 9a0620133ccce9dd35c00a96405c8d80938c2cc0 ]

    This changes the message_age_timer calculation to use the BPDU's max age as
    opposed to the local bridge's max age.  This is in accordance with section
    8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification.

    With the current implementation, when running with very large bridge
    diameters, convergance will not always occur even if a root bridge is
    configured to have a longer max age.

    Tested successfully on bridge diameters of ~200.

    Signed-off-by: Chris Healy <cphealy@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 956c741a9eef6a4e7a6755062d4afc1e686a1c5d
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Sep 11 16:58:36 2013 +0200

    net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit

    [ Upstream commit 95ee62083cb6453e056562d91f597552021e6ae7 ]

    Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
    being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
    does not seem to have the desired effect:

    SCTP + IPv4:

      22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
        192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
      22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
        192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):

    SCTP + IPv6:

      22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
        fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
        1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]

    Moreover, Alan says:

      This problem was seen with both Racoon and Racoon2. Other people have seen
      this with OpenSwan. When IPsec is configured to encrypt all upper layer
      protocols the SCTP connection does not initialize. After using Wireshark to
      follow packets, this is because the SCTP packet leaves Box A unencrypted and
      Box B believes all upper layer protocols are to be encrypted so it drops
      this packet, causing the SCTP connection to fail to initialize. When IPsec
      is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.

    In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
    string on the other end, results in cleartext on the wire where SCTP eventually
    does not report any errors, thus in the latter case that Alan reports, the
    non-paranoid user might think he's communicating over an encrypted transport on
    SCTP although he's not (tcpdump ... -X):

      ...
      0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000  ]p.......}.l....
      0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000  ....plaintext...

    Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
    receiver side. Initial follow-up analysis from Alan's bug report was done by
    Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.

    SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
    This has the implication that it probably never really got updated along with
    changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.

    SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
    a call to inet6_csk_xmit() would solve this problem, but result in unecessary
    route lookups, let us just use the cached flowi6 instead that we got through
    sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
    we do the route lookup / flow caching in sctp_transport_route(), hold it in
    tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
    sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
    of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
    instead to get the correct source routed dst entry, which we assign to the skb.

    Also source address routing example from 625034113 ("sctp: fix sctp to work with
    ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
    it is actually 'recommended' to not use that anyway due to traffic amplification [1].
    So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
    we overwrite the flow destination here, the lower IPv6 layer will be unable to
    put the correct destination address into IP header, as routing header is added in
    ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
    result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
    the wire with this patch it now looks like:

    SCTP + IPv6:

      08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
        AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
      08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
        AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296

    This fixes Kernel Bugzilla 24412. This security issue seems to be present since
    2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
    its fun with that. lksctp-tools IPv6 regression test suite passes as well with
    this patch.

     [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

    Reported-by: Alan Chester <alan.chester@tekelec.com>
    Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6f88d6f41938e39971a5c0fce3aa8d26d3dd9de
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Thu Sep 19 15:02:35 2013 +0200

    netpoll: fix NULL pointer dereference in netpoll_cleanup

    [ Upstream commit d0fe8c888b1fd1a2f84b9962cabcb98a70988aec ]

    I've been hitting a NULL ptr deref while using netconsole because the
    np->dev check and the pointer manipulation in netpoll_cleanup are done
    without rtnl and the following sequence happens when having a netconsole
    over a vlan and we remove the vlan while disabling the netconsole:
        CPU 1                   CPU2
                        removes vlan and calls the notifier
    enters store_enabled(), calls
    netdev_cleanup which checks np->dev
    and then waits for rtnl
                        executes the netconsole netdev
                        release notifier making np->dev
                        == NULL and releases rtnl
    continues to dereference a member of
    np->dev which at this point is == NULL

    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63195262c5555dc90fde66d1be41ab102cf00adb
Author: Dave Jones <davej@redhat.com>
Date:   Thu Sep 5 00:11:19 2013 -0400

    caif: Add missing braces to multiline if in cfctrl_linkup_request

    [ Upstream commit 0c1db731bfcf3a9fd6c58132134f8b0f423552f0 ]

    The indentation here implies this was meant to be a multi-line if.

    Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5
    ("caif: Handle dev_queue_xmit errors.")

    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67ea0764ff204966d8f45b35dd26e939e2377b5a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 24 15:27:45 2013 -0700

    cciss: fix info leak in cciss_ioctl32_passthru()

    commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e upstream.

    The arg64 struct has a hole after ->buf_size which isn't cleared.  Or if
    any of the calls to copy_from_user() fail then that would cause an
    information leak as well.

    This was assigned CVE-2013-2147.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Mike Miller <mike.miller@hp.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 dcad3ae646c253f445658d695f3e1f3ba0f2ac69
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 24 15:27:44 2013 -0700

    cpqarray: fix info leak in ida_locked_ioctl()

    commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a upstream.

    The pciinfo struct has a two byte hole after ->dev_fn so stack
    information could be leaked to the user.

    This was assigned CVE-2013-2147.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Mike Miller <mike.miller@hp.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 00dd675556f5c6a17bcba5f7e47c2552daeed84c
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Sat Jun 15 10:27:19 2013 -0600

    intel-iommu: Fix leaks in pagetable freeing

    commit 3269ee0bd6686baf86630300d528500ac5b516d7 upstream.

    At best the current code only seems to free the leaf pagetables and
    the root.  If you're unlucky enough to have a large gap (like any
    QEMU guest with more than 3G of memory), only the first chunk of leaf
    pagetables are freed (plus the root).  This is a massive memory leak.
    This patch re-writes the pagetable freeing function to use a
    recursive algorithm and manages to not only free all the pagetables,
    but does it without any apparent performance loss versus the current
    broken version.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.101

commit 5dba9ddd98cbc7ad319d687887981a0ea0062c75
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 22 08:58:59 2013 +0100

    Linux 3.0.101

commit 676d438e25b8b1fe251c1d474fab86187dbc6293
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed Nov 23 15:49:31 2011 -0500

    ipv6: tcp: fix panic in SYN processing

    commit c16a98ed91597b40b22b540c6517103497ef8e74 upstream.

    commit 72a3effaf633bc ([NET]: Size listen hash tables using backlog
    hint) added a bug allowing inet6_synq_hash() to return an out of bound
    array index, because of u16 overflow.

    Bug can happen if system admins set net.core.somaxconn &
    net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f11d481f8f81dec26d3370bcf8f4c1f2d53ccefc
Author: wojciech kapuscinski <wojtask9@wp.pl>
Date:   Tue Oct 1 19:54:33 2013 -0400

    drm/radeon: fix hw contexts for SUMO2 asics

    commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.

    They have 4 rather than 8.

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

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

commit 826380d59f09185201d4327121f4919d2914a2cc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 23 11:40:59 2013 +0300

    watchdog: ts72xx_wdt: locking bug in ioctl

    commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.

    Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
    interruptible deadlock.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac008905d50badfe8b695fa3f1eef20ac352e3e6
Author: Helge Deller <deller@gmx.de>
Date:   Tue Oct 1 21:54:46 2013 +0200

    parisc: fix interruption handler to respect pagefault_disable()

    commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.

    Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel.  The
    problem is, that in print_worker_info() we try to read the workqueue info via
    the probe_kernel_read() functions which use pagefault_disable() to avoid
    crashes like this:
        probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
        probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
        probe_kernel_read(name, wq->name, sizeof(name) - 1);

    The problem here is, that the first probe_kernel_read(&pwq) might return zero
    in pwq and as such the following probe_kernel_reads() try to access contents of
    the page zero which is read protected and generate a kernel segfault.

    With this patch we fix the interruption handler to call parisc_terminate()
    directly only if pagefault_disable() was not called (in which case
    preempt_count()==0).  Otherwise we hand over to the pagefault handler which
    will try to look up the faulting address in the fixup tables.

    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 546a50594e6241e2002cddbef7c350e177e08e52
Author: Dave Jones <davej@redhat.com>
Date:   Thu Oct 10 20:05:35 2013 -0400

    ext4: fix memory leak in xattr

    commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.

    If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
    potentionally return from the function without having freed these
    allocations.  If we don't do the return, we over-write the previous
    allocation pointers, so we leak either way.

    Spotted with Coverity.

    [ Fixed by tytso to set is and bs to NULL after freeing these
      pointers, in case in the retry loop we later end up triggering an
      error causing a jump to cleanup, at which point we could have a double
      free bug. -- Ted ]

    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ffc34c0d09a7d36ff84d1ac506a352a06ef5e4e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Sep 30 08:35:10 2013 -0700

    vfs: allow O_PATH file descriptors for fstatfs()

    commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.

    Olga reported that file descriptors opened with O_PATH do not work with
    fstatfs(), found during further development of ksh93's thread support.

    There is no reason to not allow O_PATH file descriptors here (fstatfs is
    very much a path operation), so use "fdget_raw()".  See commit
    55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
    for a very similar issue reported for fstat() by the same team.

    Reported-and-tested-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa759b5d100c8b0d2ec2b83fcac990f2c3ac13b7
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Sep 10 10:52:35 2013 -0400

    random: run random_int_secret_init() run after all late_initcalls

    commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.

    The some platforms (e.g., ARM) initializes their clocks as
    late_initcalls for some unknown reason.  So make sure
    random_int_secret_init() is run after all of the late_initcalls are
    run.

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