Patch to linux kernel 3.0.64 (squashed)

commit 54ea5b40f067cf098cac639973c6628c6944cfb2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 14 10:50:09 2013 -0800

    Linux 3.0.64

commit 7406f4230c4d086793cc62fa657750abf98559d6
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 1d08d86d53d881952af35f841d8cf5ff23f726d9
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 f0457844e605984a12b8043c3e21554b9b1fc8a5
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 2af567a11daa093a0141d675f8b3f1ab8ae8e70f
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 01cc083b977577eae3e91372f868019efc39bfeb
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 98d5919834d6091f0a4144ebd3c2c17f1b883d84
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 98df2584aaa730220adc29a7fbfa1c551fee5930
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 9f557574821b44a87d95756bf53f1b7fb76eb4d4
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Jan 6 18:21:49 2013 +0000

    tcp: fix MSG_SENDPAGE_NOTLAST logic

    [ Upstream commit ae62ca7b03217be5e74759dc6d7698c95df498b3 ]

    commit 35f9c09fe9c72e (tcp: tcp_sendpages() should call tcp_push() once)
    added an internal flag : MSG_SENDPAGE_NOTLAST meant to be set on all
    frags but the last one for a splice() call.

    The condition used to set the flag in pipe_to_sendpage() relied on
    splice() user passing the exact number of bytes present in the pipe,
    or a smaller one.

    But some programs pass an arbitrary high value, and the test fails.

    The effect of this bug is a lack of tcp_push() at the end of a
    splice(pipe -> socket) call, and possibly very slow or erratic TCP
    sessions.

    We should both test sd->total_len and fact that another fragment
    is in the pipe (pipe->nrbufs > 1)

    Many thanks to Willy for providing very clear bug report, bisection
    and test programs.

    Reported-by: Willy Tarreau <w@1wt.eu>
    Bisected-by: Willy Tarreau <w@1wt.eu>
    Tested-by: Willy Tarreau <w@1wt.eu>
    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 31885683c218d57ff90d827a1be5c5d3cb4263ac
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 ff1e4e5817d104e9aa46305db294602514e1c12b
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 0535d24446251c444a03d912a0022319a2de16f8
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 7340fda068b62790d612ebbd3a331a2847895f19
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 daba311aef717d505bc2ebb9a24f96ad15b7f394
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 107be19fbf77ba82dd8f081c1fb9e20ecdd07a64
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 069d8ee0271bdf29ac0fc1186cbedb3815f94255
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 d72b29e562214c7c5b635c3f44884a37bd115739
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 aa5d2659341c70682149e1c987bce6fe6620b30b
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 94510aa4e103c892e73fd688a6bd8e68bced1fe5
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 3a42cce923b0242d0293cae0a162601afa89d552
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 71d6857a18388acba0e84213778f0efba089d15f
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 6856b63b31aed9e2d3a42f2d8c7f75dbdecd4f69
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 cadce465a66df20878bfa5062092a64ab17c6042
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 55f40ea95452350c5bab3e84a561ee83becabd20
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Dec 20 14:41:18 2012 +0100

    mac80211: synchronize scan off/on-channel and PS states

    commit aacde9ee45225f7e0b90960f479aef83c66bfdc0 upstream.

    Since:

    commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
    Author: Ben Greear <greearb@candelatech.com>
    Date:   Fri Feb 4 11:54:17 2011 -0800

        mac80211: Optimize scans on current operating channel.

    we do not disable PS while going back to operational channel (on
    ieee80211_scan_state_suspend) and deffer that until scan finish.
    But since we are allowed to send frames, we can send a frame to AP
    without PM bit set, so disable PS on AP side. Then when we switch
    to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
    Hence we are off-channel with PS disabled, frames are not buffered
    by AP.

    To fix remove offchannel_ps_disable argument and always enable PS when
    going off-channel and disable it when going on-channel, like it was
    before.

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Tested-by: Seth Forshee <seth.forshee@canonical.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d973b29535f5e699da399786b41d2db25bb4b2d
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 K
Patch to linux kernel 3.0.65
commit fe34c843d97c4fa082fe66dc3a65e7bd5603c70c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 17 10:46:34 2013 -0800

    Linux 3.0.65

