Squashed commit 3.4.51 -> 3.4.52
commit 8b5ed99a4f9f2969c47501530da6dcd5a91f8f3d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Oct 26 21:06:14 2013 +0100

    Linux 3.2.52

commit 9203ceb63af1d8a2c1557ff01cbb2d75e960d2ef
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 4 10:52:36 2013 +0200

    can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX

    commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.

    In patch

        0d1862e can: flexcan: fix flexcan_chip_start() on imx6

    the loop in flexcan_chip_start() that iterates over all mailboxes after the
    soft reset of the CAN core was removed. This loop put all mailboxes (even the
    ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
    this aborts any pending TX messages.

    After a cold boot there is random garbage in the mailboxes, which leads to
    spontaneous transmit of CAN frames during first activation. Further if the
    interface was disabled with a pending message (usually due to an error
    condition on the CAN bus), this message is retransmitted after enabling the
    interface again.

    This patch fixes the regression by:
    1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
    FIFO, 8 is used by TX.
    2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
    mailbox is aborted.

    Cc: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2:
     - Adjust context
     - Hardware local echo is still enabled]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c23e05d637c461d13e473bee595ae781622b5ebf
Author: Claudiu Manoil <claudiu.manoil@freescale.com>
Date:   Sun Sep 23 22:39:08 2012 +0000

    gianfar: Change default HW Tx queue scheduling mode

    commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

    This is primarily to address transmission timeout occurrences, when
    multiple H/W Tx queues are being used concurrently. Because in
    the priority scheduling mode the controller does not service the
    Tx queues equally (but in ascending index order), Tx timeouts are
    being triggered rightaway for a basic test with multiple simultaneous
    connections like:
    iperf -c <server_ip> -n 100M -P 8

    resulting in kernel trace:
    NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue <X> timed out
    ------------[ cut here ]------------
    WARNING: at net/sched/sch_generic.c:255
    ...
    and controller reset during intense traffic, and possibly further
    complications.

    This patch changes the default H/W Tx scheduling setting (TXSCHED)
    for multi-queue devices, from priority scheduling mode to a weighted
    round robin mode with equal weights for all H/W Tx queues, and
    addresses the issue above.

    Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c617fda8c72a55a65cc5320cadb916f5981cfeb
Author: David Rientjes <rientjes@google.com>
Date:   Mon Apr 29 15:06:11 2013 -0700

    mm, show_mem: suppress page counts in non-blockable contexts

    commit 4b59e6c4730978679b414a8da61514a2518da512 upstream.

    On large systems with a lot of memory, walking all RAM to determine page
    types may take a half second or even more.

    In non-blockable contexts, the page allocator will emit a page allocation
    failure warning unless __GFP_NOWARN is specified.  In such contexts, irqs
    are typically disabled and such a lengthy delay may even result in NMI
    watchdog timeouts.

    To fix this, suppress the page walk in such contexts when printing the
    page allocation failure warning.

    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dffcc9dc54d22e3c5eadd5d42835fa47ee25b071
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b376352641ccc12b53a3aa555b9a477a8c0f44e
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Oct 2 14:57:51 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>
    [Ian Abbott: This patch applies to kernels 2.6.34.y through to 3.5.y
     inclusive.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0cf9986114ab4e16bf36a51814a0f688c79961a7
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: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c60ce91cc52e53619bb919ad5ff8891b75c2a4dd
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: Ben Hutchings <ben@decadent.org.uk>

commit 47fa3c9b8352d4f403118b01f8a97fff1353c30b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ecc545c9a903910bd23e40b6492d7b4f7ec03bc
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: Ben Hutchings <ben@decadent.org.uk>

commit e1fd636836ca3c883c172dc619a909e988a2f4b5
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: Ben Hutchings <ben@decadent.org.uk>

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

    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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 177c417ca4d861640b35ecf4fcd0f7563543e01f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 17:06:39 2013 +0100

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

    This reverts commit de77b7955c3985ca95f64af3cb10557eb17eacee, which was
    commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec upstream.

    This fix was only appropriate for Linux 3.7 onward, and introduced a
    regression when applied to earlier versions.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b1455ca9e8c44171e550980c82295162e7e31646
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: Ben Hutchings <ben@decadent.org.uk>

commit 04f82ec3a0a5399c17eb2053fa6833de064216b3
Author: Vasily Titskiy <qehgt0@gmail.com>
Date:   Fri Aug 30 18:25:04 2013 -0400

    HID: usbhid: quirk for N-Trig DuoSense Touch Screen

    commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.

    The DuoSense touchscreen device causes a 10 second timeout. This fix
    removes the delay.

    Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 297c511a4b6c6cff190525aec83b0d2de39fc3d8
Author: Stefan Kriwanek <dev@stefankriwanek.de>
Date:   Sun Aug 25 10:46:13 2013 +0200

    HID: Fix Speedlink VAD Cezanne support for some devices

    commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.

    Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
    than already done.

    I made sure through testing that this patch would not interfere with the proper
    working of a device that is bug-free. (The driver drops EV_REL events with
    abs(val) >= 256, which are not achievable even on the highest laser resolution
    hardware setting.)

    Signed-off-by: Stefan Kriwanek <mail@stefankriwanek.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6c756ccc62d4b6168f70fc5a3da5004a5f56751
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ed1d8009cc6f1b534ed94388cb7980b4a55797e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 49a58f5fa9d71155be5b6211030c281084f336a3
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6272221247a80adf0c36bf4f6ac8a4d7dcfb7e5b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31e0470e9906c42edfc4cf00404d4eb3a99dac7e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b
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>

commit 068d848f7f3d3db8c68e517ba93cb170914a64d8
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Jul 18 10:55:16 2013 +0800

    macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

    commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

    We try to linearize part of the skb when the number of iov is greater than
    MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
    one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
    network.

    Solve this problem by calculate the pages needed for iov before trying to do
    zerocopy and switch to use copy instead of zerocopy if it needs more than
    MAX_SKB_FRAGS.

    This is done through introducing a new helper to count the pages for iov, and
    call uarg->callback() manually when switching from zerocopy to copy to notify
    vhost.

    We can do further optimization on top.

    This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
    (macvtap: zerocopy: validate vectors before building skb).

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: callback only takes one argument]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 98ed9120b030962558276d8fd602eabb41a57d05
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 13:37:39 2013 +0100

    Revert "zram: use zram->lock to protect zram_free_page() in swap free notify path"

    This reverts commit 9e443904906ca2b5b3ae71f34ac4a4fa6905623e, which
    was commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.

    Taking the semaphore here leads to sleeping in atomic context.  This
    was fixed in mainline commit a0c516cbfc74 ("zram: don't grab mutex in
    zram_slot_free_noity") but that is too difficult to backport.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f0ce108f5e1c6a443548746b6f01b450f71a407
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon Apr 22 17:12:54 2013 +0000

    powerpc/pseries/lparcfg: Fix possible overflow are more than 1026

    commit 5676005acf26ab7e924a8438ea4746e47d405762 upstream.

    need set '\0' for 'local_buffer'.

    SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
    rtas_data_buf may truncated in memcpy.

    if contents are really truncated.
      the splpar_strlen is more than 1026. the next while loop checking will
      not find the end of buffer. that will cause memory access violation.

    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f362f08b46213452508f76bac4b74a4e5f5c4294
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Jan 5 15:51:13 2012 +1000

    m68knommu: clean up linker script

    commit f84f52a5c15db7d14a534815f27253b001735183 upstream.

    There is a lot of years of collected cruft in the m68knommu linker script.
    Clean it all up and use the well defined linker script support macros.

    Support is maintained for building both ROM/FLASH based and RAM based setups.
    No major changes to section layouts, though the rodata section is now lumped
    in with the read/write data section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e4063bdbee2ead4042b6caf4f603ed0cb6c0fc6
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Wed Oct 19 13:50:35 2011 +1000

    m68k: use non-MMU linker script for ColdFire MMU builds

    commit ed865e31a8273be200db9ddcdb6b844e48777abd upstream.

    Use the non-MMU linker script for ColdFire builds when we are building
    for MMU enabled. The image layout is correct for loading on existing
    ColdFire dev boards. The only addition required to the current non-MMU
    linker script is to add support for the fixup section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Matt Waddel <mwaddel@yahoo.com>
    Acked-by: Kurt Mahan <kmahan@xmission.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2187004fa49f190aa89eb1e3cc01623d62f480a8
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Dec 8 15:39:05 2011 +1000

    m68k: consolidate the vmlinux.lds linker scripts

    commit 40c1b9cfeedf79b909c961e0e00a13497e80bc82 upstream.

    The merge of m68knommu left the linker scripts a little disorganized.
    Some consistent naming and squashing two of scripts that just include
    others can simplify things a lot.

    So merge the two simple including scripts, and rename the nommu script
    to be consistent with the existing m68k linker scripts.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 38e57772a96d382cc6783f26cb152702f686b25f
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Jul 30 19:51:20 2013 -0700

    usb: core: don't try to reset_device() a port that got just disconnected

    commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream.

    The USB hub driver's event handler contains a check to catch SuperSpeed
    devices that transitioned into the SS.Inactive state and tries to fix
    them with a reset. It decides whether to do a plain hub port reset or
    call the usb_reset_device() function based on whether there was a device
    attached to the port.

    However, there are device/hub combinations (found with a JetFlash
    Transcend mass storage stick (8564:1000) on the root hub of an Intel
    LynxPoint PCH) which can transition to the SS.Inactive state on
    disconnect (and stay there long enough for the host to notice). In this
    case, above-mentioned reset check will call usb_reset_device() on the
    stale device data structure. The kernel will send pointless LPM control
    messages to the no longer connected device address and can even cause
    several 5 second khubd stalls on some (buggy?) host controllers, before
    finally accepting the device's fate amongst a flurry of error messages.

    This patch makes the choice of reset dependent on the port status that
    has just been read from the hub in addition to the existence of an
    in-kernel data structure for the device, and only proceeds with the more
    extensive reset if both are valid.

    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93d9de3ace93eebf680fbf8e3ae1ab27b85410e9
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jul 26 17:12:56 2013 +0200

    debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

    commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

    debugfs_remove_recursive() is wrong,

    1. it wrongly assumes that !list_empty(d_subdirs) means that this
       dir should be removed.

       This is not that bad by itself, but:

    2. if d_subdirs does not becomes empty after __debugfs_remove()
       it gives up and silently fails, it doesn't even try to remove
       other entries.

       However ->d_subdirs can be non-empty because it still has the
       already deleted !debugfs_positive() entries.

    3. simple_release_fs() is called even if __debugfs_remove() fails.

    Suppose we have

    	dir1/
    		dir2/
    			file2
    		file1

    and someone opens dir1/dir2/file2.

    Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
    away.

    But debugfs_remove_recursive(dir1) silently fails and doesn't remove
    this directory. Because it tries to delete (the already deleted)
    dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
    logic.

    Test-case:

    	#!/bin/sh

    	cd /sys/kernel/debug/tracing
    	echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
    	sleep 1000 < events/probe/sigprocmask/id &
    	echo -n >| kprobe_events

    	[ -d events/probe ] && echo "ERR!! failed to rm probe"

    And after that it is not possible to create another probe entry.

    With this patch debugfs_remove_recursive() skips !debugfs_positive()
    files although this is not strictly needed. The most important change
    is that it does not try to make ->d_subdirs empty, it simply scans
    the whole list(s) recursively and removes as much as possible.

    Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fa59eed8556c7f149f8ab9cea0f42f7843eecc81
Author: Salman Qazi <sqazi@google.com>
Date:   Thu Jun 14 15:31:09 2012 -0700

    perf: Use css_tryget() to avoid propping up css refcount

    commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

    An rmdir pushes css's ref count to zero.  However, if the associated
    directory is open at the time, the dentry ref count is non-zero.  If
    the fd for this directory is then passed into perf_event_open, it
    does a css_get().  This bounces the ref count back up from zero.  This
    is a problem by itself.  But what makes it turn into a crash is the
    fact that we end up doing an extra dput, since we perform a dput
    when css_put sees the ref count go down to zero.

    css_tryget() does not fall into that trap. So, we use that instead.

    Reproduction test-case for the bug:

     #include <unistd.h>
     #include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     #include <linux/unistd.h>
     #include <linux/perf_event.h>
     #include <string.h>
     #include <errno.h>
     #include <stdio.h>

     #define PERF_FLAG_PID_CGROUP    (1U << 2)

     int perf_event_open(struct perf_event_attr *hw_event_uptr,
                         pid_t pid, int cpu, int group_fd, unsigned long flags) {
             return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                     group_fd, flags);
     }

     /*
      * Directly poke at the perf_event bug, since it's proving hard to repro
      * depending on where in the kernel tree.  what moved?
      */
     int main(int argc, char **argv)
     {
            int fd;
            struct perf_event_attr attr;
            memset(&attr, 0, sizeof(attr));
            attr.exclude_kernel = 1;
            attr.size = sizeof(attr);
            mkdir("/dev/cgroup/perf_event/blah", 0777);
            fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
            perror("open");
            rmdir("/dev/cgroup/perf_event/blah");
            sleep(2);
            perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
            perror("perf_event_open");
            close(fd);
            return 0;
     }

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8d7b731f1f799f225f0c968ccb0508397657d87
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 587e5bf9a64470d080aab287d95c11a43b777cc5
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: Ben Hutchings <ben@decadent.org.uk>

commit 7af4fd8cf2529729f2981f10a83f7c277c1ec684
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: Ben Hutchings <ben@decadent.org.uk>

commit e1b92701b2b5e1b2ee1f181075ca6df4cef667e4
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: Ben Hutchings <ben@decadent.org.uk>

commit b108c975f4d210be89eacdec93bf8d34e7edbcc6
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: Ben Hutchings <ben@decadent.org.uk>

commit 19452ae3b32db6b1c33f9248f36f188fb439cc77
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: Ben Hutchings <ben@decadent.org.uk>

commit 49e3d709efa929fc179531a0bff55df92520b432
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: Ben Hutchings <ben@decadent.org.uk>

commit a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8
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: Ben Hutchings <ben@decadent.org.uk>

commit 765844f8edd831563fc646c7f747abf89eef4d4d
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: Ben Hutchings <ben@decadent.org.uk>

commit 003efcca2ad3e471e9103688a715bd33e29cb37b
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: Ben Hutchings <ben@decadent.org.uk>

commit 1d49f0ffe3731e90677c3a1cab524f144a06c48f
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

    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>
    Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 710cfab1cd10b1c227ddd20df646bd9e5494aa46
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: Ben Hutchings <ben@decadent.org.uk>

commit 10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3
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: Ben Hutchings <ben@decadent.org.uk>

commit e381c716ed158b0b77879625fa58929f1a59a940
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: Ben Hutchings <ben@decadent.org.uk>

commit dee5590a22d03d7e974ef6956747d717ef5de061
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: Ben Hutchings <ben@decadent.org.uk>

commit 669c81001fd0bd914fb2a1c15ddbb427de8a8373
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: Ben Hutchings <ben@decadent.org.uk>

commit af7e0f4a91ca9049ee9e541f8a98e762a12e9b9b
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: Ben Hutchings <ben@decadent.org.uk>

commit 2eb90b30797b3c908b597e4a2a700d6ef9ae0196
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: Ben Hutchings <ben@decadent.org.uk>

commit 836f6cb46716e36cb8d31a402c6661af5c895135
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 20:51:21 2013 +0200

    net: sctp: fix smatch warning in sctp_send_asconf_del_ip

    [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ]

    This was originally reported in [1] and posted by Neil Horman [2], he said:

      Fix up a missed null pointer check in the asconf code. If we don't find
      a local address, but we pass in an address length of more than 1, we may
      dereference a NULL laddr pointer. Currently this can't happen, as the only
      users of the function pass in the value 1 as the addrcnt parameter, but
      its not hot path, and it doesn't hurt to check for NULL should that ever
      be the case.

    The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
    from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
    while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
    so that we do *not* find a single address in the association's bind address
    list that is not in the packed array of addresses. If this happens when we
    have an established association with ASCONF-capable peers, then we could get
    a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
    and call later sctp_make_asconf_update_ip() with NULL laddr.

    BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
    and return with an error earlier. As this is incredably unintuitive and error
    prone, add a check to catch at least future bugs here. As Neil says, its not
    hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
    single-homed host").

     [1] http://www.spinics.net/lists/linux-sctp/msg02132.html
     [2] http://www.spinics.net/lists/linux-sctp/msg02133.html

    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Michio Honda <micchie@sfc.wide.ad.jp>
    Acked-By: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7def7d7b236bd3e90df969ac9b3540777619c57
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: Ben Hutchings <ben@decadent.org.uk>

commit 21958b854649fcd3a7b50db4f00573d488da1edb
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: Ben Hutchings <ben@decadent.org.uk>

commit 28cfcc851d5c8a7075ea8bb9b8695bb376f6872d
Author: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Date:   Wed Oct 2 00:34:10 2013 +0530

    powerpc/sysfs: Disable writing to PURR in guest mode

    commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.

    arch/powerpc/kernel/sysfs.c exports PURR with write permission.
    This may be valid for kernel in phyp mode. But writing to
    the file in guest mode causes crash due to a priviledge violation

    Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - CPUs are sysdev and we must use the sysdev API]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0b2d10f8f2e686c9f4b718251765f09f77ee8088
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 17:11:35 2013 +1000

    powerpc: Restore registers on error exit from csum_partial_copy_generic()

    commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.

    The csum_partial_copy_generic() function saves the PowerPC non-volatile
    r14, r15, and r16 registers for the main checksum-and-copy loop.
    Unfortunately, it fails to restore them upon error exit from this loop,
    which results in silent corruption of these registers in the presumably
    rare event of an access exception within that loop.

    This commit therefore restores these register on error exit from the loop.

    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>
    [bwh: Backported to 3.2: register name macros use lower-case 'r']
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13ce0c4a399a654effc40a9a57e87ac23cf19267
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: Ben Hutchings <ben@decadent.org.uk>

