GitHub PushEvent at 2014-04-05 19:36:49
Repository: kernel-roth
Actor: C457
Payload: {"shas":[["be32427a8f68d25ca0843bd0e194f0c0a6adb0ab","91e38e63b890fbb214c8914809fde03c73e7f24d@linux.intel.com","x86: Fix boot on Twinhead H12Y\n\ncommit 80b3e557371205566a71e569fbfcce5b11f92dbe upstream.\n\nDespite lots of investigation into why this is needed we don't\nknow or have an elegant cure. The only answer found on this\nlaptop is to mark a problem region as used so that Linux doesn't\nput anything there.\n\nCurrently all the users add reserve= command lines and anyone\nnot knowing this needs to find the magic page that documents it.\nAutomate it instead.\n\nSigned-off-by: Alan Cox <alan@linux.intel.com>\nTested-and-bugfixed-by: Arne Fitzenreiter <arne@fitzenreiter.de>\nResolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231\nLink: http://lkml.kernel.org/r/20120515174347.5109.94551.stgit@bluebook\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alan Cox",true],["136b3b49ce7955b44ec54654970f6eb91b5ac224","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","macvtap: zerocopy: fix offset calculation when building skb\n\ncommit 3afc9621f15701c557e60f61eba9242bac2771dd upstream.\n\nThis patch fixes the offset calculation when building skb:\n\n- offset1 were used as skb data offset not vector offset\n- reset offset to zero only when we advance to next vector\n\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nCc: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jason Wang",true],["f9794fcc6d98ce42bea33a51a7278360202f3194","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","macvtap: zerocopy: fix truesize underestimation\n\ncommit 4ef67ebedffa44ed9939b34708ac2fee06d2f65f upstream.\n\nAs the skb fragment were pinned/built from user pages, we should\naccount the page instead of length for truesize.\n\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nCc: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jason Wang",true],["971a864a4413a30d9044308e3fc536611dda6034","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","macvtap: zerocopy: put page when fail to get all requested user pages\n\ncommit 02ce04bb3d28c3333231f43bca677228dbc686fe upstream.\n\nWhen get_user_pages_fast() fails to get all requested pages, we could not use\nkfree_skb() to free it as it has not been put in the skb fragments. So we need\nto call put_page() instead.\n\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nCc: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jason Wang",true],["db52be087a4b3165d62b623b234e242f4d73b058","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully\n\ncommit 01d6657b388438def19c8baaea28e742b6ed32ec upstream.\n\nCurrent the SKBTX_DEV_ZEROCOPY is set unconditionally after\nzerocopy_sg_from_iovec(), this would lead NULL pointer when macvtap\nfails to build zerocopy skb because destructor_arg was not\ninitialized. Solve this by set this flag after the skb were built\nsuccessfully.\n\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nCc: Ben Hutchings <ben@decadent.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jason Wang",true],["996f0dd6f4e09a7efa8451c7ffc2d1274d76da15","e3b68a24fc9500c3d2517c22ec1132efd7c9aba7@canonical.com","Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0\n\ncommit 61c964ba1748e984cb232b431582815899bf10fe upstream.\n\nPatch adds support for BCM20702A0 device id (0a5c:21f4).\n\nusb-devices after patch was applied:\nT: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0\nD: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1\nP: Vendor=0a5c ProdID=21f4 Rev=01.12\nS: Manufacturer=Broadcom Corp\nS: Product=BCM20702A0\nS: SerialNumber=E4D53DF154D6\nC: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA\nI: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb\nI: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb\nI: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)\nI: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)\n\nusb-devices before patch was applied:\nT: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0\nD: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1\nP: Vendor=0a5c ProdID=21f4 Rev=01.12\nS: Manufacturer=Broadcom Corp\nS: Product=BCM20702A0\nS: SerialNumber=E4D53DF154D6\nC: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA\nI: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)\nI: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)\nI: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)\nI: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)\n\nSigned-off-by: Manoj Iyer <manoj.iyer@canonical.com>\nTested-by: Chris Gagnon <chris.gagnon@canonical.com>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Manoj Iyer",true],["3042b1064f90fac38a81f204d92fb7d98bf9f12f","029a69b25713d0799b81c0a39685b4c040fa1425@collabora.co.uk","Bluetooth: Use USB_VENDOR_AND_INTERFACE() for Broadcom devices\n\ncommit 92c385f46b30f4954e9dd2d2005c12d233b479ea upstream.\n\nMany Broadcom devices has a vendor specific devices class, with this rule\nwe match all existent and future controllers with this behavior.\n\nWe also remove old rules to that matches product id for Broadcom devices.\n\nTested-by: John Hommel <john.hommel@hp.com>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Gustavo Padovan",true],["243543e131e8a21515a706a3d0856966ef8c32dd","b7088a9c70345a9ab94cacab3cc3888d0a7dc884@euromail.se","Bluetooth: Add support for Apple vendor-specific devices\n\ncommit 1fa6535faf055cd71311ab887e94fc234f04ee18 upstream.\n\nAs pointed out by Gustavo and Marcel, all Apple-specific Broadcom\ndevices seen so far have the same interface class, subclass and\nprotocol numbers. This patch adds an entry which matches all of them,\nusing the new USB_VENDOR_AND_INTERFACE_INFO() macro.\n\nIn particular, this patch adds support for the MacBook Pro Retina\n(05ac:8286), which is not in the present list.\n\nSigned-off-by: Henrik Rydberg <rydberg@euromail.se>\nTested-by: Shea Levy <shea@shealevy.com>\nAcked-by: Marcel Holtmann <marcel@holtmann.org>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Henrik Rydberg",true],["392d1c750c9f2cfc4a2d7afb1808457f0496a244","282d5d3bbdb7014316a30ab22daf425f10cd096c@openbossa.org","Bluetooth: Fix use-after-free bug in SMP\n\ncommit 61a0cfb008f57ecf7eb28ee762952fb42dc15d15 upstream.\n\nIf SMP fails, we should always cancel security_timer delayed work.\nOtherwise, security_timer function may run after l2cap_conn object\nhas been freed.\n\nThis patch fixes the following warning reported by ODEBUG:\n\nWARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()\nHardware name: Bochs\nODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27\nModules linked in: btusb bluetooth\nPid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4\nCall Trace:\n [<ffffffff81174600>] ? free_obj_work+0x4a/0x7f\n [<ffffffff81023eb8>] warn_slowpath_common+0x7e/0x97\n [<ffffffff81023f65>] warn_slowpath_fmt+0x41/0x43\n [<ffffffff811746b1>] debug_print_object+0x7c/0x8d\n [<ffffffff810394f0>] ? __queue_work+0x241/0x241\n [<ffffffff81174fdd>] debug_check_no_obj_freed+0x92/0x159\n [<ffffffff810ac08e>] slab_free_hook+0x6f/0x77\n [<ffffffffa0019145>] ? l2cap_conn_del+0x148/0x157 [bluetooth]\n [<ffffffff810ae408>] kfree+0x59/0xac\n [<ffffffffa0019145>] l2cap_conn_del+0x148/0x157 [bluetooth]\n [<ffffffffa001b9a2>] l2cap_recv_frame+0xa77/0xfa4 [bluetooth]\n [<ffffffff810592f9>] ? trace_hardirqs_on_caller+0x112/0x1ad\n [<ffffffffa001c86c>] l2cap_recv_acldata+0xe2/0x264 [bluetooth]\n [<ffffffffa0002b2f>] hci_rx_work+0x235/0x33c [bluetooth]\n [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe\n [<ffffffff81038e22>] process_one_work+0x185/0x2fe\n [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe\n [<ffffffff81059f2e>] ? lock_acquired+0x1b5/0x1cf\n [<ffffffffa00028fa>] ? le_scan_work+0x11d/0x11d [bluetooth]\n [<ffffffff81036fb6>] ? spin_lock_irq+0x9/0xb\n [<ffffffff81039209>] worker_thread+0xcf/0x175\n [<ffffffff8103913a>] ? rescuer_thread+0x175/0x175\n [<ffffffff8103cfe0>] kthread+0x95/0x9d\n [<ffffffff812c5054>] kernel_threadi_helper+0x4/0x10\n [<ffffffff812c36b0>] ? retint_restore_args+0x13/0x13\n [<ffffffff8103cf4b>] ? flush_kthread_worker+0xdb/0xdb\n [<ffffffff812c5050>] ? gs_change+0x13/0x13\n\nThis bug can be reproduced using hctool lecc or l2test tools and\nbluetoothd not running.\n\nSigned-off-by: Andre Guedes <andre.guedes@openbossa.org>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Andre Guedes",true],["2d019010038cecab0440f5fe634c95ccdb94cb42","540a5b73c8ed8ee3381dfb54c1949e767fadd754@openbossa.org","Bluetooth: Change signature of smp_conn_security()\n\ncommit cc110922da7e902b62d18641a370fec01a9fa794 upstream.\n\nTo make it clear that it may be called from contexts that may not have\nany knowledge of L2CAP, we change the connection parameter, to receive\na hci_conn.\n\nThis also makes it clear that it is checking the security of the link.\n\nSigned-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Vinicius Costa Gomes",true],["2bc8c09f7f511b0119a81f4258a5fa042025c524","540a5b73c8ed8ee3381dfb54c1949e767fadd754@openbossa.org","Bluetooth: Fix sending a HCI Authorization Request over LE links\n\ncommit d8343f125710fb596f7a88cd756679f14f4e77b9 upstream.\n\nIn the case that the link is already in the connected state and a\nPairing request arrives from the mgmt interface, hci_conn_security()\nwould be called but it was not considering LE links.\n\nReported-by: João Paulo Rechi Vita <jprvita@openbossa.org>\nSigned-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>\nSigned-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Vinicius Costa Gomes",true],["e9fab2bf7b54a5739886b3ffe806d80fcf4c7f0b","54e60e0b3ed6972c60d10aba14475cde8644c703@intel.com","net: Statically initialize init_net.dev_base_head\n\ncommit 734b65417b24d6eea3e3d7457e1f11493890ee1d upstream.\n\nThis change eliminates an initialization-order hazard most\nrecently seen when netprio_cgroup is built into the kernel.\n\nWith thanks to Eric Dumazet for catching a bug.\n\nSigned-off-by: Mark Rustad <mark.d.rustad@intel.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>","Rustad, Mark D",true],["eea8e7cbf6c56d8c7eb88fee38d4bc0f2ed291a6","057714f5d85e38d86c9180c386346d25104e71f6@gmail.com","media: cx25821: Remove bad strcpy to read-only char*\n\ncommit c854d8883fec59332f0662917f8c94dcfb1c405d upstream.\n\nThe strcpy was being used to set the name of the board.\nThis was both wrong and redundant,\nsince the destination char* was read-only and\nthe name is set statically at compile time.\n\nThe type of the name field is changed to const char*\nto prevent future errors.\n\nReported-by: Radek Masin <radek@masin.eu>\nSigned-off-by: Ezequiel Garcia <elezegarcia@gmail.com>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Ezequiel Garcia",true],["29483bce87b8833c51132103ffea0716913668d6","22bc8bfd7eeb9886fe79aed380759aa078990d01@linux.vnet.ibm.com","Fix a dead loop in async_synchronize_full()\n\n[Fixed upstream by commits 2955b47d2c1983998a8c5915cb96884e67f7cb53 and\na4683487f90bfe3049686fc5c566bdc1ad03ace6 from Dan Williams, but they are much\nmore intrusive than this tiny fix, according to Andrew - gregkh]\n\nThis patch tries to fix a dead loop in  async_synchronize_full(), which\ncould be seen when preemption is disabled on a single cpu machine.\n\nvoid async_synchronize_full(void)\n{\n        do {\n                async_synchronize_cookie(next_cookie);\n        } while (!list_empty(&async_running) || !\nlist_empty(&async_pending));\n}\n\nasync_synchronize_cookie() calls async_synchronize_cookie_domain() with\n&async_running as the default domain to synchronize.\n\nHowever, there might be some works in the async_pending list from other\ndomains. On a single cpu system, without preemption, there is no chance\nfor the other works to finish, so async_synchronize_full() enters a dead\nloop.\n\nIt seems async_synchronize_full() wants to synchronize all entries in\nall running lists(domains), so maybe we could just check the entry_count\nto know whether all works are finished.\n\nCurrently, async_synchronize_cookie_domain() expects a non-NULL running\nlist ( if NULL, there would be NULL pointer dereference ), so maybe a\nNULL pointer could be used as an indication for the functions to\nsynchronize all works in all domains.\n\nReported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nSigned-off-by: Li Zhong <zhong@linux.vnet.ibm.com>\nTested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nTested-by: Christian Kujau <lists@nerdbynature.de>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Dan Williams <dan.j.williams@gmail.com>\nCc: Christian Kujau <lists@nerdbynature.de>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Cong Wang <xiyou.wangcong@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Li Zhong",true],["c537e751fe11cd02b1493ec962fec3c9af7825cd","afc9ae3e3b2239e3d07b44c03c06cff5572ba0cf@redhat.com","rds: set correct msg_namelen\n\ncommit 06b6a1cf6e776426766298d055bb3991957d90a7 upstream.\n\nJay Fenlason (fenlason@redhat.com) found a bug,\nthat recvfrom() on an RDS socket can return the contents of random kernel\nmemory to userspace if it was called with a address length larger than\nsizeof(struct sockaddr_in).\nrds_recvmsg() also fails to set the addr_len paramater properly before\nreturning, but that's just a bug.\nThere are also a number of cases wher recvfrom() can return an entirely bogus\naddress. Anything in rds_recvmsg() that returns a non-negative value but does\nnot go through the \"sin = (struct sockaddr_in *)msg->msg_name;\" code path\nat the end of the while(1) loop will return up to 128 bytes of kernel memory\nto userspace.\n\nAnd I write two test programs to reproduce this bug, you will see that in\nrds_server, fromAddr will be overwritten and the following sock_fd will be\ndestroyed.\nYes, it is the programmer's fault to set msg_namelen incorrectly, but it is\nbetter to make the kernel copy the real length of address to user space in\nsuch case.\n\nHow to run the test programs ?\nI test them on 32bit x86 system, 3.5.0-rc7.\n\n1 compile\ngcc -o rds_client rds_client.c\ngcc -o rds_server rds_server.c\n\n2 run ./rds_server on one console\n\n3 run ./rds_client on another console\n\n4 you will see something like:\nserver is waiting to receive data...\nold socket fd=3\nserver received data from client:data from client\nmsg.msg_namelen=32\nnew socket fd=-1067277685\nsendmsg()\n: Bad file descriptor\n\n/***************** rds_client.c ********************/\n\nint main(void)\n{\n\tint sock_fd;\n\tstruct sockaddr_in serverAddr;\n\tstruct sockaddr_in toAddr;\n\tchar recvBuffer[128] = \"data from client\";\n\tstruct msghdr msg;\n\tstruct iovec iov;\n\n\tsock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);\n\tif (sock_fd < 0) {\n\t\tperror(\"create socket error\\n\");\n\t\texit(1);\n\t}\n\n\tmemset(&serverAddr, 0, sizeof(serverAddr));\n\tserverAddr.sin_family = AF_INET;\n\tserverAddr.sin_addr.s_addr = inet_addr(\"127.0.0.1\");\n\tserverAddr.sin_port = htons(4001);\n\n\tif (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {\n\t\tperror(\"bind() error\\n\");\n\t\tclose(sock_fd);\n\t\texit(1);\n\t}\n\n\tmemset(&toAddr, 0, sizeof(toAddr));\n\ttoAddr.sin_family = AF_INET;\n\ttoAddr.sin_addr.s_addr = inet_addr(\"127.0.0.1\");\n\ttoAddr.sin_port = htons(4000);\n\tmsg.msg_name = &toAddr;\n\tmsg.msg_namelen = sizeof(toAddr);\n\tmsg.msg_iov = &iov;\n\tmsg.msg_iovlen = 1;\n\tmsg.msg_iov->iov_base = recvBuffer;\n\tmsg.msg_iov->iov_len = strlen(recvBuffer) + 1;\n\tmsg.msg_control = 0;\n\tmsg.msg_controllen = 0;\n\tmsg.msg_flags = 0;\n\n\tif (sendmsg(sock_fd, &msg, 0) == -1) {\n\t\tperror(\"sendto() error\\n\");\n\t\tclose(sock_fd);\n\t\texit(1);\n\t}\n\n\tprintf(\"client send data:%s\\n\", recvBuffer);\n\n\tmemset(recvBuffer, '\\0', 128);\n\n\tmsg.msg_name = &toAddr;\n\tmsg.msg_namelen = sizeof(toAddr);\n\tmsg.msg_iov = &iov;\n\tmsg.msg_iovlen = 1;\n\tmsg.msg_iov->iov_base = recvBuffer;\n\tmsg.msg_iov->iov_len = 128;\n\tmsg.msg_control = 0;\n\tmsg.msg_controllen = 0;\n\tmsg.msg_flags = 0;\n\tif (recvmsg(sock_fd, &msg, 0) == -1) {\n\t\tperror(\"recvmsg() error\\n\");\n\t\tclose(sock_fd);\n\t\texit(1);\n\t}\n\n\tprintf(\"receive data from server:%s\\n\", recvBuffer);\n\n\tclose(sock_fd);\n\n\treturn 0;\n}\n\n/***************** rds_server.c ********************/\n\nint main(void)\n{\n\tstruct sockaddr_in fromAddr;\n\tint sock_fd;\n\tstruct sockaddr_in serverAddr;\n\tunsigned int addrLen;\n\tchar recvBuffer[128];\n\tstruct msghdr msg;\n\tstruct iovec iov;\n\n\tsock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);\n\tif(sock_fd < 0) {\n\t\tperror(\"create socket error\\n\");\n\t\texit(0);\n\t}\n\n\tmemset(&serverAddr, 0, sizeof(serverAddr));\n\tserverAddr.sin_family = AF_INET;\n\tserverAddr.sin_addr.s_addr = inet_addr(\"127.0.0.1\");\n\tserverAddr.sin_port = htons(4000);\n\tif (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {\n\t\tperror(\"bind error\\n\");\n\t\tclose(sock_fd);\n\t\texit(1);\n\t}\n\n\tprintf(\"server is waiting to receive data...\\n\");\n\tmsg.msg_name = &fromAddr;\n\n\t/*\n\t * I add 16 to sizeof(fromAddr), ie 32,\n\t * and pay attention to the definition of fromAddr,\n\t * recvmsg() will overwrite sock_fd,\n\t * since kernel will copy 32 bytes to userspace.\n\t *\n\t * If you just use sizeof(fromAddr), it works fine.\n\t * */\n\tmsg.msg_namelen = sizeof(fromAddr) + 16;\n\t/* msg.msg_namelen = sizeof(fromAddr); */\n\tmsg.msg_iov = &iov;\n\tmsg.msg_iovlen = 1;\n\tmsg.msg_iov->iov_base = recvBuffer;\n\tmsg.msg_iov->iov_len = 128;\n\tmsg.msg_control = 0;\n\tmsg.msg_controllen = 0;\n\tmsg.msg_flags = 0;\n\n\twhile (1) {\n\t\tprintf(\"old socket fd=%d\\n\", sock_fd);\n\t\tif (recvmsg(sock_fd, &msg, 0) == -1) {\n\t\t\tperror(\"recvmsg() error\\n\");\n\t\t\tclose(sock_fd);\n\t\t\texit(1);\n\t\t}\n\t\tprintf(\"server received data from client:%s\\n\", recvBuffer);\n\t\tprintf(\"msg.msg_namelen=%d\\n\", msg.msg_namelen);\n\t\tprintf(\"new socket fd=%d\\n\", sock_fd);\n\t\tstrcat(recvBuffer, \"--data from server\");\n\t\tif (sendmsg(sock_fd, &msg, 0) == -1) {\n\t\t\tperror(\"sendmsg()\\n\");\n\t\t\tclose(sock_fd);\n\t\t\texit(1);\n\t\t}\n\t}\n\n\tclose(sock_fd);\n\treturn 0;\n}\n\nSigned-off-by: Weiping Pan <wpan@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Weiping Pan",true],["431f2fdd0e6bef280e7f5602ac7c31aa85aae51d","3d0f3b9ddcacec30c4008c5e030e6c13a478cb4f@quora.org","libata: Prevent interface errors with Seagate FreeAgent GoFlex\n\ncommit c531077f40abc9f2129c4c83a30b3f8d6ce1c0e7 upstream.\n\nWhen using my Seagate FreeAgent GoFlex eSATAp external disk enclosure,\ninterface errors are always seen until 1.5Gbps is negotiated [1]. This\noccurs using any disk in the enclosure, and when the disk is connected\ndirectly with a generic passive eSATAp cable, we see stable 3Gbps\noperation as expected.\n\nBlacklist 3Gbps mode to avoid dataloss and the ~30s delay bus reset\nand renegotiation incurs.\n\nSigned-off-by: Daniel J Blueman <daniel@quora.org>\nSigned-off-by: Jeff Garzik <jgarzik@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Daniel J Blueman",true],["459737614cecbb28f74c0701512d472240dd08af","b6456b24ae82a7595be3173ae585c7a827f25f37@fr.zoreil.com","r8169: RxConfig hack for the 8168evl.\n\ncommit eb2dc35d99028b698cdedba4f5522bc43e576bd2 upstream.\n\nThe 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards\nare very prone to NETDEV watchdog problems without this change. See\nhttps://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.\n\nI don't know why it *works*. It's depressingly effective though.\n\nFor the record:\n- the problem may go along IOMMU (AMD-Vi) errors but it really looks\n  like a red herring.\n- the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,\n  the chipset now fetches several Rx descriptors at a time.\n- long ago the driver ignored the RX_MULTI_EN bit.\n  e542a2269f232d61270ceddd42b73a4348dee2bb changed the RxConfig\n  settings. Whatever the problem it's now labeled a regression.\n- Realtek's own driver can identify two different 8168evl devices\n  (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only\n  sees one. It sucks.\n\nSigned-off-by: Francois Romieu <romieu@fr.zoreil.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Francois Romieu",true],["9af41d2f22f395b0715470c1887cbbb432540f37","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","sched: Fix race in task_group()\n\ncommit 8323f26ce3425460769605a6aece7a174edaa7d1 upstream.\n\nStefan reported a crash on a kernel before a3e5d1091c1 (\"sched:\nDon't call task_group() too many times in set_task_rq()\"), he\nfound the reason to be that the multiple task_group()\ninvocations in set_task_rq() returned different values.\n\nLooking at all that I found a lack of serialization and plain\nwrong comments.\n\nThe below tries to fix it using an extra pointer which is\nupdated under the appropriate scheduler locks. Its not pretty,\nbut I can't really see another way given how all the cgroup\nstuff works.\n\nReported-and-tested-by: Stefan Bader <stefan.bader@canonical.com>\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Peter Zijlstra",true],["6d17b9fd4b5f153c84f227372959d1e154adf039","0674548f4d596393408a51d6287a76ebba2f42aa@kernel.org","mm: sparse: fix usemap allocation above node descriptor section\n\ncommit 99ab7b19440a72ebdf225f99b20f8ef40decee86 upstream.\n\nAfter commit f5bf18fa22f8 (\"bootmem/sparsemem: remove limit constraint\nin alloc_bootmem_section\"), usemap allocations may easily be placed\noutside the optimal section that holds the node descriptor, even if\nthere is space available in that section.  This results in unnecessary\nhotplug dependencies that need to have the node unplugged before the\nsection holding the usemap.\n\nThe reason is that the bootmem allocator doesn't guarantee a linear\nsearch starting from the passed allocation goal but may start out at a\nmuch higher address absent an upper limit.\n\nFix this by trying the allocation with the limit at the section end,\nthen retry without if that fails.  This keeps the fix from f5bf18fa22f8\nof not panicking if the allocation does not fit in the section, but\nstill makes sure to try to stay within the section at first.\n\n[rewritten massively by Johannes to apply to 3.4]\n\nSigned-off-by: Yinghai Lu <yinghai@kernel.org>\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Yinghai Lu",true],["0311bd47fa0b36f9a0029a24dc604babeaa8d278","14059c7158912dcae849c377925c87d46da48cdf@redhat.com","media: lirc_sir: make device registration work\n\ncommit 4b71ca6bce8fab3d08c61bf330e781f957934ae1 upstream.\n\nFor one, the driver device pointer needs to be filled in, or the lirc core\nwill refuse to load the driver. And we really need to wire up all the\nplatform_device bits. This has been tested via the lirc sourceforge tree\nand verified to work, been sitting there for months, finally getting\naround to sending it. :\\\n\nSigned-off-by: Jarod Wilson <jarod@redhat.com>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>\nCC: Josh Boyer <jwboyer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jarod Wilson",true]],"size":52,"ref":"refs/heads/3.4+","head":"f2cbeff291d07c8a9bc25d1572bd55e39b2a6449"}