commit f4dc0e6ec906da70d1edf6d00f49b792f47f2efd
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date:   Wed Aug 8 05:23:22 2012 +0000

    igb: Remove artificial restriction on RQDPC stat reading

    commit ae1c07a6b7ced6c0c94c99e3b53f4e7856fa8bff upstream.

    For some reason the reading of the RQDPC register was being artificially
    limited to 4K.  Instead of limiting the value we should read the value and
    add the full amount.  Otherwise this can lead to a misleading number of
    dropped packets when the actual value is in fact much higher.

    Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Tested-by: Jeff Pieper   <jeffrey.e.pieper@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Vinson Lee <vlee@twitter.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e862f5583a92ac9680bdb18a0e5dffe2a2c3d464
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Mon Feb 11 20:49:49 2013 +0100

    PCI/PM: Clean up PME state when removing a device

    commit 249bfb83cf8ba658955f0245ac3981d941f746ee upstream.

    Devices are added to pci_pme_list when drivers use pci_enable_wake()
    or pci_wake_from_d3(), but they aren't removed from the list unless
    the driver explicitly disables wakeup.  Many drivers never disable
    wakeup, so their devices remain on the list even after they are
    removed, e.g., via hotplug.  A subsequent PME poll will oops when
    it tries to touch the device.

    This patch disables PME# on a device before removing it, which removes
    the device from pci_pme_list.  This is safe even if the device never
    had PME# enabled.

    This oops can be triggered by unplugging a Thunderbolt ethernet adapter
    on a Macbook Pro, as reported by Daniel below.

    [bhelgaas: changelog]
    Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.com
    Reported-and-tested-by: Daniel J Blueman <daniel@quora.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3339af37f35aff045db6a830185dddfac424c937
