commit 72a274602416d7c5dc04641832af8d0710a548dd
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 14 10:52:45 2013 -0800

    Linux 3.4.31

commit 495f02922e05a6858005dc6b9e07eeed026cf9a0
Author: Somnath Kotur <somnath.kotur@emulex.com>
Date:   Tue Jun 26 22:32:10 2012 +0000

    be2net: Fix to trim skb for padded vlan packets to workaround an ASIC Bug
    
    commit 93040ae5cc8dcc893eca4a4366dc8415af278edf upstream.
    
    Fixed spelling error in a comment as pointed out by DaveM.
    Also refactored existing code a bit to provide placeholders for another ASIC
    Bug workaround that will be checked-in soon after this.
    
    Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Jacek Luczak <difrost.kernel@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eac7b44eb80d3e1fa3310ad2dc57e10c2fc970fd
Author: Nithin Nayak Sujir <nsujir@broadcom.com>
Date:   Mon Jan 14 17:11:00 2013 +0000

    tg3: Fix crc errors on jumbo frame receive
    
    [ Upstream commit daf3ec688e057f6060fb9bb0819feac7a8bbf45c ]
    
    TG3_PHY_AUXCTL_SMDSP_ENABLE/DISABLE macros do a blind write to the phy
    auxiliary control register and overwrite the EXT_PKT_LEN (bit 14) resulting
    in intermittent crc errors on jumbo frames with some link partners. Change
    the code to do a read/modify/write.
    
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a10a3daa591e6ea2619da1e0418af2a30aa77ac5
Author: Nithin Nayak Sujir <nsujir@broadcom.com>
Date:   Mon Jan 14 17:10:59 2013 +0000

    tg3: Avoid null pointer dereference in tg3_interrupt in netconsole mode
    
    [ Upstream commit 9c13cb8bb477a83b9a3c9e5a5478a4e21294a760 ]
    
    When netconsole is enabled, logging messages generated during tg3_open
    can result in a null pointer dereference for the uninitialized tg3
    status block. Use the irq_sync flag to disable polling in the early
    stages. irq_sync is cleared when the driver is enabling interrupts after
    all initialization is completed.
    
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94fab0a18e9cbec420c58c7b12b93acf1663c3fd
Author: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Date:   Wed Oct 10 01:15:01 2012 +0000

    bridge: Pull ip header into skb->data before looking into ip header.
    
    [ Upstream commit 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7 ]
    
    If lower layer driver leaves the ip header in the skb fragment, it needs to
    be first pulled into skb->data before inspecting ip header length or ip version
    number.
    
    Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f641de91169472dc398fbd971cef380ad8d0f787
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Date:   Mon Feb 4 02:14:25 2013 +0000

    tcp: fix for zero packets_in_flight was too broad
    
    [ Upstream commit 6731d2095bd4aef18027c72ef845ab1087c3ba63 ]
    
    There are transients during normal FRTO procedure during which
    the packets_in_flight can go to zero between write_queue state
    updates and firing the resulting segments out. As FRTO processing
    occurs during that window the check must be more precise to
    not match "spuriously" :-). More specificly, e.g., when
    packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic
    branch that set cwnd into zero would not be taken and new segments
    might be sent out later.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Tested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2813296332187d222b96363fe29f10929f7a5228
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Feb 3 09:13:05 2013 +0000

    tcp: frto should not set snd_cwnd to 0
    
    [ Upstream commit 2e5f421211ff76c17130b4597bc06df4eeead24f ]
    
    Commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start())
    uncovered a bug in FRTO code :
    tcp_process_frto() is setting snd_cwnd to 0 if the number
    of in flight packets is 0.
    
    As Neal pointed out, if no packet is in flight we lost our
    chance to disambiguate whether a loss timeout was spurious.
    
    We should assume it was a proper loss.
    
    Reported-by: Pasi Kärkkäinen <pasik@iki.fi>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Cc: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42671f1e6fd8922b071bd3fd3e0cfad7226c654d
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Feb 6 23:41:38 2013 +0000

    netback: correct netbk_tx_err to handle wrap around.
    
    [ Upstream commit b9149729ebdcfce63f853aa54a404c6a8f6ebbf3 ]
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90ffc8f3315b0d296fea07fbc6fef87155f81f45
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Feb 6 23:41:37 2013 +0000

    xen/netback: free already allocated memory on failure in xen_netbk_get_requests
    
    [ Upstream commit 4cc7c1cb7b11b6f3515bd9075527576a1eecc4aa ]
    
    Signed-off-by: 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 33eb2607ebfcb68bc9ae8ab029f916f1f4ee5097
