GitHub PushEvent at 2014-09-06 08:15:30
Repository: hammerhead_kernel_caf_kk-3.5
Actor: neobuddy89
Payload: {"shas":[["0fabacf3d360607c0c7abeaf3c8fe4d4552f3f4a","331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","ipv6: don't count addrconf generated routes against gc limit\n\n[ Upstream commit a3300ef4bbb1f1e33ff0400e1e6cf7733d988f4f ]\n\nBrett Ciphery reported that new ipv6 addresses failed to get installed\nbecause the addrconf generated dsts where counted against the dst gc\nlimit. We don't need to count those routes like we currently don't count\nadministratively added routes.\n\nBecause the max_addresses check enforces a limit on unbounded address\ngeneration first in case someone plays with router advertisments, we\nare still safe here.\n\nReported-by: Brett Ciphery <brett.ciphery@windriver.com>\nSigned-off-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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Hannes Frederic Sowa",true],["4371fe52821b5b3e0795518a76f7db412e52292a","4452d71687b6bc2c9389c3349fdc17fbd73b833b@queasysnail.net","ipv6: don't set DST_NOCOUNT for remotely added routes\n\n[ Upstream commit c88507fbad8055297c1d1e21e599f46960cbee39 ]\n\nDST_NOCOUNT should only be used if an authorized user adds routes\nlocally. In case of routes which are added on behalf of router\nadvertisments this flag must not get used as it allows an unlimited\nnumber of routes getting added remotely.\n\nSigned-off-by: Sabrina Dubroca <sd@queasysnail.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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Sabrina Dubroca",true],["52c6dfac11179721b51d42ca0832d1258231221a","c27397faeb49941073a0419e32b7b49a98edf1a9@web.de","ipv6: Avoid unnecessary temporary addresses being generated\n\n[ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]\n\ntmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore\nage needs to be added to the condition.\n\nAge calculation in ipv6_create_tempaddr is different from the one\nin addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.\nThis can cause age in ipv6_create_tempaddr to be less than the one\nin addrconf_verify and therefore unnecessary temporary address to\nbe generated.\nUse age calculation as in addrconf_modify to avoid this.\n\nSigned-off-by: Heiner Kallweit <heiner.kallweit@web.de>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Heiner Kallweit",true],["3d58382c49d0b4f1cf367349bc96dc1dbd62d670","ed9bd6f22d2a1e0b1507d3ddc300dc248265d19a@gmail.com","ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly\n\n[ Upstream commit e367c2d03dba4c9bcafad24688fadb79dd95b218 ]\n\nIn ip6_append_data_mtu(), when the xfrm mode is not tunnel(such as\ntransport),the ipsec header need to be added in the first fragment, so the mtu\nwill decrease to reserve space for it, then the second fragment come, the mtu\nshould be turn back, as the commit 0c1833797a5a6ec23ea9261d979aa18078720b74\nsaid.  however, in the commit a493e60ac4bbe2e977e7129d6d8cbb0dd236be, it use\n*mtu = min(*mtu, ...) to change the mtu, which lead to the new mtu is alway\nequal with the first fragment's. and cannot turn back.\n\nwhen I test through  ping6 -c1 -s5000 $ip (mtu=1280):\n...frag (0|1232) ESP(spi=0x00002000,seq=0xb), length 1232\n...frag (1232|1216)\n...frag (2448|1216)\n...frag (3664|1216)\n...frag (4880|164)\n\nwhich should be:\n...frag (0|1232) ESP(spi=0x00001000,seq=0x1), length 1232\n...frag (1232|1232)\n...frag (2464|1232)\n...frag (3696|1232)\n...frag (4928|116)\n\nso delete the min() when change back the mtu.\n\nSigned-off-by: Xin Long <lucien.xin@gmail.com>\nFixes: 75a493e60ac4bb (\"ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size\")\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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","lucien",true],["4acb010098aa0c4a5de6a175a5ab04835f2151a3","331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","ipv6: some ipv6 statistic counters failed to disable bh\n\n[ Upstream commit 43a43b6040165f7b40b5b489fe61a4cb7f8c4980 ]\n\nAfter commit c15b1ccadb323ea (\"ipv6: move DAD and addrconf_verify\nprocessing to workqueue\") some counters are now updated in process context\nand thus need to disable bh before doing so, otherwise deadlocks can\nhappen on 32-bit archs. Fabio Estevam noticed this while while mounting\na NFS volume on an ARM board.\n\nAs a compensation for missing this I looked after the other *_STATS_BH\nand found three other calls which need updating:\n\n1) icmp6_send: ip6_fragment -> icmpv6_send -> icmp6_send (error handling)\n2) ip6_push_pending_frames: rawv6_sendmsg -> rawv6_push_pending_frames -> ...\n   (only in case of icmp protocol with raw sockets in error handling)\n3) ping6_v6_sendmsg (error handling)\n\nFixes: c15b1ccadb323ea (\"ipv6: move DAD and addrconf_verify processing to workqueue\")\nReported-by: Fabio Estevam <festevam@gmail.com>\nTested-by: Fabio Estevam <fabio.estevam@freescale.com>\nCc: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Hannes Frederic Sowa",true],["47d410709880550ae4f6faade717558082a0fae7","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","ipv6: Limit mtu to 65575 bytes\n\n[ Upstream commit 30f78d8ebf7f514801e71b88a10c948275168518 ]\n\nFrancois reported that setting big mtu on loopback device could prevent\ntcp sessions making progress.\n\nWe do not support (yet ?) IPv6 Jumbograms and cook corrupted packets.\n\nWe must limit the IPv6 MTU to (65535 + 40) bytes in theory.\n\nTested:\n\nifconfig lo mtu 70000\nnetperf -H ::1\n\nBefore patch : Throughput :   0.05 Mbits\n\nAfter patch : Throughput : 35484 Mbits\n\nReported-by: Francois WELLENREITER <f.wellenreiter@gmail.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>\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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric Dumazet",true],["fc67e85e837d8deeb549aa2d65dd15eba5206a42","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","net: fix inet_getid() and ipv6_select_ident() bugs\n\n[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]\n\nI noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery\nis disabled.\nNote how GSO/TSO packets do not have monotonically incrementing ID.\n\n06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)\n06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)\n06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)\n06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)\n06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)\n\nIt appears I introduced this bug in linux-3.1.\n\ninet_getid() must return the old value of peer->ip_id_count,\nnot the new one.\n\nLets revert this part, and remove the prevention of\na null identification field in IPv6 Fragment Extension Header,\nwhich is dubious and not even done properly.\n\nFixes: 87c48fa3b463 (\"ipv6: make fragment identifications less predictable\")\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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric Dumazet",true],["96434d0971d45ccc6e6549de21ca4514530f5ba5","7e9c653c8ec3abfdd967a0616fd143ca77e7b405@cn.fujitsu.com","ipv6: reallocate addrconf router for ipv6 address when lo device up\n\ncommit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.\n\ncommit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f\n\"net IPv6 : Fix broken IPv6 routing table after loopback down-up\"\nallocates addrconf router for ipv6 address when lo device up.\nbut commit a881ae1f625c599b460cc8f8a7fcb1c438f699ad\n\"ipv6:don't call addrconf_dst_alloc again when enable lo\" breaks\nthis behavior.\n\nSince the addrconf router is moved to the garbage list when\nlo device down, we should release this router and rellocate\na new one for ipv6 address when lo device up.\n\nThis patch solves bug 67951 on bugzilla\nhttps://bugzilla.kernel.org/show_bug.cgi?id=67951\n\nchange from v1:\nuse ip6_rt_put to repleace ip6_del_rt, thanks Hannes!\nchange code style, suggested by Sergei.\n\nCC: Sabrina Dubroca <sd@queasysnail.net>\nCC: Hannes Frederic Sowa <hannes@stressinduktion.org>\nReported-by: Weilong Chen <chenweilong@huawei.com>\nSigned-off-by: Weilong Chen <chenweilong@huawei.com>\nSigned-off-by: Gao feng <gaofeng@cn.fujitsu.com>\nAcked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\n[weilong: s/ip6_rt_put/dst_release]\nSigned-off-by: Chen Weilong <chenweilong@huawei.com>\nSigned-off-by: Li Zefan <lizefan@huawei.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Gao feng",true],["f3688f0cf4fdc2499f66dc8f986906ae2dbf23f9","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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric Dumazet",true],["47d0e6bd51f3886e845e65d9e1230a8ffc3e8971","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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric Dumazet",true],["eddcdf2aa07933e4e5a6f2b12ba60c4c8014db1b","331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@stressinduktion.org","net: rework recvmsg handler msg_name and msg_namelen logic\n\n[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]\n\nThis patch now always passes msg->msg_namelen as 0. recvmsg handlers must\nset msg_namelen to the proper size <= sizeof(struct sockaddr_storage)\nto return msg_name to the user.\n\nThis prevents numerous uninitialized memory leaks we had in the\nrecvmsg handlers and makes it harder for new code to accidentally leak\nuninitialized memory.\n\nOptimize for the case recvfrom is called with NULL as address. We don't\nneed to copy the address at all, so set it to NULL before invoking the\nrecvmsg handler. We can do so, because all the recvmsg handlers must\ncope with the case a plain read() is called on them. read() also sets\nmsg_name to NULL.\n\nAlso document these changes in include/linux/net.h as suggested by David\nMiller.\n\nChanges since RFC:\n\nSet msg->msg_name = NULL if user specified a NULL in msg_name but had a\nnon-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't\naffect sendto as it would bail out earlier while trying to copy-in the\naddress. It also more naturally reflects the logic by the callers of\nverify_iovec.\n\nWith this change in place I could remove \"\nif (!uaddr || msg_sys->msg_namelen == 0)\n\tmsg->msg_name = NULL\n\".\n\nThis change does not alter the user visible error logic as we ignore\nmsg_namelen as long as msg_name is NULL.\n\nAlso remove two unnecessary curly brackets in ___sys_recvmsg and change\ncomments to netdev style.\n\nCc: David Miller <davem@davemloft.net>\nSuggested-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-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>\n[neo: only reqd part]\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Hannes Frederic Sowa",true],["a1df50e6c8a88405d3a64d2f6b6e60e4c297cc05","64568d9183dcfcdd0a6fb47964820a1cdaf94ecc@googlemail.com","unix_diag: fix info leak\n\n[ Upstream commit 6865d1e834be84ddd5808d93d5035b492346c64a ]\n\nWhen filling the netlink message we miss to wipe the pad field,\ntherefore leak one byte of heap memory to userland. Fix this by\nsetting pad to 0.\n\nSigned-off-by: Mathias Krause <minipli@googlemail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Mathias Krause",true],["c78300e14215684648ed99f9fbf7cada24a063bc","8a741aa8cbd77ebc4a56ddb528ce9fd15d42f034@xmission.com","af_unix: If we don't care about credentials coallesce all messages\n\n[ Upstream commit 0e82e7f6dfeec1013339612f74abc2cdd29d43d2 ]\n\nIt was reported that the following LSB test case failed\nhttps://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we\nwere not coallescing unix stream messages when the application was\nexpecting us to.\n\nThe problem was that the first send was before the socket was accepted\nand thus sock->sk_socket was NULL in maybe_add_creds, and the second\nsend after the socket was accepted had a non-NULL value for sk->socket\nand thus we could tell the credentials were not needed so we did not\nbother.\n\nThe unnecessary credentials on the first message cause\nunix_stream_recvmsg to start verifying that all messages had the same\ncredentials before coallescing and then the coallescing failed because\nthe second message had no credentials.\n\nIgnoring credentials when we don't care in unix_stream_recvmsg fixes a\nlong standing pessimization which would fail to coallesce messages when\nreading from a unix stream socket if the senders were different even if\nwe did not care about their credentials.\n\nI have tested this and verified that the in the LSB test case mentioned\nabove that the messages do coallesce now, while the were failing to\ncoallesce without this change.\n\nReported-by: Karel Srot <ksrot@redhat.com>\nReported-by: Ding Tianhong <dingtianhong@huawei.com>\nSigned-off-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric W. Biederman",true],["ec36c3ddcab8a9b4f3cdff1742880f288052ff8e","9ff04a02a69f376b2b9aeec27187017cbf3cf5f9@redhat.com","net: unix: inherit SOCK_PASS{CRED, SEC} flags from socket to fix race\n\n[ Upstream commit 90c6bd34f884cd9cee21f1d152baf6c18bcac949 ]\n\nIn the case of credentials passing in unix stream sockets (dgram\nsockets seem not affected), we get a rather sparse race after\ncommit 16e5726 (\"af_unix: dont send SCM_CREDENTIALS by default\").\n\nWe have a stream server on receiver side that requests credential\npassing from senders (e.g. nc -U). Since we need to set SO_PASSCRED\non each spawned/accepted socket on server side to 1 first (as it's\nnot inherited), it can happen that in the time between accept() and\nsetsockopt() we get interrupted, the sender is being scheduled and\ncontinues with passing data to our receiver. At that time SO_PASSCRED\nis neither set on sender nor receiver side, hence in cmsg's\nSCM_CREDENTIALS we get eventually pid:0, uid:65534, gid:65534\n(== overflow{u,g}id) instead of what we actually would like to see.\n\nOn the sender side, here nc -U, the tests in maybe_add_creds()\ninvoked through unix_stream_sendmsg() would fail, as at that exact\ntime, as mentioned, the sender has neither SO_PASSCRED on his side\nnor sees it on the server side, and we have a valid 'other' socket\nin place. Thus, sender believes it would just look like a normal\nconnection, not needing/requesting SO_PASSCRED at that time.\n\nAs reverting 16e5726 would not be an option due to the significant\nperformance regression reported when having creds always passed,\none way/trade-off to prevent that would be to set SO_PASSCRED on\nthe listener socket and allow inheriting these flags to the spawned\nsocket on server side in accept(). It seems also logical to do so\nif we'd tell the listener socket to pass those flags onwards, and\nwould fix the race.\n\nBefore, strace:\n\nrecvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{\"blub\\n\", 4096}],\n        msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,\n        cmsg_type=SCM_CREDENTIALS{pid=0, uid=65534, gid=65534}},\n        msg_flags=0}, 0) = 5\n\nAfter, strace:\n\nrecvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{\"blub\\n\", 4096}],\n        msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,\n        cmsg_type=SCM_CREDENTIALS{pid=11580, uid=1000, gid=1000}},\n        msg_flags=0}, 0) = 5\n\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nCc: Eric Dumazet <edumazet@google.com>\nCc: Eric W. Biederman <ebiederm@xmission.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Daniel Borkmann",true],["20933027285574d55e177d51442514c7d56580bc","e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","net: unix: allow bind to fail on mutex lock\n\n[ Upstream commit 37ab4fa7844a044dc21fde45e2a0fc2f3c3b6490 ]\n\nThis is similar to the set_peek_off patch where calling bind while the\nsocket is stuck in unix_dgram_recvmsg() will block and cause a hung task\nspew after a while.\n\nThis is also the last place that did a straightforward mutex_lock(), so\nthere shouldn't be any more of these patches.\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>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Sasha Levin",true],["ed3841a5cb6093f7d1290d5073aa932e928f9719","312c7d941f03386814be517ffdb3e0eb6624e275@google.com","net: unix: non blocking recvmsg() should not return -EINTR\n\n[ Upstream commit de1443916791d75fdd26becb116898277bb0273f ]\n\nSome applications didn't expect recvmsg() on a non blocking socket\ncould return -EINTR. This possibility was added as a side effect\nof commit b3ca9b02b00704 (\"net: fix multithreaded signal handling in\nunix recv routines\").\n\nTo hit this bug, you need to be a bit unlucky, as the u->readlock\nmutex is usually held for very small periods.\n\nFixes: b3ca9b02b00704 (\"net: fix multithreaded signal handling in unix recv routines\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Rainer Weikusat <rweikusat@mobileactivedefense.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eric Dumazet",true],["692b25b6cf7f7c87d0329dffc5b0a5935d8d490e","bff32994ff0f8d048f262a8388145a71b6071bfe@intel.com","wireless: allow 40 MHz on world roaming channels 12/13\n\ncommit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream.\n\nWhen in world roaming mode, allow 40 MHz to be used\non channels 12 and 13 so that an AP that is, e.g.,\nusing HT40+ on channel 9 (in the UK) can be used.\n\nReported-by: Eddie Chapman <eddie@ehuk.net>\nTested-by: Eddie Chapman <eddie@ehuk.net>\nAcked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Johannes Berg",true],["665888ed7fd17001a016dc3ad577d8f0235b73cc","bff32994ff0f8d048f262a8388145a71b6071bfe@intel.com","cfg80211: fix interface combinations check\n\ncommit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.\n\nIf a given interface combination doesn't contain\na required interface type then we missed checking\nthat and erroneously allowed it even though iface\ntype wasn't there at all. Add a check that makes\nsure that all interface types are accounted for.\n\nReported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Johannes Berg",true],["b0b39b6f59087b48dcb0cb050143df090d3271af","fdf5551f20996bc0613832b4b54eb06eecaffd38@wizery.com","cfg80211: fix potential deadlock in regulatory\n\ncommit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.\n\nreg_timeout_work() calls restore_regulatory_settings() which\ntakes cfg80211_mutex.\n\nreg_set_request_processed() already holds cfg80211_mutex\nbefore calling cancel_delayed_work_sync(reg_timeout),\nso it might deadlock.\n\nCall the async cancel_delayed_work instead, in order\nto avoid the potential deadlock.\n\nThis is the relevant lockdep warning:\n\ncfg80211: Calling CRDA for country: XX\n\n======================================================\n[ INFO: possible circular locking dependency detected ]\n3.4.0-rc5-wl+ #26 Not tainted\n-------------------------------------------------------\nkworker/0:2/1391 is trying to acquire lock:\n (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]\n\nbut task is already holding lock:\n ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #2 ((reg_timeout).work){+.+...}:\n       [<c008fd44>] validate_chain+0xb94/0x10f0\n       [<c0090b68>] __lock_acquire+0x8c8/0x9b0\n       [<c0090d40>] lock_acquire+0xf0/0x114\n       [<c005b600>] wait_on_work+0x4c/0x154\n       [<c005c000>] __cancel_work_timer+0xd4/0x11c\n       [<c005c064>] cancel_delayed_work_sync+0x1c/0x20\n       [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]\n       [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]\n       [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]\n       [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8\n       [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0\n       [<c03c7584>] genl_rcv+0x28/0x34\n       [<c03c6720>] netlink_unicast+0x15c/0x228\n       [<c03c6c7c>] netlink_sendmsg+0x218/0x298\n       [<c03933c8>] sock_sendmsg+0xa4/0xc0\n       [<c039406c>] __sys_sendmsg+0x1e4/0x268\n       [<c0394228>] sys_sendmsg+0x4c/0x70\n       [<c0013840>] ret_fast_syscall+0x0/0x3c\n\n-> #1 (reg_mutex){+.+.+.}:\n       [<c008fd44>] validate_chain+0xb94/0x10f0\n       [<c0090b68>] __lock_acquire+0x8c8/0x9b0\n       [<c0090d40>] lock_acquire+0xf0/0x114\n       [<c04734dc>] mutex_lock_nested+0x48/0x320\n       [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]\n       [<c0059f44>] process_one_work+0x2a0/0x480\n       [<c005a4b4>] worker_thread+0x1bc/0x2bc\n       [<c0061148>] kthread+0x98/0xa4\n       [<c0014af4>] kernel_thread_exit+0x0/0x8\n\n-> #0 (cfg80211_mutex){+.+.+.}:\n       [<c008ed58>] print_circular_bug+0x68/0x2cc\n       [<c008fb28>] validate_chain+0x978/0x10f0\n       [<c0090b68>] __lock_acquire+0x8c8/0x9b0\n       [<c0090d40>] lock_acquire+0xf0/0x114\n       [<c04734dc>] mutex_lock_nested+0x48/0x320\n       [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]\n       [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]\n       [<c0059f44>] process_one_work+0x2a0/0x480\n       [<c005a4b4>] worker_thread+0x1bc/0x2bc\n       [<c0061148>] kthread+0x98/0xa4\n       [<c0014af4>] kernel_thread_exit+0x0/0x8\n\nother info that might help us debug this:\n\nChain exists of:\n  cfg80211_mutex --> reg_mutex --> (reg_timeout).work\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock((reg_timeout).work);\n                               lock(reg_mutex);\n                               lock((reg_timeout).work);\n  lock(cfg80211_mutex);\n\n *** DEADLOCK ***\n\n2 locks held by kworker/0:2/1391:\n #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480\n #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480\n\nstack backtrace:\n[<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)\n[<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)\n[<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)\n[<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)\n[<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)\n[<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)\n[<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])\n[<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])\n[<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)\n[<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)\n[<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)\n[<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)\ncfg80211: Calling CRDA to update world regulatory domain\ncfg80211: World regulatory domain updated:\ncfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)\ncfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)\ncfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)\ncfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)\ncfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)\ncfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)\n\nSigned-off-by: Eliad Peller <eliad@wizery.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Eliad Peller",true],["8791df35a43671d947da63e80027dc896021fbb9","956a8aa249cc11dbf2733fc41294eabd5c99981c@tieto.com","cfg80211: check iface combinations only when iface is running\n\ncommit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.\n\nDon't validate interface combinations on a stopped\ninterface. Otherwise we might end up being able to\ncreate a new interface with a certain type, but\nwon't be able to change an existing interface\ninto that type.\n\nThis also skips some other functions when\ninterface is stopped and changing interface type.\n\nSigned-off-by: Michal Kazior <michal.kazior@tieto.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\n[Fixes regression introduced by cherry pick of 463454b5dbd8]\nSigned-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","Michal Kazior",true]],"size":28,"ref":"refs/heads/kitkat-caf-net","head":"268341bc2d332361bb2a0df8ea1e8aba0eba0168"}