Author: Jan Beulich <JBeulich@suse.com>
Date:   Thu Jan 24 13:11:10 2013 +0000

    x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.

    commit 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc upstream.

    This fixes CVE-2013-0228 / XSA-42

    Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
    in 32bit PV guest can use to crash the > guest with the panic like this:

    -------------
    general protection fault: 0000 [#1] SMP
    last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
    Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
    iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
    xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
    mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
    unloaded: scsi_wait_scan]

    Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
    EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
    EIP is at xen_iret+0x12/0x2b
    EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
    ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
     DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
    Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
    Stack:
     00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
    Call Trace:
    Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
    8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
    10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
    EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
    general protection fault: 0000 [#2]
    ---[ end trace ab0d29a492dcd330 ]---
    Kernel panic - not syncing: Fatal exception
    Pid: 1250, comm: r Tainted: G      D    ---------------
    2.6.32-356.el6.i686 #1
    Call Trace:
     [<c08476df>] ? panic+0x6e/0x122
     [<c084b63c>] ? oops_end+0xbc/0xd0
     [<c084b260>] ? do_general_protection+0x0/0x210
     [<c084a9b7>] ? error_code+0x73/
    -------------

    Petr says: "
     I've analysed the bug and I think that xen_iret() cannot cope with
     mangled DS, in this case zeroed out (null selector/descriptor) by either
     xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
     entry was invalidated by the reproducer. "

    Jan took a look at the preliminary patch and came up a fix that solves
    this problem:

    "This code gets called after all registers other than those handled by
    IRET got already restored, hence a null selector in %ds or a non-null
    one that got loaded from a code or read-only data descriptor would
    cause a kernel mode fault (with the potential of crashing the kernel
    as a whole, if panic_on_oops is set)."

    The way to fix this is to realize that the we can only relay on the
    registers that IRET restores. The two that are guaranteed are the
    %cs and %ss as they are always fixed GDT selectors. Also they are
    inaccessible from user mode - so they cannot be altered. This is
    the approach taken in this patch.

    Another alternative option suggested by Jan would be to relay on
    the subtle realization that using the %ebp or %esp relative references uses
    the %ss segment.  In which case we could switch from using %eax to %ebp and
    would not need the %ss over-rides. That would also require one extra
    instruction to compensate for the one place where the register is used
    as scaled index. However Andrew pointed out that is too subtle and if
    further work was to be done in this code-path it could escape folks attention
    and lead to accidents.

    Reviewed-by: Petr Matousek <pmatouse@redhat.com>
    Reported-by: Petr Matousek <pmatouse@redhat.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec3918604c896df59632d47bd2ed874cbc2f262b
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Feb 11 14:52:36 2013 +0000

    x86/mm: Check if PUD is large when validating a kernel address

    commit 0ee364eb316348ddf3e0dfcd986f5f13f528f821 upstream.

    A user reported the following oops when a backup process reads
    /proc/kcore:

     BUG: unable to handle kernel paging request at ffffbb00ff33b000
     IP: [<ffffffff8103157e>] kern_addr_valid+0xbe/0x110
     [...]

     Call Trace:
      [<ffffffff811b8aaa>] read_kcore+0x17a/0x370
      [<ffffffff811ad847>] proc_reg_read+0x77/0xc0
      [<ffffffff81151687>] vfs_read+0xc7/0x130
      [<ffffffff811517f3>] sys_read+0x53/0xa0
      [<ffffffff81449692>] system_call_fastpath+0x16/0x1b

    Investigation determined that the bug triggered when reading
    system RAM at the 4G mark. On this system, that was the first
    address using 1G pages for the virt->phys direct mapping so the
    PUD is pointing to a physical address, not a PMD page.

    The problem is that the page table walker in kern_addr_valid() is
    not checking pud_large() and treats the physical address as if
    it was a PMD.  If it happens to look like pmd_none then it'll
    silently fail, probably returning zeros instead of real data. If
    the data happens to look like a present PMD though, it will be
    walked resulting in the oops above.

    This patch adds the necessary pud_large() check.

    Unfortunately the problem was not readily reproducible and now
    they are running the backup program without accessing
    /proc/kcore so the patch has not been validated but I think it
    makes sense.

    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.coM>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/20130211145236.GX21389@suse.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patch to linux kernel 3.0.66
commit 21d69845e411bfcee426070af5416ddfba350529
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 21 10:03:01 2013 -0800

    3.0.66

commit f3720830189356bed9247951ae4d7a1a6347ff10
Author: Alexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
Date:   Fri Feb 1 15:31:54 2013 +0100

    printk: fix buffer overflow when calling log_prefix function from call_console_drivers

    This patch corrects a buffer overflow in kernels from 3.0 to 3.4 when calling
    log_prefix() function from call_console_drivers().

    This bug existed in previous releases but has been revealed with commit
    162a7e7500f9664636e649ba59defe541b7c2c60 (2.6.39 => 3.0) that made changes
    about how to allocate memory for early printk buffer (use of memblock_alloc).
    It disappears with commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 (3.4 => 3.5)
    that does a refactoring of printk buffer management.

    In log_prefix(), the access to "p[0]", "p[1]", "p[2]" or
    "simple_strtoul(&p[1], &endp, 10)" may cause a buffer overflow as this
    function is called from call_console_drivers by passing "&LOG_BUF(cur_index)"
    where the index must be masked to do not exceed the buffer's boundary.

    The trick is to prepare in call_console_drivers() a buffer with the necessary
    data (PRI field of syslog message) to be safely evaluated in log_prefix().

    This patch can be applied to stable kernel branches 3.0.y, 3.2.y and 3.4.y.

    Without this patch, one can freeze a server running this loop from shell :
      $ export DUMMY=`cat /dev/urandom | tr -dc '12345AZERTYUIOPQSDFGHJKLMWXCVBNazertyuiopqsdfghjklmwxcvbn' | head -c255`
      $ while true do ; echo $DUMMY > /dev/kmsg ; done

    The "server freeze" depends on where memblock_alloc does allocate printk buffer :
    if the buffer overflow is inside another kernel allocation the problem may not
    be revealed, else the server may hangs up.

    Signed-off-by: Alexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>