Author: Matthew Daley <mattjd@gmail.com>
Date:   Wed Feb 6 23:41:36 2013 +0000

    xen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.
    
    [ Upstream commit 7d5145d8eb2b9791533ffe4dc003b129b9696c48 ]
    
    Signed-off-by: Matthew Daley <mattjd@gmail.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be7254fc6c92c016a6768cc30596198c61043ff5
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Feb 6 23:41:35 2013 +0000

    xen/netback: shutdown the ring if it contains garbage.
    
    [ Upstream commit 48856286b64e4b66ec62b94e504d0b29c1ade664 ]
    
    A buggy or malicious frontend should not be able to confuse netback.
    If we spot anything which is not as it should be then shutdown the
    device and don't try to continue with the ring in a potentially
    hostile state. Well behaved and non-hostile frontends will not be
    penalised.
    
    As well as making the existing checks for such errors fatal also add a
    new check that ensures that there isn't an insane number of requests
    on the ring (i.e. more than would fit in the ring). If the ring
    contains garbage then previously is was possible to loop over this
    insane number, getting an error each time and therefore not generating
    any more pending requests and therefore not exiting the loop in
    xen_netbk_tx_build_gops for an externded period.
    
    Also turn various netdev_dbg calls which no precipitate a fatal error
    into netdev_err, they are rate limited because the device is shutdown
    afterwards.
    
    This fixes at least one known DoS/softlockup of the backend domain.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6f5498856f31246818bbe4ebfa710ce92730a37
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Fri Feb 8 03:04:35 2013 +0000

    net: sctp: sctp_endpoint_free: zero out secret key data
    
    [ Upstream commit b5c37fe6e24eec194bb29d22fdd55d73bcc709bf ]
    
    On sctp_endpoint_destroy, previously used sensitive keying material
    should be zeroed out before the memory is returned, as we already do
    with e.g. auth keys when released.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a501d87edf7190e8fe1741d9312dfcb6361c538
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Fri Feb 8 03:04:34 2013 +0000

    net: sctp: sctp_setsockopt_auth_key: use kzfree instead of kfree
    
    [ Upstream commit 6ba542a291a5e558603ac51cda9bded347ce7627 ]
    
    In sctp_setsockopt_auth_key, we create a temporary copy of the user
    passed shared auth key for the endpoint or association and after
    internal setup, we free it right away. Since it's sensitive data, we
    should zero out the key before returning the memory back to the
    allocator. Thus, use kzfree instead of kfree, just as we do in
    sctp_auth_key_put().
    
    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 4c921d0ed5d49a93613530f4dd405fc2db3ccb84
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Thu Jan 17 11:15:08 2013 +0000

    sctp: refactor sctp_outq_teardown to insure proper re-initalization
    
    [ Upstream commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86 ]
    
    Jamie Parsons reported a problem recently, in which the re-initalization of an
    association (The duplicate init case), resulted in a loss of receive window
    space.  He tracked down the root cause to sctp_outq_teardown, which discarded
    all the data on an outq during a re-initalization of the corresponding
    association, but never reset the outq->outstanding_data field to zero.  I wrote,
    and he tested this fix, which does a proper full re-initalization of the outq,
    fixing this problem, and hopefully future proofing us from simmilar issues down
    the road.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
    Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
    CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4129dae20d6e106cb197008d9adf617e1affa89
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Fri Feb 8 00:19:11 2013 +0000

    atm/iphase: rename fregt_t -> ffreg_t
    
    [ Upstream commit ab54ee80aa7585f9666ff4dd665441d7ce41f1e8 ]
    
    We have conflicting type qualifiers for "freg_t" in s390's ptrace.h and the
    iphase atm device driver, which causes the compile error below.
    Unfortunately the s390 typedef can't be renamed, since it's a user visible api,
    nor can I change the include order in s390 code to avoid the conflict.
    
    So simply rename the iphase typedef to a new name. Fixes this compile error:
    
    In file included from drivers/atm/iphase.c:66:0:
    drivers/atm/iphase.h:639:25: error: conflicting type qualifiers for 'freg_t'
    In file included from next/arch/s390/include/asm/ptrace.h:9:0,
                     from next/arch/s390/include/asm/lowcore.h:12,
                     from next/arch/s390/include/asm/thread_info.h:30,
                     from include/linux/thread_info.h:54,
                     from include/linux/preempt.h:9,
                     from include/linux/spinlock.h:50,
                     from include/linux/seqlock.h:29,
                     from include/linux/time.h:5,
                     from include/linux/stat.h:18,
                     from include/linux/module.h:10,
                     from drivers/atm/iphase.c:43:
    next/arch/s390/include/uapi/asm/ptrace.h:197:3: note: previous declaration of 'freg_t' was here
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Acked-by: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f60f85403b3a5b566ba0eaf174930f6a626d33ad
Author: Phil Sutter <phil.sutter@viprinet.com>
Date:   Fri Feb 1 07:21:41 2013 +0000

    packet: fix leakage of tx_ring memory
    
    [ Upstream commit 9665d5d62487e8e7b1f546c00e11107155384b9a ]
    
    When releasing a packet socket, the routine packet_set_ring() is reused
    to free rings instead of allocating them. But when calling it for the
    first time, it fills req->tp_block_nr with the value of rb->pg_vec_len
    which in the second invocation makes it bail out since req->tp_block_nr
    is greater zero but req->tp_block_size is zero.
    
    This patch solves the problem by passing a zeroed auto-variable to
    packet_set_ring() upon each invocation from packet_release().
    
    As far as I can tell, this issue exists even since 69e3c75 (net: TX_RING
    and packet mmap), i.e. the original inclusion of TX ring support into
    af_packet, but applies only to sockets with both RX and TX ring
    allocated, which is probably why this was unnoticed all the time.
    
    Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
    Cc: Johann Baudy <johann.baudy@gnu-log.net>
    Cc: Daniel Borkmann <dborkman@redhat.com>
    Acked-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 d78378096e74b2fd0b42b74156ba0ae0567ea226
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jan 29 22:58:04 2013 -0500

    via-rhine: Fix bugs in NAPI support.
    
    [ Upstream commit 559bcac35facfed49ab4f408e162971612dcfdf3 ]
    
    1) rhine_tx() should use dev_kfree_skb() not dev_kfree_skb_irq()
    
    2) rhine_slow_event_task's NAPI triggering logic is racey, it
       should just hit the interrupt mask register.  This is the
       same as commit 7dbb491878a2c51d372a8890fa45a8ff80358af1
       ("r8169: avoid NAPI scheduling delay.") made to fix the same
       problem in the r8169 driver.  From Francois Romieu.
    
    Reported-by: Jamie Gloudon <jamie.gloudon@gmail.com>
    Tested-by: Jamie Gloudon <jamie.gloudon@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 909978d73590b07c3a050a569cc3bd44b1f9355c
