GitHub PushEvent at 2014-08-31 15:06:23
Repository: lks
Actor: khiemnguyen
Payload: {"shas":[["f5980d099295d4113635ded88425834a38d17125","14e5026fd500cbee455106b5b09b5e607f296ad8@qlogic.com","bnx2x: fix crash during TSO tunneling\n\n[ Upstream commit fe26566d8a05151ba1dce75081f6270f73ec4ae1 ]\n\nWhen TSO packet is transmitted additional BD w/o mapping is used\nto describe the packed. The BD needs special handling in tx\ncompletion.\n\nkernel: Call Trace:\nkernel: <IRQ>  [<ffffffff815e19ba>] dump_stack+0x19/0x1b\nkernel: [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80\nkernel: [<ffffffff8105df5c>] warn_slowpath_fmt+0x5c/0x80\nkernel: [<ffffffff814a8c0d>] ? find_iova+0x4d/0x90\nkernel: [<ffffffff814ab0e2>] intel_unmap_page.part.36+0x142/0x160\nkernel: [<ffffffff814ad0e6>] intel_unmap_page+0x26/0x30\nkernel: [<ffffffffa01f55d7>] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]\nkernel: [<ffffffffa01f8dac>] bnx2x_tx_int+0xac/0x220 [bnx2x]\nkernel: [<ffffffff8101a0d9>] ? read_tsc+0x9/0x20\nkernel: [<ffffffffa01f8fdb>] bnx2x_poll+0xbb/0x3c0 [bnx2x]\nkernel: [<ffffffff814d041a>] net_rx_action+0x15a/0x250\nkernel: [<ffffffff81067047>] __do_softirq+0xf7/0x290\nkernel: [<ffffffff815f3a5c>] call_softirq+0x1c/0x30\nkernel: [<ffffffff81014d25>] do_softirq+0x55/0x90\nkernel: [<ffffffff810673e5>] irq_exit+0x115/0x120\nkernel: [<ffffffff815f4358>] do_IRQ+0x58/0xf0\nkernel: [<ffffffff815e94ad>] common_interrupt+0x6d/0x6d\nkernel: <EOI>  [<ffffffff810bbff7>] ? clockevents_notify+0x127/0x140\nkernel: [<ffffffff814834df>] ? cpuidle_enter_state+0x4f/0xc0\nkernel: [<ffffffff81483615>] cpuidle_idle_call+0xc5/0x200\nkernel: [<ffffffff8101bc7e>] arch_cpu_idle+0xe/0x30\nkernel: [<ffffffff810b4725>] cpu_startup_entry+0xf5/0x290\nkernel: [<ffffffff815cfee1>] start_secondary+0x265/0x27b\nkernel: ---[ end trace 11aa7726f18d7e80 ]---\n\nFixes: a848ade408b (\"bnx2x: add CSUM and TSO support for encapsulation protocols\")\nReported-by: Yulong Pei <ypei@redhat.com>\nCc: Michal Schmidt <mschmidt@redhat.com>\nSigned-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Dmitry Kravkov",false],["ff1f69a89a613223c57c13190a6c9be928ac4b9d","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","inetpeer: get rid of ip_id_count\n\n[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]\n\nIdeally, we would need to generate IP ID using a per destination IP\ngenerator.\n\nlinux kernels used inet_peer cache for this purpose, but this had a huge\ncost on servers disabling MTU discovery.\n\n1) each inet_peer struct consumes 192 bytes\n\n2) inetpeer cache uses a binary tree of inet_peer structs,\n   with a nominal size of ~66000 elements under load.\n\n3) lookups in this tree are hitting a lot of cache lines, as tree depth\n   is about 20.\n\n4) If server deals with many tcp flows, we have a high probability of\n   not finding the inet_peer, allocating a fresh one, inserting it in\n   the tree with same initial ip_id_count, (cf secure_ip_id())\n\n5) We garbage collect inet_peer aggressively.\n\nIP ID generation do not have to be 'perfect'\n\nGoal is trying to avoid duplicates in a short period of time,\nso that reassembly units have a chance to complete reassembly of\nfragments belonging to one message before receiving other fragments\nwith a recycled ID.\n\nWe simply use an array of generators, and a Jenkin hash using the dst IP\nas a key.\n\nipv6_select_ident() is put back into net/ipv6/ip6_output.c where it\nbelongs (it is only used from this file)\n\nsecure_ip_id() and secure_ipv6_id() no longer are needed.\n\nRename ip_select_ident_more() to ip_select_ident_segs() to avoid\nunnecessary decrement/increment of the number of segments.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Eric Dumazet",false],["4176df017abbe847f0c09e5b839feb40e04b25ba","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","ip: make IP identifiers less predictable\n\n[ Upstream commit 04ca6973f7c1a0d8537f2d9906a0cf8e69886d75 ]\n\nIn \"Counting Packets Sent Between Arbitrary Internet Hosts\", Jeffrey and\nJedidiah describe ways exploiting linux IP identifier generation to\ninfer whether two machines are exchanging packets.\n\nWith commit 73f156a6e8c1 (\"inetpeer: get rid of ip_id_count\"), we\nchanged IP id generation, but this does not really prevent this\nside-channel technique.\n\nThis patch adds a random amount of perturbation so that IP identifiers\nfor a given destination [1] are no longer monotonically increasing after\nan idle period.\n\nNote that prandom_u32_max(1) returns 0, so if generator is used at most\nonce per jiffy, this patch inserts no hole in the ID suite and do not\nincrease collision probability.\n\nThis is jiffies based, so in the worst case (HZ=1000), the id can\nrollover after ~65 seconds of idle time, which should be fine.\n\nWe also change the hash used in __ip_select_ident() to not only hash\non daddr, but also saddr and protocol, so that ICMP probes can not be\nused to infer information for other protocols.\n\nFor IPv6, adds saddr into the hash as well, but not nexthdr.\n\nIf I ping the patched target, we can see ID are now hard to predict.\n\n21:57:11.008086 IP (...)\n    A > target: ICMP echo request, seq 1, length 64\n21:57:11.010752 IP (... id 2081 ...)\n    target > A: ICMP echo reply, seq 1, length 64\n\n21:57:12.013133 IP (...)\n    A > target: ICMP echo request, seq 2, length 64\n21:57:12.015737 IP (... id 3039 ...)\n    target > A: ICMP echo reply, seq 2, length 64\n\n21:57:13.016580 IP (...)\n    A > target: ICMP echo request, seq 3, length 64\n21:57:13.019251 IP (... id 3437 ...)\n    target > A: ICMP echo reply, seq 3, length 64\n\n[1] TCP sessions uses a per flow ID generator not changed by this patch.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Jeffrey Knockel <jeffk@cs.unm.edu>\nReported-by: Jedidiah R. Crandall <crandall@cs.unm.edu>\nCc: Willy Tarreau <w@1wt.eu>\nCc: Hannes Frederic Sowa <hannes@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Eric Dumazet",false],["15229fa9d4588b2d0e91ee81954c3a4f3c30dcb8","fc44582e3ea5c5edf025c4b49edfa21354ea32c7@gmail.com","net: sendmsg: fix NULL pointer dereference\n\n[ Upstream commit 40eea803c6b2cfaab092f053248cbeab3f368412 ]\n\nSasha's report:\n\t> While fuzzing with trinity inside a KVM tools guest running the latest -next\n\t> kernel with the KASAN patchset, I've stumbled on the following spew:\n\t>\n\t> [ 4448.949424] ==================================================================\n\t> [ 4448.951737] AddressSanitizer: user-memory-access on address 0\n\t> [ 4448.952988] Read of size 2 by thread T19638:\n\t> [ 4448.954510] CPU: 28 PID: 19638 Comm: trinity-c76 Not tainted 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813\n\t> [ 4448.956823]  ffff88046d86ca40 0000000000000000 ffff880082f37e78 ffff880082f37a40\n\t> [ 4448.958233]  ffffffffb6e47068 ffff880082f37a68 ffff880082f37a58 ffffffffb242708d\n\t> [ 4448.959552]  0000000000000000 ffff880082f37a88 ffffffffb24255b1 0000000000000000\n\t> [ 4448.961266] Call Trace:\n\t> [ 4448.963158] dump_stack (lib/dump_stack.c:52)\n\t> [ 4448.964244] kasan_report_user_access (mm/kasan/report.c:184)\n\t> [ 4448.965507] __asan_load2 (mm/kasan/kasan.c:352)\n\t> [ 4448.966482] ? netlink_sendmsg (net/netlink/af_netlink.c:2339)\n\t> [ 4448.967541] netlink_sendmsg (net/netlink/af_netlink.c:2339)\n\t> [ 4448.968537] ? get_parent_ip (kernel/sched/core.c:2555)\n\t> [ 4448.970103] sock_sendmsg (net/socket.c:654)\n\t> [ 4448.971584] ? might_fault (mm/memory.c:3741)\n\t> [ 4448.972526] ? might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3740)\n\t> [ 4448.973596] ? verify_iovec (net/core/iovec.c:64)\n\t> [ 4448.974522] ___sys_sendmsg (net/socket.c:2096)\n\t> [ 4448.975797] ? put_lock_stats.isra.13 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)\n\t> [ 4448.977030] ? lock_release_holdtime (kernel/locking/lockdep.c:273)\n\t> [ 4448.978197] ? lock_release_non_nested (kernel/locking/lockdep.c:3434 (discriminator 1))\n\t> [ 4448.979346] ? check_chain_key (kernel/locking/lockdep.c:2188)\n\t> [ 4448.980535] __sys_sendmmsg (net/socket.c:2181)\n\t> [ 4448.981592] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)\n\t> [ 4448.982773] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607)\n\t> [ 4448.984458] ? syscall_trace_enter (arch/x86/kernel/ptrace.c:1500 (discriminator 2))\n\t> [ 4448.985621] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)\n\t> [ 4448.986754] SyS_sendmmsg (net/socket.c:2201)\n\t> [ 4448.987708] tracesys (arch/x86/kernel/entry_64.S:542)\n\t> [ 4448.988929] ==================================================================\n\nThis reports means that we've come to netlink_sendmsg() with msg->msg_name == NULL and msg->msg_namelen > 0.\n\nAfter this report there was no usual \"Unable to handle kernel NULL pointer dereference\"\nand this gave me a clue that address 0 is mapped and contains valid socket address structure in it.\n\nThis bug was introduced in f3d3342602f8bcbf37d7c46641cb9bca7618eb1c\n(net: rework recvmsg handler msg_name and msg_namelen logic).\nCommit message states that:\n\t\"Set msg->msg_name = NULL if user specified a NULL in msg_name but had a\n\t non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't\n\t affect sendto as it would bail out earlier while trying to copy-in the\n\t address.\"\nBut in fact this affects sendto when address 0 is mapped and contains\nsocket address structure in it. In such case copy-in address will succeed,\nverify_iovec() function will successfully exit with msg->msg_namelen > 0\nand msg->msg_name == NULL.\n\nThis patch fixes it by setting msg_namelen to 0 if msg_name == NULL.\n\nCc: Hannes Frederic Sowa <hannes@stressinduktion.org>\nCc: Eric Dumazet <edumazet@google.com>\nCc: <stable@vger.kernel.org>\nReported-by: Sasha Levin <sasha.levin@oracle.com>\nSigned-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>\nAcked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Andrey Ryabinin",false],["822fc8dd9dec94a3505998c5febdcb41729f7d57","6d2a44798f4aa9fc72a282cacab24c170698d12a@uclouvain.be","tcp: Fix integer-overflows in TCP veno\n\n[ Upstream commit 45a07695bc64b3ab5d6d2215f9677e5b8c05a7d0 ]\n\nIn veno we do a multiplication of the cwnd and the rtt. This\nmay overflow and thus their result is stored in a u64. However, we first\nneed to cast the cwnd so that actually 64-bit arithmetic is done.\n\nA first attempt at fixing 76f1017757aa0 ([TCP]: TCP Veno congestion\ncontrol) was made by 159131149c2 (tcp: Overflow bug in Vegas), but it\nfailed to add the required cast in tcp_veno_cong_avoid().\n\nFixes: 76f1017757aa0 ([TCP]: TCP Veno congestion control)\nSigned-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Christoph Paasch",false],["5191776cd6a25948c6a6622d40e6fe4c2442794a","6d2a44798f4aa9fc72a282cacab24c170698d12a@uclouvain.be","tcp: Fix integer-overflow in TCP vegas\n\n[ Upstream commit 1f74e613ded11517db90b2bd57e9464d9e0fb161 ]\n\nIn vegas we do a multiplication of the cwnd and the rtt. This\nmay overflow and thus their result is stored in a u64. However, we first\nneed to cast the cwnd so that actually 64-bit arithmetic is done.\n\nThen, we need to do do_div to allow this to be used on 32-bit arches.\n\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Neal Cardwell <ncardwell@google.com>\nCc: Eric Dumazet <eric.dumazet@gmail.com>\nCc: David Laight <David.Laight@ACULAB.COM>\nCc: Doug Leith <doug.leith@nuim.ie>\nFixes: 8d3a564da34e (tcp: tcp_vegas cong avoid fix)\nSigned-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Christoph Paasch",false],["495d049f3e499227d28c89800bca27cc726b3bb2","9ff04a02a69f376b2b9aeec27187017cbf3cf5f9@redhat.com","net: sctp: inherit auth_capable on INIT collisions\n\n[ Upstream commit 1be9a950c646c9092fb3618197f7b6bfb50e82aa ]\n\nJason reported an oops caused by SCTP on his ARM machine with\nSCTP authentication enabled:\n\nInternal error: Oops: 17 [#1] ARM\nCPU: 0 PID: 104 Comm: sctp-test Not tainted 3.13.0-68744-g3632f30c9b20-dirty #1\ntask: c6eefa40 ti: c6f52000 task.ti: c6f52000\nPC is at sctp_auth_calculate_hmac+0xc4/0x10c\nLR is at sg_init_table+0x20/0x38\npc : [<c024bb80>]    lr : [<c00f32dc>]    psr: 40000013\nsp : c6f538e8  ip : 00000000  fp : c6f53924\nr10: c6f50d80  r9 : 00000000  r8 : 00010000\nr7 : 00000000  r6 : c7be4000  r5 : 00000000  r4 : c6f56254\nr3 : c00c8170  r2 : 00000001  r1 : 00000008  r0 : c6f1e660\nFlags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 0005397f  Table: 06f28000  DAC: 00000015\nProcess sctp-test (pid: 104, stack limit = 0xc6f521c0)\nStack: (0xc6f538e8 to 0xc6f54000)\n[...]\nBacktrace:\n[<c024babc>] (sctp_auth_calculate_hmac+0x0/0x10c) from [<c0249af8>] (sctp_packet_transmit+0x33c/0x5c8)\n[<c02497bc>] (sctp_packet_transmit+0x0/0x5c8) from [<c023e96c>] (sctp_outq_flush+0x7fc/0x844)\n[<c023e170>] (sctp_outq_flush+0x0/0x844) from [<c023ef78>] (sctp_outq_uncork+0x24/0x28)\n[<c023ef54>] (sctp_outq_uncork+0x0/0x28) from [<c0234364>] (sctp_side_effects+0x1134/0x1220)\n[<c0233230>] (sctp_side_effects+0x0/0x1220) from [<c02330b0>] (sctp_do_sm+0xac/0xd4)\n[<c0233004>] (sctp_do_sm+0x0/0xd4) from [<c023675c>] (sctp_assoc_bh_rcv+0x118/0x160)\n[<c0236644>] (sctp_assoc_bh_rcv+0x0/0x160) from [<c023d5bc>] (sctp_inq_push+0x6c/0x74)\n[<c023d550>] (sctp_inq_push+0x0/0x74) from [<c024a6b0>] (sctp_rcv+0x7d8/0x888)\n\nWhile we already had various kind of bugs in that area\nec0223ec48a9 (\"net: sctp: fix sctp_sf_do_5_1D_ce to verify if\nwe/peer is AUTH capable\") and b14878ccb7fa (\"net: sctp: cache\nauth_enable per endpoint\"), this one is a bit of a different\nkind.\n\nGiving a bit more background on why SCTP authentication is\nneeded can be found in RFC4895:\n\n  SCTP uses 32-bit verification tags to protect itself against\n  blind attackers. These values are not changed during the\n  lifetime of an SCTP association.\n\n  Looking at new SCTP extensions, there is the need to have a\n  method of proving that an SCTP chunk(s) was really sent by\n  the original peer that started the association and not by a\n  malicious attacker.\n\nTo cause this bug, we're triggering an INIT collision between\npeers; normal SCTP handshake where both sides intent to\nauthenticate packets contains RANDOM; CHUNKS; HMAC-ALGO\nparameters that are being negotiated among peers:\n\n  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->\n  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------\n  -------------------- COOKIE-ECHO -------------------->\n  <-------------------- COOKIE-ACK ---------------------\n\nRFC4895 says that each endpoint therefore knows its own random\nnumber and the peer's random number *after* the association\nhas been established. The local and peer's random number along\nwith the shared key are then part of the secret used for\ncalculating the HMAC in the AUTH chunk.\n\nNow, in our scenario, we have 2 threads with 1 non-blocking\nSEQ_PACKET socket each, setting up common shared SCTP_AUTH_KEY\nand SCTP_AUTH_ACTIVE_KEY properly, and each of them calling\nsctp_bindx(3), listen(2) and connect(2) against each other,\nthus the handshake looks similar to this, e.g.:\n\n  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->\n  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------\n  <--------- INIT[RANDOM; CHUNKS; HMAC-ALGO] -----------\n  -------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] -------->\n  ...\n\nSince such collisions can also happen with verification tags,\nthe RFC4895 for AUTH rather vaguely says under section 6.1:\n\n  In case of INIT collision, the rules governing the handling\n  of this Random Number follow the same pattern as those for\n  the Verification Tag, as explained in Section 5.2.4 of\n  RFC 2960 [5]. Therefore, each endpoint knows its own Random\n  Number and the peer's Random Number after the association\n  has been established.\n\nIn RFC2960, section 5.2.4, we're eventually hitting Action B:\n\n  B) In this case, both sides may be attempting to start an\n     association at about the same time but the peer endpoint\n     started its INIT after responding to the local endpoint's\n     INIT. Thus it may have picked a new Verification Tag not\n     being aware of the previous Tag it had sent this endpoint.\n     The endpoint should stay in or enter the ESTABLISHED\n     state but it MUST update its peer's Verification Tag from\n     the State Cookie, stop any init or cookie timers that may\n     running and send a COOKIE ACK.\n\nIn other words, the handling of the Random parameter is the\nsame as behavior for the Verification Tag as described in\nAction B of section 5.2.4.\n\nLooking at the code, we exactly hit the sctp_sf_do_dupcook_b()\ncase which triggers an SCTP_CMD_UPDATE_ASSOC command to the\nside effect interpreter, and in fact it properly copies over\npeer_{random, hmacs, chunks} parameters from the newly created\nassociation to update the existing one.\n\nAlso, the old asoc_shared_key is being released and based on\nthe new params, sctp_auth_asoc_init_active_key() updated.\nHowever, the issue observed in this case is that the previous\nasoc->peer.auth_capable was 0, and has *not* been updated, so\nthat instead of creating a new secret, we're doing an early\nreturn from the function sctp_auth_asoc_init_active_key()\nleaving asoc->asoc_shared_key as NULL. However, we now have to\nauthenticate chunks from the updated chunk list (e.g. COOKIE-ACK).\n\nThat in fact causes the server side when responding with ...\n\n  <------------------ AUTH; COOKIE-ACK -----------------\n\n... to trigger a NULL pointer dereference, since in\nsctp_packet_transmit(), it discovers that an AUTH chunk is\nbeing queued for xmit, and thus it calls sctp_auth_calculate_hmac().\n\nSince the asoc->active_key_id is still inherited from the\nendpoint, and the same as encoded into the chunk, it uses\nasoc->asoc_shared_key, which is still NULL, as an asoc_key\nand dereferences it in ...\n\n  crypto_hash_setkey(desc.tfm, &asoc_key->data[0], asoc_key->len)\n\n... causing an oops. All this happens because sctp_make_cookie_ack()\ncalled with the *new* association has the peer.auth_capable=1\nand therefore marks the chunk with auth=1 after checking\nsctp_auth_send_cid(), but it is *actually* sent later on over\nthe then *updated* association's transport that didn't initialize\nits shared key due to peer.auth_capable=0. Since control chunks\nin that case are not sent by the temporary association which\nare scheduled for deletion, they are issued for xmit via\nSCTP_CMD_REPLY in the interpreter with the context of the\n*updated* association. peer.auth_capable was 0 in the updated\nassociation (which went from COOKIE_WAIT into ESTABLISHED state),\nsince all previous processing that performed sctp_process_init()\nwas being done on temporary associations, that we eventually\nthrow away each time.\n\nThe correct fix is to update to the new peer.auth_capable\nvalue as well in the collision case via sctp_assoc_update(),\nso that in case the collision migrated from 0 -> 1,\nsctp_auth_asoc_init_active_key() can properly recalculate\nthe secret. This therefore fixes the observed server panic.\n\nFixes: 730fc3d05cd4 (\"[SCTP]: Implete SCTP-AUTH parameter processing\")\nReported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nTested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>\nCc: Vlad Yasevich <vyasevich@gmail.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Daniel Borkmann",false],["d09fdc66ecb543136f9e3304c1b6071d3dae9792","cbd80080413a7dff621bc5de2d3d61903bde20a2@redhat.com","macvlan: Initialize vlan_features to turn on offload support.\n\n[ Upstream commit 081e83a78db9b0ae1f5eabc2dedecc865f509b98 ]\n\nMacvlan devices do not initialize vlan_features.  As a result,\nany vlan devices configured on top of macvlans perform very poorly.\nInitialize vlan_features based on the vlan features of the lower-level\ndevice.\n\nSigned-off-by: Vlad Yasevich <vyasevic@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Vlad Yasevich",false],["c290a4ef1fe38bd8d29573468a189e49dbaa0681","cbd80080413a7dff621bc5de2d3d61903bde20a2@redhat.com","net: Correctly set segment mac_len in skb_segment().\n\n[ Upstream commit fcdfe3a7fa4cb74391d42b6a26dc07c20dab1d82 ]\n\nWhen performing segmentation, the mac_len value is copied right\nout of the original skb.  However, this value is not always set correctly\n(like when the packet is VLAN-tagged) and we'll end up copying a bad\nvalue.\n\nOne way to demonstrate this is to configure a VM which tags\npackets internally and turn off VLAN acceleration on the forwarding\nbridge port.  The packets show up corrupt like this:\n16:18:24.985548 52:54:00:ab:be:25 > 52:54:00:26:ce:a3, ethertype 802.1Q\n(0x8100), length 1518: vlan 100, p 0, ethertype 0x05e0,\n        0x0000:  8cdb 1c7c 8cdb 0064 4006 b59d 0a00 6402 ...|...d@.....d.\n        0x0010:  0a00 6401 9e0d b441 0a5e 64ec 0330 14fa ..d....A.^d..0..\n        0x0020:  29e3 01c9 f871 0000 0101 080a 000a e833)....q.........3\n        0x0030:  000f 8c75 6e65 7470 6572 6600 6e65 7470 ...unetperf.netp\n        0x0040:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp\n        0x0050:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp\n        0x0060:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp\n        ...\n\nThis also leads to awful throughput as GSO packets are dropped and\ncause retransmissions.\n\nThe solution is to set the mac_len using the values already available\nin then new skb.  We've already adjusted all of the header offset, so we\nmight as well correctly figure out the mac_len using skb_reset_mac_len().\nAfter this change, packets are segmented correctly and performance\nis restored.\n\nCC: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Vlad Yasevich <vyasevic@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Vlad Yasevich",false],["9d868b94a6f52a17a2a94b34e544800d741b7852","e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","iovec: make sure the caller actually wants anything in memcpy_fromiovecend\n\n[ Upstream commit 06ebb06d49486676272a3c030bfeef4bd969a8e6 ]\n\nCheck for cases when the caller requests 0 bytes instead of running off\nand dereferencing potentially invalid iovecs.\n\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Sasha Levin",false],["6e5f6266d635809c560f7fb48a710701a1d54139","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","sctp: fix possible seqlock seadlock in sctp_packet_transmit()\n\n[ Upstream commit 757efd32d5ce31f67193cc0e6a56e4dffcc42fb1 ]\n\nDave reported following splat, caused by improper use of\nIP_INC_STATS_BH() in process context.\n\nBUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551\ncaller is __this_cpu_preempt_check+0x13/0x20\nCPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33\n ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207\n 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40\n ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3\nCall Trace:\n [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a\n [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100\n [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20\n [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp]\n [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp]\n [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0\n [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80\n [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp]\n [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp]\n [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp]\n [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100\n [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp]\n [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp]\n [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp]\n [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160\n [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30\n [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220\n [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220\n [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0\n [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0\n [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0\n [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0\n [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330\n [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10\n [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2\n\nThis is a followup of commits f1d8cba61c3c4b (\"inet: fix possible\nseqlock deadlocks\") and 7f88c6b23afbd315 (\"ipv6: fix possible seqlock\ndeadlock in ip6_finish_output2\")\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Hannes Frederic Sowa <hannes@stressinduktion.org>\nReported-by: Dave Jones <davej@redhat.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nAcked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Eric Dumazet",false],["af25a08645b730f1d327110235d480266fa18acb","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Fix argument sign extension for compat_sys_futex().\n\n[ Upstream commit aa3449ee9c87d9b7660dd1493248abcc57769e31 ]\n\nOnly the second argument, 'op', is signed.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["f07030c1e2eadec2ee9863e1b7e06036a2166886","f0a29e10abf52e3965939db20f961ffd5c7f3d14@yandex.ru","sparc64: Make itc_sync_lock raw\n\n[ Upstream commit 49b6c01f4c1de3b5e5427ac5aba80f9f6d27837a ]\n\nOne more place where we must not be able\nto be preempted or to be interrupted in RT.\n\nAlways actually disable interrupts during\nsynchronization cycle.\n\nSigned-off-by: Kirill Tkhai <tkhai@yandex.ru>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Kirill Tkhai",false],["ff156a9ba7c160c8fc1c8d4bb0fb935771e105dc","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Handle 32-bit tasks properly in compute_effective_address().\n\n[ Upstream commit d037d16372bbe4d580342bebbb8826821ad9edf0 ]\n\nIf we have a 32-bit task we must chop off the top 32-bits of the\n64-bit value just as the cpu would.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["f2701cd605156eee1cd5edbc709f989a8bbe218a","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Fix top-level fault handling bugs.\n\n[ Upstream commit 70ffc6ebaead783ac8dafb1e87df0039bb043596 ]\n\nMake get_user_insn() able to cope with huge PMDs.\n\nNext, make do_fault_siginfo() more robust when get_user_insn() can't\nactually fetch the instruction.  In particular, use the MMU announced\nfault address when that happens, instead of calling\ncompute_effective_address() and computing garbage.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["e5bd62b99772098f5123bff888247dbc8e68f602","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses.\n\n[ Upstream commit e5c460f46ae7ee94831cb55cb980f942aa9e5a85 ]\n\nThis was found using Dave Jone's trinity tool.\n\nWhen a user process which is 32-bit performs a load or a store, the\ncpu chops off the top 32-bits of the effective address before\ntranslating it.\n\nThis is because we run 32-bit tasks with the PSTATE_AM (address\nmasking) bit set.\n\nWe can't run the kernel with that bit set, so when the kernel accesses\nuserspace no address masking occurs.\n\nSince a 32-bit process will have no mappings in that region we will\nproperly fault, so we don't try to handle this using access_ok(),\nwhich can safely just be a NOP on sparc64.\n\nReal faults from 32-bit processes should never generate such addresses\nso a bug check was added long ago, and it barks in the logs if this\nhappens.\n\nBut it also barks when a kernel user access causes this condition, and\nthat _can_ happen.  For example, if a pointer passed into a system call\nis \"0xfffffffc\" and the kernel access 4 bytes offset from that pointer.\n\nJust handle such faults normally via the exception entries.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["720910a60cc2509160ec043459081f274c12ccce","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.\n\n[ Upstream commit b18eb2d779240631a098626cb6841ee2dd34fda0 ]\n\nAccess to the TSB hash tables during TLB misses requires that there be\nan atomic 128-bit quad load available so that we fetch a matching TAG\nand DATA field at the same time.\n\nOn cpus prior to UltraSPARC-III only virtual address based quad loads\nare available.  UltraSPARC-III and later provide physical address\nbased variants which are easier to use.\n\nWhen we only have virtual address based quad loads available this\nmeans that we have to lock the TSB into the TLB at a fixed virtual\naddress on each cpu when it runs that process.  We can't just access\nthe PAGE_OFFSET based aliased mapping of these TSBs because we cannot\ntake a recursive TLB miss inside of the TLB miss handler without\nrisking running out of hardware trap levels (some trap combinations\ncan be deep, such as those generated by register window spill and fill\ntraps).\n\nWithout huge pages it's working perfectly fine, but when the huge TSB\ngot added another chunk of fixed virtual address space was not\nallocated for this second TSB mapping.\n\nSo we were mapping both the 8K and 4MB TSBs to the same exact virtual\naddress, causing multiple TLB matches which gives undefined behavior.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["921df8ed4c86310d215b62579703cc89741d6361","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Add membar to Niagara2 memcpy code.\n\n[ Upstream commit 5aa4ecfd0ddb1e6dcd1c886e6c49677550f581aa ]\n\nThis is the prevent previous stores from overlapping the block stores\ndone by the memcpy loop.\n\nBased upon a glibc patch by Jose E. Marchesi\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["5b36a75bc06a00ede43bf8d9e921052357384072","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Do not insert non-valid PTEs into the TSB hash table.\n\n[ Upstream commit 18f38132528c3e603c66ea464727b29e9bbcb91b ]\n\nThe assumption was that update_mmu_cache() (and the equivalent for PMDs) would\nonly be called when the PTE being installed will be accessible by the user.\n\nThis is not true for code paths originating from remove_migration_pte().\n\nThere are dire consequences for placing a non-valid PTE into the TSB.  The TLB\nmiss frramework assumes thatwhen a TSB entry matches we can just load it into\nthe TLB and return from the TLB miss trap.\n\nSo if a non-valid PTE is in there, we will deadlock taking the TLB miss over\nand over, never satisfying the miss.\n\nJust exit early from update_mmu_cache() and friends in this situation.\n\nBased upon a report and patch from Christopher Alexander Tobias Schulze.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false],["38f4577f05042a9151ae920d0107404fdb21e59a","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","sparc64: Guard against flushing openfirmware mappings.\n\n[ Upstream commit 4ca9a23765da3260058db3431faf5b4efd8cf926 ]\n\nBased almost entirely upon a patch by Christopher Alexander Tobias\nSchulze.\n\nIn commit db64fe02258f1507e13fe5212a989922323685ce (\"mm: rewrite vmap\nlayer\") lazy VMAP tlb flushing was added to the vmalloc layer.  This\ncauses problems on sparc64.\n\nSparc64 has two VMAP mapped regions and they are not contiguous with\neachother.  First we have the malloc mapping area, then another\nunrelated region, then the vmalloc region.\n\nThis \"another unrelated region\" is where the firmware is mapped.\n\nIf the lazy TLB flushing logic in the vmalloc code triggers after\nwe've had both a module unload and a vfree or similar, it will pass an\naddress range that goes from somewhere inside the malloc region to\nsomewhere inside the vmalloc region, and thus covering the\nopenfirmware area entirely.\n\nThe sparc64 kernel learns about openfirmware's dynamic mappings in\nthis region early in the boot, and then services TLB misses in this\narea.  But openfirmware has some locked TLB entries which are not\nmentioned in those dynamic mappings and we should thus not disturb\nthem.\n\nThese huge lazy TLB flush ranges causes those openfirmware locked TLB\nentries to be removed, resulting in all kinds of problems including\nhard hangs and crashes during reboot/reset.\n\nBesides causing problems like this, such huge TLB flush ranges are\nalso incredibly inefficient.  A plea has been made with the author of\nthe VMAP lazy TLB flushing code, but for now we'll put a safety guard\ninto our flush_tlb_kernel_range() implementation.\n\nSince the implementation has become non-trivial, stop defining it as a\nmacro and instead make it a function in a C source file.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","David S. Miller",false]],"size":26,"ref":"refs/heads/linux-linaro-lsk","head":"8d60710642cf8f36e8d21d9e9fd4b9536864f2f5"}