commit 408318734877aca9f11a8d7d1835456305c61f4d
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ccebcc74c81d8399c7b204aea47c1f33b09c2b17
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Mon Sep 30 13:45:12 2013 -0700

    nilfs2: fix issue with race condition of competition between segments for dirty blocks

    commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.

    Many NILFS2 users were reported about strange file system corruption
    (for example):

       NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
       NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)

    But such error messages are consequence of file system's issue that takes
    place more earlier.  Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
    and Anton Eliasson <devel@antoneliasson.se> were reported about another
    issue not so recently.  These reports describe the issue with segctor
    thread's crash:

      BUG: unable to handle kernel paging request at 0000000000004c83
      IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]

      Call Trace:
       nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
       nilfs_segctor_construct+0x17b/0x290 [nilfs2]
       nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
       kthread+0xc0/0xd0
       ret_from_fork+0x7c/0xb0

    These two issues have one reason.  This reason can raise third issue
    too.  Third issue results in hanging of segctor thread with eating of
    100% CPU.

    REPRODUCING PATH:

    One of the possible way or the issue reproducing was described by
    Jermoe me Poulin <jeromepoulin@gmail.com>:

    1. init S to get to single user mode.
    2. sysrq+E to make sure only my shell is running
    3. start network-manager to get my wifi connection up
    4. login as root and launch "screen"
    5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
    6. lscp | xz -9e > lscp.txt.xz
    7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
    8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
    9. start a screen and launch strace -f -o find-cat.log -t find
    /mnt/nilfs -type f -exec cat {} > /dev/null \;
    10. start a screen and launch strace -f -o apt-get.log -t apt-get update
    11. launch the last command again as it did not crash the first time
    12. apt-get crashes
    13. ps aux > ps-aux-crashed.log
    13. sysrq+W
    14. sysrq+E  wait for everything to terminate
    15. sysrq+SUSB

    Simplified way of the issue reproducing is starting kernel compilation
    task and "apt-get update" in parallel.

    REPRODUCIBILITY:

    The issue is reproduced not stable [60% - 80%].  It is very important to
    have proper environment for the issue reproducing.  The critical
    conditions for successful reproducing:

    (1) It should have big modified file by mmap() way.

    (2) This file should have the count of dirty blocks are greater that
        several segments in size (for example, two or three) from time to time
        during processing.

    (3) It should be intensive background activity of files modification
        in another thread.

    INVESTIGATION:

    First of all, it is possible to see that the reason of crash is not valid
    page address:

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
      NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783

    Moreover, value of b_page (0x1a82) is 6786.  This value looks like segment
    number.  And b_blocknr with b_size values look like block numbers.  So,
    buffer_head's pointer points on not proper address value.

    Detailed investigation of the issue is discovered such picture:

      [-----------------------------SEGMENT 6783-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783

      [-----------------------------SEGMENT 6784-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15

      [-----------------------------SEGMENT 6785-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12

      NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82

      BUG: unable to handle kernel paging request at 0000000000001a82
      IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]

    Usually, for every segment we collect dirty files in list.  Then, dirty
    blocks are gathered for every dirty file, prepared for write and
    submitted by means of nilfs_segbuf_submit_bh() call.  Finally, it takes
    place complete write phase after calling nilfs_end_bio_write() on the
    block layer.  Buffers/pages are marked as not dirty on final phase and
    processed files removed from the list of dirty files.

    It is possible to see that we had three prepare_write and submit_bio
    phases before segbuf_wait and complete_write phase.  Moreover, segments
    compete between each other for dirty blocks because on every iteration
    of segments processing dirty buffer_heads are added in several lists of
    payload_buffers:

      [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8

    The next pointer is the same but prev pointer has changed.  It means
    that buffer_head has next pointer from one list but prev pointer from
    another.  Such modification can be made several times.  And, finally, it
    can be resulted in various issues: (1) segctor hanging, (2) segctor
    crashing, (3) file system metadata corruption.

    FIX:
    This patch adds:

    (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
        for every proccessed dirty block;

    (2) checking of BH_Async_Write flag in
        nilfs_lookup_dirty_data_buffers() and
        nilfs_lookup_dirty_node_buffers();

    (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
        nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().

    Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
    Reported-by: Anton Eliasson <devel@antoneliasson.se>
    Cc: Paul Fertser <fercerpav@gmail.com>
    Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
    Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
    Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
    Cc: Elmer Zhang <freeboy6716@gmail.com>
    Cc: Kenneth Langga <klangga@gmail.com>
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: nilfs_clear_dirty_page() has not been separated
     from nilfs_clear_dirty_pages()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ec4a1dc57b7822ff5fc2cbe8aa19d0b4eaa70bd
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Sep 27 12:15:05 2013 +0200

    can: flexcan: fix flexcan_chip_start() on imx6

    commit 0d1862ea1a5bb876cf05555a7307080cb75bf379 upstream.

    In the flexcan_chip_start() function first the flexcan core is going through
    the soft reset sequence, then the RX FIFO is enabled.

    With the hardware is put into FIFO mode, message buffers 1...7 are reserved by
    the FIFO engine. The remaining message buffers are in reset default values.
    This patch removes the bogus initialization of the message buffers, as it
    causes an imprecise external abort on imx6.

    Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
    Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 798761949ee8ddb4a25888cf7c0722fbacbc70cc
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Thu Sep 26 13:01:44 2013 -0700

    usb: dwc3: add support for Merrifield

    commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

    Add PCI id for Intel Merrifield

    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47bd9ac912fe4b2f1f38efec89c3fe19628d6287
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue Sep 17 10:38:13 2013 +0300

    usb: dwc3: pci: add support for BayTrail

    commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

    Add PCI id for Intel BayTrail.

    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6f95357cb8bba2debf6b29347f4334e3cc12f897
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: Ben Hutchings <ben@decadent.org.uk>

commit e9c2770cfd8038419657e596410ce42bdb2e1a5b
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: Ben Hutchings <ben@decadent.org.uk>

commit 571d473b0b99c8035fa8df8d1fbbac5b00814bb6
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: Ben Hutchings <ben@decadent.org.uk>

commit 29003506beae5ad634f002d16cd73543337e2a26
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9e34fa1d28f3e04e9fbe4cdce5aa9a70c4952f6
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 24 15:45:25 2013 -0400

    USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

    commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream.

    Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
    field in their pci_driver structures should be protected by CONFIG_PM
    rather than CONFIG_PM_SLEEP.  The corresponding change has already
    been made for ohci-hcd.

    Without this change, controllers won't do runtime suspend if system
    suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7db4eda80eb05f7b0a6c7771920a2eea011b4f80
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c1a25b78eb6480c0c708e21fd746cf8b4dae9e7
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: Ben Hutchings <ben@decadent.org.uk>

commit e69de31ca0e0517bee4a99556b443fbde75ede6a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 23 10:38:26 2013 -0400

    drm/radeon: disable tests/benchmarks if accel is disabled

    commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.

    The tests are only usable if the acceleration engines have
    been successfully initialized.

    Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: there is only one test: radeon_test_moves()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3986574eb0563e306cd88d529700a4eef4fb330
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: Ben Hutchings <ben@decadent.org.uk>

commit 12c689b675726d6965320b489d0be7cb4e96d17d
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: Ben Hutchings <ben@decadent.org.uk>

commit 1dbbbf3262547a7f2d28a40224c8e3d017201c66
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: Ben Hutchings <ben@decadent.org.uk>

commit 4f31ab80a2bf09ea0e57c351842da1e647cfe9da
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:50 2013 +0200

    serial: pch_uart: fix tty-kref leak in dma-rx path

    commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

    Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

    Note that the tty ref isn't really needed anymore, but as the leak has
    always been there, fixing it before removing should makes it easier to
    backport the fix.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 73449fe73fa3d46232176fe6c73702b29b6479d2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:49 2013 +0200

    serial: pch_uart: fix tty-kref leak in rx-error path

    commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

    Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
    deadlock when pch_uart as console") which never put its tty reference.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6510909931472dadd7c13c6b0781fcf6a26813eb
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: Ben Hutchings <ben@decadent.org.uk>

commit f1f1e271a236290e402aa439e2f67057d857ed21
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date:   Mon Sep 2 14:57:51 2013 +0300

    Bluetooth: Add support for BCM20702A0 [0b05, 17cb]

    commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.

    Yet another vendor specific ID for this chipset; this one for the ASUS
    USB-BT400 Bluetooth 4.0 adapter.

    T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cb Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=000272C64400
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50a0ff96891fff6544c83441abf2f0484f94c833
Author: Peng Chen <pengchen@qti.qualcomm.com>
Date:   Fri Aug 30 17:41:40 2013 +0800

    Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.

    commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.

    usb device info:

    T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8f6513652249d566a4c7b6feaf13eee789ccd7a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 13 18:33:16 2013 -0400

    drm/radeon: fix panel scaling with eDP and LVDS bridges

    commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

    We were using the wrong set_properly callback so we always
    ended up with Full scaling even if something else (Center or
    Full aspect) was selected.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc99ffd3d8beb8103ce3d6cc3f9b3630c8a1e594
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: Ben Hutchings <ben@decadent.org.uk>

commit cb5f54477a5f46b11df2a8f3f8ac3a933a502ad3
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: logitech-dj: validate output report details

    commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream.

    A HID device could send a malicious output report that would cause the
    logitech-dj HID driver to leak kernel memory contents to the device, or
    trigger a NULL dereference during initialization:

    [  304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
    ...
    [  304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    [  304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90

    CVE-2013-2895

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: drop inapplicable changes to
     logi_dj_recv_send_report()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32eed83c07cc2b6e7487fc7c4e47938d7906f3f8
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Sep 11 21:56:57 2013 +0200

    HID: validate feature and input report details

    commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.

    When dealing with usage_index, be sure to properly use unsigned instead of
    int to avoid overflows.

    When working on report fields, always validate that their report_counts are
    in bounds.
    Without this, a HID device could report a malicious feature report that
    could trick the driver into a heap overflow:

    [  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
    ...
    [  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2897

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2:
     - Drop inapplicable changes to hid_usage::usage_index initialisation and
       to hid_report_raw_event()
     - Adjust context in report_features()
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3da8b771809032cf829869cabbffbed96cd47bc4
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 11 21:56:54 2013 +0200

    HID: LG: validate HID output report details

    commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream.

    A HID device could send a malicious output report that would cause the
    lg, lg3, and lg4 HID drivers to write beyond the output report allocation
    during an event, causing a heap overflow:

    [  325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
    ...
    [  414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten

    Additionally, while lg2 did correctly validate the report details, it was
    cleaned up and shortened.

    CVE-2013-2893

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e0f897f0929d27dc5d7de5cc24ccbeac572e5176
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: Ben Hutchings <ben@decadent.org.uk>

commit 9c8ea9f2d66ff437dd25da392a104947c703d975
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9f6e2b7e9f392b07d6773a846511b8f1b6d3ef0
Author: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Date:   Tue Sep 10 18:16:36 2013 +0900

    sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones

    commit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream.

    There is a small race between copy_process() and cgroup_attach_task()
    where child->se.parent,cfs_rq points to invalid (old) ones.

            parent doing fork()      | someone moving the parent to another cgroup
      -------------------------------+---------------------------------------------
        copy_process()
          + dup_task_struct()
            -> parent->se is copied to child->se.
               se.parent,cfs_rq of them point to old ones.

                                         cgroup_attach_task()
                                           + cgroup_task_migrate()
                                             -> parent->cgroup is updated.
                                           + cpu_cgroup_attach()
                                             + sched_move_task()
                                               + task_move_group_fair()
                                                 +- set_task_rq()
                                                    -> se.parent,cfs_rq of parent
                                                       are updated.

          + cgroup_fork()
            -> parent->cgroup is copied to child->cgroup. (*1)
          + sched_fork()
            + task_fork_fair()
              -> se.parent,cfs_rq of child are accessed
                 while they point to old ones. (*2)

    In the worst case, this bug can lead to "use-after-free" and cause a panic,
    because it's new cgroup's refcount that is incremented at (*1),
    so the old cgroup(and related data) can be freed before (*2).

    In fact, a panic caused by this bug was originally caught in RHEL6.4.

        BUG: unable to handle kernel NULL pointer dereference at (null)
        IP: [<ffffffff81051e3e>] sched_slice+0x6e/0xa0
        [...]
        Call Trace:
         [<ffffffff81051f25>] place_entity+0x75/0xa0
         [<ffffffff81056a3a>] task_fork_fair+0xaa/0x160
         [<ffffffff81063c0b>] sched_fork+0x6b/0x140
         [<ffffffff8106c3c2>] copy_process+0x5b2/0x1450
         [<ffffffff81063b49>] ? wake_up_new_task+0xd9/0x130
         [<ffffffff8106d2f4>] do_fork+0x94/0x460
         [<ffffffff81072a9e>] ? sys_wait4+0xae/0x100
         [<ffffffff81009598>] sys_clone+0x28/0x30
         [<ffffffff8100b393>] stub_clone+0x13/0x20
         [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

    Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 494fcf9f236d2ced8fede73189961526491db1dc
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: Ben Hutchings <ben@decadent.org.uk>

commit 56cbe7f7ee88a2eb06226ab3b5b4333fe0df663f
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: Ben Hutchings <ben@decadent.org.uk>

commit 89b2cd31a07fcee833fd0284eaeb7d57419a698f
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: Ben Hutchings <ben@decadent.org.uk>

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

    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: Ben Hutchings <ben@decadent.org.uk>

commit 1d7af96c344aff74a021d39c0c9063b15bda522c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 9 10:54:22 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)

    commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.

    The OUTPUT_ENABLE action jumps past the point in the coder where
    the data_offset is set on certain rs780 cards.  This worked
    previously because the OUTPUT_ENABLE action is always called
    immediately after the ENABLE action so the data_offset remained
    set.  In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
    (drm/radeon/atom: initialize more atom interpretor elements to 0),
    we explictly reset data_offset to 0 between atom calls which then
    caused this to fail.  The fix is to just skip calling the
    OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
    action does the same thing and more.  Ultimately, we could
    probably drop the OUTPUT_ENABLE action all together on DCE3
    asics.

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

    v2: only rs880 seems to be affected

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a3c0d076acaa13d53e48bee1d8ceaed32201223
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: Ben Hutchings <ben@decadent.org.uk>

commit 4741b69849e0b01077becf6d2cb902dca9984d01
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbeecda256bab53034d5a7f0c79c2f99219ce7c3
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Aug 23 10:50:39 2013 +0300

    drm/i915: try not to lose backlight CBLV precision

    commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream.

    ACPI has _BCM and _BQC methods to set and query the backlight
    brightness, respectively. The ACPI opregion has variables BCLP and CBLV
    to hold the requested and current backlight brightness, respectively.

    The BCLP variable has range 0..255 while the others have range
    0..100. This means the _BCM method has to scale the brightness for BCLP,
    and the gfx driver has to scale the requested value back for CBLV. If
    the _BQC method uses the CBLV variable (apparently some implementations
    do, some don't) for current backlight level reporting, there's room for
    rounding errors.

    Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values
    that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
    255) / 100 for scaling to BCLP.

    Reference: https://gist.github.com/aaronlu/6314920
    Reported-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2:
     - Adjust context
     - ASLE region is treated as normal memory rather than __iomem]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e4f24883632f4d46d4b43ae37a76932343a69839
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: Ben Hutchings <ben@decadent.org.uk>

commit 45e61ad38c9493eec7ece2bfe09bde2433cdaa87
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: picolcd_core: validate output report details

    commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

    A HID device could send a malicious output report that would cause the
    picolcd HID driver to trigger a NULL dereference during attr file writing.

    [jkosina@suse.cz: changed

    	report->maxfield < 1

    to

    	report->maxfield != 1

    as suggested by Bruno].

    CVE-2013-2899

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Bruno Prémont <bonbons@linux-vserver.org>
    Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c790976bda06884d78a1f8208d74e566ac41954e
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: Ben Hutchings <ben@decadent.org.uk>

commit db841e0c2b59b27c521512930d4e818d92ee1caa
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: Ben Hutchings <ben@decadent.org.uk>

commit b5f9e3533584d2fb6c90c63da767b85421b07def
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Tue Sep 3 14:28:38 2013 +0200

    fuse: readdir: check for slash in names

    commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.

    Userspace can add names containing a slash character to the directory
    listing.  Don't allow this as it could cause all sorts of trouble.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: drop changes to parse_dirplusfile() which we
     don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9eb9bfa030d8a49d54f0e4ae671e33f406bbbeff
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Jul 3 16:17:34 2013 -0300

    hdpvr: fix iteration over uninitialized lists in hdpvr_probe()

    commit 2e923a0527ac439e135b9961e58d3acd876bba10 upstream.

    free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
    but if something bad happens before that, error handling code calls hdpvr_delete(),
    which contains iteration over the lists (via hdpvr_free_buffers()).
    The patch moves the lists initialization to the beginning and by the way fixes
    goto label in error handling of registering videodev.
    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 559a2e36f047ac7e1ab27c489322cfd1409dd842
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Mar 19 09:34:58 2013 -0300

    hdpvr: register the video node at the end of probe

    commit 280847b532433ffe7a22795f926327805a127162 upstream.

    Video nodes can be used at once after registration, so make sure the full
    initialization is done before registering them.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9417815157557d273325641f7ad2b6dd147276f4
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Aug 30 17:06:04 2013 +0400

    fuse: hotfix truncate_pagecache() issue

    commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.

    The way how fuse calls truncate_pagecache() from fuse_change_attributes()
    is completely wrong. Because, w/o i_mutex held, we never sure whether
    'oldsize' and 'attr->size' are valid by the time of execution of
    truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
    released fc->lock in the middle of fuse_change_attributes(), we completely
    loose control of actions which may happen with given inode until we reach
    truncate_pagecache. The list of potentially dangerous actions includes
    mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.

    The typical outcome of doing truncate_pagecache() with outdated arguments
    is data corruption from user point of view. This is (in some sense)
    acceptable in cases when the issue is triggered by a change of the file on
    the server (i.e. externally wrt fuse operation), but it is absolutely
    intolerable in scenarios when a single fuse client modifies a file without
    any external intervention. A real life case I discovered by fsx-linux
    looked like this:

    1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
    FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
    2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
    to the server synchronously, then calls fuse_change_attributes(). The
    latter updates i_size, releases fc->lock, but before comparing oldsize vs
    attr->size..
    3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
    updating attributes and i_size, but now oldsize is equal to
    outarg.attr.size because i_size has just been updated (step 2). Hence,
    fuse_do_setattr() returns w/o calling truncate_pagecache().
    4. As soon as ftruncate(2) completes, the user extends file size by
    write(2) making a hole in the middle of file, then reads data from the hole
    either by read(2) or mmap-ed read. The user expects to get zero data from
    the hole, but gets stale data because truncate_pagecache() is not executed
    yet.

    The scenario above illustrates one side of the problem: not truncating the
    page cache even though we should. Another side corresponds to truncating
    page cache too late, when the state of inode changed significantly.
    Theoretically, the following is possible:

    1. As in the previous scenario fuse_dentry_revalidate() discovered that
    i_size changed (due to our own fuse_do_setattr()) and is going to call
    truncate_pagecache() for some 'new_size' it believes valid right now. But
    by the time that particular truncate_pagecache() is called ...
    2. fuse_do_setattr() returns (either having called truncate_pagecache() or
    not -- it doesn't matter).
    3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
    4. mmap-ed write makes a page in the extended region dirty.

    The result will be the lost of data user wrote on the fourth step.

    The patch is a hotfix resolving the issue in a simplistic way: let's skip
    dangerous i_size update and truncate_pagecache if an operation changing
    file size is in progress. This simplistic approach looks correct for the
    cases w/o external changes. And to handle them properly, more sophisticated
    and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
    postpone it until the issue is well discussed on the mailing list(s).

    Changed in v2:
     - improved patch description to cover both sides of the issue.

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: add the fuse_inode::state field which we didn't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36c0787573a41cb35f822cadd1169a1ec8d9c84f
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: Ben Hutchings <ben@decadent.org.uk>

commit e68a3e371e86af95b646517848271f0a0c4d82a8
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: Ben Hutchings <ben@decadent.org.uk>

commit c68d59cb0bd639b89ebb9531b597d1e0861b22f7
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Sun Sep 1 14:36:47 2013 +0300

    ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

    commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

    hdmi_channel_allocation() tries to find a HDMI channel allocation that
    matches the number channels in the playback stream and contains only
    speakers that the HDMI sink has reported as available via EDID. If no
    such allocation is found, 0 (stereo audio) is used.

    Using CA 0 causes the audio causes the sink to discard everything except
    the first two channels (front left and front right).

    However, the sink may be capable of receiving more channels than it has
    speakers (and then perform downmix or discard the extra channels), in
    which case it is preferable to use a CA that contains extra channels
    than to use CA 0 which discards all the non-stereo channels.

    Additionally, it seems that HBR (HD) passthrough output does not work on
    Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
    channels not present in CA). This happens with all receivers that report
    a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
    codec.

    Add a fallback in the CA selection so that the CA channel count at least
    matches the stream channel count, even if the stream contains channels
    not present in the sink speaker descriptor.

    Thanks to GrimGriefer at OpenELEC forums for discovering that changing
    the sink speaker mask allowed HBR output.

    Reported-by: GrimGriefer
    Reported-by: Ashecrow
    Reported-by: Frank Zafka <kafkaesque1978@gmail.com>
    Reported-by: Peter Frühberger <fritsch@xbmc.org>
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c12047d733f77e59d0fa3a2f3d70582717d10ba
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: Ben Hutchings <ben@decadent.org.uk>

commit f46575554ac083111a3df50ddcd66e62973b49fe
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: Ben Hutchings <ben@decadent.org.uk>

commit a8f153e2b6506f3f227cc39b5951ebb063022fb7
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: Ben Hutchings <ben@decadent.org.uk>

commit 9b2e83539a23e25786243f28852801dceeb9a351
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: Ben Hutchings <ben@decadent.org.uk>

commit e3ee677053f573a3036c0b25c8bf480ec3d7b09d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 12 11:04:29 2013 -0400

    drm/edid: add quirk for Medion MD30217PG

    commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.

    This LCD monitor (1280x1024 native) has a completely
    bogus detailed timing (640x350@70hz).  User reports that
    1280x1024@60 has waves so prefer 1280x1024@75.

    Manufacturer: MED  Model: 7b8  Serial#: 99188
    Year: 2005  Week: 5
    EDID Version: 1.3
    Analog Display Input,  Input Voltage Level: 0.700/0.700 V
    Sync:  Separate
    Max Image Size [cm]: horiz.: 34  vert.: 27
    Gamma: 2.50
    DPMS capabilities: Off; RGB/Color Display
    First detailed timing is preferred mode
    redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
    blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
    Supported established timings:
    720x400@70Hz
    640x480@60Hz
    640x480@72Hz
    640x480@75Hz
    800x600@56Hz
    800x600@60Hz
    800x600@72Hz
    800x600@75Hz
    1024x768@60Hz
    1024x768@70Hz
    1024x768@75Hz
    1280x1024@75Hz
    Manufacturer's mask: 0
    Supported standard timings:
    Supported detailed timing:
    clock: 25.2 MHz   Image Size:  337 x 270 mm
    h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
    v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
    Monitor name: MD30217PG
    Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
    Serial No: 501099188
    EDID (in hex):
              00ffffffffffff0034a4b80774830100
              050f010368221b962a0c55a559479b24
              125054afcf00310a0101010101018180
              000000000000d60980a0205e63103060
              0200510e1100001e000000fc004d4433
              3032313750470a202020000000fd0038
              4c1e530e000a202020202020000000ff
              003530313039393138380a2020200078

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reported-by: friedrich@mailstation.de
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc96269f72229f0b175bc6716040331650656b41
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 30 10:46:00 2013 -0400

    USB: fix build error when CONFIG_PM_SLEEP isn't enabled

    commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

    This patch fixes a build error that occurs when CONFIG_PM is enabled
    and CONFIG_PM_SLEEP isn't:

    >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
          .pm = &usb_hcd_pci_pm_ops

    Since the usb_hcd_pci_pm_ops structure is defined and used when
    CONFIG_PM is enabled, its declaration should not be protected by
    CONFIG_PM_SLEEP.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 223f7a608895eb1b7bc39c7e9f0b43a45f24a58f
Author: Grant Likely <grant.likely@linaro.org>
Date:   Wed Aug 28 21:24:17 2013 +0100

    of: Fix missing memory initialization on FDT unflattening

    commit 0640332e073be9207f0784df43595c0c39716e42 upstream.

    Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
    the allocation function itself needs to zero memory before returning
    it. This is a follow up to patch 9e4012752, "of: fdt: fix memory
    initialization for expanded DT" which fixed one call site but missed
    another.

    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Acked-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ccd1fd4c43407721caa38ae034359bf8d9a1b34
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>
    [bwh: Backported to 3.2: use dbg_hid() not hid_err()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 934796aadc4cf907d21b9346b70383d520bd0eea
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

    commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

    The ECDT of ASUSTEK L4R doesn't provide correct command and data
    I/O ports.  The DSDT provides the correct information instead.

    For this reason, add this machine to quirk list for ECDT validation
    and use the EC information from the DSDT.

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60d3bfb16dc6db40932968fef856b81c625f8cec
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 26 15:01:40 2013 -0400

    USB: OHCI: Allow runtime PM without system sleep

    commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

    Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
    structure should be protected by CONFIG_PM rather than
    CONFIG_PM_SLEEP.

    Without this change, OHCI controllers won't do runtime suspend if
    system suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 332ad48cc7df186cf82659c7ef50be87b91572b3
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: Ben Hutchings <ben@decadent.org.uk>

commit 72b55735d2f26b1dfcb206773974c465ca7ef04d
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>
    [bwh: Backported to 3.2: use rt2x00_eeprom_read()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0140c2fcecbdc5fdf70a10060147df9d8201d79e
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Sat Aug 24 23:38:15 2013 -0400

    mmc: tmio_mmc_dma: fix PIO fallback on SDHI

    commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.

    I'm testing SH-Mobile SDHI driver in DMA mode with  a new DMA controller  using
    'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
    to PIO but all commands time out after that.  It turned out that the fallback
    code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
    to them cleared, so that the function bails out early instead  of clearing the
    DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
    162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock).
    Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
    tmio_mmc_start_dma_{rx|tx}() helps.

    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d081af233874da71a19aa6c530bf705d40e75391
Author: Daniel Mack <zonque@gmail.com>
Date:   Wed Aug 21 11:17:21 2013 +0200

    usb: ehci-mxc: check for pdata before dereferencing

    commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.

    Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
    boards") introduced code that could potentially lead to a NULL pointer
    dereference on driver removal.

    Fix this by checking for the value of pdata before dereferencing it.

    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 63a77d815edb770711efc6dc1b2777f49d83d287
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b18b089695313ab6b6a4f7569aa3a6c02ddcc3c6
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3807f1de20f7e7178a5854bb2066eac56790fe8f
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc69de30e8b7933db4f0bbbb7340d13dcec53238
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: Ben Hutchings <ben@decadent.org.uk>

commit 5c22eba5c7a15d915352743238facb571375107d
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: Ben Hutchings <ben@decadent.org.uk>

commit 44527b813312ca17cc98623b2cbc9ce1f473038a
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: Ben Hutchings <ben@decadent.org.uk>

commit 42cb87a101c3fd0e080e9605ee70275efdcc8280
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Aug 10 15:59:15 2013 +0200

    ath9k: fix rx descriptor related race condition

    commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.

    Similar to a race condition that exists in the tx path, the hardware
    might re-read the 'next' pointer of a descriptor of the last completed
    frame. This only affects non-EDMA (pre-AR93xx) devices.

    To deal with this race, defer clearing and re-linking a completed rx
    descriptor until the next one has been processed.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f4dc9ffcb6227d10335af8be77c0f9a1a43f2578
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>
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef9ba15dbf44cf0d84131f72f7e72e6af3d0a232
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: Ben Hutchings <ben@decadent.org.uk>

commit 512749a57bddcf4252991c0b4ade576bce4365e4
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f4705f790d07d747c236a074f1c82f941244025
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be47dfad8e39e8b849fd0487292b3998284ddbc2
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Jul 16 15:45:48 2013 +0800

    libceph: unregister request in __map_request failed and nofail == false

    commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.

    For nofail == false request, if __map_request failed, the caller does
    cleanup work, like releasing the relative pages.  It doesn't make any sense
    to retry this request.

    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd1d8b9014eae19a1f87197984f051760236a2bc
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: Ben Hutchings <ben@decadent.org.uk>

commit d6722e140e6f8054f6a136dc3e3a281d16756a46
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: Ben Hutchings <ben@decadent.org.uk>

commit 384a27453c74b2fc27063dd287acf72550a1ad0f
Author: Manoj Chourasia <mchourasia@nvidia.com>
Date:   Mon Jul 22 15:33:13 2013 +0530

    HID: hidraw: correctly deallocate memory on device disconnect

    commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

    This changes puts the commit 4fe9f8e203f back in place
    with the fixes for slab corruption because of the commit.

    When a device is unplugged, wait for all processes that
    have opened the device to close before deallocating the device.

    This commit was solving kernel crash because of the corruption in
    rb tree of vmalloc. The rootcause was the device data pointer was
    geting excessed after the memory associated with hidraw was freed.

    The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
    first and then calling delete operation on the list associated with
    that hidraw leading to slab corruption.

    Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
    Tested-by: Peter Wu <lekensteyn@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c3ffb34128a34e3b58332b0fb98e8311f5c0ba08
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Thu Nov 1 11:33:26 2012 +0100

    HID: hidraw: put old deallocation mechanism in place

    commit df0cfd6990347c20ae031f3f34137cba274f1972 upstream.

    This basically reverts commit 4fe9f8e203fda. It causes multiple problems,
    namely:

    - after rmmod/modprobe cycle of bus driver, the input is not claimed any
      more. This is likely because of misplaced hid_hw_close()
    - it causes memory corruption on hidraw_list

    As original patch author is not responding to requests to fix his patch,
    and the original deallocation mechanism is not exposing any problems, I
    am reverting back to it.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f9b44910e7456fd898fe5da1f45e2d463cbfb31
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 5 03:00:18 2012 +0000

    inetpeer: fix a race in inetpeer_gc_worker()

    [ Upstream commit 55432d2b543a4b6dfae54f5c432a566877a85d90 ]

    commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
    the routing cache) added a race :

    Before freeing an inetpeer, we must respect a RCU grace period, and make
    sure no user will attempt to increase refcnt.

    inetpeer_invalidate_tree() waits for a RCU grace period before inserting
    inetpeer tree into gc_list and waking the worker. At that time, no
    concurrent lookup can find a inetpeer in this tree.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c25e82c03fed5bf21418963cebc92de7797f9b3b
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Mar 6 21:20:26 2012 +0000

    inetpeer: Invalidate the inetpeer tree along with the routing cache

    [ Upstream commit 5faa5df1fa2024bd750089ff21dcc4191798263d ]

    We initialize the routing metrics with the values cached on the
    inetpeer in rt_init_metrics(). So if we have the metrics cached on the
    inetpeer, we ignore the user configured fib_metrics.

    To fix this issue, we replace the old tree with a fresh initialized
    inet_peer_base. The old tree is removed later with a delayed work queue.

    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e7b1664d08249f111c1802050c1e49435dde8e1d
Author: Ying Xue <ying.xue@windriver.com>
Date:   Thu Aug 16 12:09:07 2012 +0000

    tipc: fix lockdep warning during bearer initialization

    [ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

    When the lockdep validator is enabled, it will report the below
    warning when we enable a TIPC bearer:

    [ INFO: possible irq lock inversion dependency detected ]
    ---------------------------------------------------------
    Possible interrupt unsafe locking scenario:

            CPU0                    CPU1
            ----                    ----
       lock(ptype_lock);
                                    local_irq_disable();
                                    lock(tipc_net_lock);
                                    lock(ptype_lock);
       <Interrupt>
       lock(tipc_net_lock);

      *** DEADLOCK ***

    the shortest dependencies between 2nd lock and 1st lock:
      -> (ptype_lock){+.+...} ops: 10 {
    [...]
    SOFTIRQ-ON-W at:
                          [<c1089418>] __lock_acquire+0x528/0x13e0
                          [<c108a360>] lock_acquire+0x90/0x100
                          [<c1553c38>] _raw_spin_lock+0x38/0x50
                          [<c14651ca>] dev_add_pack+0x3a/0x60
                          [<c182da75>] arp_init+0x1a/0x48
                          [<c182dce5>] inet_init+0x181/0x27e
                          [<c1001114>] do_one_initcall+0x34/0x170
                          [<c17f7329>] kernel_init+0x110/0x1b2
                          [<c155b6a2>] kernel_thread_helper+0x6/0x10
    [...]
       ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
       ... acquired at:
        [<c108a360>] lock_acquire+0x90/0x100
        [<c1553c38>] _raw_spin_lock+0x38/0x50
        [<c14651ca>] dev_add_pack+0x3a/0x60
        [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
        [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
        [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
        [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
        [<c148e802>] genl_rcv_msg+0x232/0x280
        [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
        [<c148e5bc>] genl_rcv+0x1c/0x30
        [<c148d144>] netlink_unicast+0x174/0x1f0
        [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
        [<c1456bc1>] sock_aio_write+0x161/0x170
        [<c1135a7c>] do_sync_write+0xac/0xf0
        [<c11360f6>] vfs_write+0x156/0x170
        [<c11361e2>] sys_write+0x42/0x70
        [<c155b0df>] sysenter_do_call+0x12/0x38
    [...]
    }
      -> (tipc_net_lock){+..-..} ops: 4 {
    [...]
        IN-SOFTIRQ-R at:
                         [<c108953a>] __lock_acquire+0x64a/0x13e0
                         [<c108a360>] lock_acquire+0x90/0x100
                         [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                         [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                         [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                         [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                         [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                         [<c13c43d2>] pcnet32_poll+0x292/0x780
                         [<c146b00a>] net_rx_action+0xfa/0x1e0
                         [<c103a4be>] __do_softirq+0xae/0x1e0
    [...]
    }

    >From the log, we can see three different call chains between
    CPU0 and CPU1:

    Time 0 on CPU0:

      kernel_init()->inet_init()->dev_add_pack()

    At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

    Time 1 on CPU1:

      tipc_enable_bearer()->enable_bearer()->dev_add_pack()

    At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
    wants to take ptype_lock to register TIPC protocol handler into the
    networking stack.  But the ptype_lock has been taken by dev_add_pack()
    on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
    busy looping.

    Time 2 on CPU0:

      netif_receive_skb()->recv_msg()->tipc_recv_msg()

    At time 2, an incoming TIPC packet arrives at CPU0, hence
    tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
    to hold tipc_net_lock.  At the moment, below scenario happens:

    On CPU0, below is our sequence of taking locks:

      lock(ptype_lock)->lock(tipc_net_lock)

    On CPU1, our sequence of taking locks looks like:

      lock(tipc_net_lock)->lock(ptype_lock)

    Obviously deadlock may happen in this case.

    But please note the deadlock possibly doesn't occur at all when the
    first TIPC bearer is enabled.  Before enable_bearer() -- running on
    CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
    recv_msg()) is not registered successfully via dev_add_pack(), so
    the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
    message comes to CPU0. But when the second TIPC bearer is
    registered, the deadlock can perhaps really happen.

    To fix it, we will push the work of registering TIPC protocol
    handler into workqueue context. After the change, both paths taking
    ptype_lock are always in process contexts, thus, the deadlock should
    never occur.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6b16097de4dac9fe49b96d18972102ad80bab09d
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Aug 30 11:18:45 2013 +0200

    ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

    [ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

    RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
    unreachable) messages:
            5 - Source address failed ingress/egress policy
    	6 - Reject route to destination

    Now they are treated as protocol error and icmpv6_err_convert() converts them
    to EPROTO.

    RFC 4443 says:
    	"Codes 5 and 6 are more informative subsets of code 1."

    Treat codes 5 and 6 as code 1 (EACCES)

    Btw, connect() returning -EPROTO confuses firefox, so that fallback to
    other/IPv4 addresses does not work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=910773

    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f99d61dcdd2e1354ef54bbaee5ae71af926fa718
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 29 23:55:05 2013 +0200

    net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

    [ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

    While looking into MLDv1/v2 code, I noticed that bridging code does
    not convert it's max delay into jiffies for MLDv2 messages as we do
    in core IPv6' multicast code.

    RFC3810, 5.1.3. Maximum Response Code says:

      The Maximum Response Code field specifies the maximum time allowed
      before sending a responding Report. The actual time allowed, called
      the Maximum Response Delay, is represented in units of milliseconds,
      and is derived from the Maximum Response Code as follows: [...]

    As we update timers that work with jiffies, we need to convert it.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Linus Lüssing <linus.luessing@web.de>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7676306f0e6a3e07fbedd55ff958dda9877d70f2
Author: Thomas Graf <tgraf@suug.ch>
Date:   Tue Sep 3 13:37:01 2013 +0200

    ipv6: Don't depend on per socket memory for neighbour discovery messages

    [ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

    Allocating skbs when sending out neighbour discovery messages
    currently uses sock_alloc_send_skb() based on a per net namespace
    socket and thus share a socket wmem buffer space.

    If a netdevice is temporarily unable to transmit due to carrier
    loss or for other reasons, the queued up ndisc messages will cosnume
    all of the wmem space and will thus prevent from any more skbs to
    be allocated even for netdevices that are able to transmit packets.

    The number of neighbour discovery messages sent is very limited,
    use of alloc_skb() bypasses the socket wmem buffer size enforcement
    while the manual call to skb_set_owner_w() maintains the socket
    reference needed for the IPv6 output path.

    This patch has orginally been posted by Eric Dumazet in a modified
    form.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60c98d1e5c84a40ff062773ab403d1dace95019b
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:30:07 2013 +0200

    ipv6: drop packets with multiple fragmentation headers

    [ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

    It is not allowed for an ipv6 packet to contain multiple fragmentation
    headers. So discard packets which were already reassembled by
    fragmentation logic and send back a parameter problem icmp.

    The updates for RFC 6980 will come in later, I have to do a bit more
    research here.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7319901766396653fae51d2f37c5d23eb4537766
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:02:27 2013 +0200

    ipv6: remove max_addresses check from ipv6_create_tempaddr

    [ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

    Because of the max_addresses check attackers were able to disable privacy
    extensions on an interface by creating enough autoconfigured addresses:

    <http://seclists.org/oss-sec/2012/q4/292>

    But the check is not actually needed: max_addresses protects the
    kernel to install too many ipv6 addresses on an interface and guards
    addrconf_prefix_rcv to install further addresses as soon as this limit
    is reached. We only generate temporary addresses in direct response of
    a new address showing up. As soon as we filled up the maximum number of
    addresses of an interface, we stop installing more addresses and thus
    also stop generating more temp addresses.

    Even if the attacker tries to generate a lot of temporary addresses
    by announcing a prefix and removing it again (lifetime == 0) we won't
    install more temp addresses, because the temporary addresses do count
    to the maximum number of addresses, thus we would stop installing new
    autoconfigured addresses when the limit is reached.

    This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
    possible).

    Thanks to Ding Tianhong to bring this topic up again.

    Cc: Ding Tianhong <dingtianhong@huawei.com>
    Cc: George Kargiotakis <kargig@void.gr>
    Cc: P J P <ppandit@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60be6501b85ef304de4c77979ca89981fd268841
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 15:52:57 2013 +0300

    tun: signedness bug in tun_get_user()

    [ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

    The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
    not totally correct.  Because "len" and "sizeof()" are size_t type, that
    means they are never less than zero.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5cacde1a5f5e7c958dd1f2f74fd57fc3bf176784
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jul 31 09:03:56 2013 -0400

    8139cp: Add dma_mapping_error checking

    [ Upstream commits cf3c4c03060b688cbc389ebc5065ebcce5653e96 and
      d06f5187469eee1b2932c02fd093d113cfc60d5e (the latter is a fixup
      from Dave Jones) ]

    Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
    https://bugzilla.redhat.com/show_bug.cgi?id=947250

    It showed several backtraces arising for dma_map_* usage without checking the
    return code on the mapping.  Add the check and abort the rx/tx operation if its
    failed.  Untested as I have no hardware and the reporter has wandered off, but
    seems pretty straightforward.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 729d6632adca3fc51a2114862926e0343e0fe744
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Aug 7 02:34:31 2013 +0200

    ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

    [ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

    In case a subtree did not match we currently stop backtracking and return
    NULL (root table from fib_lookup). This could yield in invalid routing
    table lookups when using subtrees.

    Instead continue to backtrack until a valid subtree or node is found
    and return this match.

    Also remove unneeded NULL check.

    Reported-by: Teco Boot <teco@inf-net.nl>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Cc: David Lamparter <equinox@diac24.net>
    Cc: <boutier@pps.univ-paris-diderot.fr>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a6c214e53401db1e237937c41c401449229aee9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 20:05:12 2013 -0700

    tcp: cubic: fix bug in bictcp_acked()

    [ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

    While investigating about strange increase of retransmit rates
    on hosts ~24 days after boot, Van found hystart was disabled
    if ca->epoch_start was 0, as following condition is true
    when tcp_time_stamp high order bit is set.

    (s32)(tcp_time_stamp - ca->epoch_start) < HZ

    Quoting Van :

     At initialization & after every loss ca->epoch_start is set to zero so
     I believe that the above line will turn off hystart as soon as the 2^31
     bit is set in tcp_time_stamp & hystart will stay off for 24 days.
     I think we've observed that cubic's restart is too aggressive without
     hystart so this might account for the higher drop rate we observe.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9588edd010b5b8a6bd0543279687b4af9c463ab0
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 17:10:15 2013 -0700

    tcp: cubic: fix overflow error in bictcp_update()

    [ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

    commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
    overflow error in bictcp_update() in following code :

    /* change the unit from HZ to bictcp_HZ */
    t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
          ca->epoch_start) << BICTCP_HZ) / HZ;

    Because msecs_to_jiffies() being unsigned long, compiler does
    implicit type promotion.

    We really want to constrain (tcp_time_stamp - ca->epoch_start)
    to a signed 32bit value, or else 't' has unexpected high values.

    This bugs triggers an increase of retransmit rates ~24 days after
    boot [1], as the high order bit of tcp_time_stamp flips.

    [1] for hosts with HZ=1000

    Big thanks to Van Jacobson for spotting this problem.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c521d041383bf06b840ee031002cf4d24d7e4673
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 11:18:49 2013 -0700

    fib_trie: remove potential out of bound access

    [ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

    AddressSanitizer [1] dynamic checker pointed a potential
    out of bound access in leaf_walk_rcu()

    We could allocate one more slot in tnode_new() to leave the prefetch()
    in-place but it looks not worth the pain.

    Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

    [1] :
    https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 243e49a55f2b4c04e05efe3b863592b7b8b14ca2
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Fri Aug 2 18:36:40 2013 +0400

    net: check net.core.somaxconn sysctl values

    [ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

    It's possible to assign an invalid value to the net.core.somaxconn
    sysctl variable, because there is no checks at all.

    The sk_max_ack_backlog field of the sock structure is defined as
    unsigned short. Therefore, the backlog argument in inet_listen()
    shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
    is truncated to the somaxconn value. So, the somaxconn value shouldn't
    exceed 65535 (USHRT_MAX).
    Also, negative values of somaxconn are meaningless.

    before:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    net.core.somaxconn = 65536
    $ sysctl -w net.core.somaxconn=-100
    net.core.somaxconn = -100

    after:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    error: "Invalid argument" setting key "net.core.somaxconn"
    $ sysctl -w net.core.somaxconn=-100
    error: "Invalid argument" setting key "net.core.somaxconn"

    Based on a prior patch from Changli Gao.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Reported-by: Changli Gao <xiaosuo@gmail.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 746db946cde024822904dbe590b43cae7589ad30
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu Aug 1 22:32:07 2013 -0700

    htb: fix sign extension bug

    [ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

    When userspace passes a large priority value
    the assignment of the unsigned value hopt->prio
    to  signed int cl->prio causes cl->prio to become negative and the
    comparison is with TC_HTB_NUMPRIO is always false.

    The result is that HTB crashes by referencing outside
    the array when processing packets. With this patch the large value
    wraps around like other values outside the normal range.

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

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 8b5ed99a4f9f2969c47501530da6dcd5a91f8f3d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Oct 26 21:06:14 2013 +0100

    Linux 3.2.52

commit 9203ceb63af1d8a2c1557ff01cbb2d75e960d2ef
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 4 10:52:36 2013 +0200

    can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX

    commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.

    In patch

        0d1862e can: flexcan: fix flexcan_chip_start() on imx6

    the loop in flexcan_chip_start() that iterates over all mailboxes after the
    soft reset of the CAN core was removed. This loop put all mailboxes (even the
    ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
    this aborts any pending TX messages.

    After a cold boot there is random garbage in the mailboxes, which leads to
    spontaneous transmit of CAN frames during first activation. Further if the
    interface was disabled with a pending message (usually due to an error
    condition on the CAN bus), this message is retransmitted after enabling the
    interface again.

    This patch fixes the regression by:
    1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
    FIFO, 8 is used by TX.
    2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
    mailbox is aborted.

    Cc: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2:
     - Adjust context
     - Hardware local echo is still enabled]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c23e05d637c461d13e473bee595ae781622b5ebf
Author: Claudiu Manoil <claudiu.manoil@freescale.com>
Date:   Sun Sep 23 22:39:08 2012 +0000

    gianfar: Change default HW Tx queue scheduling mode

    commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

    This is primarily to address transmission timeout occurrences, when
    multiple H/W Tx queues are being used concurrently. Because in
    the priority scheduling mode the controller does not service the
    Tx queues equally (but in ascending index order), Tx timeouts are
    being triggered rightaway for a basic test with multiple simultaneous
    connections like:
    iperf -c <server_ip> -n 100M -P 8

    resulting in kernel trace:
    NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue <X> timed out
    ------------[ cut here ]------------
    WARNING: at net/sched/sch_generic.c:255
    ...
    and controller reset during intense traffic, and possibly further
    complications.

    This patch changes the default H/W Tx scheduling setting (TXSCHED)
    for multi-queue devices, from priority scheduling mode to a weighted
    round robin mode with equal weights for all H/W Tx queues, and
    addresses the issue above.

    Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c617fda8c72a55a65cc5320cadb916f5981cfeb
Author: David Rientjes <rientjes@google.com>
Date:   Mon Apr 29 15:06:11 2013 -0700

    mm, show_mem: suppress page counts in non-blockable contexts

    commit 4b59e6c4730978679b414a8da61514a2518da512 upstream.

    On large systems with a lot of memory, walking all RAM to determine page
    types may take a half second or even more.

    In non-blockable contexts, the page allocator will emit a page allocation
    failure warning unless __GFP_NOWARN is specified.  In such contexts, irqs
    are typically disabled and such a lengthy delay may even result in NMI
    watchdog timeouts.

    To fix this, suppress the page walk in such contexts when printing the
    page allocation failure warning.

    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dffcc9dc54d22e3c5eadd5d42835fa47ee25b071
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b376352641ccc12b53a3aa555b9a477a8c0f44e
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Oct 2 14:57:51 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>
    [Ian Abbott: This patch applies to kernels 2.6.34.y through to 3.5.y
     inclusive.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0cf9986114ab4e16bf36a51814a0f688c79961a7
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: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c60ce91cc52e53619bb919ad5ff8891b75c2a4dd
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: Ben Hutchings <ben@decadent.org.uk>

commit 47fa3c9b8352d4f403118b01f8a97fff1353c30b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ecc545c9a903910bd23e40b6492d7b4f7ec03bc
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: Ben Hutchings <ben@decadent.org.uk>

commit e1fd636836ca3c883c172dc619a909e988a2f4b5
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: Ben Hutchings <ben@decadent.org.uk>

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

    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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 177c417ca4d861640b35ecf4fcd0f7563543e01f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 17:06:39 2013 +0100

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

    This reverts commit de77b7955c3985ca95f64af3cb10557eb17eacee, which was
    commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec upstream.

    This fix was only appropriate for Linux 3.7 onward, and introduced a
    regression when applied to earlier versions.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b1455ca9e8c44171e550980c82295162e7e31646
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: Ben Hutchings <ben@decadent.org.uk>

commit 04f82ec3a0a5399c17eb2053fa6833de064216b3
Author: Vasily Titskiy <qehgt0@gmail.com>
Date:   Fri Aug 30 18:25:04 2013 -0400

    HID: usbhid: quirk for N-Trig DuoSense Touch Screen

    commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.

    The DuoSense touchscreen device causes a 10 second timeout. This fix
    removes the delay.

    Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 297c511a4b6c6cff190525aec83b0d2de39fc3d8
Author: Stefan Kriwanek <dev@stefankriwanek.de>
Date:   Sun Aug 25 10:46:13 2013 +0200

    HID: Fix Speedlink VAD Cezanne support for some devices

    commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.

    Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
    than already done.

    I made sure through testing that this patch would not interfere with the proper
    working of a device that is bug-free. (The driver drops EV_REL events with
    abs(val) >= 256, which are not achievable even on the highest laser resolution
    hardware setting.)

    Signed-off-by: Stefan Kriwanek <mail@stefankriwanek.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6c756ccc62d4b6168f70fc5a3da5004a5f56751
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ed1d8009cc6f1b534ed94388cb7980b4a55797e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 49a58f5fa9d71155be5b6211030c281084f336a3
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6272221247a80adf0c36bf4f6ac8a4d7dcfb7e5b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31e0470e9906c42edfc4cf00404d4eb3a99dac7e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b
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>

commit 068d848f7f3d3db8c68e517ba93cb170914a64d8
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Jul 18 10:55:16 2013 +0800

    macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

    commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

    We try to linearize part of the skb when the number of iov is greater than
    MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
    one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
    network.

    Solve this problem by calculate the pages needed for iov before trying to do
    zerocopy and switch to use copy instead of zerocopy if it needs more than
    MAX_SKB_FRAGS.

    This is done through introducing a new helper to count the pages for iov, and
    call uarg->callback() manually when switching from zerocopy to copy to notify
    vhost.

    We can do further optimization on top.

    This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
    (macvtap: zerocopy: validate vectors before building skb).

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: callback only takes one argument]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 98ed9120b030962558276d8fd602eabb41a57d05
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 13:37:39 2013 +0100

    Revert "zram: use zram->lock to protect zram_free_page() in swap free notify path"

    This reverts commit 9e443904906ca2b5b3ae71f34ac4a4fa6905623e, which
    was commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.

    Taking the semaphore here leads to sleeping in atomic context.  This
    was fixed in mainline commit a0c516cbfc74 ("zram: don't grab mutex in
    zram_slot_free_noity") but that is too difficult to backport.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f0ce108f5e1c6a443548746b6f01b450f71a407
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon Apr 22 17:12:54 2013 +0000

    powerpc/pseries/lparcfg: Fix possible overflow are more than 1026

    commit 5676005acf26ab7e924a8438ea4746e47d405762 upstream.

    need set '\0' for 'local_buffer'.

    SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
    rtas_data_buf may truncated in memcpy.

    if contents are really truncated.
      the splpar_strlen is more than 1026. the next while loop checking will
      not find the end of buffer. that will cause memory access violation.

    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f362f08b46213452508f76bac4b74a4e5f5c4294
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Jan 5 15:51:13 2012 +1000

    m68knommu: clean up linker script

    commit f84f52a5c15db7d14a534815f27253b001735183 upstream.

    There is a lot of years of collected cruft in the m68knommu linker script.
    Clean it all up and use the well defined linker script support macros.

    Support is maintained for building both ROM/FLASH based and RAM based setups.
    No major changes to section layouts, though the rodata section is now lumped
    in with the read/write data section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e4063bdbee2ead4042b6caf4f603ed0cb6c0fc6
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Wed Oct 19 13:50:35 2011 +1000

    m68k: use non-MMU linker script for ColdFire MMU builds

    commit ed865e31a8273be200db9ddcdb6b844e48777abd upstream.

    Use the non-MMU linker script for ColdFire builds when we are building
    for MMU enabled. The image layout is correct for loading on existing
    ColdFire dev boards. The only addition required to the current non-MMU
    linker script is to add support for the fixup section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Matt Waddel <mwaddel@yahoo.com>
    Acked-by: Kurt Mahan <kmahan@xmission.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2187004fa49f190aa89eb1e3cc01623d62f480a8
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Dec 8 15:39:05 2011 +1000

    m68k: consolidate the vmlinux.lds linker scripts

    commit 40c1b9cfeedf79b909c961e0e00a13497e80bc82 upstream.

    The merge of m68knommu left the linker scripts a little disorganized.
    Some consistent naming and squashing two of scripts that just include
    others can simplify things a lot.

    So merge the two simple including scripts, and rename the nommu script
    to be consistent with the existing m68k linker scripts.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 38e57772a96d382cc6783f26cb152702f686b25f
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Jul 30 19:51:20 2013 -0700

    usb: core: don't try to reset_device() a port that got just disconnected

    commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream.

    The USB hub driver's event handler contains a check to catch SuperSpeed
    devices that transitioned into the SS.Inactive state and tries to fix
    them with a reset. It decides whether to do a plain hub port reset or
    call the usb_reset_device() function based on whether there was a device
    attached to the port.

    However, there are device/hub combinations (found with a JetFlash
    Transcend mass storage stick (8564:1000) on the root hub of an Intel
    LynxPoint PCH) which can transition to the SS.Inactive state on
    disconnect (and stay there long enough for the host to notice). In this
    case, above-mentioned reset check will call usb_reset_device() on the
    stale device data structure. The kernel will send pointless LPM control
    messages to the no longer connected device address and can even cause
    several 5 second khubd stalls on some (buggy?) host controllers, before
    finally accepting the device's fate amongst a flurry of error messages.

    This patch makes the choice of reset dependent on the port status that
    has just been read from the hub in addition to the existence of an
    in-kernel data structure for the device, and only proceeds with the more
    extensive reset if both are valid.

    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93d9de3ace93eebf680fbf8e3ae1ab27b85410e9
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jul 26 17:12:56 2013 +0200

    debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

    commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

    debugfs_remove_recursive() is wrong,

    1. it wrongly assumes that !list_empty(d_subdirs) means that this
       dir should be removed.

       This is not that bad by itself, but:

    2. if d_subdirs does not becomes empty after __debugfs_remove()
       it gives up and silently fails, it doesn't even try to remove
       other entries.

       However ->d_subdirs can be non-empty because it still has the
       already deleted !debugfs_positive() entries.

    3. simple_release_fs() is called even if __debugfs_remove() fails.

    Suppose we have

    	dir1/
    		dir2/
    			file2
    		file1

    and someone opens dir1/dir2/file2.

    Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
    away.

    But debugfs_remove_recursive(dir1) silently fails and doesn't remove
    this directory. Because it tries to delete (the already deleted)
    dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
    logic.

    Test-case:

    	#!/bin/sh

    	cd /sys/kernel/debug/tracing
    	echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
    	sleep 1000 < events/probe/sigprocmask/id &
    	echo -n >| kprobe_events

    	[ -d events/probe ] && echo "ERR!! failed to rm probe"

    And after that it is not possible to create another probe entry.

    With this patch debugfs_remove_recursive() skips !debugfs_positive()
    files although this is not strictly needed. The most important change
    is that it does not try to make ->d_subdirs empty, it simply scans
    the whole list(s) recursively and removes as much as possible.

    Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fa59eed8556c7f149f8ab9cea0f42f7843eecc81
Author: Salman Qazi <sqazi@google.com>
Date:   Thu Jun 14 15:31:09 2012 -0700

    perf: Use css_tryget() to avoid propping up css refcount

    commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

    An rmdir pushes css's ref count to zero.  However, if the associated
    directory is open at the time, the dentry ref count is non-zero.  If
    the fd for this directory is then passed into perf_event_open, it
    does a css_get().  This bounces the ref count back up from zero.  This
    is a problem by itself.  But what makes it turn into a crash is the
    fact that we end up doing an extra dput, since we perform a dput
    when css_put sees the ref count go down to zero.

    css_tryget() does not fall into that trap. So, we use that instead.

    Reproduction test-case for the bug:

     #include <unistd.h>
     #include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     #include <linux/unistd.h>
     #include <linux/perf_event.h>
     #include <string.h>
     #include <errno.h>
     #include <stdio.h>

     #define PERF_FLAG_PID_CGROUP    (1U << 2)

     int perf_event_open(struct perf_event_attr *hw_event_uptr,
                         pid_t pid, int cpu, int group_fd, unsigned long flags) {
             return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                     group_fd, flags);
     }

     /*
      * Directly poke at the perf_event bug, since it's proving hard to repro
      * depending on where in the kernel tree.  what moved?
      */
     int main(int argc, char **argv)
     {
            int fd;
            struct perf_event_attr attr;
            memset(&attr, 0, sizeof(attr));
            attr.exclude_kernel = 1;
            attr.size = sizeof(attr);
            mkdir("/dev/cgroup/perf_event/blah", 0777);
            fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
            perror("open");
            rmdir("/dev/cgroup/perf_event/blah");
            sleep(2);
            perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
            perror("perf_event_open");
            close(fd);
            return 0;
     }

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8d7b731f1f799f225f0c968ccb0508397657d87
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 587e5bf9a64470d080aab287d95c11a43b777cc5
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: Ben Hutchings <ben@decadent.org.uk>

commit 7af4fd8cf2529729f2981f10a83f7c277c1ec684
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: Ben Hutchings <ben@decadent.org.uk>

commit e1b92701b2b5e1b2ee1f181075ca6df4cef667e4
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: Ben Hutchings <ben@decadent.org.uk>

commit b108c975f4d210be89eacdec93bf8d34e7edbcc6
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: Ben Hutchings <ben@decadent.org.uk>

commit 19452ae3b32db6b1c33f9248f36f188fb439cc77
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: Ben Hutchings <ben@decadent.org.uk>

commit 49e3d709efa929fc179531a0bff55df92520b432
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: Ben Hutchings <ben@decadent.org.uk>

commit a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8
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: Ben Hutchings <ben@decadent.org.uk>

commit 765844f8edd831563fc646c7f747abf89eef4d4d
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: Ben Hutchings <ben@decadent.org.uk>

commit 003efcca2ad3e471e9103688a715bd33e29cb37b
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: Ben Hutchings <ben@decadent.org.uk>

commit 1d49f0ffe3731e90677c3a1cab524f144a06c48f
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

    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>
    Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 710cfab1cd10b1c227ddd20df646bd9e5494aa46
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: Ben Hutchings <ben@decadent.org.uk>

commit 10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3
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: Ben Hutchings <ben@decadent.org.uk>

commit e381c716ed158b0b77879625fa58929f1a59a940
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: Ben Hutchings <ben@decadent.org.uk>

commit dee5590a22d03d7e974ef6956747d717ef5de061
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: Ben Hutchings <ben@decadent.org.uk>

commit 669c81001fd0bd914fb2a1c15ddbb427de8a8373
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: Ben Hutchings <ben@decadent.org.uk>

commit af7e0f4a91ca9049ee9e541f8a98e762a12e9b9b
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: Ben Hutchings <ben@decadent.org.uk>

commit 2eb90b30797b3c908b597e4a2a700d6ef9ae0196
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: Ben Hutchings <ben@decadent.org.uk>

commit 836f6cb46716e36cb8d31a402c6661af5c895135
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 20:51:21 2013 +0200

    net: sctp: fix smatch warning in sctp_send_asconf_del_ip

    [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ]

    This was originally reported in [1] and posted by Neil Horman [2], he said:

      Fix up a missed null pointer check in the asconf code. If we don't find
      a local address, but we pass in an address length of more than 1, we may
      dereference a NULL laddr pointer. Currently this can't happen, as the only
      users of the function pass in the value 1 as the addrcnt parameter, but
      its not hot path, and it doesn't hurt to check for NULL should that ever
      be the case.

    The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
    from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
    while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
    so that we do *not* find a single address in the association's bind address
    list that is not in the packed array of addresses. If this happens when we
    have an established association with ASCONF-capable peers, then we could get
    a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
    and call later sctp_make_asconf_update_ip() with NULL laddr.

    BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
    and return with an error earlier. As this is incredably unintuitive and error
    prone, add a check to catch at least future bugs here. As Neil says, its not
    hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
    single-homed host").

     [1] http://www.spinics.net/lists/linux-sctp/msg02132.html
     [2] http://www.spinics.net/lists/linux-sctp/msg02133.html

    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Michio Honda <micchie@sfc.wide.ad.jp>
    Acked-By: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7def7d7b236bd3e90df969ac9b3540777619c57
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: Ben Hutchings <ben@decadent.org.uk>

commit 21958b854649fcd3a7b50db4f00573d488da1edb
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: Ben Hutchings <ben@decadent.org.uk>

commit 28cfcc851d5c8a7075ea8bb9b8695bb376f6872d
Author: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Date:   Wed Oct 2 00:34:10 2013 +0530

    powerpc/sysfs: Disable writing to PURR in guest mode

    commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.

    arch/powerpc/kernel/sysfs.c exports PURR with write permission.
    This may be valid for kernel in phyp mode. But writing to
    the file in guest mode causes crash due to a priviledge violation

    Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - CPUs are sysdev and we must use the sysdev API]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0b2d10f8f2e686c9f4b718251765f09f77ee8088
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 17:11:35 2013 +1000

    powerpc: Restore registers on error exit from csum_partial_copy_generic()

    commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.

    The csum_partial_copy_generic() function saves the PowerPC non-volatile
    r14, r15, and r16 registers for the main checksum-and-copy loop.
    Unfortunately, it fails to restore them upon error exit from this loop,
    which results in silent corruption of these registers in the presumably
    rare event of an access exception within that loop.

    This commit therefore restores these register on error exit from the loop.

    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>
    [bwh: Backported to 3.2: register name macros use lower-case 'r']
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13ce0c4a399a654effc40a9a57e87ac23cf19267
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: Ben Hutchings <ben@decadent.org.uk>

commit 408318734877aca9f11a8d7d1835456305c61f4d
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ccebcc74c81d8399c7b204aea47c1f33b09c2b17
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Mon Sep 30 13:45:12 2013 -0700

    nilfs2: fix issue with race condition of competition between segments for dirty blocks

    commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.

    Many NILFS2 users were reported about strange file system corruption
    (for example):

       NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
       NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)

    But such error messages are consequence of file system's issue that takes
    place more earlier.  Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
    and Anton Eliasson <devel@antoneliasson.se> were reported about another
    issue not so recently.  These reports describe the issue with segctor
    thread's crash:

      BUG: unable to handle kernel paging request at 0000000000004c83
      IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]

      Call Trace:
       nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
       nilfs_segctor_construct+0x17b/0x290 [nilfs2]
       nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
       kthread+0xc0/0xd0
       ret_from_fork+0x7c/0xb0

    These two issues have one reason.  This reason can raise third issue
    too.  Third issue results in hanging of segctor thread with eating of
    100% CPU.

    REPRODUCING PATH:

    One of the possible way or the issue reproducing was described by
    Jermoe me Poulin <jeromepoulin@gmail.com>:

    1. init S to get to single user mode.
    2. sysrq+E to make sure only my shell is running
    3. start network-manager to get my wifi connection up
    4. login as root and launch "screen"
    5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
    6. lscp | xz -9e > lscp.txt.xz
    7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
    8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
    9. start a screen and launch strace -f -o find-cat.log -t find
    /mnt/nilfs -type f -exec cat {} > /dev/null \;
    10. start a screen and launch strace -f -o apt-get.log -t apt-get update
    11. launch the last command again as it did not crash the first time
    12. apt-get crashes
    13. ps aux > ps-aux-crashed.log
    13. sysrq+W
    14. sysrq+E  wait for everything to terminate
    15. sysrq+SUSB

    Simplified way of the issue reproducing is starting kernel compilation
    task and "apt-get update" in parallel.

    REPRODUCIBILITY:

    The issue is reproduced not stable [60% - 80%].  It is very important to
    have proper environment for the issue reproducing.  The critical
    conditions for successful reproducing:

    (1) It should have big modified file by mmap() way.

    (2) This file should have the count of dirty blocks are greater that
        several segments in size (for example, two or three) from time to time
        during processing.

    (3) It should be intensive background activity of files modification
        in another thread.

    INVESTIGATION:

    First of all, it is possible to see that the reason of crash is not valid
    page address:

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
      NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783

    Moreover, value of b_page (0x1a82) is 6786.  This value looks like segment
    number.  And b_blocknr with b_size values look like block numbers.  So,
    buffer_head's pointer points on not proper address value.

    Detailed investigation of the issue is discovered such picture:

      [-----------------------------SEGMENT 6783-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783

      [-----------------------------SEGMENT 6784-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15

      [-----------------------------SEGMENT 6785-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12

      NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82

      BUG: unable to handle kernel paging request at 0000000000001a82
      IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]

    Usually, for every segment we collect dirty files in list.  Then, dirty
    blocks are gathered for every dirty file, prepared for write and
    submitted by means of nilfs_segbuf_submit_bh() call.  Finally, it takes
    place complete write phase after calling nilfs_end_bio_write() on the
    block layer.  Buffers/pages are marked as not dirty on final phase and
    processed files removed from the list of dirty files.

    It is possible to see that we had three prepare_write and submit_bio
    phases before segbuf_wait and complete_write phase.  Moreover, segments
    compete between each other for dirty blocks because on every iteration
    of segments processing dirty buffer_heads are added in several lists of
    payload_buffers:

      [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8

    The next pointer is the same but prev pointer has changed.  It means
    that buffer_head has next pointer from one list but prev pointer from
    another.  Such modification can be made several times.  And, finally, it
    can be resulted in various issues: (1) segctor hanging, (2) segctor
    crashing, (3) file system metadata corruption.

    FIX:
    This patch adds:

    (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
        for every proccessed dirty block;

    (2) checking of BH_Async_Write flag in
        nilfs_lookup_dirty_data_buffers() and
        nilfs_lookup_dirty_node_buffers();

    (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
        nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().

    Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
    Reported-by: Anton Eliasson <devel@antoneliasson.se>
    Cc: Paul Fertser <fercerpav@gmail.com>
    Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
    Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
    Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
    Cc: Elmer Zhang <freeboy6716@gmail.com>
    Cc: Kenneth Langga <klangga@gmail.com>
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: nilfs_clear_dirty_page() has not been separated
     from nilfs_clear_dirty_pages()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ec4a1dc57b7822ff5fc2cbe8aa19d0b4eaa70bd
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Sep 27 12:15:05 2013 +0200

    can: flexcan: fix flexcan_chip_start() on imx6

    commit 0d1862ea1a5bb876cf05555a7307080cb75bf379 upstream.

    In the flexcan_chip_start() function first the flexcan core is going through
    the soft reset sequence, then the RX FIFO is enabled.

    With the hardware is put into FIFO mode, message buffers 1...7 are reserved by
    the FIFO engine. The remaining message buffers are in reset default values.
    This patch removes the bogus initialization of the message buffers, as it
    causes an imprecise external abort on imx6.

    Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
    Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 798761949ee8ddb4a25888cf7c0722fbacbc70cc
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Thu Sep 26 13:01:44 2013 -0700

    usb: dwc3: add support for Merrifield

    commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

    Add PCI id for Intel Merrifield

    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47bd9ac912fe4b2f1f38efec89c3fe19628d6287
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue Sep 17 10:38:13 2013 +0300

    usb: dwc3: pci: add support for BayTrail

    commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

    Add PCI id for Intel BayTrail.

    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6f95357cb8bba2debf6b29347f4334e3cc12f897
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: Ben Hutchings <ben@decadent.org.uk>

commit e9c2770cfd8038419657e596410ce42bdb2e1a5b
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: Ben Hutchings <ben@decadent.org.uk>

commit 571d473b0b99c8035fa8df8d1fbbac5b00814bb6
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: Ben Hutchings <ben@decadent.org.uk>

commit 29003506beae5ad634f002d16cd73543337e2a26
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9e34fa1d28f3e04e9fbe4cdce5aa9a70c4952f6
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 24 15:45:25 2013 -0400

    USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

    commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream.

    Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
    field in their pci_driver structures should be protected by CONFIG_PM
    rather than CONFIG_PM_SLEEP.  The corresponding change has already
    been made for ohci-hcd.

    Without this change, controllers won't do runtime suspend if system
    suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7db4eda80eb05f7b0a6c7771920a2eea011b4f80
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c1a25b78eb6480c0c708e21fd746cf8b4dae9e7
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: Ben Hutchings <ben@decadent.org.uk>

commit e69de31ca0e0517bee4a99556b443fbde75ede6a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 23 10:38:26 2013 -0400

    drm/radeon: disable tests/benchmarks if accel is disabled

    commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.

    The tests are only usable if the acceleration engines have
    been successfully initialized.

    Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: there is only one test: radeon_test_moves()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3986574eb0563e306cd88d529700a4eef4fb330
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: Ben Hutchings <ben@decadent.org.uk>

commit 12c689b675726d6965320b489d0be7cb4e96d17d
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: Ben Hutchings <ben@decadent.org.uk>

commit 1dbbbf3262547a7f2d28a40224c8e3d017201c66
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: Ben Hutchings <ben@decadent.org.uk>

commit 4f31ab80a2bf09ea0e57c351842da1e647cfe9da
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:50 2013 +0200

    serial: pch_uart: fix tty-kref leak in dma-rx path

    commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

    Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

    Note that the tty ref isn't really needed anymore, but as the leak has
    always been there, fixing it before removing should makes it easier to
    backport the fix.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 73449fe73fa3d46232176fe6c73702b29b6479d2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:49 2013 +0200

    serial: pch_uart: fix tty-kref leak in rx-error path

    commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

    Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
    deadlock when pch_uart as console") which never put its tty reference.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6510909931472dadd7c13c6b0781fcf6a26813eb
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: Ben Hutchings <ben@decadent.org.uk>

commit f1f1e271a236290e402aa439e2f67057d857ed21
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date:   Mon Sep 2 14:57:51 2013 +0300

    Bluetooth: Add support for BCM20702A0 [0b05, 17cb]

    commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.

    Yet another vendor specific ID for this chipset; this one for the ASUS
    USB-BT400 Bluetooth 4.0 adapter.

    T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cb Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=000272C64400
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50a0ff96891fff6544c83441abf2f0484f94c833
Author: Peng Chen <pengchen@qti.qualcomm.com>
Date:   Fri Aug 30 17:41:40 2013 +0800

    Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.

    commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.

    usb device info:

    T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8f6513652249d566a4c7b6feaf13eee789ccd7a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 13 18:33:16 2013 -0400

    drm/radeon: fix panel scaling with eDP and LVDS bridges

    commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

    We were using the wrong set_properly callback so we always
    ended up with Full scaling even if something else (Center or
    Full aspect) was selected.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc99ffd3d8beb8103ce3d6cc3f9b3630c8a1e594
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: Ben Hutchings <ben@decadent.org.uk>

commit cb5f54477a5f46b11df2a8f3f8ac3a933a502ad3
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: logitech-dj: validate output report details

    commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream.

    A HID device could send a malicious output report that would cause the
    logitech-dj HID driver to leak kernel memory contents to the device, or
    trigger a NULL dereference during initialization:

    [  304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
    ...
    [  304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    [  304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90

    CVE-2013-2895

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: drop inapplicable changes to
     logi_dj_recv_send_report()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32eed83c07cc2b6e7487fc7c4e47938d7906f3f8
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Sep 11 21:56:57 2013 +0200

    HID: validate feature and input report details

    commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.

    When dealing with usage_index, be sure to properly use unsigned instead of
    int to avoid overflows.

    When working on report fields, always validate that their report_counts are
    in bounds.
    Without this, a HID device could report a malicious feature report that
    could trick the driver into a heap overflow:

    [  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
    ...
    [  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2897

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2:
     - Drop inapplicable changes to hid_usage::usage_index initialisation and
       to hid_report_raw_event()
     - Adjust context in report_features()
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3da8b771809032cf829869cabbffbed96cd47bc4
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 11 21:56:54 2013 +0200

    HID: LG: validate HID output report details

    commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream.

    A HID device could send a malicious output report that would cause the
    lg, lg3, and lg4 HID drivers to write beyond the output report allocation
    during an event, causing a heap overflow:

    [  325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
    ...
    [  414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten

    Additionally, while lg2 did correctly validate the report details, it was
    cleaned up and shortened.

    CVE-2013-2893

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e0f897f0929d27dc5d7de5cc24ccbeac572e5176
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: Ben Hutchings <ben@decadent.org.uk>

commit 9c8ea9f2d66ff437dd25da392a104947c703d975
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9f6e2b7e9f392b07d6773a846511b8f1b6d3ef0
Author: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Date:   Tue Sep 10 18:16:36 2013 +0900

    sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones

    commit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream.

    There is a small race between copy_process() and cgroup_attach_task()
    where child->se.parent,cfs_rq points to invalid (old) ones.

            parent doing fork()      | someone moving the parent to another cgroup
      -------------------------------+---------------------------------------------
        copy_process()
          + dup_task_struct()
            -> parent->se is copied to child->se.
               se.parent,cfs_rq of them point to old ones.

                                         cgroup_attach_task()
                                           + cgroup_task_migrate()
                                             -> parent->cgroup is updated.
                                           + cpu_cgroup_attach()
                                             + sched_move_task()
                                               + task_move_group_fair()
                                                 +- set_task_rq()
                                                    -> se.parent,cfs_rq of parent
                                                       are updated.

          + cgroup_fork()
            -> parent->cgroup is copied to child->cgroup. (*1)
          + sched_fork()
            + task_fork_fair()
              -> se.parent,cfs_rq of child are accessed
                 while they point to old ones. (*2)

    In the worst case, this bug can lead to "use-after-free" and cause a panic,
    because it's new cgroup's refcount that is incremented at (*1),
    so the old cgroup(and related data) can be freed before (*2).

    In fact, a panic caused by this bug was originally caught in RHEL6.4.

        BUG: unable to handle kernel NULL pointer dereference at (null)
        IP: [<ffffffff81051e3e>] sched_slice+0x6e/0xa0
        [...]
        Call Trace:
         [<ffffffff81051f25>] place_entity+0x75/0xa0
         [<ffffffff81056a3a>] task_fork_fair+0xaa/0x160
         [<ffffffff81063c0b>] sched_fork+0x6b/0x140
         [<ffffffff8106c3c2>] copy_process+0x5b2/0x1450
         [<ffffffff81063b49>] ? wake_up_new_task+0xd9/0x130
         [<ffffffff8106d2f4>] do_fork+0x94/0x460
         [<ffffffff81072a9e>] ? sys_wait4+0xae/0x100
         [<ffffffff81009598>] sys_clone+0x28/0x30
         [<ffffffff8100b393>] stub_clone+0x13/0x20
         [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

    Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 494fcf9f236d2ced8fede73189961526491db1dc
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: Ben Hutchings <ben@decadent.org.uk>

commit 56cbe7f7ee88a2eb06226ab3b5b4333fe0df663f
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: Ben Hutchings <ben@decadent.org.uk>

commit 89b2cd31a07fcee833fd0284eaeb7d57419a698f
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: Ben Hutchings <ben@decadent.org.uk>

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

    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: Ben Hutchings <ben@decadent.org.uk>

commit 1d7af96c344aff74a021d39c0c9063b15bda522c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 9 10:54:22 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)

    commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.

    The OUTPUT_ENABLE action jumps past the point in the coder where
    the data_offset is set on certain rs780 cards.  This worked
    previously because the OUTPUT_ENABLE action is always called
    immediately after the ENABLE action so the data_offset remained
    set.  In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
    (drm/radeon/atom: initialize more atom interpretor elements to 0),
    we explictly reset data_offset to 0 between atom calls which then
    caused this to fail.  The fix is to just skip calling the
    OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
    action does the same thing and more.  Ultimately, we could
    probably drop the OUTPUT_ENABLE action all together on DCE3
    asics.

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

    v2: only rs880 seems to be affected

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a3c0d076acaa13d53e48bee1d8ceaed32201223
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: Ben Hutchings <ben@decadent.org.uk>

commit 4741b69849e0b01077becf6d2cb902dca9984d01
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbeecda256bab53034d5a7f0c79c2f99219ce7c3
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Aug 23 10:50:39 2013 +0300

    drm/i915: try not to lose backlight CBLV precision

    commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream.

    ACPI has _BCM and _BQC methods to set and query the backlight
    brightness, respectively. The ACPI opregion has variables BCLP and CBLV
    to hold the requested and current backlight brightness, respectively.

    The BCLP variable has range 0..255 while the others have range
    0..100. This means the _BCM method has to scale the brightness for BCLP,
    and the gfx driver has to scale the requested value back for CBLV. If
    the _BQC method uses the CBLV variable (apparently some implementations
    do, some don't) for current backlight level reporting, there's room for
    rounding errors.

    Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values
    that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
    255) / 100 for scaling to BCLP.

    Reference: https://gist.github.com/aaronlu/6314920
    Reported-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2:
     - Adjust context
     - ASLE region is treated as normal memory rather than __iomem]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e4f24883632f4d46d4b43ae37a76932343a69839
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: Ben Hutchings <ben@decadent.org.uk>

commit 45e61ad38c9493eec7ece2bfe09bde2433cdaa87
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: picolcd_core: validate output report details

    commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

    A HID device could send a malicious output report that would cause the
    picolcd HID driver to trigger a NULL dereference during attr file writing.

    [jkosina@suse.cz: changed

    	report->maxfield < 1

    to

    	report->maxfield != 1

    as suggested by Bruno].

    CVE-2013-2899

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Bruno Prémont <bonbons@linux-vserver.org>
    Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c790976bda06884d78a1f8208d74e566ac41954e
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: Ben Hutchings <ben@decadent.org.uk>

commit db841e0c2b59b27c521512930d4e818d92ee1caa
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: Ben Hutchings <ben@decadent.org.uk>

commit b5f9e3533584d2fb6c90c63da767b85421b07def
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Tue Sep 3 14:28:38 2013 +0200

    fuse: readdir: check for slash in names

    commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.

    Userspace can add names containing a slash character to the directory
    listing.  Don't allow this as it could cause all sorts of trouble.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: drop changes to parse_dirplusfile() which we
     don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9eb9bfa030d8a49d54f0e4ae671e33f406bbbeff
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Jul 3 16:17:34 2013 -0300

    hdpvr: fix iteration over uninitialized lists in hdpvr_probe()

    commit 2e923a0527ac439e135b9961e58d3acd876bba10 upstream.

    free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
    but if something bad happens before that, error handling code calls hdpvr_delete(),
    which contains iteration over the lists (via hdpvr_free_buffers()).
    The patch moves the lists initialization to the beginning and by the way fixes
    goto label in error handling of registering videodev.
    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 559a2e36f047ac7e1ab27c489322cfd1409dd842
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Mar 19 09:34:58 2013 -0300

    hdpvr: register the video node at the end of probe

    commit 280847b532433ffe7a22795f926327805a127162 upstream.

    Video nodes can be used at once after registration, so make sure the full
    initialization is done before registering them.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9417815157557d273325641f7ad2b6dd147276f4
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Aug 30 17:06:04 2013 +0400

    fuse: hotfix truncate_pagecache() issue

    commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.

    The way how fuse calls truncate_pagecache() from fuse_change_attributes()
    is completely wrong. Because, w/o i_mutex held, we never sure whether
    'oldsize' and 'attr->size' are valid by the time of execution of
    truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
    released fc->lock in the middle of fuse_change_attributes(), we completely
    loose control of actions which may happen with given inode until we reach
    truncate_pagecache. The list of potentially dangerous actions includes
    mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.

    The typical outcome of doing truncate_pagecache() with outdated arguments
    is data corruption from user point of view. This is (in some sense)
    acceptable in cases when the issue is triggered by a change of the file on
    the server (i.e. externally wrt fuse operation), but it is absolutely
    intolerable in scenarios when a single fuse client modifies a file without
    any external intervention. A real life case I discovered by fsx-linux
    looked like this:

    1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
    FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
    2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
    to the server synchronously, then calls fuse_change_attributes(). The
    latter updates i_size, releases fc->lock, but before comparing oldsize vs
    attr->size..
    3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
    updating attributes and i_size, but now oldsize is equal to
    outarg.attr.size because i_size has just been updated (step 2). Hence,
    fuse_do_setattr() returns w/o calling truncate_pagecache().
    4. As soon as ftruncate(2) completes, the user extends file size by
    write(2) making a hole in the middle of file, then reads data from the hole
    either by read(2) or mmap-ed read. The user expects to get zero data from
    the hole, but gets stale data because truncate_pagecache() is not executed
    yet.

    The scenario above illustrates one side of the problem: not truncating the
    page cache even though we should. Another side corresponds to truncating
    page cache too late, when the state of inode changed significantly.
    Theoretically, the following is possible:

    1. As in the previous scenario fuse_dentry_revalidate() discovered that
    i_size changed (due to our own fuse_do_setattr()) and is going to call
    truncate_pagecache() for some 'new_size' it believes valid right now. But
    by the time that particular truncate_pagecache() is called ...
    2. fuse_do_setattr() returns (either having called truncate_pagecache() or
    not -- it doesn't matter).
    3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
    4. mmap-ed write makes a page in the extended region dirty.

    The result will be the lost of data user wrote on the fourth step.

    The patch is a hotfix resolving the issue in a simplistic way: let's skip
    dangerous i_size update and truncate_pagecache if an operation changing
    file size is in progress. This simplistic approach looks correct for the
    cases w/o external changes. And to handle them properly, more sophisticated
    and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
    postpone it until the issue is well discussed on the mailing list(s).

    Changed in v2:
     - improved patch description to cover both sides of the issue.

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: add the fuse_inode::state field which we didn't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36c0787573a41cb35f822cadd1169a1ec8d9c84f
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: Ben Hutchings <ben@decadent.org.uk>

commit e68a3e371e86af95b646517848271f0a0c4d82a8
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: Ben Hutchings <ben@decadent.org.uk>

commit c68d59cb0bd639b89ebb9531b597d1e0861b22f7
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Sun Sep 1 14:36:47 2013 +0300

    ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

    commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

    hdmi_channel_allocation() tries to find a HDMI channel allocation that
    matches the number channels in the playback stream and contains only
    speakers that the HDMI sink has reported as available via EDID. If no
    such allocation is found, 0 (stereo audio) is used.

    Using CA 0 causes the audio causes the sink to discard everything except
    the first two channels (front left and front right).

    However, the sink may be capable of receiving more channels than it has
    speakers (and then perform downmix or discard the extra channels), in
    which case it is preferable to use a CA that contains extra channels
    than to use CA 0 which discards all the non-stereo channels.

    Additionally, it seems that HBR (HD) passthrough output does not work on
    Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
    channels not present in CA). This happens with all receivers that report
    a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
    codec.

    Add a fallback in the CA selection so that the CA channel count at least
    matches the stream channel count, even if the stream contains channels
    not present in the sink speaker descriptor.

    Thanks to GrimGriefer at OpenELEC forums for discovering that changing
    the sink speaker mask allowed HBR output.

    Reported-by: GrimGriefer
    Reported-by: Ashecrow
    Reported-by: Frank Zafka <kafkaesque1978@gmail.com>
    Reported-by: Peter Frühberger <fritsch@xbmc.org>
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c12047d733f77e59d0fa3a2f3d70582717d10ba
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: Ben Hutchings <ben@decadent.org.uk>

commit f46575554ac083111a3df50ddcd66e62973b49fe
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: Ben Hutchings <ben@decadent.org.uk>

commit a8f153e2b6506f3f227cc39b5951ebb063022fb7
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: Ben Hutchings <ben@decadent.org.uk>

commit 9b2e83539a23e25786243f28852801dceeb9a351
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: Ben Hutchings <ben@decadent.org.uk>

commit e3ee677053f573a3036c0b25c8bf480ec3d7b09d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 12 11:04:29 2013 -0400

    drm/edid: add quirk for Medion MD30217PG

    commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.

    This LCD monitor (1280x1024 native) has a completely
    bogus detailed timing (640x350@70hz).  User reports that
    1280x1024@60 has waves so prefer 1280x1024@75.

    Manufacturer: MED  Model: 7b8  Serial#: 99188
    Year: 2005  Week: 5
    EDID Version: 1.3
    Analog Display Input,  Input Voltage Level: 0.700/0.700 V
    Sync:  Separate
    Max Image Size [cm]: horiz.: 34  vert.: 27
    Gamma: 2.50
    DPMS capabilities: Off; RGB/Color Display
    First detailed timing is preferred mode
    redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
    blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
    Supported established timings:
    720x400@70Hz
    640x480@60Hz
    640x480@72Hz
    640x480@75Hz
    800x600@56Hz
    800x600@60Hz
    800x600@72Hz
    800x600@75Hz
    1024x768@60Hz
    1024x768@70Hz
    1024x768@75Hz
    1280x1024@75Hz
    Manufacturer's mask: 0
    Supported standard timings:
    Supported detailed timing:
    clock: 25.2 MHz   Image Size:  337 x 270 mm
    h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
    v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
    Monitor name: MD30217PG
    Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
    Serial No: 501099188
    EDID (in hex):
              00ffffffffffff0034a4b80774830100
              050f010368221b962a0c55a559479b24
              125054afcf00310a0101010101018180
              000000000000d60980a0205e63103060
              0200510e1100001e000000fc004d4433
              3032313750470a202020000000fd0038
              4c1e530e000a202020202020000000ff
              003530313039393138380a2020200078

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reported-by: friedrich@mailstation.de
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc96269f72229f0b175bc6716040331650656b41
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 30 10:46:00 2013 -0400

    USB: fix build error when CONFIG_PM_SLEEP isn't enabled

    commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

    This patch fixes a build error that occurs when CONFIG_PM is enabled
    and CONFIG_PM_SLEEP isn't:

    >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
          .pm = &usb_hcd_pci_pm_ops

    Since the usb_hcd_pci_pm_ops structure is defined and used when
    CONFIG_PM is enabled, its declaration should not be protected by
    CONFIG_PM_SLEEP.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 223f7a608895eb1b7bc39c7e9f0b43a45f24a58f
Author: Grant Likely <grant.likely@linaro.org>
Date:   Wed Aug 28 21:24:17 2013 +0100

    of: Fix missing memory initialization on FDT unflattening

    commit 0640332e073be9207f0784df43595c0c39716e42 upstream.

    Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
    the allocation function itself needs to zero memory before returning
    it. This is a follow up to patch 9e4012752, "of: fdt: fix memory
    initialization for expanded DT" which fixed one call site but missed
    another.

    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Acked-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ccd1fd4c43407721caa38ae034359bf8d9a1b34
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>
    [bwh: Backported to 3.2: use dbg_hid() not hid_err()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 934796aadc4cf907d21b9346b70383d520bd0eea
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

    commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

    The ECDT of ASUSTEK L4R doesn't provide correct command and data
    I/O ports.  The DSDT provides the correct information instead.

    For this reason, add this machine to quirk list for ECDT validation
    and use the EC information from the DSDT.

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60d3bfb16dc6db40932968fef856b81c625f8cec
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 26 15:01:40 2013 -0400

    USB: OHCI: Allow runtime PM without system sleep

    commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

    Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
    structure should be protected by CONFIG_PM rather than
    CONFIG_PM_SLEEP.

    Without this change, OHCI controllers won't do runtime suspend if
    system suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 332ad48cc7df186cf82659c7ef50be87b91572b3
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: Ben Hutchings <ben@decadent.org.uk>

commit 72b55735d2f26b1dfcb206773974c465ca7ef04d
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>
    [bwh: Backported to 3.2: use rt2x00_eeprom_read()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0140c2fcecbdc5fdf70a10060147df9d8201d79e
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Sat Aug 24 23:38:15 2013 -0400

    mmc: tmio_mmc_dma: fix PIO fallback on SDHI

    commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.

    I'm testing SH-Mobile SDHI driver in DMA mode with  a new DMA controller  using
    'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
    to PIO but all commands time out after that.  It turned out that the fallback
    code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
    to them cleared, so that the function bails out early instead  of clearing the
    DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
    162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock).
    Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
    tmio_mmc_start_dma_{rx|tx}() helps.

    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d081af233874da71a19aa6c530bf705d40e75391
Author: Daniel Mack <zonque@gmail.com>
Date:   Wed Aug 21 11:17:21 2013 +0200

    usb: ehci-mxc: check for pdata before dereferencing

    commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.

    Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
    boards") introduced code that could potentially lead to a NULL pointer
    dereference on driver removal.

    Fix this by checking for the value of pdata before dereferencing it.

    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 63a77d815edb770711efc6dc1b2777f49d83d287
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b18b089695313ab6b6a4f7569aa3a6c02ddcc3c6
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3807f1de20f7e7178a5854bb2066eac56790fe8f
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc69de30e8b7933db4f0bbbb7340d13dcec53238
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: Ben Hutchings <ben@decadent.org.uk>

commit 5c22eba5c7a15d915352743238facb571375107d
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: Ben Hutchings <ben@decadent.org.uk>

commit 44527b813312ca17cc98623b2cbc9ce1f473038a
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: Ben Hutchings <ben@decadent.org.uk>

commit 42cb87a101c3fd0e080e9605ee70275efdcc8280
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Aug 10 15:59:15 2013 +0200

    ath9k: fix rx descriptor related race condition

    commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.

    Similar to a race condition that exists in the tx path, the hardware
    might re-read the 'next' pointer of a descriptor of the last completed
    frame. This only affects non-EDMA (pre-AR93xx) devices.

    To deal with this race, defer clearing and re-linking a completed rx
    descriptor until the next one has been processed.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f4dc9ffcb6227d10335af8be77c0f9a1a43f2578
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>
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef9ba15dbf44cf0d84131f72f7e72e6af3d0a232
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: Ben Hutchings <ben@decadent.org.uk>

commit 512749a57bddcf4252991c0b4ade576bce4365e4
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f4705f790d07d747c236a074f1c82f941244025
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be47dfad8e39e8b849fd0487292b3998284ddbc2
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Jul 16 15:45:48 2013 +0800

    libceph: unregister request in __map_request failed and nofail == false

    commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.

    For nofail == false request, if __map_request failed, the caller does
    cleanup work, like releasing the relative pages.  It doesn't make any sense
    to retry this request.

    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd1d8b9014eae19a1f87197984f051760236a2bc
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: Ben Hutchings <ben@decadent.org.uk>

commit d6722e140e6f8054f6a136dc3e3a281d16756a46
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: Ben Hutchings <ben@decadent.org.uk>

commit 384a27453c74b2fc27063dd287acf72550a1ad0f
Author: Manoj Chourasia <mchourasia@nvidia.com>
Date:   Mon Jul 22 15:33:13 2013 +0530

    HID: hidraw: correctly deallocate memory on device disconnect

    commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

    This changes puts the commit 4fe9f8e203f back in place
    with the fixes for slab corruption because of the commit.

    When a device is unplugged, wait for all processes that
    have opened the device to close before deallocating the device.

    This commit was solving kernel crash because of the corruption in
    rb tree of vmalloc. The rootcause was the device data pointer was
    geting excessed after the memory associated with hidraw was freed.

    The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
    first and then calling delete operation on the list associated with
    that hidraw leading to slab corruption.

    Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
    Tested-by: Peter Wu <lekensteyn@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c3ffb34128a34e3b58332b0fb98e8311f5c0ba08
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Thu Nov 1 11:33:26 2012 +0100

    HID: hidraw: put old deallocation mechanism in place

    commit df0cfd6990347c20ae031f3f34137cba274f1972 upstream.

    This basically reverts commit 4fe9f8e203fda. It causes multiple problems,
    namely:

    - after rmmod/modprobe cycle of bus driver, the input is not claimed any
      more. This is likely because of misplaced hid_hw_close()
    - it causes memory corruption on hidraw_list

    As original patch author is not responding to requests to fix his patch,
    and the original deallocation mechanism is not exposing any problems, I
    am reverting back to it.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f9b44910e7456fd898fe5da1f45e2d463cbfb31
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 5 03:00:18 2012 +0000

    inetpeer: fix a race in inetpeer_gc_worker()

    [ Upstream commit 55432d2b543a4b6dfae54f5c432a566877a85d90 ]

    commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
    the routing cache) added a race :

    Before freeing an inetpeer, we must respect a RCU grace period, and make
    sure no user will attempt to increase refcnt.

    inetpeer_invalidate_tree() waits for a RCU grace period before inserting
    inetpeer tree into gc_list and waking the worker. At that time, no
    concurrent lookup can find a inetpeer in this tree.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c25e82c03fed5bf21418963cebc92de7797f9b3b
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Mar 6 21:20:26 2012 +0000

    inetpeer: Invalidate the inetpeer tree along with the routing cache

    [ Upstream commit 5faa5df1fa2024bd750089ff21dcc4191798263d ]

    We initialize the routing metrics with the values cached on the
    inetpeer in rt_init_metrics(). So if we have the metrics cached on the
    inetpeer, we ignore the user configured fib_metrics.

    To fix this issue, we replace the old tree with a fresh initialized
    inet_peer_base. The old tree is removed later with a delayed work queue.

    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e7b1664d08249f111c1802050c1e49435dde8e1d
Author: Ying Xue <ying.xue@windriver.com>
Date:   Thu Aug 16 12:09:07 2012 +0000

    tipc: fix lockdep warning during bearer initialization

    [ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

    When the lockdep validator is enabled, it will report the below
    warning when we enable a TIPC bearer:

    [ INFO: possible irq lock inversion dependency detected ]
    ---------------------------------------------------------
    Possible interrupt unsafe locking scenario:

            CPU0                    CPU1
            ----                    ----
       lock(ptype_lock);
                                    local_irq_disable();
                                    lock(tipc_net_lock);
                                    lock(ptype_lock);
       <Interrupt>
       lock(tipc_net_lock);

      *** DEADLOCK ***

    the shortest dependencies between 2nd lock and 1st lock:
      -> (ptype_lock){+.+...} ops: 10 {
    [...]
    SOFTIRQ-ON-W at:
                          [<c1089418>] __lock_acquire+0x528/0x13e0
                          [<c108a360>] lock_acquire+0x90/0x100
                          [<c1553c38>] _raw_spin_lock+0x38/0x50
                          [<c14651ca>] dev_add_pack+0x3a/0x60
                          [<c182da75>] arp_init+0x1a/0x48
                          [<c182dce5>] inet_init+0x181/0x27e
                          [<c1001114>] do_one_initcall+0x34/0x170
                          [<c17f7329>] kernel_init+0x110/0x1b2
                          [<c155b6a2>] kernel_thread_helper+0x6/0x10
    [...]
       ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
       ... acquired at:
        [<c108a360>] lock_acquire+0x90/0x100
        [<c1553c38>] _raw_spin_lock+0x38/0x50
        [<c14651ca>] dev_add_pack+0x3a/0x60
        [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
        [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
        [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
        [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
        [<c148e802>] genl_rcv_msg+0x232/0x280
        [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
        [<c148e5bc>] genl_rcv+0x1c/0x30
        [<c148d144>] netlink_unicast+0x174/0x1f0
        [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
        [<c1456bc1>] sock_aio_write+0x161/0x170
        [<c1135a7c>] do_sync_write+0xac/0xf0
        [<c11360f6>] vfs_write+0x156/0x170
        [<c11361e2>] sys_write+0x42/0x70
        [<c155b0df>] sysenter_do_call+0x12/0x38
    [...]
    }
      -> (tipc_net_lock){+..-..} ops: 4 {
    [...]
        IN-SOFTIRQ-R at:
                         [<c108953a>] __lock_acquire+0x64a/0x13e0
                         [<c108a360>] lock_acquire+0x90/0x100
                         [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                         [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                         [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                         [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                         [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                         [<c13c43d2>] pcnet32_poll+0x292/0x780
                         [<c146b00a>] net_rx_action+0xfa/0x1e0
                         [<c103a4be>] __do_softirq+0xae/0x1e0
    [...]
    }

    >From the log, we can see three different call chains between
    CPU0 and CPU1:

    Time 0 on CPU0:

      kernel_init()->inet_init()->dev_add_pack()

    At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

    Time 1 on CPU1:

      tipc_enable_bearer()->enable_bearer()->dev_add_pack()

    At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
    wants to take ptype_lock to register TIPC protocol handler into the
    networking stack.  But the ptype_lock has been taken by dev_add_pack()
    on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
    busy looping.

    Time 2 on CPU0:

      netif_receive_skb()->recv_msg()->tipc_recv_msg()

    At time 2, an incoming TIPC packet arrives at CPU0, hence
    tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
    to hold tipc_net_lock.  At the moment, below scenario happens:

    On CPU0, below is our sequence of taking locks:

      lock(ptype_lock)->lock(tipc_net_lock)

    On CPU1, our sequence of taking locks looks like:

      lock(tipc_net_lock)->lock(ptype_lock)

    Obviously deadlock may happen in this case.

    But please note the deadlock possibly doesn't occur at all when the
    first TIPC bearer is enabled.  Before enable_bearer() -- running on
    CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
    recv_msg()) is not registered successfully via dev_add_pack(), so
    the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
    message comes to CPU0. But when the second TIPC bearer is
    registered, the deadlock can perhaps really happen.

    To fix it, we will push the work of registering TIPC protocol
    handler into workqueue context. After the change, both paths taking
    ptype_lock are always in process contexts, thus, the deadlock should
    never occur.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6b16097de4dac9fe49b96d18972102ad80bab09d
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Aug 30 11:18:45 2013 +0200

    ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

    [ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

    RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
    unreachable) messages:
            5 - Source address failed ingress/egress policy
    	6 - Reject route to destination

    Now they are treated as protocol error and icmpv6_err_convert() converts them
    to EPROTO.

    RFC 4443 says:
    	"Codes 5 and 6 are more informative subsets of code 1."

    Treat codes 5 and 6 as code 1 (EACCES)

    Btw, connect() returning -EPROTO confuses firefox, so that fallback to
    other/IPv4 addresses does not work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=910773

    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f99d61dcdd2e1354ef54bbaee5ae71af926fa718
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 29 23:55:05 2013 +0200

    net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

    [ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

    While looking into MLDv1/v2 code, I noticed that bridging code does
    not convert it's max delay into jiffies for MLDv2 messages as we do
    in core IPv6' multicast code.

    RFC3810, 5.1.3. Maximum Response Code says:

      The Maximum Response Code field specifies the maximum time allowed
      before sending a responding Report. The actual time allowed, called
      the Maximum Response Delay, is represented in units of milliseconds,
      and is derived from the Maximum Response Code as follows: [...]

    As we update timers that work with jiffies, we need to convert it.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Linus Lüssing <linus.luessing@web.de>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7676306f0e6a3e07fbedd55ff958dda9877d70f2
Author: Thomas Graf <tgraf@suug.ch>
Date:   Tue Sep 3 13:37:01 2013 +0200

    ipv6: Don't depend on per socket memory for neighbour discovery messages

    [ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

    Allocating skbs when sending out neighbour discovery messages
    currently uses sock_alloc_send_skb() based on a per net namespace
    socket and thus share a socket wmem buffer space.

    If a netdevice is temporarily unable to transmit due to carrier
    loss or for other reasons, the queued up ndisc messages will cosnume
    all of the wmem space and will thus prevent from any more skbs to
    be allocated even for netdevices that are able to transmit packets.

    The number of neighbour discovery messages sent is very limited,
    use of alloc_skb() bypasses the socket wmem buffer size enforcement
    while the manual call to skb_set_owner_w() maintains the socket
    reference needed for the IPv6 output path.

    This patch has orginally been posted by Eric Dumazet in a modified
    form.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60c98d1e5c84a40ff062773ab403d1dace95019b
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:30:07 2013 +0200

    ipv6: drop packets with multiple fragmentation headers

    [ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

    It is not allowed for an ipv6 packet to contain multiple fragmentation
    headers. So discard packets which were already reassembled by
    fragmentation logic and send back a parameter problem icmp.

    The updates for RFC 6980 will come in later, I have to do a bit more
    research here.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7319901766396653fae51d2f37c5d23eb4537766
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:02:27 2013 +0200

    ipv6: remove max_addresses check from ipv6_create_tempaddr

    [ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

    Because of the max_addresses check attackers were able to disable privacy
    extensions on an interface by creating enough autoconfigured addresses:

    <http://seclists.org/oss-sec/2012/q4/292>

    But the check is not actually needed: max_addresses protects the
    kernel to install too many ipv6 addresses on an interface and guards
    addrconf_prefix_rcv to install further addresses as soon as this limit
    is reached. We only generate temporary addresses in direct response of
    a new address showing up. As soon as we filled up the maximum number of
    addresses of an interface, we stop installing more addresses and thus
    also stop generating more temp addresses.

    Even if the attacker tries to generate a lot of temporary addresses
    by announcing a prefix and removing it again (lifetime == 0) we won't
    install more temp addresses, because the temporary addresses do count
    to the maximum number of addresses, thus we would stop installing new
    autoconfigured addresses when the limit is reached.

    This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
    possible).

    Thanks to Ding Tianhong to bring this topic up again.

    Cc: Ding Tianhong <dingtianhong@huawei.com>
    Cc: George Kargiotakis <kargig@void.gr>
    Cc: P J P <ppandit@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60be6501b85ef304de4c77979ca89981fd268841
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 15:52:57 2013 +0300

    tun: signedness bug in tun_get_user()

    [ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

    The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
    not totally correct.  Because "len" and "sizeof()" are size_t type, that
    means they are never less than zero.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5cacde1a5f5e7c958dd1f2f74fd57fc3bf176784
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jul 31 09:03:56 2013 -0400

    8139cp: Add dma_mapping_error checking

    [ Upstream commits cf3c4c03060b688cbc389ebc5065ebcce5653e96 and
      d06f5187469eee1b2932c02fd093d113cfc60d5e (the latter is a fixup
      from Dave Jones) ]

    Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
    https://bugzilla.redhat.com/show_bug.cgi?id=947250

    It showed several backtraces arising for dma_map_* usage without checking the
    return code on the mapping.  Add the check and abort the rx/tx operation if its
    failed.  Untested as I have no hardware and the reporter has wandered off, but
    seems pretty straightforward.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 729d6632adca3fc51a2114862926e0343e0fe744
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Aug 7 02:34:31 2013 +0200

    ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

    [ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

    In case a subtree did not match we currently stop backtracking and return
    NULL (root table from fib_lookup). This could yield in invalid routing
    table lookups when using subtrees.

    Instead continue to backtrack until a valid subtree or node is found
    and return this match.

    Also remove unneeded NULL check.

    Reported-by: Teco Boot <teco@inf-net.nl>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Cc: David Lamparter <equinox@diac24.net>
    Cc: <boutier@pps.univ-paris-diderot.fr>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a6c214e53401db1e237937c41c401449229aee9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 20:05:12 2013 -0700

    tcp: cubic: fix bug in bictcp_acked()

    [ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

    While investigating about strange increase of retransmit rates
    on hosts ~24 days after boot, Van found hystart was disabled
    if ca->epoch_start was 0, as following condition is true
    when tcp_time_stamp high order bit is set.

    (s32)(tcp_time_stamp - ca->epoch_start) < HZ

    Quoting Van :

     At initialization & after every loss ca->epoch_start is set to zero so
     I believe that the above line will turn off hystart as soon as the 2^31
     bit is set in tcp_time_stamp & hystart will stay off for 24 days.
     I think we've observed that cubic's restart is too aggressive without
     hystart so this might account for the higher drop rate we observe.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9588edd010b5b8a6bd0543279687b4af9c463ab0
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 17:10:15 2013 -0700

    tcp: cubic: fix overflow error in bictcp_update()

    [ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

    commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
    overflow error in bictcp_update() in following code :

    /* change the unit from HZ to bictcp_HZ */
    t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
          ca->epoch_start) << BICTCP_HZ) / HZ;

    Because msecs_to_jiffies() being unsigned long, compiler does
    implicit type promotion.

    We really want to constrain (tcp_time_stamp - ca->epoch_start)
    to a signed 32bit value, or else 't' has unexpected high values.

    This bugs triggers an increase of retransmit rates ~24 days after
    boot [1], as the high order bit of tcp_time_stamp flips.

    [1] for hosts with HZ=1000

    Big thanks to Van Jacobson for spotting this problem.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c521d041383bf06b840ee031002cf4d24d7e4673
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 11:18:49 2013 -0700

    fib_trie: remove potential out of bound access

    [ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

    AddressSanitizer [1] dynamic checker pointed a potential
    out of bound access in leaf_walk_rcu()

    We could allocate one more slot in tnode_new() to leave the prefetch()
    in-place but it looks not worth the pain.

    Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

    [1] :
    https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 243e49a55f2b4c04e05efe3b863592b7b8b14ca2
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Fri Aug 2 18:36:40 2013 +0400

    net: check net.core.somaxconn sysctl values

    [ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

    It's possible to assign an invalid value to the net.core.somaxconn
    sysctl variable, because there is no checks at all.

    The sk_max_ack_backlog field of the sock structure is defined as
    unsigned short. Therefore, the backlog argument in inet_listen()
    shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
    is truncated to the somaxconn value. So, the somaxconn value shouldn't
    exceed 65535 (USHRT_MAX).
    Also, negative values of somaxconn are meaningless.

    before:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    net.core.somaxconn = 65536
    $ sysctl -w net.core.somaxconn=-100
    net.core.somaxconn = -100

    after:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    error: "Invalid argument" setting key "net.core.somaxconn"
    $ sysctl -w net.core.somaxconn=-100
    error: "Invalid argument" setting key "net.core.somaxconn"

    Based on a prior patch from Changli Gao.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Reported-by: Changli Gao <xiaosuo@gmail.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 746db946cde024822904dbe590b43cae7589ad30
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu Aug 1 22:32:07 2013 -0700

    htb: fix sign extension bug

    [ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

    When userspace passes a large priority value
    the assignment of the unsigned value hopt->prio
    to  signed int cl->prio causes cl->prio to become negative and the
    comparison is with TC_HTB_NUMPRIO is always false.

    The result is that HTB crashes by referencing outside
    the array when processing packets. With this patch the large value
    wraps around like other values outside the normal range.

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

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 8b5ed99a4f9f2969c47501530da6dcd5a91f8f3d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Oct 26 21:06:14 2013 +0100

    Linux 3.2.52

commit 9203ceb63af1d8a2c1557ff01cbb2d75e960d2ef
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Oct 4 10:52:36 2013 +0200

    can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX

    commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream.

    In patch

        0d1862e can: flexcan: fix flexcan_chip_start() on imx6

    the loop in flexcan_chip_start() that iterates over all mailboxes after the
    soft reset of the CAN core was removed. This loop put all mailboxes (even the
    ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63,
    this aborts any pending TX messages.

    After a cold boot there is random garbage in the mailboxes, which leads to
    spontaneous transmit of CAN frames during first activation. Further if the
    interface was disabled with a pending message (usually due to an error
    condition on the CAN bus), this message is retransmitted after enabling the
    interface again.

    This patch fixes the regression by:
    1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX
    FIFO, 8 is used by TX.
    2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that
    mailbox is aborted.

    Cc: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2:
     - Adjust context
     - Hardware local echo is still enabled]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c23e05d637c461d13e473bee595ae781622b5ebf
Author: Claudiu Manoil <claudiu.manoil@freescale.com>
Date:   Sun Sep 23 22:39:08 2012 +0000

    gianfar: Change default HW Tx queue scheduling mode

    commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

    This is primarily to address transmission timeout occurrences, when
    multiple H/W Tx queues are being used concurrently. Because in
    the priority scheduling mode the controller does not service the
    Tx queues equally (but in ascending index order), Tx timeouts are
    being triggered rightaway for a basic test with multiple simultaneous
    connections like:
    iperf -c <server_ip> -n 100M -P 8

    resulting in kernel trace:
    NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue <X> timed out
    ------------[ cut here ]------------
    WARNING: at net/sched/sch_generic.c:255
    ...
    and controller reset during intense traffic, and possibly further
    complications.

    This patch changes the default H/W Tx scheduling setting (TXSCHED)
    for multi-queue devices, from priority scheduling mode to a weighted
    round robin mode with equal weights for all H/W Tx queues, and
    addresses the issue above.

    Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c617fda8c72a55a65cc5320cadb916f5981cfeb
Author: David Rientjes <rientjes@google.com>
Date:   Mon Apr 29 15:06:11 2013 -0700

    mm, show_mem: suppress page counts in non-blockable contexts

    commit 4b59e6c4730978679b414a8da61514a2518da512 upstream.

    On large systems with a lot of memory, walking all RAM to determine page
    types may take a half second or even more.

    In non-blockable contexts, the page allocator will emit a page allocation
    failure warning unless __GFP_NOWARN is specified.  In such contexts, irqs
    are typically disabled and such a lengthy delay may even result in NMI
    watchdog timeouts.

    To fix this, suppress the page walk in such contexts when printing the
    page allocation failure warning.

    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dffcc9dc54d22e3c5eadd5d42835fa47ee25b071
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b376352641ccc12b53a3aa555b9a477a8c0f44e
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Oct 2 14:57:51 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>
    [Ian Abbott: This patch applies to kernels 2.6.34.y through to 3.5.y
     inclusive.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0cf9986114ab4e16bf36a51814a0f688c79961a7
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: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c60ce91cc52e53619bb919ad5ff8891b75c2a4dd
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: Ben Hutchings <ben@decadent.org.uk>

commit 47fa3c9b8352d4f403118b01f8a97fff1353c30b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ecc545c9a903910bd23e40b6492d7b4f7ec03bc
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: Ben Hutchings <ben@decadent.org.uk>

commit e1fd636836ca3c883c172dc619a909e988a2f4b5
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: Ben Hutchings <ben@decadent.org.uk>

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

    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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 177c417ca4d861640b35ecf4fcd0f7563543e01f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 17:06:39 2013 +0100

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

    This reverts commit de77b7955c3985ca95f64af3cb10557eb17eacee, which was
    commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec upstream.

    This fix was only appropriate for Linux 3.7 onward, and introduced a
    regression when applied to earlier versions.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b1455ca9e8c44171e550980c82295162e7e31646
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: Ben Hutchings <ben@decadent.org.uk>

commit 04f82ec3a0a5399c17eb2053fa6833de064216b3
Author: Vasily Titskiy <qehgt0@gmail.com>
Date:   Fri Aug 30 18:25:04 2013 -0400

    HID: usbhid: quirk for N-Trig DuoSense Touch Screen

    commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream.

    The DuoSense touchscreen device causes a 10 second timeout. This fix
    removes the delay.

    Signed-off-by: Vasily Titskiy <qehgt0@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 297c511a4b6c6cff190525aec83b0d2de39fc3d8
Author: Stefan Kriwanek <dev@stefankriwanek.de>
Date:   Sun Aug 25 10:46:13 2013 +0200

    HID: Fix Speedlink VAD Cezanne support for some devices

    commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream.

    Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing
    than already done.

    I made sure through testing that this patch would not interfere with the proper
    working of a device that is bug-free. (The driver drops EV_REL events with
    abs(val) >= 256, which are not achievable even on the highest laser resolution
    hardware setting.)

    Signed-off-by: Stefan Kriwanek <mail@stefankriwanek.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6c756ccc62d4b6168f70fc5a3da5004a5f56751
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ed1d8009cc6f1b534ed94388cb7980b4a55797e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 49a58f5fa9d71155be5b6211030c281084f336a3
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6272221247a80adf0c36bf4f6ac8a4d7dcfb7e5b
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31e0470e9906c42edfc4cf00404d4eb3a99dac7e
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b
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>

commit 068d848f7f3d3db8c68e517ba93cb170914a64d8
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Jul 18 10:55:16 2013 +0800

    macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

    commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream.

    We try to linearize part of the skb when the number of iov is greater than
    MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
    one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
    network.

    Solve this problem by calculate the pages needed for iov before trying to do
    zerocopy and switch to use copy instead of zerocopy if it needs more than
    MAX_SKB_FRAGS.

    This is done through introducing a new helper to count the pages for iov, and
    call uarg->callback() manually when switching from zerocopy to copy to notify
    vhost.

    We can do further optimization on top.

    This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73
    (macvtap: zerocopy: validate vectors before building skb).

    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: callback only takes one argument]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 98ed9120b030962558276d8fd602eabb41a57d05
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Oct 20 13:37:39 2013 +0100

    Revert "zram: use zram->lock to protect zram_free_page() in swap free notify path"

    This reverts commit 9e443904906ca2b5b3ae71f34ac4a4fa6905623e, which
    was commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.

    Taking the semaphore here leads to sleeping in atomic context.  This
    was fixed in mainline commit a0c516cbfc74 ("zram: don't grab mutex in
    zram_slot_free_noity") but that is too difficult to backport.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f0ce108f5e1c6a443548746b6f01b450f71a407
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon Apr 22 17:12:54 2013 +0000

    powerpc/pseries/lparcfg: Fix possible overflow are more than 1026

    commit 5676005acf26ab7e924a8438ea4746e47d405762 upstream.

    need set '\0' for 'local_buffer'.

    SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
    rtas_data_buf may truncated in memcpy.

    if contents are really truncated.
      the splpar_strlen is more than 1026. the next while loop checking will
      not find the end of buffer. that will cause memory access violation.

    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f362f08b46213452508f76bac4b74a4e5f5c4294
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Jan 5 15:51:13 2012 +1000

    m68knommu: clean up linker script

    commit f84f52a5c15db7d14a534815f27253b001735183 upstream.

    There is a lot of years of collected cruft in the m68knommu linker script.
    Clean it all up and use the well defined linker script support macros.

    Support is maintained for building both ROM/FLASH based and RAM based setups.
    No major changes to section layouts, though the rodata section is now lumped
    in with the read/write data section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e4063bdbee2ead4042b6caf4f603ed0cb6c0fc6
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Wed Oct 19 13:50:35 2011 +1000

    m68k: use non-MMU linker script for ColdFire MMU builds

    commit ed865e31a8273be200db9ddcdb6b844e48777abd upstream.

    Use the non-MMU linker script for ColdFire builds when we are building
    for MMU enabled. The image layout is correct for loading on existing
    ColdFire dev boards. The only addition required to the current non-MMU
    linker script is to add support for the fixup section.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Matt Waddel <mwaddel@yahoo.com>
    Acked-by: Kurt Mahan <kmahan@xmission.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2187004fa49f190aa89eb1e3cc01623d62f480a8
Author: Greg Ungerer <gerg@uclinux.org>
Date:   Thu Dec 8 15:39:05 2011 +1000

    m68k: consolidate the vmlinux.lds linker scripts

    commit 40c1b9cfeedf79b909c961e0e00a13497e80bc82 upstream.

    The merge of m68knommu left the linker scripts a little disorganized.
    Some consistent naming and squashing two of scripts that just include
    others can simplify things a lot.

    So merge the two simple including scripts, and rename the nommu script
    to be consistent with the existing m68k linker scripts.

    Signed-off-by: Greg Ungerer <gerg@uclinux.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 38e57772a96d382cc6783f26cb152702f686b25f
Author: Julius Werner <jwerner@chromium.org>
Date:   Tue Jul 30 19:51:20 2013 -0700

    usb: core: don't try to reset_device() a port that got just disconnected

    commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream.

    The USB hub driver's event handler contains a check to catch SuperSpeed
    devices that transitioned into the SS.Inactive state and tries to fix
    them with a reset. It decides whether to do a plain hub port reset or
    call the usb_reset_device() function based on whether there was a device
    attached to the port.

    However, there are device/hub combinations (found with a JetFlash
    Transcend mass storage stick (8564:1000) on the root hub of an Intel
    LynxPoint PCH) which can transition to the SS.Inactive state on
    disconnect (and stay there long enough for the host to notice). In this
    case, above-mentioned reset check will call usb_reset_device() on the
    stale device data structure. The kernel will send pointless LPM control
    messages to the no longer connected device address and can even cause
    several 5 second khubd stalls on some (buggy?) host controllers, before
    finally accepting the device's fate amongst a flurry of error messages.

    This patch makes the choice of reset dependent on the port status that
    has just been read from the hub in addition to the existence of an
    in-kernel data structure for the device, and only proceeds with the more
    extensive reset if both are valid.

    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93d9de3ace93eebf680fbf8e3ae1ab27b85410e9
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Jul 26 17:12:56 2013 +0200

    debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

    commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

    debugfs_remove_recursive() is wrong,

    1. it wrongly assumes that !list_empty(d_subdirs) means that this
       dir should be removed.

       This is not that bad by itself, but:

    2. if d_subdirs does not becomes empty after __debugfs_remove()
       it gives up and silently fails, it doesn't even try to remove
       other entries.

       However ->d_subdirs can be non-empty because it still has the
       already deleted !debugfs_positive() entries.

    3. simple_release_fs() is called even if __debugfs_remove() fails.

    Suppose we have

    	dir1/
    		dir2/
    			file2
    		file1

    and someone opens dir1/dir2/file2.

    Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
    away.

    But debugfs_remove_recursive(dir1) silently fails and doesn't remove
    this directory. Because it tries to delete (the already deleted)
    dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
    logic.

    Test-case:

    	#!/bin/sh

    	cd /sys/kernel/debug/tracing
    	echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
    	sleep 1000 < events/probe/sigprocmask/id &
    	echo -n >| kprobe_events

    	[ -d events/probe ] && echo "ERR!! failed to rm probe"

    And after that it is not possible to create another probe entry.

    With this patch debugfs_remove_recursive() skips !debugfs_positive()
    files although this is not strictly needed. The most important change
    is that it does not try to make ->d_subdirs empty, it simply scans
    the whole list(s) recursively and removes as much as possible.

    Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fa59eed8556c7f149f8ab9cea0f42f7843eecc81
Author: Salman Qazi <sqazi@google.com>
Date:   Thu Jun 14 15:31:09 2012 -0700

    perf: Use css_tryget() to avoid propping up css refcount

    commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

    An rmdir pushes css's ref count to zero.  However, if the associated
    directory is open at the time, the dentry ref count is non-zero.  If
    the fd for this directory is then passed into perf_event_open, it
    does a css_get().  This bounces the ref count back up from zero.  This
    is a problem by itself.  But what makes it turn into a crash is the
    fact that we end up doing an extra dput, since we perform a dput
    when css_put sees the ref count go down to zero.

    css_tryget() does not fall into that trap. So, we use that instead.

    Reproduction test-case for the bug:

     #include <unistd.h>
     #include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     #include <linux/unistd.h>
     #include <linux/perf_event.h>
     #include <string.h>
     #include <errno.h>
     #include <stdio.h>

     #define PERF_FLAG_PID_CGROUP    (1U << 2)

     int perf_event_open(struct perf_event_attr *hw_event_uptr,
                         pid_t pid, int cpu, int group_fd, unsigned long flags) {
             return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                     group_fd, flags);
     }

     /*
      * Directly poke at the perf_event bug, since it's proving hard to repro
      * depending on where in the kernel tree.  what moved?
      */
     int main(int argc, char **argv)
     {
            int fd;
            struct perf_event_attr attr;
            memset(&attr, 0, sizeof(attr));
            attr.exclude_kernel = 1;
            attr.size = sizeof(attr);
            mkdir("/dev/cgroup/perf_event/blah", 0777);
            fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
            perror("open");
            rmdir("/dev/cgroup/perf_event/blah");
            sleep(2);
            perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
            perror("perf_event_open");
            close(fd);
            return 0;
     }

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8d7b731f1f799f225f0c968ccb0508397657d87
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 587e5bf9a64470d080aab287d95c11a43b777cc5
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: Ben Hutchings <ben@decadent.org.uk>

commit 7af4fd8cf2529729f2981f10a83f7c277c1ec684
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: Ben Hutchings <ben@decadent.org.uk>

commit e1b92701b2b5e1b2ee1f181075ca6df4cef667e4
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: Ben Hutchings <ben@decadent.org.uk>

commit b108c975f4d210be89eacdec93bf8d34e7edbcc6
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: Ben Hutchings <ben@decadent.org.uk>

commit 19452ae3b32db6b1c33f9248f36f188fb439cc77
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: Ben Hutchings <ben@decadent.org.uk>

commit 49e3d709efa929fc179531a0bff55df92520b432
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: Ben Hutchings <ben@decadent.org.uk>

commit a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8
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: Ben Hutchings <ben@decadent.org.uk>

commit 765844f8edd831563fc646c7f747abf89eef4d4d
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: Ben Hutchings <ben@decadent.org.uk>

commit 003efcca2ad3e471e9103688a715bd33e29cb37b
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: Ben Hutchings <ben@decadent.org.uk>

commit 1d49f0ffe3731e90677c3a1cab524f144a06c48f
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

    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>
    Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 710cfab1cd10b1c227ddd20df646bd9e5494aa46
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: Ben Hutchings <ben@decadent.org.uk>

commit 10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3
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: Ben Hutchings <ben@decadent.org.uk>

commit e381c716ed158b0b77879625fa58929f1a59a940
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: Ben Hutchings <ben@decadent.org.uk>

commit dee5590a22d03d7e974ef6956747d717ef5de061
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: Ben Hutchings <ben@decadent.org.uk>

commit 669c81001fd0bd914fb2a1c15ddbb427de8a8373
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: Ben Hutchings <ben@decadent.org.uk>

commit af7e0f4a91ca9049ee9e541f8a98e762a12e9b9b
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: Ben Hutchings <ben@decadent.org.uk>

commit 2eb90b30797b3c908b597e4a2a700d6ef9ae0196
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: Ben Hutchings <ben@decadent.org.uk>

commit 836f6cb46716e36cb8d31a402c6661af5c895135
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 20:51:21 2013 +0200

    net: sctp: fix smatch warning in sctp_send_asconf_del_ip

    [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ]

    This was originally reported in [1] and posted by Neil Horman [2], he said:

      Fix up a missed null pointer check in the asconf code. If we don't find
      a local address, but we pass in an address length of more than 1, we may
      dereference a NULL laddr pointer. Currently this can't happen, as the only
      users of the function pass in the value 1 as the addrcnt parameter, but
      its not hot path, and it doesn't hurt to check for NULL should that ever
      be the case.

    The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
    from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
    while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
    so that we do *not* find a single address in the association's bind address
    list that is not in the packed array of addresses. If this happens when we
    have an established association with ASCONF-capable peers, then we could get
    a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
    and call later sctp_make_asconf_update_ip() with NULL laddr.

    BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
    and return with an error earlier. As this is incredably unintuitive and error
    prone, add a check to catch at least future bugs here. As Neil says, its not
    hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
    single-homed host").

     [1] http://www.spinics.net/lists/linux-sctp/msg02132.html
     [2] http://www.spinics.net/lists/linux-sctp/msg02133.html

    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Michio Honda <micchie@sfc.wide.ad.jp>
    Acked-By: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7def7d7b236bd3e90df969ac9b3540777619c57
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: Ben Hutchings <ben@decadent.org.uk>

commit 21958b854649fcd3a7b50db4f00573d488da1edb
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: Ben Hutchings <ben@decadent.org.uk>

commit 28cfcc851d5c8a7075ea8bb9b8695bb376f6872d
Author: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Date:   Wed Oct 2 00:34:10 2013 +0530

    powerpc/sysfs: Disable writing to PURR in guest mode

    commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.

    arch/powerpc/kernel/sysfs.c exports PURR with write permission.
    This may be valid for kernel in phyp mode. But writing to
    the file in guest mode causes crash due to a priviledge violation

    Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - CPUs are sysdev and we must use the sysdev API]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0b2d10f8f2e686c9f4b718251765f09f77ee8088
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 17:11:35 2013 +1000

    powerpc: Restore registers on error exit from csum_partial_copy_generic()

    commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.

    The csum_partial_copy_generic() function saves the PowerPC non-volatile
    r14, r15, and r16 registers for the main checksum-and-copy loop.
    Unfortunately, it fails to restore them upon error exit from this loop,
    which results in silent corruption of these registers in the presumably
    rare event of an access exception within that loop.

    This commit therefore restores these register on error exit from the loop.

    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>
    [bwh: Backported to 3.2: register name macros use lower-case 'r']
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13ce0c4a399a654effc40a9a57e87ac23cf19267
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: Ben Hutchings <ben@decadent.org.uk>

commit 408318734877aca9f11a8d7d1835456305c61f4d
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ccebcc74c81d8399c7b204aea47c1f33b09c2b17
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Mon Sep 30 13:45:12 2013 -0700

    nilfs2: fix issue with race condition of competition between segments for dirty blocks

    commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.

    Many NILFS2 users were reported about strange file system corruption
    (for example):

       NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
       NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)

    But such error messages are consequence of file system's issue that takes
    place more earlier.  Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
    and Anton Eliasson <devel@antoneliasson.se> were reported about another
    issue not so recently.  These reports describe the issue with segctor
    thread's crash:

      BUG: unable to handle kernel paging request at 0000000000004c83
      IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]

      Call Trace:
       nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
       nilfs_segctor_construct+0x17b/0x290 [nilfs2]
       nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
       kthread+0xc0/0xd0
       ret_from_fork+0x7c/0xb0

    These two issues have one reason.  This reason can raise third issue
    too.  Third issue results in hanging of segctor thread with eating of
    100% CPU.

    REPRODUCING PATH:

    One of the possible way or the issue reproducing was described by
    Jermoe me Poulin <jeromepoulin@gmail.com>:

    1. init S to get to single user mode.
    2. sysrq+E to make sure only my shell is running
    3. start network-manager to get my wifi connection up
    4. login as root and launch "screen"
    5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
    6. lscp | xz -9e > lscp.txt.xz
    7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
    8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
    9. start a screen and launch strace -f -o find-cat.log -t find
    /mnt/nilfs -type f -exec cat {} > /dev/null \;
    10. start a screen and launch strace -f -o apt-get.log -t apt-get update
    11. launch the last command again as it did not crash the first time
    12. apt-get crashes
    13. ps aux > ps-aux-crashed.log
    13. sysrq+W
    14. sysrq+E  wait for everything to terminate
    15. sysrq+SUSB

    Simplified way of the issue reproducing is starting kernel compilation
    task and "apt-get update" in parallel.

    REPRODUCIBILITY:

    The issue is reproduced not stable [60% - 80%].  It is very important to
    have proper environment for the issue reproducing.  The critical
    conditions for successful reproducing:

    (1) It should have big modified file by mmap() way.

    (2) This file should have the count of dirty blocks are greater that
        several segments in size (for example, two or three) from time to time
        during processing.

    (3) It should be intensive background activity of files modification
        in another thread.

    INVESTIGATION:

    First of all, it is possible to see that the reason of crash is not valid
    page address:

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
      NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783

    Moreover, value of b_page (0x1a82) is 6786.  This value looks like segment
    number.  And b_blocknr with b_size values look like block numbers.  So,
    buffer_head's pointer points on not proper address value.

    Detailed investigation of the issue is discovered such picture:

      [-----------------------------SEGMENT 6783-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783

      [-----------------------------SEGMENT 6784-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15

      [-----------------------------SEGMENT 6785-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12

      NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785

      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82

      BUG: unable to handle kernel paging request at 0000000000001a82
      IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]

    Usually, for every segment we collect dirty files in list.  Then, dirty
    blocks are gathered for every dirty file, prepared for write and
    submitted by means of nilfs_segbuf_submit_bh() call.  Finally, it takes
    place complete write phase after calling nilfs_end_bio_write() on the
    block layer.  Buffers/pages are marked as not dirty on final phase and
    processed files removed from the list of dirty files.

    It is possible to see that we had three prepare_write and submit_bio
    phases before segbuf_wait and complete_write phase.  Moreover, segments
    compete between each other for dirty blocks because on every iteration
    of segments processing dirty buffer_heads are added in several lists of
    payload_buffers:

      [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8

    The next pointer is the same but prev pointer has changed.  It means
    that buffer_head has next pointer from one list but prev pointer from
    another.  Such modification can be made several times.  And, finally, it
    can be resulted in various issues: (1) segctor hanging, (2) segctor
    crashing, (3) file system metadata corruption.

    FIX:
    This patch adds:

    (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
        for every proccessed dirty block;

    (2) checking of BH_Async_Write flag in
        nilfs_lookup_dirty_data_buffers() and
        nilfs_lookup_dirty_node_buffers();

    (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
        nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().

    Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
    Reported-by: Anton Eliasson <devel@antoneliasson.se>
    Cc: Paul Fertser <fercerpav@gmail.com>
    Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
    Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
    Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
    Cc: Elmer Zhang <freeboy6716@gmail.com>
    Cc: Kenneth Langga <klangga@gmail.com>
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: nilfs_clear_dirty_page() has not been separated
     from nilfs_clear_dirty_pages()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ec4a1dc57b7822ff5fc2cbe8aa19d0b4eaa70bd
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Sep 27 12:15:05 2013 +0200

    can: flexcan: fix flexcan_chip_start() on imx6

    commit 0d1862ea1a5bb876cf05555a7307080cb75bf379 upstream.

    In the flexcan_chip_start() function first the flexcan core is going through
    the soft reset sequence, then the RX FIFO is enabled.

    With the hardware is put into FIFO mode, message buffers 1...7 are reserved by
    the FIFO engine. The remaining message buffers are in reset default values.
    This patch removes the bogus initialization of the message buffers, as it
    causes an imprecise external abort on imx6.

    Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
    Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 798761949ee8ddb4a25888cf7c0722fbacbc70cc
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Thu Sep 26 13:01:44 2013 -0700

    usb: dwc3: add support for Merrifield

    commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

    Add PCI id for Intel Merrifield

    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47bd9ac912fe4b2f1f38efec89c3fe19628d6287
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue Sep 17 10:38:13 2013 +0300

    usb: dwc3: pci: add support for BayTrail

    commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

    Add PCI id for Intel BayTrail.

    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6f95357cb8bba2debf6b29347f4334e3cc12f897
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: Ben Hutchings <ben@decadent.org.uk>

commit e9c2770cfd8038419657e596410ce42bdb2e1a5b
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: Ben Hutchings <ben@decadent.org.uk>

commit 571d473b0b99c8035fa8df8d1fbbac5b00814bb6
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: Ben Hutchings <ben@decadent.org.uk>

commit 29003506beae5ad634f002d16cd73543337e2a26
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c9e34fa1d28f3e04e9fbe4cdce5aa9a70c4952f6
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 24 15:45:25 2013 -0400

    USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

    commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream.

    Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
    field in their pci_driver structures should be protected by CONFIG_PM
    rather than CONFIG_PM_SLEEP.  The corresponding change has already
    been made for ohci-hcd.

    Without this change, controllers won't do runtime suspend if system
    suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7db4eda80eb05f7b0a6c7771920a2eea011b4f80
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c1a25b78eb6480c0c708e21fd746cf8b4dae9e7
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: Ben Hutchings <ben@decadent.org.uk>

commit e69de31ca0e0517bee4a99556b443fbde75ede6a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 23 10:38:26 2013 -0400

    drm/radeon: disable tests/benchmarks if accel is disabled

    commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.

    The tests are only usable if the acceleration engines have
    been successfully initialized.

    Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: there is only one test: radeon_test_moves()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3986574eb0563e306cd88d529700a4eef4fb330
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: Ben Hutchings <ben@decadent.org.uk>

commit 12c689b675726d6965320b489d0be7cb4e96d17d
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: Ben Hutchings <ben@decadent.org.uk>

commit 1dbbbf3262547a7f2d28a40224c8e3d017201c66
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: Ben Hutchings <ben@decadent.org.uk>

commit 4f31ab80a2bf09ea0e57c351842da1e647cfe9da
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:50 2013 +0200

    serial: pch_uart: fix tty-kref leak in dma-rx path

    commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

    Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

    Note that the tty ref isn't really needed anymore, but as the leak has
    always been there, fixing it before removing should makes it easier to
    backport the fix.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 73449fe73fa3d46232176fe6c73702b29b6479d2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Sep 10 12:50:49 2013 +0200

    serial: pch_uart: fix tty-kref leak in rx-error path

    commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

    Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
    deadlock when pch_uart as console") which never put its tty reference.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6510909931472dadd7c13c6b0781fcf6a26813eb
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: Ben Hutchings <ben@decadent.org.uk>

commit f1f1e271a236290e402aa439e2f67057d857ed21
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date:   Mon Sep 2 14:57:51 2013 +0300

    Bluetooth: Add support for BCM20702A0 [0b05, 17cb]

    commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.

    Yet another vendor specific ID for this chipset; this one for the ASUS
    USB-BT400 Bluetooth 4.0 adapter.

    T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cb Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=000272C64400
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50a0ff96891fff6544c83441abf2f0484f94c833
Author: Peng Chen <pengchen@qti.qualcomm.com>
Date:   Fri Aug 30 17:41:40 2013 +0800

    Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.

    commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.

    usb device info:

    T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8f6513652249d566a4c7b6feaf13eee789ccd7a
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Sep 13 18:33:16 2013 -0400

    drm/radeon: fix panel scaling with eDP and LVDS bridges

    commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.

    We were using the wrong set_properly callback so we always
    ended up with Full scaling even if something else (Center or
    Full aspect) was selected.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fc99ffd3d8beb8103ce3d6cc3f9b3630c8a1e594
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: Ben Hutchings <ben@decadent.org.uk>

commit cb5f54477a5f46b11df2a8f3f8ac3a933a502ad3
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: logitech-dj: validate output report details

    commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream.

    A HID device could send a malicious output report that would cause the
    logitech-dj HID driver to leak kernel memory contents to the device, or
    trigger a NULL dereference during initialization:

    [  304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
    ...
    [  304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    [  304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90

    CVE-2013-2895

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: drop inapplicable changes to
     logi_dj_recv_send_report()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32eed83c07cc2b6e7487fc7c4e47938d7906f3f8
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Sep 11 21:56:57 2013 +0200

    HID: validate feature and input report details

    commit cc6b54aa54bf40b762cab45a9fc8aa81653146eb upstream.

    When dealing with usage_index, be sure to properly use unsigned instead of
    int to avoid overflows.

    When working on report fields, always validate that their report_counts are
    in bounds.
    Without this, a HID device could report a malicious feature report that
    could trick the driver into a heap overflow:

    [  634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
    ...
    [  676.469629] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

    CVE-2013-2897

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2:
     - Drop inapplicable changes to hid_usage::usage_index initialisation and
       to hid_report_raw_event()
     - Adjust context in report_features()
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3da8b771809032cf829869cabbffbed96cd47bc4
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 11 21:56:54 2013 +0200

    HID: LG: validate HID output report details

    commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream.

    A HID device could send a malicious output report that would cause the
    lg, lg3, and lg4 HID drivers to write beyond the output report allocation
    during an event, causing a heap overflow:

    [  325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
    ...
    [  414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten

    Additionally, while lg2 did correctly validate the report details, it was
    cleaned up and shortened.

    CVE-2013-2893

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e0f897f0929d27dc5d7de5cc24ccbeac572e5176
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: Ben Hutchings <ben@decadent.org.uk>

commit 9c8ea9f2d66ff437dd25da392a104947c703d975
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9f6e2b7e9f392b07d6773a846511b8f1b6d3ef0
Author: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Date:   Tue Sep 10 18:16:36 2013 +0900

    sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones

    commit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream.

    There is a small race between copy_process() and cgroup_attach_task()
    where child->se.parent,cfs_rq points to invalid (old) ones.

            parent doing fork()      | someone moving the parent to another cgroup
      -------------------------------+---------------------------------------------
        copy_process()
          + dup_task_struct()
            -> parent->se is copied to child->se.
               se.parent,cfs_rq of them point to old ones.

                                         cgroup_attach_task()
                                           + cgroup_task_migrate()
                                             -> parent->cgroup is updated.
                                           + cpu_cgroup_attach()
                                             + sched_move_task()
                                               + task_move_group_fair()
                                                 +- set_task_rq()
                                                    -> se.parent,cfs_rq of parent
                                                       are updated.

          + cgroup_fork()
            -> parent->cgroup is copied to child->cgroup. (*1)
          + sched_fork()
            + task_fork_fair()
              -> se.parent,cfs_rq of child are accessed
                 while they point to old ones. (*2)

    In the worst case, this bug can lead to "use-after-free" and cause a panic,
    because it's new cgroup's refcount that is incremented at (*1),
    so the old cgroup(and related data) can be freed before (*2).

    In fact, a panic caused by this bug was originally caught in RHEL6.4.

        BUG: unable to handle kernel NULL pointer dereference at (null)
        IP: [<ffffffff81051e3e>] sched_slice+0x6e/0xa0
        [...]
        Call Trace:
         [<ffffffff81051f25>] place_entity+0x75/0xa0
         [<ffffffff81056a3a>] task_fork_fair+0xaa/0x160
         [<ffffffff81063c0b>] sched_fork+0x6b/0x140
         [<ffffffff8106c3c2>] copy_process+0x5b2/0x1450
         [<ffffffff81063b49>] ? wake_up_new_task+0xd9/0x130
         [<ffffffff8106d2f4>] do_fork+0x94/0x460
         [<ffffffff81072a9e>] ? sys_wait4+0xae/0x100
         [<ffffffff81009598>] sys_clone+0x28/0x30
         [<ffffffff8100b393>] stub_clone+0x13/0x20
         [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

    Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 494fcf9f236d2ced8fede73189961526491db1dc
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: Ben Hutchings <ben@decadent.org.uk>

commit 56cbe7f7ee88a2eb06226ab3b5b4333fe0df663f
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: Ben Hutchings <ben@decadent.org.uk>

commit 89b2cd31a07fcee833fd0284eaeb7d57419a698f
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: Ben Hutchings <ben@decadent.org.uk>

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

    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: Ben Hutchings <ben@decadent.org.uk>

commit 1d7af96c344aff74a021d39c0c9063b15bda522c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Sep 9 10:54:22 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)

    commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.

    The OUTPUT_ENABLE action jumps past the point in the coder where
    the data_offset is set on certain rs780 cards.  This worked
    previously because the OUTPUT_ENABLE action is always called
    immediately after the ENABLE action so the data_offset remained
    set.  In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
    (drm/radeon/atom: initialize more atom interpretor elements to 0),
    we explictly reset data_offset to 0 between atom calls which then
    caused this to fail.  The fix is to just skip calling the
    OUTPUT_ENABLE action on the problematic chipsets.  The ENABLE
    action does the same thing and more.  Ultimately, we could
    probably drop the OUTPUT_ENABLE action all together on DCE3
    asics.

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

    v2: only rs880 seems to be affected

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a3c0d076acaa13d53e48bee1d8ceaed32201223
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: Ben Hutchings <ben@decadent.org.uk>

commit 4741b69849e0b01077becf6d2cb902dca9984d01
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbeecda256bab53034d5a7f0c79c2f99219ce7c3
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Aug 23 10:50:39 2013 +0300

    drm/i915: try not to lose backlight CBLV precision

    commit cac6a5ae0118832936eb162ec4cedb30f2422bcc upstream.

    ACPI has _BCM and _BQC methods to set and query the backlight
    brightness, respectively. The ACPI opregion has variables BCLP and CBLV
    to hold the requested and current backlight brightness, respectively.

    The BCLP variable has range 0..255 while the others have range
    0..100. This means the _BCM method has to scale the brightness for BCLP,
    and the gfx driver has to scale the requested value back for CBLV. If
    the _BQC method uses the CBLV variable (apparently some implementations
    do, some don't) for current backlight level reporting, there's room for
    rounding errors.

    Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values
    that were passed to _BCM, presuming the _BCM simply uses bclp = (in *
    255) / 100 for scaling to BCLP.

    Reference: https://gist.github.com/aaronlu/6314920
    Reported-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Aaron Lu <aaron.lu@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2:
     - Adjust context
     - ASLE region is treated as normal memory rather than __iomem]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e4f24883632f4d46d4b43ae37a76932343a69839
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: Ben Hutchings <ben@decadent.org.uk>

commit 45e61ad38c9493eec7ece2bfe09bde2433cdaa87
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: Ben Hutchings <ben@decadent.org.uk>

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

    HID: picolcd_core: validate output report details

    commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream.

    A HID device could send a malicious output report that would cause the
    picolcd HID driver to trigger a NULL dereference during attr file writing.

    [jkosina@suse.cz: changed

    	report->maxfield < 1

    to

    	report->maxfield != 1

    as suggested by Bruno].

    CVE-2013-2899

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Bruno Prémont <bonbons@linux-vserver.org>
    Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c790976bda06884d78a1f8208d74e566ac41954e
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: Ben Hutchings <ben@decadent.org.uk>

commit db841e0c2b59b27c521512930d4e818d92ee1caa
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: Ben Hutchings <ben@decadent.org.uk>

commit b5f9e3533584d2fb6c90c63da767b85421b07def
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Tue Sep 3 14:28:38 2013 +0200

    fuse: readdir: check for slash in names

    commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream.

    Userspace can add names containing a slash character to the directory
    listing.  Don't allow this as it could cause all sorts of trouble.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: drop changes to parse_dirplusfile() which we
     don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9eb9bfa030d8a49d54f0e4ae671e33f406bbbeff
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Jul 3 16:17:34 2013 -0300

    hdpvr: fix iteration over uninitialized lists in hdpvr_probe()

    commit 2e923a0527ac439e135b9961e58d3acd876bba10 upstream.

    free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
    but if something bad happens before that, error handling code calls hdpvr_delete(),
    which contains iteration over the lists (via hdpvr_free_buffers()).
    The patch moves the lists initialization to the beginning and by the way fixes
    goto label in error handling of registering videodev.
    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 559a2e36f047ac7e1ab27c489322cfd1409dd842
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Mar 19 09:34:58 2013 -0300

    hdpvr: register the video node at the end of probe

    commit 280847b532433ffe7a22795f926327805a127162 upstream.

    Video nodes can be used at once after registration, so make sure the full
    initialization is done before registering them.

    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9417815157557d273325641f7ad2b6dd147276f4
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Aug 30 17:06:04 2013 +0400

    fuse: hotfix truncate_pagecache() issue

    commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream.

    The way how fuse calls truncate_pagecache() from fuse_change_attributes()
    is completely wrong. Because, w/o i_mutex held, we never sure whether
    'oldsize' and 'attr->size' are valid by the time of execution of
    truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
    released fc->lock in the middle of fuse_change_attributes(), we completely
    loose control of actions which may happen with given inode until we reach
    truncate_pagecache. The list of potentially dangerous actions includes
    mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.

    The typical outcome of doing truncate_pagecache() with outdated arguments
    is data corruption from user point of view. This is (in some sense)
    acceptable in cases when the issue is triggered by a change of the file on
    the server (i.e. externally wrt fuse operation), but it is absolutely
    intolerable in scenarios when a single fuse client modifies a file without
    any external intervention. A real life case I discovered by fsx-linux
    looked like this:

    1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
    FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
    2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
    to the server synchronously, then calls fuse_change_attributes(). The
    latter updates i_size, releases fc->lock, but before comparing oldsize vs
    attr->size..
    3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
    updating attributes and i_size, but now oldsize is equal to
    outarg.attr.size because i_size has just been updated (step 2). Hence,
    fuse_do_setattr() returns w/o calling truncate_pagecache().
    4. As soon as ftruncate(2) completes, the user extends file size by
    write(2) making a hole in the middle of file, then reads data from the hole
    either by read(2) or mmap-ed read. The user expects to get zero data from
    the hole, but gets stale data because truncate_pagecache() is not executed
    yet.

    The scenario above illustrates one side of the problem: not truncating the
    page cache even though we should. Another side corresponds to truncating
    page cache too late, when the state of inode changed significantly.
    Theoretically, the following is possible:

    1. As in the previous scenario fuse_dentry_revalidate() discovered that
    i_size changed (due to our own fuse_do_setattr()) and is going to call
    truncate_pagecache() for some 'new_size' it believes valid right now. But
    by the time that particular truncate_pagecache() is called ...
    2. fuse_do_setattr() returns (either having called truncate_pagecache() or
    not -- it doesn't matter).
    3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
    4. mmap-ed write makes a page in the extended region dirty.

    The result will be the lost of data user wrote on the fourth step.

    The patch is a hotfix resolving the issue in a simplistic way: let's skip
    dangerous i_size update and truncate_pagecache if an operation changing
    file size is in progress. This simplistic approach looks correct for the
    cases w/o external changes. And to handle them properly, more sophisticated
    and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
    postpone it until the issue is well discussed on the mailing list(s).

    Changed in v2:
     - improved patch description to cover both sides of the issue.

    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    [bwh: Backported to 3.2: add the fuse_inode::state field which we didn't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36c0787573a41cb35f822cadd1169a1ec8d9c84f
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: Ben Hutchings <ben@decadent.org.uk>

commit e68a3e371e86af95b646517848271f0a0c4d82a8
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: Ben Hutchings <ben@decadent.org.uk>

commit c68d59cb0bd639b89ebb9531b597d1e0861b22f7
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Sun Sep 1 14:36:47 2013 +0300

    ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA

    commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream.

    hdmi_channel_allocation() tries to find a HDMI channel allocation that
    matches the number channels in the playback stream and contains only
    speakers that the HDMI sink has reported as available via EDID. If no
    such allocation is found, 0 (stereo audio) is used.

    Using CA 0 causes the audio causes the sink to discard everything except
    the first two channels (front left and front right).

    However, the sink may be capable of receiving more channels than it has
    speakers (and then perform downmix or discard the extra channels), in
    which case it is preferable to use a CA that contains extra channels
    than to use CA 0 which discards all the non-stereo channels.

    Additionally, it seems that HBR (HD) passthrough output does not work on
    Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
    channels not present in CA). This happens with all receivers that report
    a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
    codec.

    Add a fallback in the CA selection so that the CA channel count at least
    matches the stream channel count, even if the stream contains channels
    not present in the sink speaker descriptor.

    Thanks to GrimGriefer at OpenELEC forums for discovering that changing
    the sink speaker mask allowed HBR output.

    Reported-by: GrimGriefer
    Reported-by: Ashecrow
    Reported-by: Frank Zafka <kafkaesque1978@gmail.com>
    Reported-by: Peter Frühberger <fritsch@xbmc.org>
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c12047d733f77e59d0fa3a2f3d70582717d10ba
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: Ben Hutchings <ben@decadent.org.uk>

commit f46575554ac083111a3df50ddcd66e62973b49fe
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: Ben Hutchings <ben@decadent.org.uk>

commit a8f153e2b6506f3f227cc39b5951ebb063022fb7
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: Ben Hutchings <ben@decadent.org.uk>

commit 9b2e83539a23e25786243f28852801dceeb9a351
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: Ben Hutchings <ben@decadent.org.uk>

commit e3ee677053f573a3036c0b25c8bf480ec3d7b09d
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 12 11:04:29 2013 -0400

    drm/edid: add quirk for Medion MD30217PG

    commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.

    This LCD monitor (1280x1024 native) has a completely
    bogus detailed timing (640x350@70hz).  User reports that
    1280x1024@60 has waves so prefer 1280x1024@75.

    Manufacturer: MED  Model: 7b8  Serial#: 99188
    Year: 2005  Week: 5
    EDID Version: 1.3
    Analog Display Input,  Input Voltage Level: 0.700/0.700 V
    Sync:  Separate
    Max Image Size [cm]: horiz.: 34  vert.: 27
    Gamma: 2.50
    DPMS capabilities: Off; RGB/Color Display
    First detailed timing is preferred mode
    redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
    blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
    Supported established timings:
    720x400@70Hz
    640x480@60Hz
    640x480@72Hz
    640x480@75Hz
    800x600@56Hz
    800x600@60Hz
    800x600@72Hz
    800x600@75Hz
    1024x768@60Hz
    1024x768@70Hz
    1024x768@75Hz
    1280x1024@75Hz
    Manufacturer's mask: 0
    Supported standard timings:
    Supported detailed timing:
    clock: 25.2 MHz   Image Size:  337 x 270 mm
    h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
    v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
    Monitor name: MD30217PG
    Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
    Serial No: 501099188
    EDID (in hex):
              00ffffffffffff0034a4b80774830100
              050f010368221b962a0c55a559479b24
              125054afcf00310a0101010101018180
              000000000000d60980a0205e63103060
              0200510e1100001e000000fc004d4433
              3032313750470a202020000000fd0038
              4c1e530e000a202020202020000000ff
              003530313039393138380a2020200078

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reported-by: friedrich@mailstation.de
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc96269f72229f0b175bc6716040331650656b41
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 30 10:46:00 2013 -0400

    USB: fix build error when CONFIG_PM_SLEEP isn't enabled

    commit 9d8924297cd9c256c23c02abae40202563452453 upstream.

    This patch fixes a build error that occurs when CONFIG_PM is enabled
    and CONFIG_PM_SLEEP isn't:

    >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
          .pm = &usb_hcd_pci_pm_ops

    Since the usb_hcd_pci_pm_ops structure is defined and used when
    CONFIG_PM is enabled, its declaration should not be protected by
    CONFIG_PM_SLEEP.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 223f7a608895eb1b7bc39c7e9f0b43a45f24a58f
Author: Grant Likely <grant.likely@linaro.org>
Date:   Wed Aug 28 21:24:17 2013 +0100

    of: Fix missing memory initialization on FDT unflattening

    commit 0640332e073be9207f0784df43595c0c39716e42 upstream.

    Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
    the allocation function itself needs to zero memory before returning
    it. This is a follow up to patch 9e4012752, "of: fdt: fix memory
    initialization for expanded DT" which fixed one call site but missed
    another.

    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Acked-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ccd1fd4c43407721caa38ae034359bf8d9a1b34
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>
    [bwh: Backported to 3.2: use dbg_hid() not hid_err()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 934796aadc4cf907d21b9346b70383d520bd0eea
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

    commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

    The ECDT of ASUSTEK L4R doesn't provide correct command and data
    I/O ports.  The DSDT provides the correct information instead.

    For this reason, add this machine to quirk list for ECDT validation
    and use the EC information from the DSDT.

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60d3bfb16dc6db40932968fef856b81c625f8cec
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Aug 26 15:01:40 2013 -0400

    USB: OHCI: Allow runtime PM without system sleep

    commit 69820e01aa756b8d228143d997f71523c1e97984 upstream.

    Since ohci-hcd supports runtime PM, the .pm field in its pci_driver
    structure should be protected by CONFIG_PM rather than
    CONFIG_PM_SLEEP.

    Without this change, OHCI controllers won't do runtime suspend if
    system suspend or hibernation isn't enabled.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 332ad48cc7df186cf82659c7ef50be87b91572b3
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: Ben Hutchings <ben@decadent.org.uk>

commit 72b55735d2f26b1dfcb206773974c465ca7ef04d
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>
    [bwh: Backported to 3.2: use rt2x00_eeprom_read()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0140c2fcecbdc5fdf70a10060147df9d8201d79e
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Sat Aug 24 23:38:15 2013 -0400

    mmc: tmio_mmc_dma: fix PIO fallback on SDHI

    commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream.

    I'm testing SH-Mobile SDHI driver in DMA mode with  a new DMA controller  using
    'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
    to PIO but all commands time out after that.  It turned out that the fallback
    code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
    to them cleared, so that the function bails out early instead  of clearing the
    DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
    162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock).
    Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
    tmio_mmc_start_dma_{rx|tx}() helps.

    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d081af233874da71a19aa6c530bf705d40e75391
Author: Daniel Mack <zonque@gmail.com>
Date:   Wed Aug 21 11:17:21 2013 +0200

    usb: ehci-mxc: check for pdata before dereferencing

    commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream.

    Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
    boards") introduced code that could potentially lead to a NULL pointer
    dereference on driver removal.

    Fix this by checking for the value of pdata before dereferencing it.

    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 63a77d815edb770711efc6dc1b2777f49d83d287
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b18b089695313ab6b6a4f7569aa3a6c02ddcc3c6
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3807f1de20f7e7178a5854bb2066eac56790fe8f
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc69de30e8b7933db4f0bbbb7340d13dcec53238
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: Ben Hutchings <ben@decadent.org.uk>

commit 5c22eba5c7a15d915352743238facb571375107d
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: Ben Hutchings <ben@decadent.org.uk>

commit 44527b813312ca17cc98623b2cbc9ce1f473038a
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: Ben Hutchings <ben@decadent.org.uk>

commit 42cb87a101c3fd0e080e9605ee70275efdcc8280
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sat Aug 10 15:59:15 2013 +0200

    ath9k: fix rx descriptor related race condition

    commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.

    Similar to a race condition that exists in the tx path, the hardware
    might re-read the 'next' pointer of a descriptor of the last completed
    frame. This only affects non-EDMA (pre-AR93xx) devices.

    To deal with this race, defer clearing and re-linking a completed rx
    descriptor until the next one has been processed.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f4dc9ffcb6227d10335af8be77c0f9a1a43f2578
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>
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef9ba15dbf44cf0d84131f72f7e72e6af3d0a232
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: Ben Hutchings <ben@decadent.org.uk>

commit 512749a57bddcf4252991c0b4ade576bce4365e4
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f4705f790d07d747c236a074f1c82f941244025
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>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be47dfad8e39e8b849fd0487292b3998284ddbc2
Author: majianpeng <majianpeng@gmail.com>
Date:   Tue Jul 16 15:45:48 2013 +0800

    libceph: unregister request in __map_request failed and nofail == false

    commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.

    For nofail == false request, if __map_request failed, the caller does
    cleanup work, like releasing the relative pages.  It doesn't make any sense
    to retry this request.

    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bd1d8b9014eae19a1f87197984f051760236a2bc
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: Ben Hutchings <ben@decadent.org.uk>

commit d6722e140e6f8054f6a136dc3e3a281d16756a46
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: Ben Hutchings <ben@decadent.org.uk>

commit 384a27453c74b2fc27063dd287acf72550a1ad0f
Author: Manoj Chourasia <mchourasia@nvidia.com>
Date:   Mon Jul 22 15:33:13 2013 +0530

    HID: hidraw: correctly deallocate memory on device disconnect

    commit 212a871a3934beccf43431608c27ed2e05a476ec upstream.

    This changes puts the commit 4fe9f8e203f back in place
    with the fixes for slab corruption because of the commit.

    When a device is unplugged, wait for all processes that
    have opened the device to close before deallocating the device.

    This commit was solving kernel crash because of the corruption in
    rb tree of vmalloc. The rootcause was the device data pointer was
    geting excessed after the memory associated with hidraw was freed.

    The commit 4fe9f8e203f was buggy as it was also freeing the hidraw
    first and then calling delete operation on the list associated with
    that hidraw leading to slab corruption.

    Signed-off-by: Manoj Chourasia <mchourasia@nvidia.com>
    Tested-by: Peter Wu <lekensteyn@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c3ffb34128a34e3b58332b0fb98e8311f5c0ba08
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Thu Nov 1 11:33:26 2012 +0100

    HID: hidraw: put old deallocation mechanism in place

    commit df0cfd6990347c20ae031f3f34137cba274f1972 upstream.

    This basically reverts commit 4fe9f8e203fda. It causes multiple problems,
    namely:

    - after rmmod/modprobe cycle of bus driver, the input is not claimed any
      more. This is likely because of misplaced hid_hw_close()
    - it causes memory corruption on hidraw_list

    As original patch author is not responding to requests to fix his patch,
    and the original deallocation mechanism is not exposing any problems, I
    am reverting back to it.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f9b44910e7456fd898fe5da1f45e2d463cbfb31
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 5 03:00:18 2012 +0000

    inetpeer: fix a race in inetpeer_gc_worker()

    [ Upstream commit 55432d2b543a4b6dfae54f5c432a566877a85d90 ]

    commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
    the routing cache) added a race :

    Before freeing an inetpeer, we must respect a RCU grace period, and make
    sure no user will attempt to increase refcnt.

    inetpeer_invalidate_tree() waits for a RCU grace period before inserting
    inetpeer tree into gc_list and waking the worker. At that time, no
    concurrent lookup can find a inetpeer in this tree.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c25e82c03fed5bf21418963cebc92de7797f9b3b
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Mar 6 21:20:26 2012 +0000

    inetpeer: Invalidate the inetpeer tree along with the routing cache

    [ Upstream commit 5faa5df1fa2024bd750089ff21dcc4191798263d ]

    We initialize the routing metrics with the values cached on the
    inetpeer in rt_init_metrics(). So if we have the metrics cached on the
    inetpeer, we ignore the user configured fib_metrics.

    To fix this issue, we replace the old tree with a fresh initialized
    inet_peer_base. The old tree is removed later with a delayed work queue.

    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e7b1664d08249f111c1802050c1e49435dde8e1d
Author: Ying Xue <ying.xue@windriver.com>
Date:   Thu Aug 16 12:09:07 2012 +0000

    tipc: fix lockdep warning during bearer initialization

    [ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

    When the lockdep validator is enabled, it will report the below
    warning when we enable a TIPC bearer:

    [ INFO: possible irq lock inversion dependency detected ]
    ---------------------------------------------------------
    Possible interrupt unsafe locking scenario:

            CPU0                    CPU1
            ----                    ----
       lock(ptype_lock);
                                    local_irq_disable();
                                    lock(tipc_net_lock);
                                    lock(ptype_lock);
       <Interrupt>
       lock(tipc_net_lock);

      *** DEADLOCK ***

    the shortest dependencies between 2nd lock and 1st lock:
      -> (ptype_lock){+.+...} ops: 10 {
    [...]
    SOFTIRQ-ON-W at:
                          [<c1089418>] __lock_acquire+0x528/0x13e0
                          [<c108a360>] lock_acquire+0x90/0x100
                          [<c1553c38>] _raw_spin_lock+0x38/0x50
                          [<c14651ca>] dev_add_pack+0x3a/0x60
                          [<c182da75>] arp_init+0x1a/0x48
                          [<c182dce5>] inet_init+0x181/0x27e
                          [<c1001114>] do_one_initcall+0x34/0x170
                          [<c17f7329>] kernel_init+0x110/0x1b2
                          [<c155b6a2>] kernel_thread_helper+0x6/0x10
    [...]
       ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
       ... acquired at:
        [<c108a360>] lock_acquire+0x90/0x100
        [<c1553c38>] _raw_spin_lock+0x38/0x50
        [<c14651ca>] dev_add_pack+0x3a/0x60
        [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
        [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
        [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
        [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
        [<c148e802>] genl_rcv_msg+0x232/0x280
        [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
        [<c148e5bc>] genl_rcv+0x1c/0x30
        [<c148d144>] netlink_unicast+0x174/0x1f0
        [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
        [<c1456bc1>] sock_aio_write+0x161/0x170
        [<c1135a7c>] do_sync_write+0xac/0xf0
        [<c11360f6>] vfs_write+0x156/0x170
        [<c11361e2>] sys_write+0x42/0x70
        [<c155b0df>] sysenter_do_call+0x12/0x38
    [...]
    }
      -> (tipc_net_lock){+..-..} ops: 4 {
    [...]
        IN-SOFTIRQ-R at:
                         [<c108953a>] __lock_acquire+0x64a/0x13e0
                         [<c108a360>] lock_acquire+0x90/0x100
                         [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                         [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                         [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                         [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                         [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                         [<c13c43d2>] pcnet32_poll+0x292/0x780
                         [<c146b00a>] net_rx_action+0xfa/0x1e0
                         [<c103a4be>] __do_softirq+0xae/0x1e0
    [...]
    }

    >From the log, we can see three different call chains between
    CPU0 and CPU1:

    Time 0 on CPU0:

      kernel_init()->inet_init()->dev_add_pack()

    At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

    Time 1 on CPU1:

      tipc_enable_bearer()->enable_bearer()->dev_add_pack()

    At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
    wants to take ptype_lock to register TIPC protocol handler into the
    networking stack.  But the ptype_lock has been taken by dev_add_pack()
    on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
    busy looping.

    Time 2 on CPU0:

      netif_receive_skb()->recv_msg()->tipc_recv_msg()

    At time 2, an incoming TIPC packet arrives at CPU0, hence
    tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
    to hold tipc_net_lock.  At the moment, below scenario happens:

    On CPU0, below is our sequence of taking locks:

      lock(ptype_lock)->lock(tipc_net_lock)

    On CPU1, our sequence of taking locks looks like:

      lock(tipc_net_lock)->lock(ptype_lock)

    Obviously deadlock may happen in this case.

    But please note the deadlock possibly doesn't occur at all when the
    first TIPC bearer is enabled.  Before enable_bearer() -- running on
    CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
    recv_msg()) is not registered successfully via dev_add_pack(), so
    the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
    message comes to CPU0. But when the second TIPC bearer is
    registered, the deadlock can perhaps really happen.

    To fix it, we will push the work of registering TIPC protocol
    handler into workqueue context. After the change, both paths taking
    ptype_lock are always in process contexts, thus, the deadlock should
    never occur.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6b16097de4dac9fe49b96d18972102ad80bab09d
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Aug 30 11:18:45 2013 +0200

    ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

    [ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

    RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
    unreachable) messages:
            5 - Source address failed ingress/egress policy
    	6 - Reject route to destination

    Now they are treated as protocol error and icmpv6_err_convert() converts them
    to EPROTO.

    RFC 4443 says:
    	"Codes 5 and 6 are more informative subsets of code 1."

    Treat codes 5 and 6 as code 1 (EACCES)

    Btw, connect() returning -EPROTO confuses firefox, so that fallback to
    other/IPv4 addresses does not work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=910773

    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f99d61dcdd2e1354ef54bbaee5ae71af926fa718
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 29 23:55:05 2013 +0200

    net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

    [ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

    While looking into MLDv1/v2 code, I noticed that bridging code does
    not convert it's max delay into jiffies for MLDv2 messages as we do
    in core IPv6' multicast code.

    RFC3810, 5.1.3. Maximum Response Code says:

      The Maximum Response Code field specifies the maximum time allowed
      before sending a responding Report. The actual time allowed, called
      the Maximum Response Delay, is represented in units of milliseconds,
      and is derived from the Maximum Response Code as follows: [...]

    As we update timers that work with jiffies, we need to convert it.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Linus Lüssing <linus.luessing@web.de>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7676306f0e6a3e07fbedd55ff958dda9877d70f2
Author: Thomas Graf <tgraf@suug.ch>
Date:   Tue Sep 3 13:37:01 2013 +0200

    ipv6: Don't depend on per socket memory for neighbour discovery messages

    [ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

    Allocating skbs when sending out neighbour discovery messages
    currently uses sock_alloc_send_skb() based on a per net namespace
    socket and thus share a socket wmem buffer space.

    If a netdevice is temporarily unable to transmit due to carrier
    loss or for other reasons, the queued up ndisc messages will cosnume
    all of the wmem space and will thus prevent from any more skbs to
    be allocated even for netdevices that are able to transmit packets.

    The number of neighbour discovery messages sent is very limited,
    use of alloc_skb() bypasses the socket wmem buffer size enforcement
    while the manual call to skb_set_owner_w() maintains the socket
    reference needed for the IPv6 output path.

    This patch has orginally been posted by Eric Dumazet in a modified
    form.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60c98d1e5c84a40ff062773ab403d1dace95019b
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:30:07 2013 +0200

    ipv6: drop packets with multiple fragmentation headers

    [ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

    It is not allowed for an ipv6 packet to contain multiple fragmentation
    headers. So discard packets which were already reassembled by
    fragmentation logic and send back a parameter problem icmp.

    The updates for RFC 6980 will come in later, I have to do a bit more
    research here.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7319901766396653fae51d2f37c5d23eb4537766
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:02:27 2013 +0200

    ipv6: remove max_addresses check from ipv6_create_tempaddr

    [ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

    Because of the max_addresses check attackers were able to disable privacy
    extensions on an interface by creating enough autoconfigured addresses:

    <http://seclists.org/oss-sec/2012/q4/292>

    But the check is not actually needed: max_addresses protects the
    kernel to install too many ipv6 addresses on an interface and guards
    addrconf_prefix_rcv to install further addresses as soon as this limit
    is reached. We only generate temporary addresses in direct response of
    a new address showing up. As soon as we filled up the maximum number of
    addresses of an interface, we stop installing more addresses and thus
    also stop generating more temp addresses.

    Even if the attacker tries to generate a lot of temporary addresses
    by announcing a prefix and removing it again (lifetime == 0) we won't
    install more temp addresses, because the temporary addresses do count
    to the maximum number of addresses, thus we would stop installing new
    autoconfigured addresses when the limit is reached.

    This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
    possible).

    Thanks to Ding Tianhong to bring this topic up again.

    Cc: Ding Tianhong <dingtianhong@huawei.com>
    Cc: George Kargiotakis <kargig@void.gr>
    Cc: P J P <ppandit@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60be6501b85ef304de4c77979ca89981fd268841
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 15:52:57 2013 +0300

    tun: signedness bug in tun_get_user()

    [ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

    The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
    not totally correct.  Because "len" and "sizeof()" are size_t type, that
    means they are never less than zero.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5cacde1a5f5e7c958dd1f2f74fd57fc3bf176784
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jul 31 09:03:56 2013 -0400

    8139cp: Add dma_mapping_error checking

    [ Upstream commits cf3c4c03060b688cbc389ebc5065ebcce5653e96 and
      d06f5187469eee1b2932c02fd093d113cfc60d5e (the latter is a fixup
      from Dave Jones) ]

    Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
    https://bugzilla.redhat.com/show_bug.cgi?id=947250

    It showed several backtraces arising for dma_map_* usage without checking the
    return code on the mapping.  Add the check and abort the rx/tx operation if its
    failed.  Untested as I have no hardware and the reporter has wandered off, but
    seems pretty straightforward.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 729d6632adca3fc51a2114862926e0343e0fe744
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Aug 7 02:34:31 2013 +0200

    ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

    [ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

    In case a subtree did not match we currently stop backtracking and return
    NULL (root table from fib_lookup). This could yield in invalid routing
    table lookups when using subtrees.

    Instead continue to backtrack until a valid subtree or node is found
    and return this match.

    Also remove unneeded NULL check.

    Reported-by: Teco Boot <teco@inf-net.nl>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Cc: David Lamparter <equinox@diac24.net>
    Cc: <boutier@pps.univ-paris-diderot.fr>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a6c214e53401db1e237937c41c401449229aee9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 20:05:12 2013 -0700

    tcp: cubic: fix bug in bictcp_acked()

    [ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

    While investigating about strange increase of retransmit rates
    on hosts ~24 days after boot, Van found hystart was disabled
    if ca->epoch_start was 0, as following condition is true
    when tcp_time_stamp high order bit is set.

    (s32)(tcp_time_stamp - ca->epoch_start) < HZ

    Quoting Van :

     At initialization & after every loss ca->epoch_start is set to zero so
     I believe that the above line will turn off hystart as soon as the 2^31
     bit is set in tcp_time_stamp & hystart will stay off for 24 days.
     I think we've observed that cubic's restart is too aggressive without
     hystart so this might account for the higher drop rate we observe.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9588edd010b5b8a6bd0543279687b4af9c463ab0
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 17:10:15 2013 -0700

    tcp: cubic: fix overflow error in bictcp_update()

    [ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

    commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
    overflow error in bictcp_update() in following code :

    /* change the unit from HZ to bictcp_HZ */
    t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
          ca->epoch_start) << BICTCP_HZ) / HZ;

    Because msecs_to_jiffies() being unsigned long, compiler does
    implicit type promotion.

    We really want to constrain (tcp_time_stamp - ca->epoch_start)
    to a signed 32bit value, or else 't' has unexpected high values.

    This bugs triggers an increase of retransmit rates ~24 days after
    boot [1], as the high order bit of tcp_time_stamp flips.

    [1] for hosts with HZ=1000

    Big thanks to Van Jacobson for spotting this problem.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c521d041383bf06b840ee031002cf4d24d7e4673
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 11:18:49 2013 -0700

    fib_trie: remove potential out of bound access

    [ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

    AddressSanitizer [1] dynamic checker pointed a potential
    out of bound access in leaf_walk_rcu()

    We could allocate one more slot in tnode_new() to leave the prefetch()
    in-place but it looks not worth the pain.

    Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

    [1] :
    https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 243e49a55f2b4c04e05efe3b863592b7b8b14ca2
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Fri Aug 2 18:36:40 2013 +0400

    net: check net.core.somaxconn sysctl values

    [ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

    It's possible to assign an invalid value to the net.core.somaxconn
    sysctl variable, because there is no checks at all.

    The sk_max_ack_backlog field of the sock structure is defined as
    unsigned short. Therefore, the backlog argument in inet_listen()
    shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
    is truncated to the somaxconn value. So, the somaxconn value shouldn't
    exceed 65535 (USHRT_MAX).
    Also, negative values of somaxconn are meaningless.

    before:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    net.core.somaxconn = 65536
    $ sysctl -w net.core.somaxconn=-100
    net.core.somaxconn = -100

    after:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    error: "Invalid argument" setting key "net.core.somaxconn"
    $ sysctl -w net.core.somaxconn=-100
    error: "Invalid argument" setting key "net.core.somaxconn"

    Based on a prior patch from Changli Gao.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Reported-by: Changli Gao <xiaosuo@gmail.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 746db946cde024822904dbe590b43cae7589ad30
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu Aug 1 22:32:07 2013 -0700

    htb: fix sign extension bug

    [ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

    When userspace passes a large priority value
    the assignment of the unsigned value hopt->prio
    to  signed int cl->prio causes cl->prio to become negative and the
    comparison is with TC_HTB_NUMPRIO is always false.

    The result is that HTB crashes by referencing outside
    the array when processing packets. With this patch the large value
    wraps around like other values outside the normal range.

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

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
Squashed commit 3.4.52 -> 3.4.53
commit 66c8d27b7084ecd4d7d17dc7a69e6f993f5a2549
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Nov 28 14:02:07 2013 +0000

    Linux 3.2.53

commit 654999008741f5f3721229338db19800e2f0d9e7
Author: Ming Lei <ming.lei@canonical.com>
Date:   Thu Oct 31 16:34:17 2013 -0700

    lib/scatterlist.c: don't flush_kernel_dcache_page on slab page

    commit 3d77b50c5874b7e923be946ba793644f82336b75 upstream.

    Commit b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
    functions") introduces two sg buffer copy helpers, and calls
    flush_kernel_dcache_page() on pages in SG list after these pages are
    written to.

    Unfortunately, the commit may introduce a potential bug:

     - Before sending some SCSI commands, kmalloc() buffer may be passed to
       block layper, so flush_kernel_dcache_page() can see a slab page
       finally

     - According to cachetlb.txt, flush_kernel_dcache_page() is only called
       on "a user page", which surely can't be a slab page.

     - ARCH's implementation of flush_kernel_dcache_page() may use page
       mapping information to do optimization so page_mapping() will see the
       slab page, then VM_BUG_ON() is triggered.

    Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
    and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
    before calling flush_kernel_dcache_page().

    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Simon Baatz <gmbnomis@gmail.com>
    Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43455e8604586d80d43ebb23f9cbb31d6321ef7d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:01:11 2013 +0300

    Staging: bcm: info leak in ioctl

    commit 8d1e72250c847fa96498ec029891de4dc638a5ba upstream.

    The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
    information to user space.

    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 840834b578803d8153b6fd8526d23e615916208b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 23:00:15 2013 +0300

    staging: wlags49_h2: buffer overflow setting station name

    commit b5e2f339865fb443107e5b10603e53bbc92dc054 upstream.

    We need to check the length parameter before doing the memcpy().  I've
    actually changed it to strlcpy() as well so that it's NUL terminated.

    You need CAP_NET_ADMIN to trigger these so it's not the end of the
    world.

    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a88f5ccd2ac9798c046609a8aec18c3f522a6334
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:11:06 2013 +0300

    aacraid: missing capable() check in compat ioctl

    commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.

    In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
    added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
    check as well.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 02c54b6cf2b7bd1089bef485d7a81bdf0c5999d8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Oct 29 22:06:04 2013 +0300

    uml: check length in exitcode_proc_write()

    commit 201f99f170df14ba52ea4c52847779042b7a623b upstream.

    We don't cap the size of buffer from the user so we could write past the
    end of the array here.  Only root can write to this file.

    Reported-by: Nico Golde <nico@ngolde.de>
    Reported-by: Fabian Yamaguchi <fabs@goesec.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a3537782a1a2765778cc89ca60dd779eef7092b6
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 08:35:02 2013 +0100

    ASoC: wm_hubs: Add missing break in hp_supply_event()

    commit 268ff14525edba31da29a12a9dd693cdd6a7872e upstream.

    Spotted by coverity CID 115170.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e3151a89fa85a1d3a216348f650f3438070f39a4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 30 12:29:40 2013 +0100

    ALSA: hda - Add a fixup for ASUS N76VZ

    commit 6fc16e58adf50c0f1e4478538983fb5ff6f453d4 upstream.

    ASUS N76VZ needs the same fixup as N56VZ for supporting the boost
    speaker.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846529
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0bfd575845a118c5861ada86aba6211a5c1fc366
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Oct 29 10:21:34 2013 -0700

    Fix a few incorrectly checked [io_]remap_pfn_range() calls

    commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1 upstream.

    Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
    really should use the vm_iomap_memory() helper.  This trivially converts
    two of them to the helper, and comments about why the third one really
    needs to continue to use remap_pfn_range(), and adds the missing size
    check.

    Reported-by: Nico Golde <nico@ngolde.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
    [bwh: Backported to 3.2:
     - Adjust context
     - Also remove redundant vm_flags changes, removed separately upstream]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0625072cc2e206b5fdf08db231c8cef99ac8c288
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 28 14:21:49 2013 +0100

    ASoC: dapm: Fix source list debugfs outputs

    commit ff18620c2157671a8ee21ebb8e6a3520ea209b1f upstream.

    ... due to a copy & paste error.

    Spotted by coverity CID 710923.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 794c67ef0f3b13190fdc7d7be95a865400b37bd3
Author: Helge Deller <deller@gmx.de>
Date:   Sat Oct 26 23:19:25 2013 +0200

    parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM

    commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.

    Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
    not able to bring up other CPUs than the monarch CPU and instead crashed the
    kernel.  The reason was unclear, esp. since it involved various machines (e.g.
    J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
    when less than 4GB were installed, or if a 32bit Linux kernel was booted.

    In the end, the fix for those SMP problems is trivial:
    During the early phase of the initialization of the CPUs, including the monarch
    CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
    It's documented that this firmware function may clobber various registers, and
    one one of those possibly clobbered registers is %cr30 which holds the task
    thread info pointer.

    Now, if %cr30 would always have been clobbered, then this bug would have been
    detected much earlier. But lots of testing finally showed, that - at least for
    %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
    turned zero after the firmware call.

    So, after finding the root cause, the explanation for the various crashes
    became clear:
    - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
      problem.
    - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
      thread info pointer was below 4GB.
    - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
      the upper 32bit were zero anyay.
    - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
      info pointer was located above the 4GB boundary.

    Finally, the patch to fix this problem is trivial by saving the %cr30 register
    before the firmware call and restoring it afterwards.

    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: Ben Hutchings <ben@decadent.org.uk>

commit 5874fd1d23ed9a7a49802c2cfeed8d57b9ae303d
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Oct 25 21:53:33 2013 +0800

    target/pscsi: fix return value check

    commit 58932e96e438cd78f75e765d7b87ef39d3533d15 upstream.

    In case of error, the function scsi_host_lookup() returns NULL
    pointer not ERR_PTR(). The IS_ERR() test in the return value check
    should be replaced with NULL test.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.2: pscsi_configure_device() returns a pointer]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 069b7dec73731bb979c5fcc773934d2f403f69a0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Oct 10 16:45:27 2013 -0400

    drm/radeon/atom: workaround vbios bug in transmitter table on rs780

    commit c23632d4e57c0dd20bf50eca08fa0eb8ad3ff680 upstream.

    Some rs780 asics seem to be affected as well.

    See:
    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72

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

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2afe1a102cd3962ed4ec683128765fd33a4ab666
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 16 09:49:02 2013 +0100

    drm: Pad drm_mode_get_connector to 64-bit boundary

    commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.

    Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
    the 4 bytes beyond the end of its structure with a 32-bit userspace
    running on a 64-bit kernel. This is due to the padding gcc inserts as
    the drm_mode_get_connector struct includes a u64 and its size is not a
    natural multiple of u64s.

    64-bit kernel:

    sizeof(drm_mode_get_connector)=80, alignof=8
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4

    32-bit userspace:

    sizeof(drm_mode_get_connector)=76, alignof=4
    sizeof(drm_mode_get_encoder)=20, alignof=4
    sizeof(drm_mode_modeinfo)=68, alignof=4

    Fortuituously we can insert explicit padding to the tail of our
    structures without breaking ABI.

    Reported-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b60ff9bf0fa3a0a1e5b81055383ddbef42002f18
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 16 11:22:44 2013 +0100

    drm: Prevent overwriting from userspace underallocating core ioctl structs

    commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.

    Apply the protections from

    commit 1b2f1489633888d4a06028315dc19d65768a1c05
    Author: Dave Airlie <airlied@redhat.com>
    Date:   Sat Aug 14 20:20:34 2010 +1000

        drm: block userspace under allocating buffer and having drivers overwrite it (v2)

    to the core ioctl structs as well, for we found one instance where there
    is a 32-/64-bit size mismatch and were guilty of writing beyond the end
    of the user's buffer.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 640c4ad6d759b60a64049ff46c9acff5954f18d6
Author: Geyslan G. Bem <geyslan@gmail.com>
Date:   Fri Oct 11 16:49:16 2013 -0300

    ecryptfs: Fix memory leakage in keystore.c

    commit 3edc8376c06133e3386265a824869cad03a4efd4 upstream.

    In 'decrypt_pki_encrypted_session_key' function:

    Initializes 'payload' pointer and releases it on exit.

    Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit affb0bf19afa81cf004c67e357a33a9693e9ff3e
Author: Enrico Mioso <mrkiko.rs@gmail.com>
Date:   Tue Oct 15 15:06:47 2013 +0200

    usb: serial: option: blacklist Olivetti Olicard200

    commit fd8573f5828873343903215f203f14dc82de397c upstream.

    Interface 6 of this device speaks QMI as per tests done by us.
    Credits go to Antonella for providing the hardware.

    Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
    Tested-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b4634b793e79242f151654edef8510e28f4d0d74
Author: Oliver Neukum <oneukum@suse.de>
Date:   Wed Oct 16 12:26:07 2013 +0200

    USB: quirks: add touchscreen that is dazzeled by remote wakeup

    commit 614ced91fc6fbb5a1cdd12f0f1b6c9197d9f1350 upstream.

    The device descriptors are messed up after remote wakeup

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

commit 7a14369589fd368dd0a83e6b70d0a3eddef071e8
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Oct 16 03:17:47 2013 +0100

    dm snapshot: fix data corruption

    commit e9c6a182649f4259db704ae15a91ac820e63b0ca upstream.

    This patch fixes a particular type of data corruption that has been
    encountered when loading a snapshot's metadata from disk.

    When we allocate a new chunk in persistent_prepare, we increment
    ps->next_free and we make sure that it doesn't point to a metadata area
    by further incrementing it if necessary.

    When we load metadata from disk on device activation, ps->next_free is
    positioned after the last used data chunk. However, if this last used
    data chunk is followed by a metadata area, ps->next_free is positioned
    erroneously to the metadata area. A newly-allocated chunk is placed at
    the same location as the metadata area, resulting in data or metadata
    corruption.

    This patch changes the code so that ps->next_free skips the metadata
    area when metadata are loaded in function read_exceptions.

    The patch also moves a piece of code from persistent_prepare_exception
    to a separate function skip_metadata to avoid code duplication.

    CVE-2013-4299

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06512214e58849e661a67cdc215ca7af26afa58a
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Tue Oct 15 02:22:43 2013 +0400

    xtensa: don't use alternate signal stack on threads

    commit cba9a90053e3b7973eff4f1946f33032e98eeed5 upstream.

    According to create_thread(3): "The new thread does not inherit the creating
    thread's alternate signal stack". Since commit f9a3879a (Fix sigaltstack
    corruption among cloned threads), current->sas_ss_size is set to 0 for cloned
    processes sharing VM with their parent. Don't use the (nonexistent) alternate
    signal stack in this case. This has been broken since commit 29c4dfd9 ([XTENSA]
    Remove non-rt signal handling).

    Fixes the SA_ONSTACK part of the nptl/tst-cancel20 test from uClibc.

    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Chris Zankel <chris@zankel.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c76c2d92d331a029c88355d676cc68982c236d1
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Oct 14 16:22:40 2013 +0200

    USB: quirks.c: add one device that cannot deal with suspension

    commit 4294bca7b423d1a5aa24307e3d112a04075e3763 upstream.

    The device is not responsive when resumed, unless it is reset.

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

commit d58900877a2845d03b40638fc3b4f2b2d0afe652
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Oct 11 14:47:05 2013 +0200

    wireless: radiotap: fix parsing buffer overrun

    commit f5563318ff1bde15b10e736e97ffce13be08bc1a upstream.

    When parsing an invalid radiotap header, the parser can overrun
    the buffer that is passed in because it doesn't correctly check
     1) the minimum radiotap header size
     2) the space for extended bitmaps

    The first issue doesn't affect any in-kernel user as they all
    check the minimum size before calling the radiotap function.
    The second issue could potentially affect the kernel if an skb
    is passed in that consists only of the radiotap header with a
    lot of extended bitmaps that extend past the SKB. In that case
    a read-only buffer overrun by at most 4 bytes is possible.

    Fix this by adding the appropriate checks to the parser.

    Reported-by: Evan Huus <eapache@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d6c0dfc93890ac6621b64a33ceeefa283aebec64
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: Ben Hutchings <ben@decadent.org.uk>

commit d84e903280832e9ae044eba776b017e3fb422c28
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>
    [bwh: Backported to 3.2: use fget_raw() not fdget_raw()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 564d091beba05e7437c8fa1c31a1976f9e80479d
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: Ben Hutchings <ben@decadent.org.uk>

commit 135528ae1e8b39dde4590b35138e5bdaaaf7b34b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 5 18:14:18 2013 -0700

    USB: serial: option: add support for Inovia SEW858 device

    commit f4c19b8e165cff1a6607c21f8809441d61cab7ec upstream.

    This patch adds the device id for the Inovia SEW858 device to the option driver.

    Reported-by: Pavel Parkhomenko <ra85551@gmail.com>
    Tested-by: Pavel Parkhomenko <ra85551@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d08ec28ed82cd96b717cff22dabcd7011751d375
Author: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
Date:   Fri Oct 11 03:48:21 2013 +0000

    USB: support new huawei devices in option.c

    commit d544db293a44a2a3b09feab7dbd59668b692de71 upstream.

    Add new supporting declarations to option.c, to support Huawei new
    devices with new bInterfaceSubClass value.

    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b7a25d8eb7889d7492333a28cb0a00e6e570438
Author: Ingo Molnar <mingo@kernel.org>
Date:   Thu Oct 10 10:16:30 2013 +0200

    compiler/gcc4: Add quirk for 'asm goto' miscompilation bug

    commit 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

    Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
    a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
    constructs, as outlined here:

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670

    Implement a workaround suggested by Jakub Jelinek.

    Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Suggested-by: Jakub Jelinek <jakub@redhat.com>
    Reviewed-by: Richard Henderson <rth@twiddle.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2:
     - Drop inapplicable changes
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c12558716007837227b962caa4299b355870fed6
Author: Daniel Santos <daniel.santos@pobox.com>
Date:   Thu Feb 21 16:41:39 2013 -0800

    compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

    commit 3f3f8d2f48acfd8ed3b8e6b7377935da57b27b16 upstream.

    Throughout compiler*.h, many version checks are made.  These can be
    simplified by using the macro that gcc's documentation recommends.
    However, my primary reason for adding this is that I need bug-check
    macros that are enabled at certain gcc versions and it's cleaner to use
    this macro than the tradition method:

      #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)

    If you add patch level, it gets this ugly:

      #if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
          __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))

    As opposed to:

      #if GCC_VERSION >= 40201

    While having separate headers for gcc 3 & 4 eliminates some of this
    verbosity, they can still be cleaned up by this.

    See also:

      http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

    Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
    Acked-by: Borislav Petkov <bp@alien8.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ee698d67a4af1fd37ba5b40733f103a62f223774
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Sep 21 13:58:22 2013 -0400

    random: allow architectures to optionally define random_get_entropy()

    commit 61875f30daf60305712e25b209ef41ced2635bad upstream.

    Allow architectures which have a disabled get_cycles() function to
    provide a random_get_entropy() function which provides a fine-grained,
    rapidly changing counter that can be used by the /dev/random driver.

    For example, an architecture might have a rapidly changing register
    used to control random TLB cache eviction, or DRAM refresh that
    doesn't meet the requirements of get_cycles(), but which is good
    enough for the needs of the random driver.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 52d4f668a2ebb3d33b2ece452d4f3bcec6c87b7d
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date:   Tue Oct 8 10:18:20 2013 -0500

    rtlwifi: rtl8192cu: Fix error in pointer arithmetic

    commit 9473ca6e920a3b9ca902753ce52833657f9221cc upstream.

    An error in calculating the offset in an skb causes the driver to read
    essential device info from the wrong locations. The main effect is that
    automatic gain calculations are nonsense.

    Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cb5c1a3906d2101ed7f70254b70b94e62e8d988e
Author: Paul Mackerras <paulus@samba.org>
Date:   Sat Sep 21 09:53:28 2013 +1000

    KVM: PPC: Book3S HV: Fix typo in saving DSCR

    commit cfc860253abd73e1681696c08ea268d33285a2c4 upstream.

    This fixes a typo in the code that saves the guest DSCR (Data Stream
    Control Register) into the kvm_vcpu_arch struct on guest exit.  The
    effect of the typo was that the DSCR value was saved in the wrong place,
    so changes to the DSCR by the guest didn't persist across guest exit
    and entry, and some host kernel memory got corrupted.

    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Acked-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 21f58875dda7b00228bba716d48e3e2eafb210f9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 12 08:11:06 2013 +0200

    xhci: Fix spurious wakeups after S5 on Haswell

    commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 upstream.

    Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
    mysterious wakeups after shutdown occasionally.  After discussing with
    BIOS engineers, they explained that the new BIOS expects that the
    wakeup sources are cleared and set to D3 for all wakeup devices when
    the system is going to sleep or power off, but the current xhci driver
    doesn't do this properly (partly intentionally).

    This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
    fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
    shutdown ops as done in xhci_stop(), and setting the device to PCI D3
    at shutdown and remove ops.

    The PCI D3 call is based on the initial fix patch by Oliver Neukum.

    [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
    XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
    in them.  Sarah also fixed a collision with a quirk submitted around the
    same time, by changing the xhci->quirks bit from 17 to 18.]

    This patch should be backported to kernels as old as 3.0, that
    contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add
    Lynx Point to list of Intel switchable hosts."

    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3585a755cec3b70cb10e55ba4a25ae0dfe04c3a2
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Sep 30 15:50:54 2013 +0200

    xhci: quirk for extra long delay for S4

    commit 455f58925247e8a1a1941e159f3636ad6ee4c90b upstream.

    It has been reported that this chipset really cannot
    sleep without this extraordinary delay.

    This patch should be backported, in order to ensure this host functions
    under stable kernels.  The last quirk for Fresco Logic hosts (commit
    bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
    quirk.") was backported to stable kernels as old as 2.6.36.

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use xhci_dbg() instead of xhci_dbg_trace()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc77997de6b3cbe994ba052653ec8e292af5b627
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Aug 5 13:36:00 2013 -0700

    xhci: Don't enable/disable RWE on bus suspend/resume.

    commit f217c980ca980e3a645b7485ea5eae9a747f4945 upstream.

    The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable
    remote wakeup for devices in the lower power link state L1.  It has
    nothing to do with the device suspend remote wakeup from L2.  The RWE
    bit is designed to be set once (when USB 2.0 LPM is enabled for the
    port) and cleared only when USB 2.0 LPM is disabled for the port.

    The xHCI bus suspend method was setting the RWE bit erroneously, and the
    bus resume method was clearing it.  The xHCI 1.0 specification with
    errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware
    Controlled LPM":

    "While Hardware USB2 LPM is enabled, software shall not modify the
    HIRDBESL or RWE fields of the USB2 PORTPMSC register..."

    If we have previously enabled USB 2.0 LPM for a device, that means when
    the USB 2.0 bus is resumed, we violate the xHCI specification by
    clearing RWE.  It also means that after a bus resume, the host would
    think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM
    enabled, which is not what we want.

    This patch should be backported to kernels as old as 3.2, that
    contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set
    USB2 hardware LPM".  That was the first kernel that supported USB 2.0
    Link PM.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    [bwh: Backported to 3.2: deleted code was cosmetically different]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2fd79cac4fcebaf6937934c640ec17605864aefa
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: Ben Hutchings <ben@decadent.org.uk>

commit 83e92c513be4e0c48cd4f6bc458b01a4bba86ce0
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Wed Oct 2 19:15:03 2013 +0200

    hwmon: (applesmc) Always read until end of data

    commit 25f2bd7f5add608c1d1405938f39c96927b275ca upstream.

    The crash reported and investigated in commit 5f4513 turned out to be
    caused by a change to the read interface on newer (2012) SMCs.

    Tests by Chris show that simply reading the data valid line is enough
    for the problem to go away. Additional tests show that the newer SMCs
    no longer wait for the number of requested bytes, but start sending
    data right away.  Apparently the number of bytes to read is no longer
    specified as before, but instead found out by reading until end of
    data. Failure to read until end of data confuses the state machine,
    which eventually causes the crash.

    As a remedy, assuming bit0 is the read valid line, make sure there is
    nothing more to read before leaving the read function.

    Tested to resolve the original problem, and runtested on MBA3,1,
    MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
    machines before 2012.

    Tested-by: Chris Murphy <chris@cmurf.com>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 591c6cac8e8844d06e940774898c23f8684f5465
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Sep 16 11:12:07 2013 +0300

    mac80211: correctly close cancelled scans

    commit a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.

    __ieee80211_scan_completed is called from a worker. This
    means that the following flow is possible.

     * driver calls ieee80211_scan_completed
     * mac80211 cancels the scan (that is already complete)
     * __ieee80211_scan_completed runs

    When scan_work will finally run, it will see that the scan
    hasn't been aborted and might even trigger another scan on
    another band. This leads to a situation where cfg80211's
    scan is not done and no further scan can be issued.

    Fix this by setting a new flag when a HW scan is being
    cancelled so that no other scan will be triggered.

    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 780e58dcd9f573fbee4cf32fb949958cad6901e3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Oct 8 19:57:50 2013 +0200

    ALSA: hda - Add fixup for ASUS N56VZ

    commit c6cc3d58b4042f5cadae653ff8d3df26af1a0169 upstream.

    ASUS N56VZ needs a fixup for the bass speaker pin, which was already
    provided via model=asus-mode4.

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=841645
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36439570a28275c01999b884885cf6a0d65bec73
Author: Gwendal Grignou <gwendal@google.com>
Date:   Fri Aug 7 16:17:49 2009 -0700

    libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures

    commit f13e220161e738c2710b9904dcb3cf8bb0bcce61 upstream.

    libata EH decrements scmd->retries when the command failed for reasons
    unrelated to the command itself so that, for example, commands aborted
    due to suspend / resume cycle don't get penalized; however,
    decrementing scmd->retries isn't enough for ATA passthrough commands.

    Without this fix, ATA passthrough commands are not resend to the
    drive, and no error is signalled to the caller because:

    - allowed retry count is 1
    - ata_eh_qc_complete fill the sense data, so result is valid
    - sense data is filled with untouched ATA registers.

    Signed-off-by: Gwendal Grignou <gwendal@google.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3a3703b885535fa42759353adc09b5302ea7581b
Author: Daniel Mack <zonque@gmail.com>
Date:   Wed Oct 2 17:49:50 2013 +0200

    ALSA: snd-usb-usx2y: remove bogus frame checks

    commit a9d14bc0b188a822e42787d01e56c06fe9750162 upstream.

    The frame check in i_usX2Y_urb_complete() and
    i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as
    described in this LAU thread:

      http://linuxaudio.org/mailarchive/lau/2013/5/20/200177

    This patch removes the check code entirely.

    Cc: fzu@wemgehoertderstaat.de
    Reported-by: Dr Nicholas J Bailey <nicholas.bailey@glasgow.ac.uk>
    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6f20aa6d2d19b3df47970094fb98b363df48441
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Sep 24 19:34:26 2013 +0300

    iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series

    commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream.

    Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2:
     - Adjust filenames
     - Drop const from struct iwl_cfg]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 24d009c5a58b5df550e510b0afb15c189a2d6fc0
Author: Shuduo Sang <sangshuduo@gmail.com>
Date:   Sat Mar 30 14:26:37 2013 +0800

    iwlwifi: add new pci id for 6x35 series

    commit 20ecf9fd3bebc4147e2996c08a75d6f0229b90df upstream.

    some new thinkpad laptops use intel chip with new pci id need be added
    lspci -vnn output:
     Network controller [0280]: Intel Corporation Centrino Advanced-N 6235
     [8086:088f] (rev 24)
     Subsystem: Intel Corporation Device [8086:5260]

    Signed-off-by: Shuduo Sang <sangshuduo@gmail.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 248a026f0d4f16b2773d83df77266c613ba0396d
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Wed Feb 22 08:18:55 2012 -0800

    iwlwifi: one more sku added to 6x35 series

    commit 259653d86b80ed01c70d47b7307140ae0ba19420 upstream.

    Add new sku to 6x35 series

    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ccd7804d6f566af973c3e5ccce557d6f84fb9f3b
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Wed Feb 22 10:21:09 2012 -0800

    iwlwifi: update pci subsystem id

    commit 378911233f424d7a1bf4a579587ae71c7d887166 upstream.

    Update the pci subsystem id and product name for 6005 series devices

    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7da01b3cdb931b14ba3b950a1042b2afd7951bc8
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu Nov 10 06:55:06 2011 -0800

    iwlwifi: remove un-supported SKUs

    commit b6cb406a023184733bffc7762a75a2e204fff6b9 upstream.

    BG only SKUs are no longer supported by 2000 and 1x5 series. Remove it

    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f9430ebd8ec3f780539944006edd821e70cdcabb
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu Nov 10 06:55:03 2011 -0800

    iwlwifi: two more SKUs for 6x05 series

    commit 75a56eccb01fcc3c1ae8000130f3c9b3c8ec68d9 upstream.

    Add two more SKUs for 6x05 series of device.
    First SKU has low 5GHz channels actives, the other SKU has high 5GHz channels actives.

    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06c5e3983fcaca7a9953890d603b075607e8bbd2
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: Ben Hutchings <ben@decadent.org.uk>

commit c2a4b018aaa492c2de179b182b0e4b2b4c41bb8a
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Sep 29 21:39:34 2013 +0200

    mac80211: update sta->last_rx on acked tx frames

    commit 0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.

    When clients are idle for too long, hostapd sends nullfunc frames for
    probing. When those are acked by the client, the idle time needs to be
    updated.

    To make this work (and to avoid unnecessary probing), update sta->last_rx
    whenever an ACK was received for a tx packet. Only do this if the flag
    IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f9ec1e9afbfea2bac94d54dd92d969755798160d
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Sep 17 11:15:43 2013 +0200

    mac80211: drop spoofed packets in ad-hoc mode

    commit 6329b8d917adc077caa60c2447385554130853a3 upstream.

    If an Ad-Hoc node receives packets with the Cell ID or its own MAC
    address as source address, it hits a WARN_ON in sta_info_insert_check()
    With many packets, this can massively spam the logs. One way that this
    can easily happen is through having Cisco APs in the area with rouge AP
    detection and countermeasures enabled.
    Such Cisco APs will regularly send fake beacons, disassoc and deauth
    packets that trigger these warnings.

    To fix this issue, drop such spoofed packets early in the rx path.

    Reported-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: use compare_ether_addr() instead of ether_addr_equal()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5005abcbe8ff0d235cf9cee5e520e3cf551eab10
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>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8ce33654079ba5d5b55523b7ac317099c609cd02
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Fri Sep 6 21:49:56 2013 -0500

    jfs: fix error path in ialloc

    commit 8660998608cfa1077e560034db81885af8e1e885 upstream.

    If insert_inode_locked() fails, we shouldn't be calling
    unlock_new_inode().

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Tested-by: Michael L. Semon <mlsemon35@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 40b3183d5a1c19369c3c15b9bce144f2ccf330f0
Author: Fan Du <fan.du@windriver.com>
Date:   Tue Apr 30 15:27:27 2013 -0700

    include/linux/fs.h: disable preempt when acquire i_size_seqcount write lock

    commit 74e3d1e17b2e11d175970b85acd44f5927000ba2 upstream.

    Two rt tasks bind to one CPU core.

    The higher priority rt task A preempts a lower priority rt task B which
    has already taken the write seq lock, and then the higher priority rt
    task A try to acquire read seq lock, it's doomed to lockup.

    rt task A with lower priority: call write
    i_size_write                                        rt task B with higher priority: call sync, and preempt task A
      write_seqcount_begin(&inode->i_size_seqcount);    i_size_read
      inode->i_size = i_size;                             read_seqcount_begin <-- lockup here...

    So disable preempt when acquiring every i_size_seqcount *write* lock will
    cure the problem.

    Signed-off-by: Fan Du <fan.du@windriver.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b9662482043ed426ada7afbb406090bf0b9ebda8
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed Oct 9 22:23:23 2013 -0400

    tracing: Fix potential out-of-bounds in trace_get_user()

    commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.

    Andrey reported the following report:

    ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
    ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)
    Accessed by thread T13003:
      #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
      #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
      #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
      #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
      #4 ffffffff812a1065 (__fput+0x155/0x360)
      #5 ffffffff812a12de (____fput+0x1e/0x30)
      #6 ffffffff8111708d (task_work_run+0x10d/0x140)
      #7 ffffffff810ea043 (do_exit+0x433/0x11f0)
      #8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
      #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
      #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

    Allocated by thread T5167:
      #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
      #1 ffffffff8128337c (__kmalloc+0xbc/0x500)
      #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
      #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
      #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
      #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
      #6 ffffffff8129b668 (finish_open+0x68/0xa0)
      #7 ffffffff812b66ac (do_last+0xb8c/0x1710)
      #8 ffffffff812b7350 (path_openat+0x120/0xb50)
      #9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
      #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
      #11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
      #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

    Shadow bytes around the buggy address:
      ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
      ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
      ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap redzone:          fa
      Heap kmalloc redzone:  fb
      Freed heap region:     fd
      Shadow gap:            fe

    The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'

    Although the crash happened in ftrace_regex_open() the real bug
    occurred in trace_get_user() where there's an incrementation to
    parser->idx without a check against the size. The way it is triggered
    is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
    that reads the last character stores it and then breaks out because
    there is no more characters. Then the last character is read to determine
    what to do next, and the index is incremented without checking size.

    Then the caller of trace_get_user() usually nulls out the last character
    with a zero, but since the index is equal to the size, it writes a nul
    character after the allocated space, which can corrupt memory.

    Luckily, only root user has write access to this file.

    Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bb116a889998b2385f57b4295c957c11395be049
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 08:13:30 2013 +0000

    netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the packet

    commit 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.

    Some Cisco phones create huge messages that are spread over multiple packets.
    After calculating the offset of the SIP body, it is validated to be within
    the packet and the packet is dropped otherwise. This breaks operation of
    these phones. Since connection tracking is supposed to be passive, just let
    those packets pass unmodified and untracked.

    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.2: there is no log message to delete]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8be753be2f0a7a6982622317f508c00909e2e8b
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Sat Nov 24 12:11:21 2012 +0000

    8139cp: re-enable interrupts after tx timeout

    commit 01ffc0a7f1c1801a2354719dedbc32aff45b987d upstream.

    Recovery doesn't work too well if we leave interrupts disabled...

    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5124ae99ac8a8f63d0fca9b75adaef40b20678ff
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Oct 22 00:07:47 2013 +0200

    inet: fix possible memory corruption with UDP_CORK and UFO

    [ This is a simplified -stable version of a set of upstream commits. ]

    This is a replacement patch only for stable which does fix the problems
    handled by the following two commits in -net:

    "ip_output: do skb ufo init for peeked non ufo skb as well" (e93b7d748be887cd7639b113ba7d7ef792a7efb9)
    "ip6_output: do skb ufo init for peeked non ufo skb as well" (c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)

    Three frames are written on a corked udp socket for which the output
    netdevice has UFO enabled.  If the first and third frame are smaller than
    the mtu and the second one is bigger, we enqueue the second frame with
    skb_append_datato_frags without initializing the gso fields. This leads
    to the third frame appended regulary and thus constructing an invalid skb.

    This fixes the problem by always using skb_append_datato_frags as soon
    as the first frag got enqueued to the skb without marking the packet
    as SKB_GSO_UDP.

    The problem with only two frames for ipv6 was fixed by "ipv6: udp
    packets following an UFO enqueued packet need also be handled by UFO"
    (2811ebac2521ceac84f2bdae402455baa6a7fb47).

    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a39639b430450748b0c896de2833ada237883713
Author: Markus Trippelsdorf <markus@trippelsdorf.de>
Date:   Wed Apr 4 10:45:27 2012 +0200

    perf tools: Fix getrusage() related build failure on glibc trunk

    commit 7b78f13603c6fcb64e020a0bbe31a651ea2b657b upstream.

    On a system running glibc trunk perf doesn't build:

        CC builtin-sched.o
    builtin-sched.c: In function ‘get_cpu_usage_nsec_parent’: builtin-sched.c:399:16: error: storage size of ‘ru’ isn’t known builtin-sched.c:403:2: error: implicit declaration of function ‘getrusage’ [-Werror=implicit-function-declaration]
        [...]

    Fix it by including sys/resource.h.

    Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120404084527.GA294@x4
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e14dc9525b13e69991e577d9c6e0d768b1fe29c
Author: Wei Liu <wei.liu2@citrix.com>
Date:   Mon Oct 28 12:07:57 2013 +0000

    xen-netback: use jiffies_64 value to calculate credit timeout

    [ Upstream commit 059dfa6a93b779516321e5112db9d7621b1367ba ]

    time_after_eq() only works if the delta is < MAX_ULONG/2.

    For a 32bit Dom0, if netfront sends packets at a very low rate, the time
    between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
    and the test for timer_after_eq() will be incorrect. Credit will not be
    replenished and the guest may become unable to send packets (e.g., if
    prior to the long gap, all credit was exhausted).

    Use jiffies_64 variant to mitigate this problem for 32bit Dom0.

    Suggested-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Cc: Jason Luan <jianhai.luan@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d08b0a5594dde8b0fbda5d38cb01a81954a9829e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Oct 28 13:55:29 2013 +0100

    perf: Fix perf ring buffer memory ordering

    commit bf378d341e4873ed928dc3c636252e6895a21f50 upstream.

    The PPC64 people noticed a missing memory barrier and crufty old
    comments in the perf ring buffer code. So update all the comments and
    add the missing barrier.

    When the architecture implements local_t using atomic_long_t there
    will be double barriers issued; but short of introducing more
    conditional barrier primitives this is the best we can do.

    Reported-by: Victor Kaplansky <victork@il.ibm.com>
    Tested-by: Victor Kaplansky <victork@il.ibm.com>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
    Cc: michael@ellerman.id.au
    Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Michael Neuling <mikey@neuling.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: anton@samba.org
    Cc: benh@kernel.crashing.org
    Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 498a727b33ee121e4b57428257a05f657674af46
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date:   Sat Jun 22 17:21:00 2013 +0300

    zram: allow request end to coincide with disksize

    commit 75c7caf5a052ffd8db3312fa7864ee2d142890c4 upstream.

    Pass valid_io_request() checks if request end coincides with disksize
    (end equals bound), only fail if we attempt to read beyond the bound.

    mkfs.ext2 produces numerous errors:
    [ 2164.632747] quiet_error: 1 callbacks suppressed
    [ 2164.633260] Buffer I/O error on device zram0, logical block 153599
    [ 2164.633265] lost page write due to I/O error on zram0

    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b712f1354a50e043f37583d5f31e013245d7825
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Thu Apr 26 13:10:39 2012 -0500

    ext3: return 32/64-bit dir name hash according to usage type

    commit d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06 upstream.

    This is based on commit d1f5273e9adb40724a85272f248f210dc4ce919a
    ext4: return 32/64-bit dir name hash according to usage type
    by Fan Yong <yong.fan@whamcloud.com>

    Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
    to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
    and telldir().  However, this causes problems if there are 32-bit hash
    collisions, since the NFSv2 server can get stuck resending the same
    entries from the directory repeatedly.

    Allow ext3 to return a full 64-bit hash (both major and minor) for
    telldir to decrease the chance of hash collisions.

    This patch does implement a new ext3_dir_llseek op, because with 64-bit
    hashes, nfs will attempt to seek to a hash "offset" which is much
    larger than ext3's s_maxbytes.  So for dx dirs, we call
    generic_file_llseek_size() with the appropriate max hash value as the
    maximum seekable size.  Otherwise we just pass through to
    generic_file_llseek().

    Patch-updated-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Patch-updated-by: Eric Sandeen <sandeen@redhat.com>
    (blame us if something is not correct)

    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7ddeebd9bb1f005226b818f58cd6b2eaadf7976c
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Sun Mar 18 22:44:50 2012 -0400

    nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)

    commit 06effdbb49af5f6c7d20affaec74603914acc768 upstream.

    Use 32-bit or 64-bit llseek() hashes for directory offsets depending on
    the NFS version. NFSv2 gets 32-bit hashes only.

    NOTE: This patch got rather complex as Christoph asked to set the
    filp->f_mode flag in the open call or immediatly after dentry_open()
    in nfsd_open() to avoid races.
    Personally I still do not see a reason for that and in my opinion
    FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it
    follows directly after nfsd_open() without a chance of races.

    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Acked-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1ccc87a6bdf9397675c8b086cf633db0a17ee51
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Sun Mar 18 22:44:49 2012 -0400

    nfsd: rename 'int access' to 'int may_flags' in nfsd_open()

    commit 999448a8c0202d8c41711c92385323520644527b upstream.

    Just rename this variable, as the next patch will add a flag and
    'access' as variable name would not be correct any more.

    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Acked-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 72b749f64fc5550e3fb0f3c72868011737ef235c
Author: Fan Yong <yong.fan@whamcloud.com>
Date:   Sun Mar 18 22:44:40 2012 -0400

    ext4: return 32/64-bit dir name hash according to usage type

    commit d1f5273e9adb40724a85272f248f210dc4ce919a upstream.

    Traditionally ext2/3/4 has returned a 32-bit hash value from llseek()
    to appease NFSv2, which can only handle a 32-bit cookie for seekdir()
    and telldir().  However, this causes problems if there are 32-bit hash
    collisions, since the NFSv2 server can get stuck resending the same
    entries from the directory repeatedly.

    Allow ext4 to return a full 64-bit hash (both major and minor) for
    telldir to decrease the chance of hash collisions.  This still needs
    integration on the NFS side.

    Patch-updated-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    (blame me if something is not correct)

    Signed-off-by: Fan Yong <yong.fan@whamcloud.com>
    Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3576bd5915b9bd55886b6d92603ae6f2d3adb2d
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Tue Mar 13 22:51:38 2012 -0400

    fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash

    commit 6a8a13e03861c0ab83ab07d573ca793cff0e5d00 upstream.

    Those flags are supposed to be set by NFS readdir() to tell ext3/ext4
    to 32bit (NFSv2) or 64bit hash values (offsets) in seekdir().

    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b538dfee448ce5711105363cd1ceca5b77705979
Author: Nikhil P Rao <nikhil.rao@intel.com>
Date:   Wed Jun 20 12:56:00 2012 -0700

    PCI: fix truncation of resource size to 32 bits

    commit d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream.

    _pci_assign_resource() took an int "size" argument, which meant that
    sizes larger than 4GB were truncated.  Change type to resource_size_t.

    [bhelgaas: changelog]
    Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d4bd91401f292ce14996bbdd1c5e99c43d572ae6
Author: Mariusz Ceier <mceier+kernel@gmail.com>
Date:   Mon Oct 21 19:45:04 2013 +0200

    davinci_emac.c: Fix IFF_ALLMULTI setup

    [ Upstream commit d69e0f7ea95fef8059251325a79c004bac01f018 ]

    When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't,
    emac_dev_mcast_set should only enable RX of multicasts and reset
    MACHASH registers.

    It does this, but afterwards it either sets up multicast MACs
    filtering or disables RX of multicasts and resets MACHASH registers
    again, rendering IFF_ALLMULTI flag useless.

    This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and
    disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set.

    Tested with kernel 2.6.37.

    Signed-off-by: Mariusz Ceier <mceier+kernel@gmail.com>
    Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 55bf9001c5311b9a3e06c2be94e59b70881adea1
Author: Seif Mazareeb <seif@marvell.com>
Date:   Thu Oct 17 20:33:21 2013 -0700

    net: fix cipso packet validation when !NETLABEL

    [ Upstream commit f2e5ddcc0d12f9c4c7b254358ad245c9dddce13b ]

    When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop
    forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel
    crash in an SMP system, since the CPU executing this function will
    stall /not respond to IPIs.

    This problem can be reproduced by running the IP Stack Integrity Checker
    (http://isic.sourceforge.net) using the following command on a Linux machine
    connected to DUT:

    "icmpsic -s rand -d <DUT IP address> -r 123456"
    wait (1-2 min)

    Signed-off-by: Seif Mazareeb <seif@marvell.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c310512efc9d46346b3e2b6c507bccdb291f5dab
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Oct 17 22:51:31 2013 +0200

    net: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race

    [ Upstream commit 90c6bd34f884cd9cee21f1d152baf6c18bcac949 ]

    In the case of credentials passing in unix stream sockets (dgram
    sockets seem not affected), we get a rather sparse race after
    commit 16e5726 ("af_unix: dont send SCM_CREDENTIALS by default").

    We have a stream server on receiver side that requests credential
    passing from senders (e.g. nc -U). Since we need to set SO_PASSCRED
    on each spawned/accepted socket on server side to 1 first (as it's
    not inherited), it can happen that in the time between accept() and
    setsockopt() we get interrupted, the sender is being scheduled and
    continues with passing data to our receiver. At that time SO_PASSCRED
    is neither set on sender nor receiver side, hence in cmsg's
    SCM_CREDENTIALS we get eventually pid:0, uid:65534, gid:65534
    (== overflow{u,g}id) instead of what we actually would like to see.

    On the sender side, here nc -U, the tests in maybe_add_creds()
    invoked through unix_stream_sendmsg() would fail, as at that exact
    time, as mentioned, the sender has neither SO_PASSCRED on his side
    nor sees it on the server side, and we have a valid 'other' socket
    in place. Thus, sender believes it would just look like a normal
    connection, not needing/requesting SO_PASSCRED at that time.

    As reverting 16e5726 would not be an option due to the significant
    performance regression reported when having creds always passed,
    one way/trade-off to prevent that would be to set SO_PASSCRED on
    the listener socket and allow inheriting these flags to the spawned
    socket on server side in accept(). It seems also logical to do so
    if we'd tell the listener socket to pass those flags onwards, and
    would fix the race.

    Before, strace:

    recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
            msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
            cmsg_type=SCM_CREDENTIALS{pid=0, uid=65534, gid=65534}},
            msg_flags=0}, 0) = 5

    After, strace:

    recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
            msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
            cmsg_type=SCM_CREDENTIALS{pid=11580, uid=1000, gid=1000}},
            msg_flags=0}, 0) = 5

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e6c24ff286f37711185fe1b6ce1cea58d7fc8c50
Author: Salva Peiró <speiro@ai2.upv.es>
Date:   Wed Oct 16 12:46:50 2013 +0200

    wanxl: fix info leak in ioctl

    [ Upstream commit 2b13d06c9584b4eb773f1e80bbaedab9a1c344e1 ]

    The wanxl_ioctl() code fails to initialize the two padding bytes of
    struct sync_serial_settings after the ->loopback member. Add an explicit
    memset(0) before filling the structure to avoid the info leak.

    Signed-off-by: Salva Peiró <speiro@ai2.upv.es>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d082949fefde5d6b7acedab5936d938ae5e374b
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Tue Oct 15 22:01:31 2013 -0400

    sctp: Perform software checksum if packet has to be fragmented.

    [ Upstream commit d2dbbba77e95dff4b4f901fee236fef6d9552072 ]

    IP/IPv6 fragmentation knows how to compute only TCP/UDP checksum.
    This causes problems if SCTP packets has to be fragmented and
    ipsummed has been set to PARTIAL due to checksum offload support.
    This condition can happen when retransmitting after MTU discover,
    or when INIT or other control chunks are larger then MTU.
    Check for the rare fragmentation condition in SCTP and use software
    checksum calculation in this case.

    CC: Fan Du <fan.du@windriver.com>
    Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa4797fc468f1f7ca5b96bedbe457612b317da60
Author: Fan Du <fan.du@windriver.com>
Date:   Tue Oct 15 22:01:30 2013 -0400

    sctp: Use software crc32 checksum when xfrm transform will happen.

    [ Upstream commit 27127a82561a2a3ed955ce207048e1b066a80a2a ]

    igb/ixgbe have hardware sctp checksum support, when this feature is enabled
    and also IPsec is armed to protect sctp traffic, ugly things happened as
    xfrm_output checks CHECKSUM_PARTIAL to do checksum operation(sum every thing
    up and pack the 16bits result in the checksum field). The result is fail
    establishment of sctp communication.

    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Fan Du <fan.du@windriver.com>
    Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 69ef6988b6e77c3d170289828b210aba8178a2cd
Author: Vlad Yasevich <vyasevich@gmail.com>
Date:   Tue Oct 15 22:01:29 2013 -0400

    net: dst: provide accessor function to dst->xfrm

    [ Upstream commit e87b3998d795123b4139bc3f25490dd236f68212 ]

    dst->xfrm is conditionally defined.  Provide accessor funtion that
    is always available.

    Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d6e066a9d33b2a09590153505fc9abd8fe9ba624
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Oct 12 14:08:34 2013 -0700

    bnx2x: record rx queue for LRO packets

    [ Upstream commit 60e66fee56b2256dcb1dc2ea1b2ddcb6e273857d ]

    RPS support is kind of broken on bnx2x, because only non LRO packets
    get proper rx queue information. This triggers reorders, as it seems
    bnx2x like to generate a non LRO packet for segment including TCP PUSH
    flag : (this might be pure coincidence, but all the reorders I've
    seen involve segments with a PUSH)

    11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
    11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
    11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985797>
    11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
    11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
    11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
    11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>

    We must call skb_record_rx_queue() to properly give to RPS (and more
    generally for TX queue selection on forward path) the receive queue
    information.

    Similar fix is needed for skb_mark_napi_id(), but will be handled
    in a separate patch to ease stable backports.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Cc: Eilon Greenstein <eilong@broadcom.com>
    Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c92d60f0b331feafbf42a33aa6e17cdc2d7448c9
Author: Mathias Krause <minipli@googlemail.com>
Date:   Mon Sep 30 22:03:07 2013 +0200

    connector: use nlmsg_len() to check message length

    [ Upstream commit 162b2bedc084d2d908a04c93383ba02348b648b0 ]

    The current code tests the length of the whole netlink message to be
    at least as long to fit a cn_msg. This is wrong as nlmsg_len includes
    the length of the netlink message header. Use nlmsg_len() instead to
    fix this "off-by-NLMSG_HDRLEN" size check.

    Cc: stable@vger.kernel.org  # v2.6.14+
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5bf019ebfa38379d51698b7f0fefcd44d6f0447d
Author: Salva Peiró <speiro@ai2.upv.es>
Date:   Fri Oct 11 12:50:03 2013 +0300

    farsync: fix info leak in ioctl

    [ Upstream commit 96b340406724d87e4621284ebac5e059d67b2194 ]

    The fst_get_iface() code fails to initialize the two padding bytes of
    struct sync_serial_settings after the ->loopback member. Add an explicit
    memset(0) before filling the structure to avoid the info leak.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d9aab1cfdd30ff43df1e45f9430c30d99c2c6e47
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 10 06:30:09 2013 -0700

    l2tp: must disable bh before calling l2tp_xmit_skb()

    [ Upstream commit 455cc32bf128e114455d11ad919321ab89a2c312 ]

    François Cachereul made a very nice bug report and suspected
    the bh_lock_sock() / bh_unlok_sock() pair used in l2tp_xmit_skb() from
    process context was not good.

    This problem was added by commit 6af88da14ee284aaad6e4326da09a89191ab6165
    ("l2tp: Fix locking in l2tp_core.c").

    l2tp_eth_dev_xmit() runs from BH context, so we must disable BH
    from other l2tp_xmit_skb() users.

    [  452.060011] BUG: soft lockup - CPU#1 stuck for 23s! [accel-pppd:6662]
    [  452.061757] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppoe pppox
    ppp_generic slhc ipv6 ext3 mbcache jbd virtio_balloon xfs exportfs dm_mod
    virtio_blk ata_generic virtio_net floppy ata_piix libata virtio_pci virtio_ring virtio [last unloaded: scsi_wait_scan]
    [  452.064012] CPU 1
    [  452.080015] BUG: soft lockup - CPU#2 stuck for 23s! [accel-pppd:6643]
    [  452.080015] CPU 2
    [  452.080015]
    [  452.080015] Pid: 6643, comm: accel-pppd Not tainted 3.2.46.mini #1 Bochs Bochs
    [  452.080015] RIP: 0010:[<ffffffff81059f6c>]  [<ffffffff81059f6c>] do_raw_spin_lock+0x17/0x1f
    [  452.080015] RSP: 0018:ffff88007125fc18  EFLAGS: 00000293
    [  452.080015] RAX: 000000000000aba9 RBX: ffffffff811d0703 RCX: 0000000000000000
    [  452.080015] RDX: 00000000000000ab RSI: ffff8800711f6896 RDI: ffff8800745c8110
    [  452.080015] RBP: ffff88007125fc18 R08: 0000000000000020 R09: 0000000000000000
    [  452.080015] R10: 0000000000000000 R11: 0000000000000280 R12: 0000000000000286
    [  452.080015] R13: 0000000000000020 R14: 0000000000000240 R15: 0000000000000000
    [  452.080015] FS:  00007fdc0cc24700(0000) GS:ffff8800b6f00000(0000) knlGS:0000000000000000
    [  452.080015] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  452.080015] CR2: 00007fdb054899b8 CR3: 0000000074404000 CR4: 00000000000006a0
    [  452.080015] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  452.080015] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  452.080015] Process accel-pppd (pid: 6643, threadinfo ffff88007125e000, task ffff8800b27e6dd0)
    [  452.080015] Stack:
    [  452.080015]  ffff88007125fc28 ffffffff81256559 ffff88007125fc98 ffffffffa01b2bd1
    [  452.080015]  ffff88007125fc58 000000000000000c 00000000029490d0 0000009c71dbe25e
    [  452.080015]  000000000000005c 000000080000000e 0000000000000000 ffff880071170600
    [  452.080015] Call Trace:
    [  452.080015]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
    [  452.080015]  [<ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
    [  452.080015]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
    [  452.080015]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
    [  452.080015]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
    [  452.080015]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
    [  452.080015]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
    [  452.080015]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
    [  452.080015]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
    [  452.080015]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
    [  452.080015]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
    [  452.080015] Code: 81 48 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 <8a> 07 eb f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3
    [  452.080015] Call Trace:
    [  452.080015]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
    [  452.080015]  [<ffffffffa01b2bd1>] l2tp_xmit_skb+0x189/0x4ac [l2tp_core]
    [  452.080015]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
    [  452.080015]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
    [  452.080015]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
    [  452.080015]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
    [  452.080015]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
    [  452.080015]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
    [  452.080015]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
    [  452.080015]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
    [  452.080015]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
    [  452.064012]
    [  452.064012] Pid: 6662, comm: accel-pppd Not tainted 3.2.46.mini #1 Bochs Bochs
    [  452.064012] RIP: 0010:[<ffffffff81059f6e>]  [<ffffffff81059f6e>] do_raw_spin_lock+0x19/0x1f
    [  452.064012] RSP: 0018:ffff8800b6e83ba0  EFLAGS: 00000297
    [  452.064012] RAX: 000000000000aaa9 RBX: ffff8800b6e83b40 RCX: 0000000000000002
    [  452.064012] RDX: 00000000000000aa RSI: 000000000000000a RDI: ffff8800745c8110
    [  452.064012] RBP: ffff8800b6e83ba0 R08: 000000000000c802 R09: 000000000000001c
    [  452.064012] R10: ffff880071096c4e R11: 0000000000000006 R12: ffff8800b6e83b18
    [  452.064012] R13: ffffffff8125d51e R14: ffff8800b6e83ba0 R15: ffff880072a589c0
    [  452.064012] FS:  00007fdc0b81e700(0000) GS:ffff8800b6e80000(0000) knlGS:0000000000000000
    [  452.064012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  452.064012] CR2: 0000000000625208 CR3: 0000000074404000 CR4: 00000000000006a0
    [  452.064012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  452.064012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  452.064012] Process accel-pppd (pid: 6662, threadinfo ffff88007129a000, task ffff8800744f7410)
    [  452.064012] Stack:
    [  452.064012]  ffff8800b6e83bb0 ffffffff81256559 ffff8800b6e83bc0 ffffffff8121c64a
    [  452.064012]  ffff8800b6e83bf0 ffffffff8121ec7a ffff880072a589c0 ffff880071096c62
    [  452.064012]  0000000000000011 ffffffff81430024 ffff8800b6e83c80 ffffffff8121f276
    [  452.064012] Call Trace:
    [  452.064012]  <IRQ>
    [  452.064012]  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
    [  452.064012]  [<ffffffff8121c64a>] spin_lock+0x9/0xb
    [  452.064012]  [<ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
    [  452.064012]  [<ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
    [  452.064012]  [<ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
    [  452.064012]  [<ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
    [  452.064012]  [<ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
    [  452.064012]  [<ffffffff811fe54e>] ip_local_deliver+0x53/0x84
    [  452.064012]  [<ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
    [  452.064012]  [<ffffffff811fe78f>] ip_rcv+0x210/0x269
    [  452.064012]  [<ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
    [  452.064012]  [<ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
    [  452.064012]  [<ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
    [  452.064012]  [<ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
    [  452.064012]  [<ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
    [  452.064012]  [<ffffffff811d9417>] net_rx_action+0x73/0x184
    [  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffff810343b9>] __do_softirq+0xc3/0x1a8
    [  452.064012]  [<ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
    [  452.064012]  [<ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
    [  452.064012]  [<ffffffff8125e0ac>] call_softirq+0x1c/0x26
    [  452.064012]  [<ffffffff81003587>] do_softirq+0x45/0x82
    [  452.064012]  [<ffffffff81034667>] irq_exit+0x42/0x9c
    [  452.064012]  [<ffffffff8125e146>] do_IRQ+0x8e/0xa5
    [  452.064012]  [<ffffffff8125676e>] common_interrupt+0x6e/0x6e
    [  452.064012]  <EOI>
    [  452.064012]  [<ffffffff810b82a1>] ? kfree+0x8a/0xa3
    [  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
    [  452.064012]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
    [  452.064012]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
    [  452.064012]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
    [  452.064012]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
    [  452.064012]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
    [  452.064012]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
    [  452.064012]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
    [  452.064012]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b
    [  452.064012] Code: 89 e5 72 0c 31 c0 48 81 ff 45 66 25 81 0f 92 c0 5d c3 55 b8 00 01 00 00 48 89 e5 f0 66 0f c1 07 0f b6 d4 38 d0 74 06 f3 90 8a 07 <eb> f6 5d c3 90 90 55 48 89 e5 9c 58 0f 1f 44 00 00 5d c3 55 48
    [  452.064012] Call Trace:
    [  452.064012]  <IRQ>  [<ffffffff81256559>] _raw_spin_lock+0xe/0x10
    [  452.064012]  [<ffffffff8121c64a>] spin_lock+0x9/0xb
    [  452.064012]  [<ffffffff8121ec7a>] udp_queue_rcv_skb+0x186/0x269
    [  452.064012]  [<ffffffff8121f276>] __udp4_lib_rcv+0x297/0x4ae
    [  452.064012]  [<ffffffff8121c178>] ? raw_rcv+0xe9/0xf0
    [  452.064012]  [<ffffffff8121f4a7>] udp_rcv+0x1a/0x1c
    [  452.064012]  [<ffffffff811fe385>] ip_local_deliver_finish+0x12b/0x1a5
    [  452.064012]  [<ffffffff811fe54e>] ip_local_deliver+0x53/0x84
    [  452.064012]  [<ffffffff811fe1d0>] ip_rcv_finish+0x2bc/0x2f3
    [  452.064012]  [<ffffffff811fe78f>] ip_rcv+0x210/0x269
    [  452.064012]  [<ffffffff8101911e>] ? kvm_clock_get_cycles+0x9/0xb
    [  452.064012]  [<ffffffff811d88cd>] __netif_receive_skb+0x3a5/0x3f7
    [  452.064012]  [<ffffffff811d8eba>] netif_receive_skb+0x57/0x5e
    [  452.064012]  [<ffffffff811cf30f>] ? __netdev_alloc_skb+0x1f/0x3b
    [  452.064012]  [<ffffffffa0049126>] virtnet_poll+0x4ba/0x5a4 [virtio_net]
    [  452.064012]  [<ffffffff811d9417>] net_rx_action+0x73/0x184
    [  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffff810343b9>] __do_softirq+0xc3/0x1a8
    [  452.064012]  [<ffffffff81013b56>] ? ack_APIC_irq+0x10/0x12
    [  452.064012]  [<ffffffff81256559>] ? _raw_spin_lock+0xe/0x10
    [  452.064012]  [<ffffffff8125e0ac>] call_softirq+0x1c/0x26
    [  452.064012]  [<ffffffff81003587>] do_softirq+0x45/0x82
    [  452.064012]  [<ffffffff81034667>] irq_exit+0x42/0x9c
    [  452.064012]  [<ffffffff8125e146>] do_IRQ+0x8e/0xa5
    [  452.064012]  [<ffffffff8125676e>] common_interrupt+0x6e/0x6e
    [  452.064012]  <EOI>  [<ffffffff810b82a1>] ? kfree+0x8a/0xa3
    [  452.064012]  [<ffffffffa01b2cc2>] ? l2tp_xmit_skb+0x27a/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffffa01b2c25>] ? l2tp_xmit_skb+0x1dd/0x4ac [l2tp_core]
    [  452.064012]  [<ffffffffa01c2d36>] pppol2tp_sendmsg+0x15e/0x19c [l2tp_ppp]
    [  452.064012]  [<ffffffff811c7872>] __sock_sendmsg_nosec+0x22/0x24
    [  452.064012]  [<ffffffff811c83bd>] sock_sendmsg+0xa1/0xb6
    [  452.064012]  [<ffffffff81254e88>] ? __schedule+0x5c1/0x616
    [  452.064012]  [<ffffffff8103c7c6>] ? __dequeue_signal+0xb7/0x10c
    [  452.064012]  [<ffffffff810bbd21>] ? fget_light+0x75/0x89
    [  452.064012]  [<ffffffff811c8444>] ? sockfd_lookup_light+0x20/0x56
    [  452.064012]  [<ffffffff811c9b34>] sys_sendto+0x10c/0x13b
    [  452.064012]  [<ffffffff8125cac2>] system_call_fastpath+0x16/0x1b

    Reported-by: François Cachereul <f.cachereul@alphalink.fr>
    Tested-by: François Cachereul <f.cachereul@alphalink.fr>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: James Chapman <jchapman@katalix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 98459c1ed3af5d9240be460baf3ac6415d2a2dfe
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon Oct 7 23:19:58 2013 +0200

    net: vlan: fix nlmsg size calculation in vlan_get_size()

    [ Upstream commit c33a39c575068c2ea9bffb22fd6de2df19c74b89 ]

    This patch fixes the calculation of the nlmsg size, by adding the missing
    nla_total_size().

    Cc: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 75770c94c91d6d637d95d70062fc67a1c468003a
Author: Marcelo Ricardo Leitner <mleitner@redhat.com>
Date:   Tue Oct 8 16:41:13 2013 +0200

    ipv6: restrict neighbor entry creation to output flow

    This patch is based on 3.2.y branch, the one used by reporter. Please let me
    know if it should be different. Thanks.

    The patch which introduced the regression was applied on stables:
    3.0.64 3.4.31 3.7.8 3.2.39

    The patch which introduced the regression was for stable trees only.

    ---8<---

    Commit 0d6a77079c475033cb622c07c5a880b392ef664e "ipv6: do not create
    neighbor entries for local delivery" introduced a regression on
    which routes to local delivery would not work anymore. Like this:

        $ ip -6 route add local 2001::/64 dev lo
        $ ping6 -c1 2001::9
        PING 2001::9(2001::9) 56 data bytes
        ping: sendmsg: Invalid argument

    As this is a local delivery, that commit would not allow the creation of a
    neighbor entry and thus the packet cannot be sent.

    But as TPROXY scenario actually needs to avoid the neighbor entry creation only
    for input flow, this patch now limits previous patch to input flow, keeping
    output as before that patch.

    Reported-by: Debabrata Banerjee <dbavatar@gmail.com>
    Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 69c1c491074f33cf282b374a0518e94cc85a49d6
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sat Oct 5 21:25:17 2013 +0200

    can: dev: fix nlmsg size calculation in can_get_size()

    [ Upstream commit fe119a05f8ca481623a8d02efcc984332e612528 ]

    This patch fixes the calculation of the nlmsg size, by adding the missing
    nla_total_size().

    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ba76ac268b89169d3285929d7e249335ba0c728
Author: Jiri Benc <jbenc@redhat.com>
Date:   Fri Oct 4 17:04:48 2013 +0200

    ipv4: fix ineffective source address selection

    [ Upstream commit 0a7e22609067ff524fc7bbd45c6951dd08561667 ]

    When sending out multicast messages, the source address in inet->mc_addr is
    ignored and rewritten by an autoselected one. This is caused by a typo in
    commit 813b3b5db831 ("ipv4: Use caller's on-stack flowi as-is in output
    route lookups").

    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d60eefc05ce636242132fa3a1c094229338bc9dd
Author: Mathias Krause <minipli@googlemail.com>
Date:   Mon Sep 30 22:03:06 2013 +0200

    proc connector: fix info leaks

    [ Upstream commit e727ca82e0e9616ab4844301e6bae60ca7327682 ]

    Initialize event_data for all possible message types to prevent leaking
    kernel stack contents to userland (up to 20 bytes). Also set the flags
    member of the connector message to 0 to prevent leaking two more stack
    bytes this way.

    Cc: stable@vger.kernel.org  # v2.6.15+
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f1d515ce7d27262d9acb468aece806264886a9be
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 3 00:27:20 2013 +0300

    net: heap overflow in __audit_sockaddr()

    [ Upstream commit 1661bf364ae9c506bc8795fef70d1532931be1e8 ]

    We need to cap ->msg_namelen or it leads to a buffer overflow when we
    to the memcpy() in __audit_sockaddr().  It requires CAP_AUDIT_CONTROL to
    exploit this bug.

    The call tree is:
    ___sys_recvmsg()
      move_addr_to_user()
        audit_sockaddr()
          __audit_sockaddr()

    Reported-by: Jüri Aedla <juri.aedla@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ea54bc74c4cc418b395bc361fb1138255ea18080
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 1 21:04:11 2013 -0700

    net: do not call sock_put() on TIMEWAIT sockets

    [ Upstream commit 80ad1d61e72d626e30ebe8529a0455e660ca4693 ]

    commit 3ab5aee7fe84 ("net: Convert TCP & DCCP hash tables to use RCU /
    hlist_nulls") incorrectly used sock_put() on TIMEWAIT sockets.

    We should instead use inet_twsk_put()

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7e3694085b35039ee57527ac6469d2202ba7cbd8
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Oct 4 10:31:41 2013 -0700

    tcp: do not forget FIN in tcp_shifted_skb()

    [ Upstream commit 5e8a402f831dbe7ee831340a91439e46f0d38acd ]

    Yuchung found following problem :

     There are bugs in the SACK processing code, merging part in
     tcp_shift_skb_data(), that incorrectly resets or ignores the sacked
     skbs FIN flag. When a receiver first SACK the FIN sequence, and later
     throw away ofo queue (e.g., sack-reneging), the sender will stop
     retransmitting the FIN flag, and hangs forever.

    Following packetdrill test can be used to reproduce the bug.

    $ cat sack-merge-bug.pkt
    `sysctl -q net.ipv4.tcp_fack=0`

    // Establish a connection and send 10 MSS.
    0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    +.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
    +.000 bind(3, ..., ...) = 0
    +.000 listen(3, 1) = 0

    +.050 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
    +.000 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
    +.001 < . 1:1(0) ack 1 win 1024
    +.000 accept(3, ..., ...) = 4

    +.100 write(4, ..., 12000) = 12000
    +.000 shutdown(4, SHUT_WR) = 0
    +.000 > . 1:10001(10000) ack 1
    +.050 < . 1:1(0) ack 2001 win 257
    +.000 > FP. 10001:12001(2000) ack 1
    +.050 < . 1:1(0) ack 2001 win 257 <sack 10001:11001,nop,nop>
    +.050 < . 1:1(0) ack 2001 win 257 <sack 10001:12002,nop,nop>
    // SACK reneg
    +.050 < . 1:1(0) ack 12001 win 257
    +0 %{ print "unacked: ",tcpi_unacked }%
    +5 %{ print "" }%

    First, a typo inverted left/right of one OR operation, then
    code forgot to advance end_seq if the merged skb carried FIN.

    Bug was added in 2.6.29 by commit 832d11c5cd076ab
    ("tcp: Try to restore large SKBs while SACK processing")

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5704e2706445e6fa20df4eb1017d8016f2e9a16
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 15 11:54:30 2013 -0700

    tcp: must unclone packets before mangling them

    [ Upstream commit c52e2421f7368fd36cbe330d2cf41b10452e39a9 ]

    TCP stack should make sure it owns skbs before mangling them.

    We had various crashes using bnx2x, and it turned out gso_size
    was cleared right before bnx2x driver was populating TC descriptor
    of the _previous_ packet send. TCP stack can sometime retransmit
    packets that are still in Qdisc.

    Of course we could make bnx2x driver more robust (using
    ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.

    We have identified two points where skb_unclone() was needed.

    This patch adds a WARN_ON_ONCE() to warn us if we missed another
    fix of this kind.

    Kudos to Neal for finding the root cause of this bug. Its visible
    using small MSS.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>