Author: Marcelo Ricardo Leitner <mleitner@redhat.com>
Date:   Tue Jan 29 22:26:08 2013 +0000

    ipv6: do not create neighbor entries for local delivery
    
    [ Upstream commit bd30e947207e2ea0ff2c08f5b4a03025ddce48d3 ]
    
    They will be created at output, if ever needed. This avoids creating
    empty neighbor entries when TPROXYing/Forwarding packets for addresses
    that are not even directly reachable.
    
    Note that IPv4 already handles it this way. No neighbor entries are
    created for local input.
    
    Tested by myself and customer.
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c1128b87d5814de27f8ddc445783a81914b194f
Author: Cong Wang <amwang@redhat.com>
Date:   Sun Jan 27 21:14:08 2013 +0000

    pktgen: correctly handle failures when adding a device
    
    [ Upstream commit 604dfd6efc9b79bce432f2394791708d8e8f6efc ]
    
    The return value of pktgen_add_device() is not checked, so
    even if we fail to add some device, for example, non-exist one,
    we still see "OK:...". This patch fixes it.
    
    After this patch, I got:
    
    	# echo "add_device non-exist" > /proc/net/pktgen/kpktgend_0
    	-bash: echo: write error: No such device
    	# cat /proc/net/pktgen/kpktgend_0
    	Running:
    	Stopped:
    	Result: ERROR: can not add device non-exist
    	# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
    	# cat /proc/net/pktgen/kpktgend_0
    	Running:
    	Stopped: eth0
    	Result: OK: add_device=eth0
    
    (Candidate for -stable)
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e38660420e8e12d7fd6b58069d985b6298aad176
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 25 07:44:41 2013 +0000

    net: loopback: fix a dst refcounting issue
    
    [ Upstream commit 794ed393b707f01858f5ebe2ae5eabaf89d00022 ]
    
    Ben Greear reported crashes in ip_rcv_finish() on a stress
    test involving many macvlans.
    
    We tracked the bug to a dst use after free. ip_rcv_finish()
    was calling dst->input() and got garbage for dst->input value.
    
    It appears the bug is in loopback driver, lacking
    a skb_dst_force() before calling netif_rx().
    
    As a result, a non refcounted dst, normally protected by a
    RCU read_lock section, was escaping this section and could
    be freed before the packet being processed.
    
      [<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
      [<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
      [<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
      [<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
      [<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
      [<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
      [<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
      [<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
      [<ffffffff814ad90e>] ip_finish_output+0x63/0x68
      [<ffffffff814ae412>] ip_output+0x61/0x67
      [<ffffffff814ab904>] dst_output+0x17/0x1b
      [<ffffffff814adb6d>] ip_local_out+0x1e/0x23
      [<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
      [<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
      [<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
      [<ffffffff814c3571>] tcp_connect+0x53c/0x587
      [<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
      [<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
      [<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
      [<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
      [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
      [<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
      [<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
      [<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
      [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
      [<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
      [<ffffffff814632c6>] sys_connect+0x75/0x98
    
    This bug was introduced in linux-2.6.35, in commit
    7fee226ad2397b (net: add a noref bit on skb dst)
    
    skb_dst_force() is enforced in dev_queue_xmit() for devices having a
    qdisc.
    
    Reported-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 646e28ceca9036d5b2e76f4b116bba0bc60081c1
Author: Timo Teräs <timo.teras@iki.fi>
Date:   Mon Jan 21 22:30:35 2013 +0000

    r8169: remove the obsolete and incorrect AMD workaround
    
    [ Upstream commit 5d0feaff230c0abfe4a112e6f09f096ed99e0b2d ]
    
    This was introduced in commit 6dccd16 "r8169: merge with version
    6.001.00 of Realtek's r8169 driver". I did not find the version
    6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
    this hunk is no longer present.
    
    Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
    rev d" claims to have fixed this issue otherwise.
    
    The magic compare mask of 0xfffe000 is dubious as it masks
    parts of the Reserved part, and parts of the VLAN tag. But this
    does not make much sense as the VLAN tag parts are perfectly
    valid there. In matter of fact this seems to be triggered with
    any VLAN tagged packet as RxVlanTag bit is matched. I would
    suspect 0xfffe0000 was intended to test reserved part only.
    
    Finally, this hunk is evil as it can cause more packets to be
    handled than what was NAPI quota causing net/core/dev.c:
    net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
    mess up the NAPI state causing device to hang.
    
    As result, any system using VLANs and having high receive
    traffic (so that NAPI poll budget limits rtl_rx) would result
    in device hang.
    
    Signed-off-by: Timo Teräs <timo.teras@iki.fi>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30a66dd405e36be6f470f4c383c16583b44812e1
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 22 06:33:05 2013 +0000

    netxen: fix off by one bug in netxen_release_tx_buffer()
    
    [ Upstream commit a05948f296ce103989b28a2606e47d2e287c3c89 ]
    
    Christoph Paasch found netxen could trigger a BUG in its dismantle
    phase, in netxen_release_tx_buffer(), using full size TSO packets.
    
    cmd_buf->frag_count includes the skb->data part, so the loop must
    start at index 1 instead of 0, or else we can make an out
    of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]
    
    Christoph provided the fixes in netxen_map_tx_skb() function.
    In case of a dma mapping error, its better to clear the dma fields
    so that we don't try to unmap them again in netxen_release_tx_buffer()
    
    Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Christoph Paasch <christoph.paasch@uclouvain.be>
    Cc: Sony Chacko <sony.chacko@qlogic.com>
    Cc: Rajesh Borundia <rajesh.borundia@qlogic.com>
    Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a2593d54499ec5d2ac5682503ae1973bfcd3bcb
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Mon Jan 21 11:57:21 2013 +0000

    isdn/gigaset: fix zero size border case in debug dump
    
    [ Upstream commit d721a1752ba544df8d7d36959038b26bc92bdf80 ]
    
    If subtracting 12 from l leaves zero we'd do a zero size allocation,
    leading to an oops later when we try to set the NUL terminator.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37c1a8504945755e6e0f39449023e250eb2c2618
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date:   Thu Jan 17 05:30:43 2013 +0000

    net/mlx4_core: Set number of msix vectors under SRIOV mode to firmware defaults
    
    [ Upstream commit ca4c7b35f75492de7fbf5ee95be07481c348caee ]
    
    The lines
    
    	if (mlx4_is_mfunc(dev)) {
    		nreq = 2;
    	} else {
    
    which hard code the number of requested msi-x vectors under multi-function
    mode to two can be removed completely, since the firmware sets num_eqs and
    reserved_eqs appropriately Thus, the code line:
    
    	nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs, nreq);
    
    is by itself sufficient and correct for all cases. Currently, for mfunc
    mode num_eqs = 32 and reserved_eqs = 28, hence four vectors will be enabled.
    
    This triples (one vector is used for the async events and commands EQ) the
    horse power provided for processing of incoming packets on netdev RSS scheme,
    IO initiators/targets commands processing flows, etc.
    
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Amir Vadai <amirv@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70f85892c8a0e0eee5f4eeb5371b72e9b46744ab
Author: Yan Burman <yanb@mellanox.com>
Date:   Thu Jan 17 05:30:42 2013 +0000

    net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
    
    [ Upstream commit 213815a1e6ae70b9648483b110bc5081795f99e8 ]
    
    Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
    same host" introduced a regression under which a bridge acting as vSwitch
    whose uplink is an mlx4 Ethernet device become non-operative in native
    (non sriov) mode. This happens since broadcast ARP requests sent by VMs
    were loopback-ed by the HW and hence the bridge learned VM source MACs
    on both the VM and the uplink ports.
    
    The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
    configuration or when the device is in selftest.
    
    Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Yan Burman <yanb@mellanox.com>
    Signed-off-by: Amir Vadai <amirv@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0adabb18a751ecff5da1e03d47b13dd9628b89b
Author: Rob Herring <rob.herring@calxeda.com>
Date:   Wed Jan 16 13:36:37 2013 +0000

    net: calxedaxgmac: throw away overrun frames
    
    [ Upstream commit d6fb3be544b46a7611a3373fcaa62b5b0be01888 ]
    
    The xgmac driver assumes 1 frame per descriptor. If a frame larger than
    the descriptor's buffer size is received, the frame will spill over into
    the next descriptor. So check for received frames that span more than one
    descriptor and discard them. This prevents a crash if we receive erroneous
    large packets.
    
    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07da6b22a219ba7907ad41118f0e77f4b8fae9a9
Author: Romain KUNTZ <r.kuntz@ipflavors.com>
Date:   Wed Jan 16 12:47:40 2013 +0000

    ipv6: fix header length calculation in ip6_append_data()
    
    [ Upstream commit 7efdba5bd9a2f3e2059beeb45c9fa55eefe1bced ]
    
    Commit 299b0767 (ipv6: Fix IPsec slowpath fragmentation problem)
    has introduced a error in the header length calculation that
    provokes corrupted packets when non-fragmentable extensions
    headers (Destination Option or Routing Header Type 2) are used.
    
    rt->rt6i_nfheader_len is the length of the non-fragmentable
    extension header, and it should be substracted to
    rt->dst.header_len, and not to exthdrlen, as it was done before
    commit 299b0767.
    
    This patch reverts to the original and correct behavior. It has
    been successfully tested with and without IPsec on packets
    that include non-fragmentable extensions headers.
    
    Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
    Acked-by: 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 6320f430b95a00ef958d7e98655823bfb3c1b918
Author: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date:   Wed Jan 16 09:55:57 2013 -0800

    MAINTAINERS: Stephen Hemminger email change
    
    [ Upstream commit adbbf69d1a54abf424e91875746a610dcc80017d ]
    
    I changed my email because the vyatta.com mail server is now
    redirected to brocade.com; and the Brocade mail system
    is not friendly to Linux desktop users.
    
    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 3b69055b43c57783a8bf99a8e40f773580e451a1
Author: Romain Kuntz <r.kuntz@ipflavors.com>
Date:   Wed Jan 9 15:02:26 2013 +0100

    ipv6: fix the noflags test in addrconf_get_prefix_route
    
    [ Upstream commit 85da53bf1c336bb07ac038fb951403ab0478d2c5 ]
    
    The tests on the flags in addrconf_get_prefix_route() does no make
    much sense: the 'noflags' parameter contains the set of flags that
    must not match with the route flags, so the test must be done
    against 'noflags', and not against 'flags'.
    
    Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ad715758022062a34bccede6200803e26480c97
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Jan 7 21:17:00 2013 +0000

    net: prevent setting ttl=0 via IP_TTL
    
    [ Upstream commit c9be4a5c49cf51cc70a993f004c5bb30067a65ce ]
    
    A regression is introduced by the following commit:
    
    	commit 4d52cfbef6266092d535237ba5a4b981458ab171
    	Author: Eric Dumazet <eric.dumazet@gmail.com>
    	Date:   Tue Jun 2 00:42:16 2009 -0700
    
    	    net: ipv4/ip_sockglue.c cleanups
    
    	    Pure cleanups
    
    but it is not a pure cleanup...
    
    	-               if (val != -1 && (val < 1 || val>255))
    	+               if (val != -1 && (val < 0 || val > 255))
    
    Since there is no reason provided to allow ttl=0, change it back.
    
    Reported-by: nitin padalia <padalia.nitin@gmail.com>
    Cc: nitin padalia <padalia.nitin@gmail.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-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 7f8d73f9e71d58187f42d26088578be5d2d70859
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Thu Jan 3 09:02:37 2013 +0000

    samsung-laptop: Disable on EFI hardware
    
    commit e0094244e41c4d0c7ad69920681972fc45d8ce34 upstream.
    
    It has been reported that running this driver on some Samsung laptops
    with EFI can cause those machines to become bricked as detailed in the
    following report,
    
    	https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    
    There have also been reports of this driver causing Machine Check
    Exceptions on recent EFI-enabled Samsung laptops,
    
    	https://bugzilla.kernel.org/show_bug.cgi?id=47121
    
    So disable it if booting from EFI since this driver relies on
    grovelling around in the BIOS memory map which isn't going to work.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: Corentin Chary <corentincj@iksaif.net>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Steve Langasek <steve.langasek@canonical.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 739230186fa9d6999f88c53f0cb6d07ed4234fb0
Author: Matt Fleming <matt.fleming@intel.com>
Date:   Wed Nov 14 09:42:35 2012 +0000

    efi: Make 'efi_enabled' a function to query EFI facilities
    
    commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.
    
    Originally 'efi_enabled' indicated whether a kernel was booted from
    EFI firmware. Over time its semantics have changed, and it now
    indicates whether or not we are booted on an EFI machine with
    bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
    
    The immediate motivation for this patch is the bug report at,
    
        https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
    
    which details how running a platform driver on an EFI machine that is
    designed to run under BIOS can cause the machine to become
    bricked. Also, the following report,
    
        https://bugzilla.kernel.org/show_bug.cgi?id=47121
    
    details how running said driver can also cause Machine Check
    Exceptions. Drivers need a new means of detecting whether they're
    running on an EFI machine, as sadly the expression,
    
        if (!efi_enabled)
    
    hasn't been a sufficient condition for quite some time.
    
    Users actually want to query 'efi_enabled' for different reasons -
    what they really want access to is the list of available EFI
    facilities.
    
    For instance, the x86 reboot code needs to know whether it can invoke
    the ResetSystem() function provided by the EFI runtime services, while
    the ACPI OSL code wants to know whether the EFI config tables were
    mapped successfully. There are also checks in some of the platform
    driver code to simply see if they're running on an EFI machine (which
    would make it a bad idea to do BIOS-y things).
    
    This patch is a prereq for the samsung-laptop fix patch.
    
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Corentin Chary <corentincj@iksaif.net>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Olof Johansson <olof@lixom.net>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Steve Langasek <steve.langasek@canonical.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a256a4c2001293548f0851b66ea8f39b704bac72
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Tue Jan 29 10:44:23 2013 -0600

    Bluetooth: Fix handling of unexpected SMP PDUs
    
    commit 8cf9fa1240229cbdd888236c0c43fcbad680cf00 upstream.
    
    The conn->smp_chan pointer can be NULL if SMP PDUs arrive at unexpected
    moments. To avoid NULL pointer dereferences the code should be checking
    for this and disconnect if an unexpected SMP PDU arrives. This patch
    fixes the issue by adding a check for conn->smp_chan for all other PDUs
    except pairing request and security request (which are are the first
    PDUs to come to initialize the SMP context).
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7308f843f36c30dd1247989a45611760567ea44f
Author: T Makphaibulchoke <tmac@hp.com>
Date:   Thu Oct 4 17:16:55 2012 -0700

    kernel/resource.c: fix stack overflow in __reserve_region_with_split()
    
    commit 4965f5667f36a95b41cda6638875bc992bd7d18b upstream.
    
    Using a recursive call add a non-conflicting region in
    __reserve_region_with_split() could result in a stack overflow in the case
    that the recursive calls are too deep.  Convert the recursive calls to an
    iterative loop to avoid the problem.
    
    Tested on a machine containing 135 regions.  The kernel no longer panicked
    with stack overflow.
    
    Also tested with code arbitrarily adding regions with no conflict,
    embedding two consecutive conflicts and embedding two non-consecutive
    conflicts.
    
    Signed-off-by: T Makphaibulchoke <tmac@hp.com>
    Reviewed-by: Ram Pai <linuxram@us.ibm.com>
    Cc: Paul Gortmaker <paul.gortmaker@gmail.com>
    Cc: Wei Yang <weiyang@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b2d4e113bf714732b041aa879945c4c5ae4b139
Author: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date:   Tue Jan 22 09:50:26 2013 +1030

    virtio_console: Don't access uninitialized data.
    
    commit aded024a12b32fc1ed9a80639681daae2d07ec25 upstream.
    
    Don't access uninitialized work-queue when removing device.
    The work queue is initialized only if the device multi-queue.
    So don't call cancel_work unless this is a multi-queue device.
    
    This fixes the following panic:
    
    Kernel panic - not syncing: BUG!
    Call Trace:
    62031b28:  [<6026085d>] panic+0x16b/0x2d3
    62031b30:  [<6004ef5e>] flush_work+0x0/0x1d7
    62031b60:  [<602606f2>] panic+0x0/0x2d3
    62031b68:  [<600333b0>] memcpy+0x0/0x140
    62031b80:  [<6002d58a>] unblock_signals+0x0/0x84
    62031ba0:  [<602609c5>] printk+0x0/0xa0
    62031bd8:  [<60264e51>] __mutex_unlock_slowpath+0x13d/0x148
    62031c10:  [<6004ef5e>] flush_work+0x0/0x1d7
    62031c18:  [<60050234>] try_to_grab_pending+0x0/0x17e
    62031c38:  [<6004e984>] get_work_gcwq+0x71/0x8f
    62031c48:  [<60050539>] __cancel_work_timer+0x5b/0x115
    62031c78:  [<628acc85>] unplug_port+0x0/0x191 [virtio_console]
    62031c98:  [<6005061c>] cancel_work_sync+0x12/0x14
    62031ca8:  [<628ace96>] virtcons_remove+0x80/0x15c [virtio_console]
    62031ce8:  [<628191de>] virtio_dev_remove+0x1e/0x7e [virtio]
    62031d08:  [<601cf242>] __device_release_driver+0x75/0xe4
    62031d28:  [<601cf2dd>] device_release_driver+0x2c/0x40
    62031d48:  [<601ce0dd>] driver_unbind+0x7d/0xc6
    62031d88:  [<601cd5d9>] drv_attr_store+0x27/0x29
    62031d98:  [<60115f61>] sysfs_write_file+0x100/0x14d
    62031df8:  [<600b737d>] vfs_write+0xcb/0x184
    62031e08:  [<600b58b8>] filp_close+0x88/0x94
    62031e38:  [<600b7686>] sys_write+0x59/0x88
    62031e88:  [<6001ced1>] handle_syscall+0x5d/0x80
    62031ea8:  [<60030a74>] userspace+0x405/0x531
    62031f08:  [<600d32cc>] sys_dup+0x0/0x5e
    62031f28:  [<601b11d6>] strcpy+0x0/0x18
    62031f38:  [<600be46c>] do_execve+0x10/0x12
    62031f48:  [<600184c7>] run_init_process+0x43/0x45
    62031fd8:  [<60019a91>] new_thread_handler+0xba/0xbc
    
    Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5327297d3596654ca58e8a79ec38fa48c8f83fc0
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sat Feb 2 15:55:00 2013 -0600

    rtlwifi: Fix scheduling while atomic bug
    
    commit a5ffbe0a1993a27072742ef7db6cf9839956fce9 upstream.
    
    Kernel commits 41affd5 and 6539306 changed the locking in rtl_lps_leave()
    from a spinlock to a mutex by doing the calls indirectly from a work queue
    to reduce the time that interrupts were disabled. This change was fine for
    most systems; however a scheduling while atomic bug was reported in
    https://bugzilla.redhat.com/show_bug.cgi?id=903881. The backtrace indicates
    that routine rtl_is_special(), which calls rtl_lps_leave() in three places
    was entered in atomic context. These direct calls are replaced by putting a
    request on the appropriate work queue.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Reported-and-tested-by: Nathaniel Doherty <ntdoherty@gmail.com>
    Cc: Nathaniel Doherty <ntdoherty@gmail.com>
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f2ffd29fe0438dfb683a8f0ca0e451408e36970
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Jan 27 16:24:25 2013 -0600

    rtlwifi: Fix the usage of the wrong variable in usb.c
    
    commit 0a06ad8e3a1cb5311b7dbafde45410aa1bce9d40 upstream.
    
    In routine _rtl_rx_pre_process(), skb_dequeue() is called to get an skb;
    however, the wrong variable name is used in subsequent calls.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>