commit 55db48a6716054f17bba1aaf04f1d74e11f7ea0c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 27 10:41:32 2013 -0700

    Linux 3.9.8

commit 9ebc0bf8c7c82dff0f915b2a7f2af2a63c394ae0
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Jun 20 17:44:22 2013 +0300

    spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc()
    
    commit cc0ee9873c6afafb387379ca1df25da78a08c603 upstream.
    
    ACPI part of the driver accidentally used sizeof(*ssp) instead of the
    correct sizeof(*pdata). This leads to nasty memory corruptions like the one
    below:
    
        BUG: unable to handle kernel paging request at 0000000749fd30b8
        IP: [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
        PGD 0
        Oops: 0000 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443
        task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000
        RIP: 0010:[<ffffffff813fe8a1>]  [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
        RSP: 0000:ffff88014839fde8  EFLAGS: 00010046
        RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200
        RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640
        RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001
        R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040
        R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640
        FS:  0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Stack:
         ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20
         ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90
         ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000
        Call Trace:
         [<ffffffff810e0baf>] worker_thread+0x7f/0x390
         [<ffffffff81120abd>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff810e0b30>] ? manage_workers.isra.22+0x2b0/0x2b0
         [<ffffffff810e6c09>] kthread+0xd9/0xe0
         [<ffffffff810f93df>] ? local_clock+0x3f/0x50
         [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
         [<ffffffff818c5dec>] ret_from_fork+0x7c/0xb0
         [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
    
    Fix this by using the right structure size in devm_kzalloc().
    
    Reported-by: Jerome Blin <jerome.blin@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4666d3e5fb1a1f7b5eefb4e0fe2f8bbe4e59236a
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Jun 18 17:29:44 2013 +0300

    spi/pxa2xx: use GFP_ATOMIC in sg table allocation
    
    commit 5548f98c46538d1da04eff179a52e50537d11465 upstream.
    
    pxa2xx_spi_map_dma_buffer() gets called in tasklet context so we can't
    sleep when we allocate a new sg table. Use GFP_ATOMIC here instead.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a622ab9bca8e5b2882025f7041d72a25cf70c23
Author: Damian Hobson-Garcia <dhobsong@igel.co.jp>
Date:   Tue Mar 26 10:31:22 2013 +0900

    drivers: uio: Fix UIO device registration failure
    
    commit 5ed0505c713805f89473cdc0bbfb5110dfd840cb upstream.
    
    Until recently uio_get_minor() returned 0 for success and
    a negative value on failure.  This became non-negative for suceess and
    negative for failure.  Restore the original return value spec so that we can
    successfully initialize UIO devices with a non-zero minor device
    number.
    
    Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
    Cc: "Hans J. Koch" <hjk@hansjkoch.de>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c52217e88ae0f3a4ae00562d86e338f8f85969b4
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jun 4 10:44:21 2013 +0200

    perf: Fix mmap() accounting hole
    
    commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b upstream.
    
    Vince's fuzzer once again found holes. This time it spotted a leak in
    the locked page accounting.
    
    When an event had redirected output and its close() was the last
    reference to the buffer we didn't have a vm context to undo accounting.
    
    Change the code to destroy the buffer on the last munmap() and detach
    all redirected events at that time. This provides us the right context
    to undo the vm accounting.
    
    Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130604084421.GI8923@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c297d10214bc3eece56d313779642626b1f8e0ed
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue May 28 10:55:48 2013 +0200

    perf: Fix perf mmap bugs
    
    commit 26cb63ad11e04047a64309362674bcbbd6a6f246 upstream.
    
    Vince reported a problem found by his perf specific trinity
    fuzzer.
    
    Al noticed 2 problems with perf's mmap():
    
     - it has issues against fork() since we use vma->vm_mm for accounting.
     - it has an rb refcount leak on double mmap().
    
    We fix the issues against fork() by using VM_DONTCOPY; I don't
    think there's code out there that uses this; we didn't hear
    about weird accounting problems/crashes. If we do need this to
    work, the previously proposed VM_PINNED could make this work.
    
    Aside from the rb reference leak spotted by Al, Vince's example
    prog was indeed doing a double mmap() through the use of
    perf_event_set_output().
    
    This exposes another problem, since we now have 2 events with
    one buffer, the accounting gets screwy because we account per
    event. Fix this by making the buffer responsible for its own
    accounting.
    
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Link: http://lkml.kernel.org/r/20130528085548.GA12193@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80e14deab672c43e0ccde437cbf076698b11218e
Author: Josh Durgin <josh.durgin@inktank.com>
Date:   Wed Jun 12 19:15:06 2013 -0700

    rbd: use the correct length for format 2 object names
    
    commit 3a96d5cd7bdce45d5dded75c3a62d4fb98050280 upstream.
    
    [Backported for 3.9-stable.
    'kmalloc(MAX_OBJ_NAME_SIZE + 1, GFP_NOIO)' was changed as
    'kmem_cache_alloc(rbd_segment_name_cache, GFP_NOIO)' in 78c2a44
    since 3.10-rc1, and 78c2a44 is relied on a big patchset, so restore
    it as 3.9 did.]
    
    Format 2 objects use 16 characters for the object name suffix to be
    able to express the full 64-bit range of object numbers. Format 1
    images only use 12 characters for this. Using 12-character names for
    format 2 caused userspace and kernel rbd clients to read differently
    named objects, which made an image written by one client look empty to
    the other client.
    
    Reported-by: Chris Dunlop <chris@onthe.net.au>
    Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
    Reviewed-by: Sage Weil <sage@inktank.com>
    Reviewed-by: Lingzhu Xiang <lxiang@redhat.com>
    Signed-off-by: Zhouping Liu <zliu@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8900341a8db086ab7712eb93b5c4b0815db84e6c
Author: Joern Engel <joern@logfs.org>
Date:   Thu May 30 16:36:51 2013 -0400

    target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()
    
    commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c upstream.
    
    Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
    almost two years ago.  I have no idea why we only started seeing it now,
    but we did.
    
    Rough callgraph:
    core_tpg_set_initiator_node_queue_depth()
    `-> spin_lock_irqsave(&tpg->session_lock, flags);
    `-> lio_tpg_shutdown_session()
        `-> iscsit_stop_time2retain_timer()
            `-> spin_unlock_bh(&se_tpg->session_lock);
            `-> spin_lock_bh(&se_tpg->session_lock);
    `-> spin_unlock_irqrestore(&tpg->session_lock, flags);
    
    core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
    but 140854cb changed that to spin_lock_irqsave().  However,
    lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
    held, as does iscsit_stop_time2retain_timer():
     *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held
    
    Stale documentation is mostly annoying, but in this case the dropping
    the lock with the _bh variant is plain wrong.  It is also wrong to drop
    locks two functions below the lock-holder, but I will ignore that bit
    for now.
    
    After some more locking and unlocking we eventually hit this backtrace:
    ------------[ cut here ]------------
    WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
    Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
    Call Trace:
     [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0
     [<ffffffffa040ae37>] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
     [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20
     [<ffffffff810472f8>] local_bh_enable_ip+0xe8/0x100
     [<ffffffff815b8365>] _raw_spin_unlock_bh+0x15/0x20
     [<ffffffffa040ae37>] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
     [<ffffffffa041149a>] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
     [<ffffffffa0417fab>] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
     [<ffffffffa033ede4>] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
     [<ffffffffa0409032>] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
     [<ffffffffa0415c29>] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
     [<ffffffffa0331b49>] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
     [<ffffffff811b857d>] configfs_write_file+0xbd/0x120
     [<ffffffff81148f36>] vfs_write+0xc6/0x180
     [<ffffffff81149251>] sys_write+0x51/0x90
     [<ffffffff815c0969>] system_call_fastpath+0x16/0x1b
    ---[ end trace 3747632b9b164652 ]---
    
    As a pure band-aid, this patch drops the _bh.
    
    Signed-off-by: Joern Engel <joern@logfs.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit bcdf8edb46b9275bb89aabbc79469823da89cfe1
Author: Peter Hurley <peter@hurleysoftware.com>
Date:   Thu Jun 13 15:56:37 2013 -0400

    tty: Fix transient pty write() EIO
    
    commit 7c61c3d8f44d5d822f758754287af644307b4af9 upstream.
    
    Commit 699390354da6c258b65bf8fa79cfd5feaede50b6
    ('pty: Ignore slave pty close() if never successfully opened')
    introduced a bug with ptys whereby a write() in parallel with an
    open() on an existing pty could mistakenly indicate an I/O error.
    
    Only indicate an I/O error if the condition on open() actually exists.
    
    Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Tested-by: Mikael Pettersson <mikpe@it.uu.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9ed15641859740ad111e2e1a4fff1ae7c592e87
Author: Roland Dreier <roland@purestorage.com>
Date:   Wed Jun 5 09:54:17 2013 -0700

    tcm_qla2xxx: Fix residual for underrun commands that fail
    
    commit b5aff3d2747bea08b386edd070941a45611ffe51 upstream.
    
    Suppose an initiator sends a DATA IN command with an allocation length
    shorter than the FC transfer length -- we get a target message like
    
        TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12
    
    In that case, the target core adjusts the data_length and sets
    se_cmd->residual_count for the underrun.  But now suppose that command
    fails and we end up in tcm_qla2xxx_queue_status() -- that function
    unconditionally overwrites residual_count with the already adjusted
    data_length, and the initiator will burp with a message like
    
        qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes).
    
    Fix this by adding on to the existing underflow residual count instead.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
    Cc: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbf322be24a8e42b7d7fb88db9503ec65845b3a5
Author: Ming Lei <ming.lei@canonical.com>
Date:   Sat Jun 15 16:36:38 2013 +0800

    firmware loader: fix use-after-free by double abort
    
    commit 875979368eb4cfecff9f0e97625b90cc6009269d upstream.
    
    fw_priv->buf is accessed in both request_firmware_load() and
    writing to sysfs file of 'loading' context, but not protected
    by 'fw_lock' entirely. The patch makes sure that access on
    'fw_priv->buf' is protected by the lock.
    
    So fixes the double abort problem reported by nirinA raseliarison:
    
    	http://lkml.org/lkml/2013/6/14/188
    
    Reported-and-tested-by: nirinA raseliarison <nirina.raseliarison@gmail.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8608da733091cd11c8efcf35341a04c43b96966
Author: Anders Hammarquist <iko@iko.pp.se>
Date:   Wed Jun 19 01:45:48 2013 +0200

    USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
    
    commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
    
    Add product id for Abbott strip port cable for Precision meter which
    uses the TI 3410 chip.
    
    Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25869202403f70e6f3bf94b616090a6ee287cc19
Author: Shawn Joseph <jms.576@gmail.com>
Date:   Tue Jun 18 23:07:45 2013 -0700

    Input: xpad - fix for "Mad Catz Street Fighter IV FightPad" controllers
    
    commit be66227151c0cd4da536098c3ee07809101c6faa upstream.
    
    Added MAP_TRIGGERS_TO_BUTTONS for Mad Catz Street Fighter IV FightPad
    device. This controller model was already supported by the xpad
    driver, but none of the buttons work correctly without this change.
    
    Tested on kernel version 3.9.5.
    
    Signed-off-by: Shawn Joseph <jms.576@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b22b6d7de96b6737163cc26dfabfd738943d4203
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Jun 10 11:05:40 2013 -0700

    Input: add missing dependencies on CONFIG_HAS_IOMEM
    
    commit 150e5928d6063b273a80d9d6722417ac3c93ff82 upstream.
    
    Several drivers don't build on s390 with CONFIG_PCI disabled as
    they require MMIO functions.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f31259ca287923cef5a8efc566ff004fd472d0
Author: Ferruh Yigit <fery@cypress.com>
Date:   Thu May 23 09:56:55 2013 -0700

    Input: cyttsp - fix memcpy size param
    
    commit d2983cdb480157f637df07723f28aaa657b1080d upstream.
    
    memcpy param is wrong because of offset in bl_cmd, this may corrupt the
    stack which may cause a crash.
    
    Tested-by: Ferruh Yigit <fery@cypress.com> on TMA300-DVK
    Signed-off-by: Ferruh Yigit <fery@cypress.com>
    Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15aaf7e76567ab59307bfd68aa0be41abaa5b003
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Mar 25 20:19:59 2013 +0000

    net_sched: better precise estimation on packet length for untrusted packets
    
    [ Upstream commit 15e5a030716468dce4032fa0f398d840fa2756f6 ]
    
    gso_segs were reset to zero when kernel receive packets from untrusted
    source. But we use this zero value to estimate precise packet len which is
    wrong. So this patch tries to estimate the correct gso_segs value before using
    it in qdisc_pkt_len_init().
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acc196ccdd3cc88567892243f86b74f9c30db6b2
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Mar 25 20:19:58 2013 +0000

    netback: set transport header before passing it to kernel
    
    [ Upstream commit f9ca8f74399f9195fd8e01f67a8424a8d33efa55 ]
    
    Currently, for the packets receives from netback, before doing header check,
    kernel just reset the transport header in netif_receive_skb() which pretends non
    l4 header. This is suboptimal for precise packet length estimation (introduced
    in 1def9238: net_sched: more precise pkt_len computation) which needs correct l4
    header for gso packets.
    
    The patch just reuse the header probed by netback for partial checksum packets
    and tries to use skb_flow_dissect() for other cases, if both fail, just pretend
    no l4 header.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb552c1b88aa59f3d9091c9c0351f727ff01f186
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Mar 25 20:19:57 2013 +0000

    packet: set transport header before doing xmit
    
    [ Upstream commit c1aad275b0293d2b1905ec95a945422262470684 ]
    
    Set the transport header for 1) some drivers (e.g ixgbe needs l4 header to do
    atr) 2) precise packet length estimation (introduced in 1def9238) needs l4
    header to compute header length.
    
    So this patch first tries to get l4 header for packet socket through
    skb_flow_dissect(), and pretend no l4 header if skb_flow_dissect() fails.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f23cbca260db299e3c2debcbfbd9c928bf79707
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Mar 25 20:19:56 2013 +0000

    tuntap: set transport header before passing it to kernel
    
    [ Upstream commit 38502af77e07b5d6650b9ff99a0b482d86366592 ]
    
    Currently, for the packets receives from tuntap, before doing header check,
    kernel just reset the transport header in netif_receive_skb() which pretends no
    l4 header. This is suboptimal for precise packet length estimation (introduced
    in 1def9238) which needs correct l4 header for gso packets.
    
    So this patch set the transport header to csum_start for partial checksum
    packets, otherwise it first try skb_flow_dissect(), if it fails, just reset the
    transport header.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af7a606afaf5863914b32883d529ca27b4795eee
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Mar 25 20:19:55 2013 +0000

    macvtap: set transport header before passing skb to lower device
    
    [ Upstream commit 9b4d669bc06c215d64f56f1eb0d4eb96e14d689d ]
    
    Set the transport header for 1) some drivers (e.g ixgbe) needs l4 header 2)
    precise packet length estimation (introduced in 1def9238) needs l4 header to
    compute header length.
    
    For the packets with partial checksum, the patch just set the transport header
    to csum_start. Otherwise tries to use skb_flow_dissect() to get l4 offset, if it
    fails, just pretend no l4 header.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0eba2a6a88197e5581087c919be84312a144c936
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Apr 22 20:40:39 2013 +0000

    tuntap: correct the return value in tun_set_iff()
    
    [ Upstream commit e8dbad66ef56074eadb41ed5998acd2320447018 ]
    
    commit (3be8fbab tuntap: fix error return code in tun_set_iff()) breaks the
    creation of multiqueue tuntap since it forbids to create more than one queues
    for a multiqueue tuntap device. We need return 0 instead -EBUSY here since we
    don't want to re-initialize the device when one or more queues has been already
    attached. Add a comment and correct the return value to zero.
    
    Reported-by: Jerry Chu <hkchu@google.com>
    Cc: Jerry Chu <hkchu@google.com>
    Cc: Wei Yongjun <weiyj.lk@gmail.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by:  Jerry Chu <hkchu@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1017d77dc87e2444bb58416725621d5413d03047
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Jun 13 10:15:45 2013 +0900

    net: sh_eth: fix incorrect RX length error if R8A7740
    
    [ Upstream commit dd019897358b815f7828dab90b51d51df4d3658d ]
    
    This patch fixes an issue that the driver increments the "RX length error"
    on every buffer in sh_eth_rx() if the R8A7740.
    This patch also adds a description about the Receive Frame Status bits.
    
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbeb69e0d16302877d2a44ab2311dcc733269db9
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Wed Jun 12 14:26:44 2013 -0400

    sctp: fully initialize sctp_outq in sctp_outq_init
    
    [ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]
    
    In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
    (refactor sctp_outq_teardown to insure proper re-initalization)
    we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
    outq structure.  Steve West recently asked me why I removed the q->error = 0
    initalization from sctp_outq_teardown.  I did so because I was operating under
    the impression that sctp_outq_init would properly initalize that value for us,
    but it doesn't.  sctp_outq_init operates under the assumption that the outq
    struct is all 0's (as it is when called from sctp_association_init), but using
    it in __sctp_outq_teardown violates that assumption. We should do a memset in
    sctp_outq_init to ensure that the entire structure is in a known state there
    instead.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: netdev@vger.kernel.org
    CC: davem@davemloft.net
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f85b48ad4b57125ad0571fe796bdf83ccdb1ff8
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:36 2013 +0200

    l2tp: Fix sendmsg() return value
    
    [ Upstream commit a6f79d0f26704214b5b702bbac525cb72997f984 ]
    
    PPPoL2TP sockets should comply with the standard send*() return values
    (i.e. return number of bytes sent instead of 0 upon success).
    
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3f2b2e9fdc9a57c4a74f27b2e2102287638554f
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:23 2013 +0200

    l2tp: Fix PPP header erasure and memory leak
    
    [ Upstream commit 55b92b7a11690bc377b5d373872a6b650ae88e64 ]
    
    Copy user data after PPP framing header. This prevents erasure of the
    added PPP header and avoids leaking two bytes of uninitialised memory
    at the end of skb's data buffer.
    
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1f52acbab988ac47dda238a569264aaf586b7d6
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Jun 12 16:02:27 2013 +0200

    packet: packet_getname_spkt: make sure string is always 0-terminated
    
    [ Upstream commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe ]
    
    uaddr->sa_data is exactly of size 14, which is hard-coded here and
    passed as a size argument to strncpy(). A device name can be of size
    IFNAMSIZ (== 16), meaning we might leave the destination string
    unterminated. Thus, use strlcpy() and also sizeof() while we're
    at it. We need to memset the data area beforehand, since strlcpy
    does not padd the remaining buffer with zeroes for user space, so
    that we do not possibly leak anything.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cadc4351e3bb9a55460139fb8cdb00266c45e24
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Sat Jun 8 15:00:54 2013 +0200

    team: move add to port list before port enablement
    
    [ Upstream commit 72df935d985c1575ed44ad2c8c653b28147993fa ]
    
    team_port_enable() adds port to port_hashlist. Reader sees port
    in team_get_port_by_index_rcu() and returns it, but
    team_get_first_port_txable_rcu() tries to go through port_list, where the
    port is not inserted yet -> NULL pointer dereference.
    Fix this by reordering port_list and port_hashlist insertion.
    Panic is easily triggeable when txing packets and adding/removing port
    in a loop.
    
    Introduced by commit 3d249d4c "net: introduce ethernet teaming device"
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 397ab236f5273dfc2ab81ec637a61b3eb22bfc08
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Sat Jun 8 15:00:53 2013 +0200

    team: check return value of team_get_port_by_index_rcu() for NULL
    
    [ Upstream commit 76c455decbbad31de21c727edb184a963f42b40b ]
    
    team_get_port_by_index_rcu() might return NULL due to race between port
    removal and skb tx path. Panic is easily triggeable when txing packets
    and adding/removing port in a loop.
    
    introduced by commit 3d249d4ca "net: introduce ethernet teaming device"
    and commit 753f993911b "team: introduce random mode" (for random mode)
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b26c93c46a3dec25ed236d4ba6107eb4ed5d9401
Author: Jason Wang <jasowang@redhat.com>
Date:   Sat Jun 8 14:17:41 2013 +0800

    tuntap: set SOCK_ZEROCOPY flag during open
    
    [ Upstream commit 19a6afb23e5d323e1245baa4e62755492b2f1200 ]
    
    Commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990
    (tuntap: move socket to tun_file) forgets to set SOCK_ZEROCOPY flag, which will
    prevent vhost_net from doing zercopy w/ tap. This patch fixes this by setting
    it during file open.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 724a0863028eeb06607ed32972d12666c495becb
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jun 6 15:53:47 2013 +0200

    net: sctp: fix NULL pointer dereference in socket destruction
    
    [ Upstream commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c ]
    
    While stress testing sctp sockets, I hit the following panic:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    PGD 7cead067 PUD 7ce76067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: sctp(F) libcrc32c(F) [...]
    CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
    Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
    task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
    RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
    RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
    RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
    RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
    FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
     ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
     0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
    Call Trace:
     [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
     [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
     [<ffffffff814df36e>] inet_create+0x2ae/0x350
     [<ffffffff81455a6f>] __sock_create+0x11f/0x240
     [<ffffffff81455bf0>] sock_create+0x30/0x40
     [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
     [<ffffffff815403be>] ? do_page_fault+0xe/0x10
     [<ffffffff8153cb32>] ? page_fault+0x22/0x30
     [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
    Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
          1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
          8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
    RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
     RSP <ffff88007b569e08>
    CR2: 0000000000000020
    ---[ end trace e0d71ec1108c1dd9 ]---
    
    I did not hit this with the lksctp-tools functional tests, but with a
    small, multi-threaded test program, that heavily allocates, binds,
    listens and waits in accept on sctp sockets, and then randomly kills
    some of them (no need for an actual client in this case to hit this).
    Then, again, allocating, binding, etc, and then killing child processes.
    
    This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
    is set. The cause for that is actually very simple: in sctp_endpoint_init()
    we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
    our crypto transforms through crypto_alloc_hash(). In our scenario,
    it then can happen that crypto_alloc_hash() fails with -EINTR from
    crypto_larval_wait(), thus we bail out and release the socket via
    sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
    dereference as soon as we try to access members in the endpoint during
    sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
    if we have that case, we do not need to do any cleanup work and just
    leave the destruction handler.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3a4cc9ed7abcc4fb9db50c63018ee2008643537
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Jun 5 15:40:46 2013 +0800

    vhost_net: clear msg.control for non-zerocopy case during tx
    
    [ Upstream commit 4364d5f96eed7994a2c625bd9216656e55fba0cb ]
    
    When we decide not use zero-copy, msg.control should be set to NULL otherwise
    macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs
    wrongly.
    
    Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84
    (vhost-net: skip head management if no outstanding).
    
    This solves the following warnings:
    
    WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]()
    Modules linked in: vhost_net macvtap macvlan tun nfsd exportfs bridge stp llc openvswitch kvm_amd kvm bnx2 megaraid_sas [last unloaded: tun]
    CPU: 5 PID: 8670 Comm: vhost-8668 Not tainted 3.10.0-rc2+ #1566
    Hardware name: Dell Inc. PowerEdge R715/00XHKG, BIOS 1.5.2 04/19/2011
    ffffffffa0198323 ffff88007c9ebd08 ffffffff81796b73 ffff88007c9ebd48
    ffffffff8103d66b 000000007b773e20 ffff8800779f0000 ffff8800779f43f0
    ffff8800779f8418 000000000000015c 0000000000000062 ffff88007c9ebd58
    Call Trace:
    [<ffffffff81796b73>] dump_stack+0x19/0x1e
    [<ffffffff8103d66b>] warn_slowpath_common+0x6b/0xa0
    [<ffffffff8103d6b5>] warn_slowpath_null+0x15/0x20
    [<ffffffffa0197627>] handle_tx+0x477/0x4b0 [vhost_net]
    [<ffffffffa0197690>] handle_tx_kick+0x10/0x20 [vhost_net]
    [<ffffffffa019541e>] vhost_worker+0xfe/0x1a0 [vhost_net]
    [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
    [<ffffffffa0195320>] ? vhost_attach_cgroups_work+0x30/0x30 [vhost_net]
    [<ffffffff81061f46>] kthread+0xc6/0xd0
    [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
    [<ffffffff817a1aec>] ret_from_fork+0x7c/0xb0
    [<ffffffff81061e80>] ? kthread_freezable_should_stop+0x70/0x70
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fa5ee7e56ae382d9fe3f3d9484c79645c81340c
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 4 07:11:48 2013 +0000

    net_sched: htb: do not mix 1ns and 64ns time units
    
    [ Upstream commit 5343a7f8be11951cb3095b91e8e4eb506cfacc0f ]
    
    commit 56b765b79 ("htb: improved accuracy at high rates") added another
    regression for low rates, because it mixes 1ns and 64ns time units.
    
    So the maximum delay (mbuffer) was not 60 second, but 937 ms.
    
    Lets convert all time fields to 1ns as 64bit arches are becoming the
    norm.
    
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9042ce7879f9dfa9c5b1a30fea1f8789a15b00c3
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sun Jun 2 22:16:21 2013 +0000

    ipv6: assign rt6_info to inet6_ifaddr in init_loopback
    
    [ Upstream commit 534c877928a16ae5f9776436a497109639bf67dc ]
    
    Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
    "net IPv6 : Fix broken IPv6 routing table after loopback down-up"
    forgot to assign rt6_info to the inet6_ifaddr.
    When disable the net device, the rt6_info which allocated
    in init_loopback will not be destroied in __ipv6_ifa_notify.
    
    This will trigger the waring message below
    [23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1
    
    Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3aec030938930f0d54baf6e60b21074676943eca
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jun 2 13:55:05 2013 +0000

    net_sched: restore "overhead xxx" handling
    
    [ Upstream commit 01cb71d2d47b78354358e4bb938bb06323e17498 ]
    
    commit 56b765b79 ("htb: improved accuracy at high rates")
    broke the "overhead xxx" handling, as well as the "linklayer atm"
    attribute.
    
    tc class add ... htb rate X ceil Y linklayer atm overhead 10
    
    This patch restores the "overhead xxx" handling, for htb, tbf
    and act_police
    
    The "linklayer atm" thing needs a separate fix.
    
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vimalkumar <j.vimal@gmail.com>
    Cc: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d6b883e70a12f089614e72e85e3cd53757feae2
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed May 29 09:06:27 2013 +0000

    net: force a reload of first item in hlist_nulls_for_each_entry_rcu
    
    [ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]
    
    Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
    first item in the rcu protected list, in case the loop was restarted.
    
    This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37
    
    rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
    ptr->field :
    
    In some cases, gcc caches the value or ptr->field in a register.
    
    Use a barrier() to disallow such caching, as documented in
    Documentation/atomic_ops.txt line 114
    
    Thanks a lot to Roman for providing analysis and numerous patches.
    
    Diagnosed-by: Roman Gushchin <klamm@yandex-team.ru>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Boris Zhmurov <zhmurov@yandex-team.ru>
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ddbe4a80d995778197406f6a7fc69a12fc5932b
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Thu May 30 06:45:27 2013 +0000

    udp6: Fix udp fragmentation for tunnel traffic.
    
    [ Upstream commit 1e2bd517c108816220f262d7954b697af03b5f9c ]
    
    udp6 over GRE tunnel does not work after to GRE tso changes. GRE
    tso handler passes inner packet but keeps track of outer header
    start in SKB_GSO_CB(skb)->mac_offset.  udp6 fragment need to
    take care of outer header, which start at the mac_offset, while
    adding fragment header.
    This bug is introduced by commit 68c3316311 (GRE: Add TCP
    segmentation offload for GRE).
    
    Reported-by: Dmitry Kravkov <dkravkov@gmail.com>
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Tested-by: Dmitry Kravkov <dmitry@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 997a75d57a5e97f350ac978ebfd53c91f680b03d
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue May 28 18:32:11 2013 +0000

    tuntap: forbid changing mq flag for persistent device
    
    [ Upstream commit 8e6d91ae0917bf934ed86411148f79d904728d51 ]
    
    We currently allow changing the mq flag (IFF_MULTI_QUEUE) for a persistent
    device. This will result a mismatch between the number the queues in netdev and
    tuntap. This is because we only allocate a 1q netdevice when IFF_MULTI_QUEUE was
    not specified, so when we set the IFF_MULTI_QUEUE and try to attach more queues
    later, netif_set_real_num_tx_queues() may fail which result a single queue
    netdevice with multiple sockets attached.
    
    Solve this by disallowing changing the mq flag for persistent device.
    
    Bug was introduced by commit edfb6a148ce62e5e19354a1dcd9a34e00815c2a1
    (tuntap: reduce memory using of queues).
    
    Reported-by: Sriram Narasimhan <sriram.narasimhan@hp.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db12be9d9717bdb1ca87caa315118a5b2b331753
Author: Federico Vaga <federico.vaga@gmail.com>
Date:   Tue May 28 05:02:44 2013 +0000

    net/core/sock.c: add missing VSOCK string in af_family_*_key_strings
    
    [ Upstream commit 456db6a4d495f40777da6f1f32f62f13026f52db ]
    
    The three arrays of strings: af_family_key_strings,
    af_family_slock_key_strings and af_family_clock_key_strings have not
    VSOCK's string
    
    Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d47a8d585f15a1a7fff655c859bfd90a7fd6f560
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed May 22 14:07:44 2013 -0700

    net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
    
    [ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
      a7526eb5d06b0084ef12d7b168d008fcf516caab ]
    
    MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
    it's a hack that steals a bit to indicate to other networking code
    that a compat entry was used.  So don't allow it from a non-compat
    syscall.
    
    This prevents an oops when running this code:
    
    int main()
    {
    	int s;
    	struct sockaddr_in addr;
    	struct msghdr *hdr;
    
    	char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
    	                      PROT_READ | PROT_WRITE,
    	                      MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
    	if (highpage == MAP_FAILED)
    		err(1, "mmap");
    
    	s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    	if (s == -1)
    		err(1, "socket");
    
            addr.sin_family = AF_INET;
            addr.sin_port = htons(1);
            addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    	if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
    		err(1, "connect");
    
    	void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
    	printf("Evil address is %p\n", evil);
    
    	if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
    		err(1, "sendmmsg");
    
    	return 0;
    }
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 791169e5924d35532443c9538e3ba0d49ef0de10
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Tue May 28 08:26:49 2013 +0200

    ipv4: fix redirect handling for TCP packets
    
    [ Upstream commit f96ef988cc603487c03a6de07807b06cbe641829 ]
    
    Unlike ipv4_redirect() and ipv4_sk_redirect(), ip_do_redirect()
    doesn't call __build_flow_key() directly but via
    ip_rt_build_flow_key() wrapper. This leads to __build_flow_key()
    getting pointer to IPv4 header of the ICMP redirect packet
    rather than pointer to the embedded IPv4 header of the packet
    initiating the redirect.
    
    As a result, handling of ICMP redirects initiated by TCP packets
    is broken. Issue was introduced by
    
    	4895c771c ("ipv4: Add FIB nexthop exceptions.")
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92a47b4c37e9d47887407bb892d9595ef05e89f1
Author: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date:   Sun May 26 21:31:28 2013 +0000

    net: phy: fix a bug when verify the EEE support
    
    [ Upstream commit 9a9c56cb34e65000d1f0a4b7553399bfcf7c5a52 ]
    
    The phy_init_eee has to exit with an error when the
    local device and its link partner both do not support EEE.
    So this patch fixes a problem when verify this.
    
    Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9622e5d22e42da9ade7cf72a1f04bebab1292332
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 24 05:49:58 2013 +0000

    ip_tunnel: fix kernel panic with icmp_dest_unreach
    
    [ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]
    
    Daniel Petre reported crashes in icmp_dst_unreach() with following call
    graph:
    
    Daniel found a similar problem mentioned in
     http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html
    
    And indeed this is the root cause : skb->cb[] contains data fooling IP
    stack.
    
    We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
    is called. Or else skb->cb[] might contain garbage from GSO segmentation
    layer.
    
    A similar fix was tested on linux-3.9, but gre code was refactored in
    linux-3.10. I'll send patches for stable kernels as well.
    
    Many thanks to Daniel for providing reports, patches and testing !
    
    Reported-by: Daniel Petre <daniel.petre@rcs-rds.ro>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 351cd36b0eae5cde8ca1fa7af89dfc14cc783b49
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 23 07:44:20 2013 +0000

    tcp: xps: fix reordering issues
    
    [ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]
    
    commit 3853b5841c01a ("xps: Improvements in TX queue selection")
    introduced ooo_okay flag, but the condition to set it is slightly wrong.
    
    In our traces, we have seen ACK packets being received out of order,
    and RST packets sent in response.
    
    We should test if we have any packets still in host queue.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a76328a972feb3ee70a7918e7b5f23406543bff
Author: Timo Teräs <timo.teras@iki.fi>
Date:   Wed May 22 01:40:47 2013 +0000

    xfrm: properly handle invalid states as an error
    
    [ Upstream commit 497574c72c9922cf20c12aed15313c389f722fa0 ]
    
    The error exit path needs err explicitly set. Otherwise it
    returns success and the only caller, xfrm_output_resume(),
    would oops in skb_dst(skb)->ops derefence as skb_dst(skb) is
    NULL.
    
    Bug introduced in commit bb65a9cb (xfrm: removes a superfluous
    check and add a statistic).
    
    Signed-off-by: Timo Teräs <timo.teras@iki.fi>
    Cc: Li RongQing <roy.qing.li@gmail.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bedc6277cbf2289a6a63bd83b20d89591d392336
Author: Nandita Dukkipati <nanditad@google.com>
Date:   Tue May 21 15:12:07 2013 +0000

    tcp: bug fix in proportional rate reduction.
    
    [ Upstream commit 35f079ebbc860dcd1cca70890c9c8d59c1145525 ]
    
    This patch is a fix for a bug triggering newly_acked_sacked < 0
    in tcp_ack(.).
    
    The bug is triggered by sacked_out decreasing relative to prior_sacked,
    but packets_out remaining the same as pior_packets. This is because the
    snapshot of prior_packets is taken after tcp_sacktag_write_queue() while
    prior_sacked is captured before tcp_sacktag_write_queue(). The problem
    is: tcp_sacktag_write_queue (tcp_match_skb_to_sack() -> tcp_fragment)
    adjusts the pcount for packets_out and sacked_out (MSS change or other
    reason). As a result, this delta in pcount is reflected in
    (prior_sacked - sacked_out) but not in (prior_packets - packets_out).
    
    This patch does the following:
    1) initializes prior_packets at the start of tcp_ack() so as to
    capture the delta in packets_out created by tcp_fragment.
    2) introduces a new "previous_packets_out" variable that snapshots
    packets_out right before tcp_clean_rtx_queue, so pkts_acked can be
    correctly computed as before.
    3) Computes pkts_acked using previous_packets_out, and computes
    newly_acked_sacked using prior_packets.
    
    Signed-off-by: Nandita Dukkipati <nanditad@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6921ecb3fb34ea14a4b82d0f9d8853ceee8f1201
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Mon May 20 06:54:43 2013 +0000

    8139cp: reset BQL when ring tx ring cleared
    
    [ Upstream commit 98962baad72fd6d393bf39dbb7c2076532c363c6 ]
    
    This patch cures transmit timeout's with DHCP observed
    while running under KVM. When the transmit ring is cleaned out,
    the Byte Queue Limit values need to be reset.
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b22e5134f8920a630c64d8a97f3c92208616f6ef
Author: Francois Romieu <romieu@fr.zoreil.com>
Date:   Sat May 18 01:24:46 2013 +0000

    r8169: fix offloaded tx checksum for small packets.
    
    [ Upstream commit b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]
    
    8168evl offloaded checksums are wrong since commit
    e5195c1f31f399289347e043d6abf3ffa80f0005 ("r8169: fix 8168evl frame padding.")
    pads small packets to 60 bytes (without ethernet checksum). Typical symptoms
    appear as UDP checksums which are wrong by the count of added bytes.
    
    It isn't worth compensating. Let the driver checksum.
    
    Due to the skb length changes, TSO code is moved before the Tx descriptor gets
    written.
    
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Tested-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4299de8beb0957340857dd4724ef32a9d0459bf
Author: Paul Moore <pmoore@redhat.com>
Date:   Fri May 17 09:08:50 2013 +0000

    netlabel: improve domain mapping validation
    
    [ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]
    
    The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
    does not properly validate new domain hash entries resulting in
    potential problems when an administrator attempts to add an invalid
    entry.  One such problem, as reported by Vlad Halilov, is a kernel
    BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
    adding an IPv6 outbound mapping with a CIPSO configuration.
    
    This patch corrects this problem by adding the necessary validation
    code to netlbl_domhsh_add() via the newly created
    netlbl_domhsh_validate() function.
    
    Ideally this patch should also be pushed to the currently active
    -stable trees.
    
    Reported-by: Vlad Halilov <vlad.halilov@gmail.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61ca440d36151d63b6b5c4ac5bb9bb8933332926
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 17 04:53:13 2013 +0000

    ipv6: fix possible crashes in ip6_cork_release()
    
    [ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]
    
    commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
    added some code duplication and bad error recovery, leading to potential
    crash in ip6_cork_release() as kfree() could be called with garbage.
    
    use kzalloc() to make sure this wont happen.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9104ef4aa6b7684214a807ae683eeb33bc0f317
Author: Sridhar Samudrala <sri@us.ibm.com>
Date:   Fri May 17 06:39:07 2013 +0000

    vxlan: Update vxlan fdb 'used' field after each usage
    
    [ Upstream commit 014be2c8eac3381e202f684c1f35ae184a8b152b ]
    
    Fix some instances where vxlan fdb 'used' field is not updated after the entry
    is used.
    
    v2: rename vxlan_find_mac() as __vxlan_find_mac() and create a new vxlan_find_mac()
    that also updates ->used field.
    
    Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6108961b022d3bca9cded380a94731897e09543a
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu May 16 22:25:34 2013 +0000

    gianfar: add missing iounmap() on error in gianfar_ptp_probe()
    
    [ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]
    
    Add the missing iounmap() before return from gianfar_ptp_probe()
    in the error handling case.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4acfe8fb6ea6e05f91585f7390fcf338324c4f1d
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 13 02:24:11 2013 +0000

    net/802/mrp: fix lockdep splat
    
    [ Upstream commit faff57a92ba1d7247c5e86ecea2886d2c9d54507 ]
    
    commit fb745e9a037895 ("net/802/mrp: fix possible race condition when
    calling mrp_pdu_queue()") introduced a lockdep splat.
    
    [   19.735147] =================================
    [   19.735235] [ INFO: inconsistent lock state ]
    [   19.735324] 3.9.2-build-0063 #4 Not tainted
    [   19.735412] ---------------------------------
    [   19.735500] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    [   19.735592] rmmod/1840 [HC0[0]:SC0[0]:HE1:SE1] takes:
    [   19.735682]  (&(&app->lock)->rlock#2){+.?...}, at: [<f862bb5b>]
    mrp_uninit_applicant+0x69/0xba [mrp]
    
    app->lock is normally taken under softirq context, so disable BH to
    avoid the splat.
    
    Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: David Ward <david.ward@ll.mit.edu>
    Cc: Cong Wang <amwang@redhat.com>
    Tested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbdbe6882d8ff9918c015686a6a48b02414d920b
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 13 21:25:52 2013 +0000

    tcp: fix tcp_md5_hash_skb_data()
    
    [ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]
    
    TCP md5 communications fail [1] for some devices, because sg/crypto code
    assume page offsets are below PAGE_SIZE.
    
    This was discovered using mlx4 driver [2], but I suspect loopback
    might trigger the same bug now we use order-3 pages in tcp_sendmsg()
    
    [1] Failure is giving following messages.
    
    huh, entered softirq 3 NET_RX ffffffff806ad230 preempt_count 00000100,
    exited with 00000101?
    
    [2] mlx4 driver uses order-2 pages to allocate RX frags
    
    Reported-by: Matt Schnall <mischnal@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Bernhard Beck <bbeck@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecfaafb3c1d177bf89123cead507f160b6005871
Author: Frank Li <Frank.Li@freescale.com>
Date:   Tue May 7 14:08:44 2013 +0000

    net: fec: fix kernel oops when plug/unplug cable many times
    
    [ Upstream commits 54309fa60b5f57b90c1842176f6045e665d21142 and
      3169134478a9638baf0dbb4fdca5a0718cbe8e27 ]
    
    reproduce steps
     1. flood ping from other machine
     	ping -f -s 41000 IP
     2. run below script
        while [ 1 ]; do ethtool -s eth0 autoneg off;
        sleep 3;ethtool -s eth0 autoneg on; sleep 4; done;
    
    You can see oops in one hour.
    
    The reason is fec_restart clear BD but NAPI may use it.
    The solution is disable NAPI and stop xmit when reset BD.
    disable NAPI may sleep, so fec_restart can't be call in
    atomic context.
    
    Signed-off-by: Frank Li <Frank.Li@freescale.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Tested-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d609cfeee98ba6e95f41c2cf299744008c4d03da
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 19 11:15:26 2013 -0400

    x86: Fix section mismatch on load_ucode_ap
    
    commit 949785996ec2250fa958fc3a924e5186e9a8fa2c upstream.
    
    We are in the process of removing all the __cpuinit annotations.
    While working on making that change, an existing problem was
    made evident:
    
      WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
      in reference from the function cpu_init() to the function
      .init.text:load_ucode_ap()   The function cpu_init() references
      the function __init load_ucode_ap().  This is often because cpu_init
      lacks a __init annotation or the annotation of load_ucode_ap is wrong.
    
    This now appears because in my working tree, cpu_init() is no longer
    tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
    hypothesis from the audit is the correct one, as there was an incorrect
    __init tag on the prototype in the header (but __cpuinit was used on
    the function itself.)
    
    The audit is telling us that the prototype's __init annotation took
    effect and the function did land in the .init.text section.  Checking
    with objdump on a mainline tree that still has __cpuinit shows that
    the __cpuinit on the function takes precedence over the __init on the
    prototype, but that won't be true once we make __cpuinit a no-op.
    
    Even though we are removing __cpuinit, we temporarily align both
    the function and the prototype on __cpuinit so that the changeset
    can be applied to stable trees  if desired.
    
    [ hpa: build fix only, no object code change ]
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 975f0ca2c8a9f066974ba298287a2c36ccd380a0
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Jun 18 12:33:40 2013 -0700

    x86: fix build error and kconfig for ia32_emulation and binfmt
    
    commit d1603990ea626668c78527376d9ec084d634202d upstream.
    
    Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
    when COMPAT_BINFMT_ELF is being selected.
    
    warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)
    
    fs/built-in.o: In function `elf_core_dump':
    compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
    compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
    compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'
    
    [ hpa: This was sent to me for -next but it is a low risk build fix ]
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e967c60e3c8b378317d019c0c8bba9b56caab13f
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Jun 13 13:17:01 2013 -0700

    x86, mtrr: Fix original mtrr range get for mtrr_cleanup
    
    commit d8d386c10630d8f7837700f4c466443d49e12cc0 upstream.
    
    Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
    during add range) broke mtrr cleanup on his setup in 3.9.5.
    corresponding commit in upstream is fbe06b7bae7c.
    
      *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G
    
    https://bugzilla.kernel.org/show_bug.cgi?id=59491
    
    So it rejects new var mtrr layout.
    
    It turns out we have some problem with initial mtrr range retrieval.
    The current sequence is:
    	x86_get_mtrr_mem_range
    		==> bunchs of add_range_with_merge
    		==> bunchs of subract_range
    		==> clean_sort_range
    	add_range_with_merge for [0,1M)
    	sort_range()
    
    add_range_with_merge could have blank slots, so we can not just
    sort only, that will have final result have extra blank slot in head.
    
    So move that calling add_range_with_merge for [0,1M), with that we
    could avoid extra clean_sort_range calling.
    
    Reported-by: Joshua Covington <joshuacov@googlemail.com>
    Tested-by: Joshua Covington <joshuacov@googlemail.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f94b921ee8575107dbfef5593781cd7fc2ecd23
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Thu Jun 13 13:17:02 2013 -0700

    range: Do not add new blank slot with add_range_with_merge
    
    commit 0541881502a1276149889fe468662ff6a8fc8f6d upstream.
    
    Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
    during add range) broke mtrr cleanup on his setup in 3.9.5.
    corresponding commit in upstream is fbe06b7bae7c.
    
    The reason is add_range_with_merge could generate blank spot.
    
    We could avoid that by searching new expanded start/end, that
    new range should include all connected ranges in range array.
    At last add the new expanded start/end to the range array.
    Also move up left array so do not add new blank slot in the
    range array.
    
    -v2: move left array to avoid enhance add_range()
    -v3: include fix from Joshua about memmove declaring when
         DYN_DEBUG is used.
    
    Reported-by: Joshua Covington <joshuacov@googlemail.com>
    Tested-by: Joshua Covington <joshuacov@googlemail.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1371154622-8929-3-git-send-email-yinghai@kernel.org
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4cf36527d2897bc14387201fa2ed6772c0ef4ff
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Wed Jun 19 10:02:28 2013 -0400

    drm/radeon: update lockup tracking when scheduling in empty ring
    
    commit 8444d5c69549aa0f0b574cc608742d4669e1cc01 upstream.
    
    There might be issue with lockup detection when scheduling on an
    empty ring that have been sitting idle for a while. Thus update
    the lockup tracking data when scheduling new work in an empty ring.
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Tested-by: Andy Lutomirski <luto@amacapital.net>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7811fd799beebd19076ec84ea160f0f14bf40f7d
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jun 6 12:41:17 2013 -0400

    drm/radeon: do not try to uselessly update virtual memory pagetable
    
    commit 3813f5ca9ab7a00e80a17aab34f155453c66c78a upstream.
    
    If a buffer is never bound to a virtual memory pagetable than don't try
    to unbind it. Only drawback is that we don't update the pagetable when
    unbinding the ib pool buffer which is fine because it only happens at
    suspend or module unload/shutdown.
    
    Fixes spurious messages about buffers without VM mappings. E.g.:
    radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 258378e9b7cd4e08cdbc1a72c101e0886cbb27f1
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Wed Jun 19 03:14:20 2013 +0200

    drm/prime: Honor requested file flags when exporting a buffer
    
    commit ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 upstream.
    
    The DRM PRIME API passes file flags to the driver for the exported
    buffer. Honor them instead of hardcoding 0600.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb8b3337e5cb2adf7d75f0842522e4ff5847cd90
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 19 00:44:45 2013 +0200

    ACPI / PM: Fix error code path for power resources initialization
    
    commit 6ee22e9d59151550a55d370b14109bdae8b58bda upstream.
    
    Commit 781d737 (ACPI: Drop power resources driver) introduced a
    bug in the power resources initialization error code path causing
    a NULL pointer to be referenced in acpi_release_power_resource()
    if there's an error triggering a jump to the 'err' label in
    acpi_add_power_resource().  This happens because the list_node
    field of struct acpi_power_resource has not been initialized yet
    at this point and doing a list_del() on it is a bad idea.
    
    To prevent this problem from occuring, initialize the list_node
    field of struct acpi_power_resource upfront.
    
    Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b7cda9f9cd4d928c69b3aa7a9a70c9fff74b256
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sun Jun 16 00:38:30 2013 +0200

    ACPI / dock: Take ACPI scan lock in write_undock()
    
    commit 8112006f41fd76ddf4988f8ddd904563db85613c upstream.
    
    Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
    memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
    called under acpi_scan_lock, but currently the following scenario
    violating that requirement is possible:
    
     write_undock()
      handle_eject_request()
       hotplug_dock_devices()
        dock_remove_acpi_device()
         acpi_bus_trim()
    
    Fix that by making write_undock() acquire acpi_scan_lock before
    calling handle_eject_request() as appropriate (begin_undock() is
    under the lock too in analogy with acpi_dock_deferred_cb()).
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Toshi Kani <toshi.kani@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e827255cad1f41448a100d7c93579f995d3a5ed5
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon May 20 15:41:45 2013 +0000

    ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
    
    commit 204ebc0aa30a7115f300cac39fbb7eeb66524881 upstream.
    
    acpi_get_override_irq() was added because there was a problem with
    buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
    commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
    IRQ8 issues in IOAPIC mode).
    
    With ACPI 5 enumerated devices there are typically one or more
    extended IRQ resources per device (and these IRQs can be shared).
    However, the acpi_get_override_irq() workaround forces all IRQs in
    range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
    as can be seen from the dmesg below:
    
    	ACPI: IRQ 6 override to edge, high
    	ACPI: IRQ 7 override to edge, high
    	ACPI: IRQ 7 override to edge, high
    	ACPI: IRQ 13 override to edge, high
    
    Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
    the same thing:
    
    	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00
    
    The _CSR method for INT33C2 (and INT33C3) device returns following
    resource:
    
    	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
    	{
    		0x00000007,
    	}
    
    which states that this is supposed to be level triggered, active low,
    shared IRQ instead.
    
    Fix this by making sure that acpi_get_override_irq() gets only called
    when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
    
    While we are there, correct pr_warning() to print the right triggering
    value.
    
    This change turns out to be necessary to make DMA work correctly on
    systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
    
    [rjw: Changelog]
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c78078398d9c86a7b36b02726399d07013b1e732
Author: Zhanghaoyu (A) <haoyu.zhang@huawei.com>
Date:   Fri Jun 14 07:36:13 2013 +0000

    KVM: x86: remove vcpu's CPL check in host-invoked XCR set
    
    commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.
    
    __kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
    called in two flows, one is invoked by guest, call stack shown as below,
    
      handle_xsetbv(or xsetbv_interception)
        kvm_set_xcr
          __kvm_set_xcr
    
    the other one is invoked by host, for example during system reset:
    
      kvm_arch_vcpu_ioctl
        kvm_vcpu_ioctl_x86_set_xcrs
          __kvm_set_xcr
    
    The former does need the CPL check, but the latter does not.
    
    Signed-off-by: Zhang Haoyu <haoyu.zhang@huawei.com>
    [Tweaks to commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f918123bd108a9b50bceaf4b32ac173b9e3f3e
Author: Igor Mammedov <imammedo@redhat.com>
Date:   Mon Jun 10 18:31:11 2013 +0200

    x86: kvmclock: zero initialize pvclock shared memory area
    
    commit 07868fc6aaf57847b0f3a3d53086b7556eb83f4a upstream.
    
    kernel might hung in pvclock_clocksource_read() due to
    uninitialized memory might contain odd version value in
    following cycle:
    
            do {
                    version = __pvclock_read_cycles(src, &ret, &flags);
            } while ((src->version & 1) || version != src->version);
    
    if secondary kvmclock is accessed before it's registered with kvm.
    
    Clear garbage in pvclock shared memory area right after it's
    allocated to avoid this issue.
    
    Ref: https://bugzilla.kernel.org/show_bug.cgi?id=59521
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    [See BZ for analysis.  We may want a different fix for 3.11, but
     this is the safest for now - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5440f5d68b518339a9ee2fdc838c8caef19e36de
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jun 16 21:27:12 2013 +0100

    x86/efi: Fix dummy variable buffer allocation
    
    commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream.
    
    1. Check for allocation failure
    2. Clear the buffer contents, as they may actually be written to flash
    3. Don't leak the buffer
    
    Compile-tested only.
    
    [ Tested successfully on my buggy ASUS machine - Matt ]
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04778bad36603c0ced7f1540671de81e9b41ef0c
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Fri Feb 22 01:30:44 2013 +0100

    carl9170: fix frame drop and WARN due to minstrel_ht change
    
    commit 5f34608fa2acbfef5a06d0072a978c9943c28a2d upstream.
    
    With "mac80211/minstrel_ht: add support for using CCK rates"
    minstrel_ht selects legacy CCK rates as viable rates for
    outgoing frames which might be sent as part of an A-MPDU
    [IEEE80211_TX_CTL_AMPDU is set].
    
    This behavior triggered the following WARN_ON in the driver:
    > WARNING: at carl9170/tx.c:995 carl9170_op_tx+0x1dd/0x6fd
    The driver assumed that the rate control algorithm made a
    mistake and dropped the frame.
    
    This patch removes the noisy warning altogether and allows
    said A-MPDU frames with CCK sample and/or fallback rates to
    be transmitted seamlessly.
    
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 386f1a109388d7eeb485008c4089ce8458731156
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Fri Jun 14 09:05:41 2013 +0200

    parisc: provide pci_mmap_page_range() for parisc
    
    commit 2cc7138f4347df939ce03f313e3d87794bab36f8 upstream.
    
    pci_mmap_page_range() is needed for X11-server support on C8000 with ATI
    FireGL card.
    
    Signed-off-by Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c46f66eefb7212e173f962fe2b2442449ce10cbf
Author: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date:   Sun Jun 9 23:00:21 2013 +0200

    parisc: fix serial ports on C8000 workstation
    
    commit 9a66d1869d90f13fbaf83dcce5b1aeec86fbc699 upstream.
    
    The C8000 workstation (64 bit kernel only) has a somewhat different
    serial port configuration than other models.
    Thomas Bogendoerfer sent a patch to fix this in September 2010, which
    was now minimally modified by me.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 549b3750960246aefda940bed50b01b6557f4d15
Author: Helge Deller <deller@gmx.de>
Date:   Wed Jun 5 20:50:01 2013 +0000

    parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50 (part 2)
    
    commit 91ea8207168793b365322be3c90a4ee9e8b03ed4 upstream.
    
    Make sure that we really return -1 (instead of 0x00ff) as node id for
    page frame numbers which are not physically available.
    
    This finally fixes the kernel panic when running
    cat /proc/kpageflags /proc/kpagecount.
    
    Theoretically this patch now limits the number of physical memory ranges
    to 127 instead of 254, but currently we have MAX_PHYSMEM_RANGES
    hardcoded to 8 which is sufficient for all existing parisc machines.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bb6948d3d84c1ecea5efc6ac710953a91c9c7c6
Author: Helge Deller <deller@gmx.de>
Date:   Thu May 30 21:06:39 2013 +0000

    parisc: parport0: fix this legacy no-device port driver!
    
    commit 4edb38695d9a3cd62739f8595e21f36f0aabf4c2 upstream.
    
    Fix the above kernel error from parport_announce_port() on 32bit GSC
    machines (e.g. B160L). The parport driver requires now a pointer to the
    device struct.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 753c43534ba817c8bd14b77e6fd0b43dea3892d2
Author: Chen Gang <gang.chen@asianux.com>
Date:   Thu May 30 01:18:43 2013 +0000

    parisc: kernel: using strlcpy() instead of strcpy()
    
    commit ea99b1adf22abd62bdcf14b1c9a0a4d3664eefd8 upstream.
    
    'boot_args' is an input args, and 'boot_command_line' has a fix length.
    So use strlcpy() instead of strcpy() to avoid memory overflow.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Acked-by: Kyle McMartin <kyle@mcmartin.ca>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a56ddb0d36e20774cec963b919d6ce08d41d0e79
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Wed May 29 09:56:58 2013 +0000

    parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"
    
    commit 766039022a480ede847659daaa78772bdcc598ae upstream.
    
    There's a Makefile line setting cflags for CONFIG_PA7100. But that
    Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
    covers both PA7000 and PA7100 processors. So let's use the corresponding
    Kconfig macro.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 573ae3719ff195084e669b12e7334d77a2a4e111
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 28 20:35:54 2013 +0000

    parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50
    
    commit ae249b5fa27f9fba25aa59664d4338efc2dd2394 upstream.
    
    With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
    cat /proc/kpageflags triggers this kernel bug:
    
    kernel BUG at arch/parisc/include/asm/mmzone.h:50!
    CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
     IAOQ[0]: kpageflags_read0x128/0x238
     IAOQ[1]: kpageflags_read0x12c/0x238
     RP(r2): proc_reg_read0xbc/0x130
    Backtrace:
     [<00000000402ca2d4>] proc_reg_read0xbc/0x130
     [<0000000040235bcc>] vfs_read0xc4/0x1d0
     [<0000000040235f0c>] SyS_read0x94/0xf0
     [<0000000040105fc0>] syscall_exit0x0/0x14
    
    kpageflags_read() walks through the whole memory, even if some memory
    areas are physically not available. So, we should better not BUG on an
    unavailable pfn in pfn_to_nid() but just return the expected value -1 or
    0.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fd29ffeedc34861e5512c4cdc6a3c648880823d
Author: Chen Gang <gang.chen@asianux.com>
Date:   Mon May 27 04:57:09 2013 +0000

    parisc: memory overflow, 'name' length is too short for using
    
    commit 3f108de96ba449a8df3d7e3c053bf890fee2cb95 upstream.
    
    'path.bc[i]' can be asigned by PCI_SLOT() which can '> 10', so sizeof(6
    * "%u:" + "%u" + '\0') may be 21.
    
    Since 'name' length is 20, it may be memory overflow.
    
    And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
    max length of 'name' must be less than 28.
    
    So simplify thinking, we can use 28 instead of 20 directly, and do not
    think of whether 'patchc.bc[i]' can '> 100'.
    
    Signed-off-by: Chen Gang <gang.chen@asianux.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02f52975eb0858eb03ca091f644c8eb171895f92
Author: Helge Deller <deller@gmx.de>
Date:   Fri May 24 21:27:35 2013 +0000

    parisc: fix irq stack on UP and SMP
    
    commit d96b51ec14650b490ab98e738bcc02309396e5bc upstream.
    
    The logic to detect if the irq stack was already in use with
    raw_spin_trylock() is wrong, because it will generate a "trylock failure
    on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.
    
    arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
    no atomic protection is given and we are reentrant here. A mutex didn't
    worked either and brings more overhead by turning off interrupts.
    
    So, let's use the fastest path for parisc which is the ldcw instruction.
    
    Counting how often the irq stack was used is pretty useless, so just
    drop this piece of code.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec62e8914c5994ab7c7873b6522691b70458bfa1
Author: John David Anglin <dave.anglin@bell.net>
Date:   Mon May 20 16:42:53 2013 +0000

    parisc: make interrupt and interruption stack allocation reentrant
    
    commit b63a2bbc0b9b106a93e11952ab057e2408f2eb02 upstream.
    
    The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
    frame for external interrupts and interruptions requiring a stack frame.
    They are currently not reentrant in that they save register context
    before the stack is set or adjusted.
    
    I have observed a number of system crashes where there was clear
    evidence of stack corruption during interrupt processing, and as a
    result register corruption. Some interruptions can still occur during
    interruption processing, however external interrupts are disabled and
    data TLB misses don't occur for absolute accesses. So, it's not entirely
    clear what triggers this issue. Also, if an interruption occurs when
    Q=0, it is generally not possible to recover as the shadowed registers
    are not copied.
    
    The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
    macros to allocate stack before doing register saves. The new code is a
    couple of instructions shorter than the old implementation. Thus, it's
    an improvement even if it doesn't fully resolve the stack corruption
    issue. Based on limited testing, it improves SMP system stability.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 495a903504ed9a9bcfe85b60fd33d9df97f7df4c
Author: Helge Deller <deller@gmx.de>
Date:   Sat May 18 19:35:44 2013 +0000

    parisc: show number of FPE and unaligned access handler calls in /proc/interrupts
    
    commit d0c3be806a3fe7f4abdb0f7e7287addb55e73f35 upstream.
    
    Show number of floating point assistant and unaligned access fixup
    handler in /proc/interrupts file.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08ac6970e5c266cd1a9201321e452099abf4532f
Author: Helge Deller <deller@gmx.de>
Date:   Thu May 16 20:42:39 2013 +0000

    parisc: add rp5470 entry to machine database
    
    commit 949451b9b19da5e998778eb78929aafc73b5c227 upstream.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48baa280fc7a23559f27a8661f34812e2c80e539
Author: Helge Deller <deller@gmx.de>
Date:   Fri May 10 21:24:01 2013 +0000

    parisc: implement irq stacks - part 2 (v2)
    
    commit 416821d3d68164909b2cbcf398e4ba0797f5f8a2 upstream.
    
    This patch fixes few build issues which were introduced with the last
    irq stack patch, e.g. the combination of stack overflow check and irq
    stack.
    
    Furthermore we now do proper locking and change the irq bh handler
    to use the irq stack as well.
    
    In /proc/interrupts one now can monitor how huge the irq stack has grown
    and how often it was preferred over the kernel stack.
    
    IRQ stacks are now enabled by default just to make sure that we not
    overflow the kernel stack by accident.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34afdc6cee2da3bcf9f6b3a80ec55bb1c99afb9b
Author: Zhao Hongjiang <zhaohongjiang@huawei.com>
Date:   Tue May 7 16:18:12 2013 -0700

    parisc: remove the second argument of kmap_atomic()
    
    commit 1ab4ce762370b82870834899e49c08129d7ae271 upstream.
    
    kmap_atomic() requires only one argument now.
    
    Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6f14ceec1ce77775a83090f89eacc0176c42757
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 7 21:42:47 2013 +0000

    parisc: tlb flush counting fix for SMP and UP
    
    commit 0fc537d1d655cdae69b489dbba46ad617cfc1373 upstream.
    
    Fix up build error on UP and show correctly number of function call
    (ipi) irqs.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b12a2f1a77a764665fb2cc4322964f3010244b33
Author: Helge Deller <deller@gmx.de>
Date:   Mon May 6 19:20:26 2013 +0000

    parisc: more irq statistics in /proc/interrupts
    
    commit cd85d5514d5c4d7e78abac923fc032457d0c5091 upstream.
    
    Add framework and initial values for more fine grained statistics in
    /proc/interrupts.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85d1f3a085961333a59e30906baabf8f5993d266
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 7 20:25:42 2013 +0000

    parisc: implement irq stacks
    
    commit 200c880420a2c02a0899120ce52d801fad705b90 upstream.
    
    Default kernel stack size on parisc is 16k.  During tests we found that the
    kernel stack can easily grow beyond 13k, which leaves 3k left for irq
    processing.
    
    This patch adds the possibility to activate an additional stack of 16k per CPU
    which is being used during irq processing.  This implementation does not yet
    uses this irq stack for the irq bh handler.
    
    The assembler code for call_on_stack was heavily cleaned up by John
    David Anglin.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    CC: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57c9e56523dcb65821d9cbd9382b1cb453ce2ad9
Author: Helge Deller <deller@gmx.de>
Date:   Tue May 7 19:28:52 2013 +0000

    parisc: add kernel stack overflow check
    
    commit 9372450cc22d185f708e5cc3557cf991be4b7dc5 upstream.
    
    Add the CONFIG_DEBUG_STACKOVERFLOW config option to enable checks to
    detect kernel stack overflows.
    
    Stack overflows can not be detected reliable since we do not want to
    introduce too much overhead.
    
    Instead, during irq processing in do_cpu_irq_mask() we check kernel
    stack usage of the interrupted kernel process. Kernel threads can be
    easily detected by checking the value of space register 7 (sr7) which
    is zero when running inside the kernel.
    
    Since THREAD_SIZE is 16k and PAGE_SIZE is 4k, reduce the alignment of
    the init thread to the lower value (PAGE_SIZE) in the kernel
    vmlinux.ld.S linker script.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d92e6a30702e4c2268e6793ccfcb1e2fa5562eb1
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Mon May 27 21:09:53 2013 +0200

    brcmfmac: Turn off ARP offloading when configured for AP.
    
    commit b3657453f16a7b84eab9b93bb9a9a2901ffc70af upstream.
    
    ARP offloading should only be used in STA or P2P client mode. It
    is currently configured once at init. When being configured for AP
    ARP offloading should be turned off and when AP mode is left it can
    be turned back on.
    
    Reviewed-by: Arend Van Spriel <arend@broadcom.com>
    Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8eff5bf73956bd2965978c6a97a8ff99465a66a
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu May 30 18:05:55 2013 -0500

    rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networks
    
    commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30 upstream.
    
    Driver rtl8192cu can connect to WPA2 networks, but fails for any other
    encryption method. The cause is a failure to set the rate control data
    blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793
    and https://bugzilla.redhat.com/show_bug.cgi?id=761525.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51843d5b1732fb48dedcc1f8509d5e086a4e7cce
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Sat Jun 15 16:47:47 2013 -0400

    tilepro: work around module link error with gcc 4.7
    
    commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.
    
    gcc 4.7.x is emitting calls to __ffsdi2 where previously
    it used to inline the appropriate ctz instructions.
    While this needs to be fixed in gcc, it's also easy to avoid
    having it cause build failures when building with those
    compilers by exporting __ffsdi2 to modules.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b999a5332208ee04517763b60ebc88b1411596c2
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Mon Jun 3 17:17:15 2013 +0800

    clk: remove notifier from list before freeing it
    
    commit 72b5322f11ff0abf6a52b3007486656578d2c982 upstream.
    
    The @cn is stay in @clk_notifier_list after it is freed, it cause
    memory corruption.
    
    Example, if @clk is registered(first), unregistered(first),
    registered(second), unregistered(second).
    
    The freed @cn will be used when @clk is registered(second),
    and the bug will be happened when @clk is unregistered(second):
    
    [  517.040000] clk_notif_dbg clk_notif_dbg.1: clk_notifier_unregister()
    [  517.040000] Unable to handle kernel paging request at virtual address 00df3008
    [  517.050000] pgd = ed858000
    [  517.050000] [00df3008] *pgd=00000000
    [  517.060000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    [  517.060000] Modules linked in: clk_notif_dbg(O-) [last unloaded: clk_notif_dbg]
    [  517.060000] CPU: 1 PID: 499 Comm: modprobe Tainted: G           O 3.10.0-rc3-00119-ga93cb29-dirty #85
    [  517.060000] task: ee1e0180 ti: ee3e6000 task.ti: ee3e6000
    [  517.060000] PC is at srcu_readers_seq_idx+0x48/0x84
    [  517.060000] LR is at srcu_readers_seq_idx+0x60/0x84
    [  517.060000] pc : [<c0052720>]    lr : [<c0052738>]    psr: 80070013
    [  517.060000] sp : ee3e7d48  ip : 00000000  fp : ee3e7d6c
    [  517.060000] r10: 00000000  r9 : ee3e6000  r8 : 00000000
    [  517.060000] r7 : ed84fe4c  r6 : c068ec90  r5 : c068e430  r4 : 00000000
    [  517.060000] r3 : 00df3000  r2 : 00000000  r1 : 00000002  r0 : 00000000
    [  517.060000] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  517.060000] Control: 18c5387d  Table: 2d85804a  DAC: 00000015
    [  517.060000] Process modprobe (pid: 499, stack limit = 0xee3e6238)
    [  517.060000] Stack: (0xee3e7d48 to 0xee3e8000)
    ....
    [  517.060000] [<c0052720>] (srcu_readers_seq_idx+0x48/0x84) from [<c0052790>] (try_check_zero+0x34/0xfc)
    [  517.060000] [<c0052790>] (try_check_zero+0x34/0xfc) from [<c00528b0>] (srcu_advance_batches+0x58/0x114)
    [  517.060000] [<c00528b0>] (srcu_advance_batches+0x58/0x114) from [<c0052c30>] (__synchronize_srcu+0x114/0x1ac)
    [  517.060000] [<c0052c30>] (__synchronize_srcu+0x114/0x1ac) from [<c0052d14>] (synchronize_srcu+0x2c/0x34)
    [  517.060000] [<c0052d14>] (synchronize_srcu+0x2c/0x34) from [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74)
    [  517.060000] [<c0053a08>] (srcu_notifier_chain_unregister+0x68/0x74) from [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0)
    [  517.060000] [<c0375a78>] (clk_notifier_unregister+0x7c/0xc0) from [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg])
    [  517.060000] [<bf008034>] (clk_notif_dbg_remove+0x34/0x9c [clk_notif_dbg]) from [<c02bb974>] (platform_drv_remove+0x24/0x28)
    [  517.060000] [<c02bb974>] (platform_drv_remove+0x24/0x28) from [<c02b9bf8>] (__device_release_driver+0x8c/0xd4)
    [  517.060000] [<c02b9bf8>] (__device_release_driver+0x8c/0xd4) from [<c02ba680>] (driver_detach+0x9c/0xc4)
    [  517.060000] [<c02ba680>] (driver_detach+0x9c/0xc4) from [<c02b99c4>] (bus_remove_driver+0xcc/0xfc)
    [  517.060000] [<c02b99c4>] (bus_remove_driver+0xcc/0xfc) from [<c02bace4>] (driver_unregister+0x54/0x78)
    [  517.060000] [<c02bace4>] (driver_unregister+0x54/0x78) from [<c02bbb44>] (platform_driver_unregister+0x1c/0x20)
    [  517.060000] [<c02bbb44>] (platform_driver_unregister+0x1c/0x20) from [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg])
    [  517.060000] [<bf0081f8>] (clk_notif_dbg_driver_exit+0x14/0x1c [clk_notif_dbg]) from [<c00835e4>] (SyS_delete_module+0x200/0x28c)
    [  517.060000] [<c00835e4>] (SyS_delete_module+0x200/0x28c) from [<c000edc0>] (ret_fast_syscall+0x0/0x48)
    [  517.060000] Code: e5973004 e7911102 e0833001 e2881002 (e7933101)
    
    Reported-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Tested-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: Mike Turquette <mturquette@linaro.org>
    [mturquette@linaro.org: shortened $SUBJECT]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dea4deb43c96c502bef7b8f056b2f17c7af17d58
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jun 15 11:21:09 2013 +0200

    ALSA: usb-audio: work around Android accessory firmware bug
    
    commit 342cda29343a6272c630f94ed56810a76740251b upstream.
    
    When the Android firmware enables the audio interfaces in accessory
    mode, it always declares in the control interface's baInterfaceNr array
    that interfaces 0 and 1 belong to the audio function.  However, the
    accessory interface itself, if also enabled, already is at index 0 and
    shifts the actual audio interface numbers to 1 and 2, which prevents the
    PCM streaming interface from being seen by the host driver.
    
    To get the PCM interface interface to work, detect when the descriptors
    point to the (for this driver useless) accessory interface, and redirect
    to the correct one.
    
    Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Tested-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e233ade63ddd7797136a59b1b48b187cc683cd37
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 17 10:19:49 2013 +0200

    ALSA: hda - Fix pin configurations for MacBook Air 4,2
    
    commit 6ab982e8cf8e5760da407ccdc4abc815bea23179 upstream.
    
    MacBook Air 4,2 requires the whole default pin configuration table to
    be overridden by the driver, as usual, as Apple's machines don't set
    up properly after boot.  Otherwise mic won't work, and other ill
    effect may happen.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59381
    Reported-and-tested-by: Peter John Hartman <peterjohnhartman@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7961ded3141ec1945723d3cd782defb0d775cec
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 17 10:25:02 2013 +0200

    ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310
    
    commit 36691e1be6ec551eef4a5225f126a281f8c051c2 upstream.
    
    Just like the previous fix for LogitechHD Webcam c270 in commit
    11e7064f35bb87da8f427d1aa4bbd8b7473a3993, c310 model also requires the
    same workaround for avoiding the kernel warning.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59741
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 932f903f53e416b2d812ca5d1c0c6613475622f8
Author: Jed Davis <jld@mozilla.com>
Date:   Thu Jun 20 04:07:14 2013 +0100

    perf: arm64: Record the user-mode PC in the call chain.
    
    commit abc41254181e901ef5eda2c884ca6cd88a186b6d upstream.
    
    With this change, we no longer lose the innermost entry in the user-mode
    part of the call chain.  See also the x86 port, which includes the ip,
    and the corresponding change in arch/arm.
    
    Signed-off-by: Jed Davis <jld@mozilla.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 178dff24056a048259f8cc72fa47fdfbda5a95ee
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date:   Mon Jun 10 18:05:51 2013 +0100

    ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B
    
    commit 049be07053ebbf0ee8543caea23ae7bdf0765bb2 upstream.
    
    This commit fixes the ID and mask for the PJ4B which was too
    restrictive and didn't match the CPU of the Armada 370 SoC.
    
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 688b92cf4ec673d6fffebf27ccfd1a867cf530c9
Author: Jon Medhurst <tixy@linaro.org>
Date:   Fri Jun 7 10:35:35 2013 +0100

    ARM: 7752/1: errata: LoUIS bit field in CLIDR register is incorrect
    
    commit 691557941af4c12bd307ad81a4d9fa9c7743ac28 upstream.
    
    On Cortex-A9 before version r1p0, the LoUIS bit field of the CLIDR
    register returns zero when it should return one. This leads to cache
    maintenance operations which rely on this value to not function as
    intended, causing data corruption.
    
    The workaround for this errata is to detect affected CPUs and correct
    the LoUIS value read.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Jon Medhurst <tixy@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>