{"push_id":597311003,"size":196,"distinct_size":196,"ref":"refs/heads/dave-3.18.y","head":"85edc2ca5bd59e813aabee636ca358d2b4fc37c7","before":"0ea64518b9373c34d8ca49e7f537d380537e1824","commits":[{"sha":"8e9f6bdb35ae63a83ab8d0338eb13d72d596aba5","author":{"email":"1ee125182537a91f90180f97fc3b3cb011bdf78a@google.com","name":"Willem de Bruijn"},"message":"ip: zero sockaddr returned on error queue\n\n[ Upstream commit f812116b174e59a350acc8e4856213a166a91222 ]\n\nThe sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That\nstructure is defined and allocated on the stack as\n\n    struct {\n            struct sock_extended_err ee;\n            struct sockaddr_in(6)    offender;\n    } errhdr;\n\nThe second part is only initialized for certain SO_EE_ORIGIN values.\nAlways initialize it completely.\n\nAn MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that\nwould return uninitialized bytes.\n\nSigned-off-by: Willem de Bruijn <willemb@google.com>\n\n----\n\nAlso verified that there is no padding between errhdr.ee and\nerrhdr.offender that could leak additional kernel data.\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/8e9f6bdb35ae63a83ab8d0338eb13d72d596aba5"},{"sha":"9e4cc1ed83e5459a43085e0cab26aa269bb2dfb3","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"net: rps: fix cpu unplug\n\n[ Upstream commit ac64da0b83d82abe62f78b3d0e21cca31aea24fa ]\n\nsoftnet_data.input_pkt_queue is protected by a spinlock that\nwe must hold when transferring packets from victim queue to an active\none. This is because other cpus could still be trying to enqueue packets\ninto victim queue.\n\nA second problem is that when we transfert the NAPI poll_list from\nvictim to current cpu, we absolutely need to special case the percpu\nbacklog, because we do not want to add complex locking to protect\nprocess_queue : Only owner cpu is allowed to manipulate it, unless cpu\nis offline.\n\nBased on initial patch from Prasad Sodagudi & Subash Abhinov\nKasiviswanathan.\n\nThis version is better because we do not slow down packet processing,\nonly make migration safer.\n\nReported-by: Prasad Sodagudi <psodagud@codeaurora.org>\nReported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Tom Herbert <therbert@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/9e4cc1ed83e5459a43085e0cab26aa269bb2dfb3"},{"sha":"eb4890059155d5de636acba5b4421cb826d6fa4f","author":{"email":"4d5bb2d32024e62584022f82eb016d5f4634880b@jauu.net","name":"Hagen Paul Pfeifer"},"message":"ipv6: stop sending PTB packets for MTU < 1280\n\n[ Upstream commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2 ]\n\nReduce the attack vector and stop generating IPv6 Fragment Header for\npaths with an MTU smaller than the minimum required IPv6 MTU\nsize (1280 byte) - called atomic fragments.\n\nSee IETF I-D \"Deprecating the Generation of IPv6 Atomic Fragments\" [1]\nfor more information and how this \"feature\" can be misused.\n\n[1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00\n\nSigned-off-by: Fernando Gont <fgont@si6networks.com>\nSigned-off-by: Hagen Paul Pfeifer <hagen@jauu.net>\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>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/eb4890059155d5de636acba5b4421cb826d6fa4f"},{"sha":"e452612a3d5a59a8a7e5f33a579869d49b7ec90b","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"netxen: fix netxen_nic_poll() logic\n\n[ Upstream commit 6088beef3f7517717bd21d90b379714dd0837079 ]\n\nNAPI poll logic now enforces that a poller returns exactly the budget\nwhen it wants to be called again.\n\nIf a driver limits TX completion, it has to return budget as well when\nthe limit is hit, not the number of received packets.\n\nReported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nFixes: d75b1ade567f (\"net: less interrupt masking in NAPI\")\nCc: Manish Chopra <manish.chopra@qlogic.com>\nAcked-by: Manish Chopra <manish.chopra@qlogic.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/e452612a3d5a59a8a7e5f33a579869d49b7ec90b"},{"sha":"c75e4b05b591b6c134b7e66c1ea39757f452f1e8","author":{"email":"9ff04a02a69f376b2b9aeec27187017cbf3cf5f9@redhat.com","name":"Daniel Borkmann"},"message":"net: sctp: fix slab corruption from use after free on INIT collisions\n\n[ Upstream commit 600ddd6825543962fb807884169e57b580dba208 ]\n\nWhen hitting an INIT collision case during the 4WHS with AUTH enabled, as\nalready described in detail in commit 1be9a950c646 (\"net: sctp: inherit\nauth_capable on INIT collisions\"), it can happen that we occasionally\nstill remotely trigger the following panic on server side which seems to\nhave been uncovered after the fix from commit 1be9a950c646 ...\n\n[  533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff\n[  533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230\n[  533.940559] PGD 5030f2067 PUD 0\n[  533.957104] Oops: 0000 [#1] SMP\n[  533.974283] Modules linked in: sctp mlx4_en [...]\n[  534.939704] Call Trace:\n[  534.951833]  [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0\n[  534.984213]  [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0\n[  535.015025]  [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170\n[  535.045661]  [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0\n[  535.074593]  [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50\n[  535.105239]  [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]\n[  535.138606]  [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0\n[  535.166848]  [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b\n\n... or depending on the the application, for example this one:\n\n[ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff\n[ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0\n[ 1370.054568] PGD 633c94067 PUD 0\n[ 1370.070446] Oops: 0000 [#1] SMP\n[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]\n[ 1370.963431] Call Trace:\n[ 1370.974632]  [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960\n[ 1371.000863]  [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960\n[ 1371.027154]  [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170\n[ 1371.054679]  [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130\n[ 1371.080183]  [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b\n\nWith slab debugging enabled, we can see that the poison has been overwritten:\n\n[  669.826368] BUG kmalloc-128 (Tainted: G        W     ): Poison overwritten\n[  669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b\n[  669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494\n[  669.826424]  __slab_alloc+0x4bf/0x566\n[  669.826433]  __kmalloc+0x280/0x310\n[  669.826453]  sctp_auth_create_key+0x23/0x50 [sctp]\n[  669.826471]  sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]\n[  669.826488]  sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]\n[  669.826505]  sctp_do_sm+0x29d/0x17c0 [sctp] [...]\n[  669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494\n[  669.826635]  __slab_free+0x39/0x2a8\n[  669.826643]  kfree+0x1d6/0x230\n[  669.826650]  kzfree+0x31/0x40\n[  669.826666]  sctp_auth_key_put+0x19/0x20 [sctp]\n[  669.826681]  sctp_assoc_update+0x1ee/0x2d0 [sctp]\n[  669.826695]  sctp_do_sm+0x674/0x17c0 [sctp]\n\nSince this only triggers in some collision-cases with AUTH, the problem at\nheart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice\nwhen having refcnt 1, once directly in sctp_assoc_update() and yet again\nfrom within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on\nthe already kzfree'd memory, which is also consistent with the observation\nof the poison decrease from 0x6b to 0x6a (note: the overwrite is detected\nat a later point in time when poison is checked on new allocation).\n\nReference counting of auth keys revisited:\n\nShared keys for AUTH chunks are being stored in endpoints and associations\nin endpoint_shared_keys list. On endpoint creation, a null key is being\nadded; on association creation, all endpoint shared keys are being cached\nand thus cloned over to the association. struct sctp_shared_key only holds\na pointer to the actual key bytes, that is, struct sctp_auth_bytes which\nkeeps track of users internally through refcounting. Naturally, on assoc\nor enpoint destruction, sctp_shared_key are being destroyed directly and\nthe reference on sctp_auth_bytes dropped.\n\nUser space can add keys to either list via setsockopt(2) through struct\nsctp_authkey and by passing that to sctp_auth_set_key() which replaces or\nadds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes\nwith refcount 1 and in case of replacement drops the reference on the old\nsctp_auth_bytes. A key can be set active from user space through setsockopt()\non the id via sctp_auth_set_active_key(), which iterates through either\nendpoint_shared_keys and in case of an assoc, invokes (one of various places)\nsctp_auth_asoc_init_active_key().\n\nsctp_auth_asoc_init_active_key() computes the actual secret from local's\nand peer's random, hmac and shared key parameters and returns a new key\ndirectly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops\nthe reference if there was a previous one. The secret, which where we\neventually double drop the ref comes from sctp_auth_asoc_set_secret() with\nintitial refcount of 1, which also stays unchanged eventually in\nsctp_assoc_update(). This key is later being used for crypto layer to\nset the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().\n\nTo close the loop: asoc->asoc_shared_key is freshly allocated secret\nmaterial and independant of the sctp_shared_key management keeping track\nof only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76\n(\"net: sctp: fix memory leak in auth key management\") is independant of\nthis bug here since it concerns a different layer (though same structures\nbeing used eventually). asoc->asoc_shared_key is reference dropped correctly\non assoc destruction in sctp_association_free() and when active keys are\nbeing replaced in sctp_auth_asoc_init_active_key(), it always has a refcount\nof 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is\nto remove that sctp_auth_key_put() from there which fixes these panics.\n\nFixes: 730fc3d05cd4 (\"[SCTP]: Implete SCTP-AUTH parameter processing\")\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/c75e4b05b591b6c134b7e66c1ea39757f452f1e8"},{"sha":"9ad1a959ac71423224aa8f248af3cc258e54e46a","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","name":"Hannes Frederic Sowa"},"message":"ipv4: try to cache dst_entries which would cause a redirect\n\n[ Upstream commit df4d92549f23e1c037e83323aff58a21b3de7fe0 ]\n\nNot caching dst_entries which cause redirects could be exploited by hosts\non the same subnet, causing a severe DoS attack. This effect aggravated\nsince commit f88649721268999 (\"ipv4: fix dst race in sk_dst_get()\").\n\nLookups causing redirects will be allocated with DST_NOCACHE set which\nwill force dst_release to free them via RCU.  Unfortunately waiting for\nRCU grace period just takes too long, we can end up with >1M dst_entries\nwaiting to be released and the system will run OOM. rcuos threads cannot\ncatch up under high softirq load.\n\nAttaching the flag to emit a redirect later on to the specific skb allows\nus to cache those dst_entries thus reducing the pressure on allocation\nand deallocation.\n\nThis issue was discovered by Marcelo Leitner.\n\nCc: Julian Anastasov <ja@ssi.bg>\nSigned-off-by: Marcelo Leitner <mleitner@redhat.com>\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: Julian Anastasov <ja@ssi.bg>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/9ad1a959ac71423224aa8f248af3cc258e54e46a"},{"sha":"faf8cf001d5c4479cabdea4ef11dae11b9c727a9","author":{"email":"ef65de1c7be0aa837fe7b25ba9a7739905af6a55@gondor.apana.org.au","name":"Herbert Xu"},"message":"udp_diag: Fix socket skipping within chain\n\n[ Upstream commit 86f3cddbc3037882414c7308973530167906b7e9 ]\n\nWhile working on rhashtable walking I noticed that the UDP diag\ndumping code is buggy.  In particular, the socket skipping within\na chain never happens, even though we record the number of sockets\nthat should be skipped.\n\nAs this code was supposedly copied from TCP, this patch does what\nTCP does and resets num before we walk a chain.\n\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nAcked-by: Pavel Emelyanov <xemul@parallels.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/faf8cf001d5c4479cabdea4ef11dae11b9c727a9"},{"sha":"3a06a68b40164cc73b89017a5ec9eec925037631","author":{"email":"1dc9a55fbcba59128627e933e7c9fd67d2a78e24@codeaurora.org","name":"subashab@codeaurora.org"},"message":"ping: Fix race in free in receive path\n\n[ Upstream commit fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ]\n\nAn exception is seen in ICMP ping receive path where the skb\ndestructor sock_rfree() tries to access a freed socket. This happens\nbecause ping_rcv() releases socket reference with sock_put() and this\ninternally frees up the socket. Later icmp_rcv() will try to free the\nskb and as part of this, skb destructor is called and which leads\nto a kernel panic as the socket is freed already in ping_rcv().\n\n-->|exception\n-007|sk_mem_uncharge\n-007|sock_rfree\n-008|skb_release_head_state\n-009|skb_release_all\n-009|__kfree_skb\n-010|kfree_skb\n-011|icmp_rcv\n-012|ip_local_deliver_finish\n\nFix this incorrect free by cloning this skb and processing this cloned\nskb instead.\n\nThis patch was suggested by Eric Dumazet\n\nSigned-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>\nCc: Eric Dumazet <edumazet@google.com>\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>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/3a06a68b40164cc73b89017a5ec9eec925037631"},{"sha":"b0e791661b291dfea609f6c647066b005fb546b5","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","name":"Hannes Frederic Sowa"},"message":"ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too\n\n[ Upstream commit 6e9e16e6143b725662e47026a1d0f270721cdd24 ]\n\nLubomir Rintel reported that during replacing a route the interface\nreference counter isn't correctly decremented.\n\nTo quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:\n| [root@rhel7-5 lkundrak]# sh -x lal\n| + ip link add dev0 type dummy\n| + ip link set dev0 up\n| + ip link add dev1 type dummy\n| + ip link set dev1 up\n| + ip addr add 2001:db8:8086::2/64 dev dev0\n| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20\n| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10\n| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20\n| + ip link del dev0 type dummy\n| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...\n|  kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2\n|\n| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...\n|  kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2\n\nDuring replacement of a rt6_info we must walk all parent nodes and check\nif the to be replaced rt6_info got propagated. If so, replace it with\nan alive one.\n\nFixes: 4a287eba2de3957 (\"IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag\")\nReported-by: Lubomir Rintel <lkundrak@v3.sk>\nSigned-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nTested-by: Lubomir Rintel <lkundrak@v3.sk>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/b0e791661b291dfea609f6c647066b005fb546b5"},{"sha":"e3b175f60e9c79f559d14f76590a701b62c583c4","author":{"email":"3dda28f5bb93199f5e7fb74da2e58f50ff4427be@gmx.com","name":"Govindarajulu Varadarajan"},"message":"bnx2x: fix napi poll return value for repoll\n\n[ Upstream commit 24e579c8898aa641ede3149234906982290934e5 ]\n\nWith the commit d75b1ade567ffab (\"net: less interrupt masking in NAPI\") napi\nrepoll is done only when work_done == budget. When in busy_poll is we return 0\nin napi_poll. We should return budget.\n\nSigned-off-by: Govindarajulu Varadarajan <_govind@gmx.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/e3b175f60e9c79f559d14f76590a701b62c583c4"},{"sha":"db4d24bc7f3be9fedd6f97585a2ef9f72b7478e7","author":{"email":"923f7720577207a44b32e59bbfbea59d27f1ae8e@lst.de","name":"Christoph Hellwig"},"message":"net: don't OOPS on socket aio\n\n[ Upstream commit 06539d3071067ff146a9bffd1c801fa56d290909 ]\n\nSigned-off-by: Christoph Hellwig <hch@lst.de>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/db4d24bc7f3be9fedd6f97585a2ef9f72b7478e7"},{"sha":"7a0189390ed2eecfc928017ec8696d0cf80c24c7","author":{"email":"d3f6ba90004ada8c36186a20548ed980b7e493d1@cumulusnetworks.com","name":"Roopa Prabhu"},"message":"bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify\n\n[ Upstream commit 59ccaaaa49b5b096cdc1f16706a9f931416b2332 ]\n\nReported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081\n\nThis patch avoids calling rtnl_notify if the device ndo_bridge_getlink\nhandler does not return any bytes in the skb.\n\nAlternately, the skb->len check can be moved inside rtnl_notify.\n\nFor the bridge vlan case described in 92081, there is also a fix needed\nin bridge driver to generate a proper notification. Will fix that in\nsubsequent patch.\n\nv2: rebase patch on net tree\n\nSigned-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/7a0189390ed2eecfc928017ec8696d0cf80c24c7"},{"sha":"617417f9990b33c162c08a2e29cc356c50ce3943","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"tcp: ipv4: initialize unicast_sock sk_pacing_rate\n\n[ Upstream commit 811230cd853d62f09ed0addd0ce9a1b9b0e13fb5 ]\n\nWhen I added sk_pacing_rate field, I forgot to initialize its value\nin the per cpu unicast_sock used in ip_send_unicast_reply()\n\nThis means that for sch_fq users, RST packets, or ACK packets sent\non behalf of TIME_WAIT sockets might be sent to slowly or even dropped\nonce we reach the per flow limit.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nFixes: 95bd09eb2750 (\"tcp: TSO packets automatic sizing\")\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/617417f9990b33c162c08a2e29cc356c50ce3943"},{"sha":"b974d00b778962b9b83c477a7359e40a28f7ed98","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"ipv4: tcp: get rid of ugly unicast_sock\n\n[ Upstream commit bdbbb8527b6f6a358dbcb70dac247034d665b8e4 ]\n\nIn commit be9f4a44e7d41 (\"ipv4: tcp: remove per net tcp_sock\")\nI tried to address contention on a socket lock, but the solution\nI chose was horrible :\n\ncommit 3a7c384ffd57e (\"ipv4: tcp: unicast_sock should not land outside\nof TCP stack\") addressed a selinux regression.\n\ncommit 0980e56e506b (\"ipv4: tcp: set unicast_sock uc_ttl to -1\")\ntook care of another regression.\n\ncommit b5ec8eeac46 (\"ipv4: fix ip_send_skb()\") fixed another regression.\n\ncommit 811230cd85 (\"tcp: ipv4: initialize unicast_sock sk_pacing_rate\")\nwas another shot in the dark.\n\nReally, just use a proper socket per cpu, and remove the skb_orphan()\ncall, to re-enable flow control.\n\nThis solves a serious problem with FQ packet scheduler when used in\nhostile environments, as we do not want to allocate a flow structure\nfor every RST packet sent in response to a spoofed packet.\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>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/b974d00b778962b9b83c477a7359e40a28f7ed98"},{"sha":"15f7f69a6baccddc90f6cc313ebc4b04cc75829a","author":{"email":"cef439e78636cdab99cd2923826c5065a0743e5b@strlen.de","name":"Florian Westphal"},"message":"ppp: deflate: never return len larger than output buffer\n\n[ Upstream commit e2a4800e75780ccf4e6c2487f82b688ba736eb18 ]\n\nWhen we've run out of space in the output buffer to store more data, we\nwill call zlib_deflate with a NULL output buffer until we've consumed\nremaining input.\n\nWhen this happens, olen contains the size the output buffer would have\nconsumed iff we'd have had enough room.\n\nThis can later cause skb_over_panic when ppp_generic skb_put()s\nthe returned length.\n\nReported-by: Iain Douglas <centos@1n6.org.uk>\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/15f7f69a6baccddc90f6cc313ebc4b04cc75829a"},{"sha":"6743ca71e113f4a2b5ee58b060807974d4d33f8b","author":{"email":"849b7ce4f31c4b266d748dab7a8ca8f901d6a555@telus.com","name":"Saran Maruti Ramanara"},"message":"net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param\n\n[ Upstream commit cfbf654efc6d78dc9812e030673b86f235bf677d ]\n\nWhen making use of RFC5061, section 4.2.4. for setting the primary IP\naddress, we're passing a wrong parameter header to param_type2af(),\nresulting always in NULL being returned.\n\nAt this point, param.p points to a sctp_addip_param struct, containing\na sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation\nid. Followed by that, as also presented in RFC5061 section 4.2.4., comes\nthe actual sctp_addr_param, which also contains a sctp_paramhdr, but\nthis time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that\nparam_type2af() can make use of. Since we already hold a pointer to\naddr_param from previous line, just reuse it for param_type2af().\n\nFixes: d6de3097592b (\"[SCTP]: Add the handling of \"Set Primary IP Address\" parameter to INIT\")\nSigned-off-by: Saran Maruti Ramanara <saran.neti@telus.com>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/6743ca71e113f4a2b5ee58b060807974d4d33f8b"},{"sha":"d2ddce3df7c7e8bdabea6c2990589440cd50fa7d","author":{"email":"6c26c5044f1d67d9ed5db6596adb36d25510e216@microsoft.com","name":"Haiyang Zhang"},"message":"hyperv: Fix the error processing in netvsc_send()\n\n[ Upstream commit d953ca4ddf71aa91a4596b2ff7ff1598f6ad4708 ]\n\nThe existing code frees the skb in EAGAIN case, in which the skb will be\nretried from upper layer and used again.\nAlso, the existing code doesn't free send buffer slot in error case, because\nthere is no completion message for unsent packets.\nThis patch fixes these problems.\n\n(Please also include this patch for stable trees. Thanks!)\n\nSigned-off-by: Haiyang Zhang <haiyangz@microsoft.com>\nReviewed-by: K. Y. Srinivasan <kys@microsoft.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/d2ddce3df7c7e8bdabea6c2990589440cd50fa7d"},{"sha":"a17ad4adfff6ebd29c0f07177b5236c0e7f04ac9","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"net: sched: fix panic in rate estimators\n\n[ Upstream commit 0d32ef8cef9aa8f375e128f78b77caceaa7e8da0 ]\n\nDoing the following commands on a non idle network device\npanics the box instantly, because cpu_bstats gets overwritten\nby stats.\n\ntc qdisc add dev eth0 root <your_favorite_qdisc>\n... some traffic (one packet is enough) ...\ntc qdisc replace dev eth0 root est 1sec 4sec <your_favorite_qdisc>\n\n[  325.355596] BUG: unable to handle kernel paging request at ffff8841dc5a074c\n[  325.362609] IP: [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90\n[  325.369158] PGD 1fa7067 PUD 0\n[  325.372254] Oops: 0000 [#1] SMP\n[  325.375514] Modules linked in: ...\n[  325.398346] CPU: 13 PID: 14313 Comm: tc Not tainted 3.19.0-smp-DEV #1163\n[  325.412042] task: ffff8800793ab5d0 ti: ffff881ff2fa4000 task.ti: ffff881ff2fa4000\n[  325.419518] RIP: 0010:[<ffffffff81541c9e>]  [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90\n[  325.428506] RSP: 0018:ffff881ff2fa7928  EFLAGS: 00010286\n[  325.433824] RAX: 000000000000000c RBX: ffff881ff2fa796c RCX: 000000000000000c\n[  325.440988] RDX: ffff8841dc5a0744 RSI: 0000000000000060 RDI: 0000000000000060\n[  325.448120] RBP: ffff881ff2fa7948 R08: ffffffff81cd4f80 R09: 0000000000000000\n[  325.455268] R10: ffff883ff223e400 R11: 0000000000000000 R12: 000000015cba0744\n[  325.462405] R13: ffffffff81cd4f80 R14: ffff883ff223e460 R15: ffff883feea0722c\n[  325.469536] FS:  00007f2ee30fa700(0000) GS:ffff88407fa20000(0000) knlGS:0000000000000000\n[  325.477630] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  325.483380] CR2: ffff8841dc5a074c CR3: 0000003feeae9000 CR4: 00000000001407e0\n[  325.490510] Stack:\n[  325.492524]  ffff883feea0722c ffff883fef719dc0 ffff883feea0722c ffff883ff223e4a0\n[  325.499990]  ffff881ff2fa79a8 ffffffff815424ee ffff883ff223e49c 000000015cba0744\n[  325.507460]  00000000f2fa7978 0000000000000000 ffff881ff2fa79a8 ffff883ff223e4a0\n[  325.514956] Call Trace:\n[  325.517412]  [<ffffffff815424ee>] gen_new_estimator+0x8e/0x230\n[  325.523250]  [<ffffffff815427aa>] gen_replace_estimator+0x4a/0x60\n[  325.529349]  [<ffffffff815718ab>] tc_modify_qdisc+0x52b/0x590\n[  325.535117]  [<ffffffff8155edd0>] rtnetlink_rcv_msg+0xa0/0x240\n[  325.540963]  [<ffffffff8155ed30>] ? __rtnl_unlock+0x20/0x20\n[  325.546532]  [<ffffffff8157f811>] netlink_rcv_skb+0xb1/0xc0\n[  325.552145]  [<ffffffff8155b355>] rtnetlink_rcv+0x25/0x40\n[  325.557558]  [<ffffffff8157f0d8>] netlink_unicast+0x168/0x220\n[  325.563317]  [<ffffffff8157f47c>] netlink_sendmsg+0x2ec/0x3e0\n\nLets play safe and not use an union : percpu 'pointers' are mostly read\nanyway, and we have typically few qdiscs per host.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: John Fastabend <john.fastabend@gmail.com>\nFixes: 22e0f8b9322c (\"net: sched: make bstats per cpu and estimator RCU safe\")\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/a17ad4adfff6ebd29c0f07177b5236c0e7f04ac9"},{"sha":"4e55dad93ed97ddcce8f4517683cf9aafa22337b","author":{"email":"d55521028c14e0f378be5444e4ea388161c0d7e7@redhat.com","name":"Eric Sandeen"},"message":"ext4: ignore journal checksum on remount; don't fail\n\ncommit 2d5b86e048780c5efa7f7d9708815555919e7b05 upstream.\n\nAs of v3.18, ext4 started rejecting a remount which changes the\njournal_checksum option.\n\nPrior to that, it was simply ignored; the problem here is that\nif someone has this in their fstab for the root fs, now the box\nfails to boot properly, because remount of root with the new options\nwill fail, and the box proceeds with a readonly root.\n\nI think it is a little nicer behavior to accept the option, but\nwarn that it's being ignored, rather than failing the mount,\nbut that might be a subjective matter...\n\nReported-by: Cónräd <conradsand.arma@gmail.com>\nSigned-off-by: Eric Sandeen <sandeen@redhat.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nCc: Josh Boyer <jwboyer@fedoraproject.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/4e55dad93ed97ddcce8f4517683cf9aafa22337b"},{"sha":"bdb39ccebcec202fe782292925a1485d8443edca","author":{"email":"b79c083a3c07cc7a5a7055ad6af8240be896cb86@gmail.com","name":"Austin Lund"},"message":"media/rc: Send sync space information on the lirc device\n\ncommit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream.\n\nUserspace expects to see a long space before the first pulse is sent on\nthe lirc device.  Currently, if a long time has passed and a new packet\nis started, the lirc codec just returns and doesn't send anything.  This\nmakes lircd ignore many perfectly valid signals unless they are sent in\nquick sucession.  When a reset event is delivered, we cannot know\nanything about the duration of the space.  But it should be safe to\nassume it has been a long time and we just set the duration to maximum.\n\nSigned-off-by: Austin Lund <austin.lund@gmail.com>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/davet321/rpi-linux/commits/bdb39ccebcec202fe782292925a1485d8443edca"}]}