{"push_id":2424055645,"size":67,"distinct_size":67,"ref":"refs/heads/android-8.1","head":"cc18646403d7592619a9e6e0c7359ace84b34a8e","before":"ee1ae195f1417a8149419a046f6c44bd448b7ed0","commits":[{"sha":"0ca7c402cfcb33035e47e18d99e2b58248520478","author":{"name":"H. Nikolaus Schaller","email":"a5299c95093d4bfc163918beb0c47fe6fef836c8@goldelico.com"},"message":"Input: tsc2007 - check for presence and power down tsc2007 during probe\n\n\n[ Upstream commit 934df23171e7c5b71d937104d4957891c39748ff ]\n\n1. check if chip is really present and don't succeed if it isn't.\n2. if it succeeds, power down the chip until accessed\n\nSigned-off-by: H. Nikolaus Schaller <hns@goldelico.com>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/0ca7c402cfcb33035e47e18d99e2b58248520478"},{"sha":"843d4286d819d47ebb8cc079929d42ffcebce6ab","author":{"name":"Valtteri Heikkilä","email":"d35705a43fba4c07a1e06629cd63aec22da91e6b@nic.fi"},"message":"HID: reject input outside logical range only if null state is set\n\n\n[ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ]\n\nThis patch fixes an issue in drivers/hid/hid-input.c where USB HID\ncontrol null state flag is not checked upon rejecting inputs outside\nlogical minimum-maximum range. The check should be made according to USB\nHID specification 1.11, section 6.2.2.5, p.31. The fix will resolve\nissues with some game controllers, such as:\nhttps://bugzilla.kernel.org/show_bug.cgi?id=68621\n\n[tk@the-tk.com: shortened and fixed spelling in commit message]\nSigned-off-by: Valtteri Heikkilä <rnd@nic.fi>\nSigned-off-by: Tomasz Kramkowski <tk@the-tk.com>\nAcked-By: Benjamin Tissoires <benjamin.tissoires@redhat.com>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/843d4286d819d47ebb8cc079929d42ffcebce6ab"},{"sha":"058645e2f0647c85f2bfd577771546d198739fd2","author":{"name":"Prarit Bhargava","email":"57afa0c35fd38a11b51d30edc3a65ab805a2449c@redhat.com"},"message":"PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()\n\n\n[ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]\n\nThe pci_bus_type .shutdown method, pci_device_shutdown(), is called from\ndevice_shutdown() in the kernel restart and shutdown paths.\n\nPreviously, pci_device_shutdown() called pci_msi_shutdown() and\npci_msix_shutdown().  This disables MSI and MSI-X, which causes the device\nto fall back to raising interrupts via INTx.  But the driver is still bound\nto the device, it doesn't know about this change, and it likely doesn't\nhave an INTx handler, so these INTx interrupts cause \"nobody cared\"\nwarnings like this:\n\n  irq 16: nobody cared (try booting with the \"irqpoll\" option)\n  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1\n  Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/\n  ...\n\nThe MSI disabling code was added by d52877c7b1af (\"pci/irq: let\npci_device_shutdown to call pci_msi_shutdown v2\") because a driver left MSI\nenabled and kdump failed because the kexeced kernel wasn't prepared to\nreceive the MSI interrupts.\n\nSubsequent commits 1851617cd2da (\"PCI/MSI: Disable MSI at enumeration even\nif kernel doesn't support MSI\") and  e80e7edc55ba (\"PCI/MSI: Initialize MSI\ncapability for all architectures\") changed the kexeced kernel to disable\nall MSIs itself so it no longer depends on the crashed kernel to clean up\nafter itself.\n\nStop disabling MSI/MSI-X in pci_device_shutdown().  This resolves the\n\"nobody cared\" unhandled IRQ issue above.  It also allows PCI serial\ndevices, which may rely on the MSI interrupts, to continue outputting\nmessages during reboot/shutdown.\n\n[bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls\naltogether]\nFixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351\nSigned-off-by: Prarit Bhargava <prarit@redhat.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nCC: Alex Williamson <alex.williamson@redhat.com>\nCC: David Arcari <darcari@redhat.com>\nCC: Myron Stowe <mstowe@redhat.com>\nCC: Lukas Wunner <lukas@wunner.de>\nCC: Keith Busch <keith.busch@intel.com>\nCC: Mika Westerberg <mika.westerberg@linux.intel.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/058645e2f0647c85f2bfd577771546d198739fd2"},{"sha":"989dcfa4923324a2aa0c9607f3c771f77ec605c1","author":{"name":"Alexander Potapenko","email":"8a652d6e37d449a8e8c8989569d8839dd1bfdb29@google.com"},"message":"selinux: check for address length in selinux_socket_bind()\n\n\n[ Upstream commit e2f586bd83177d22072b275edd4b8b872daba924 ]\n\nKMSAN (KernelMemorySanitizer, a new error detection tool) reports use of\nuninitialized memory in selinux_socket_bind():\n\n==================================================================\nBUG: KMSAN: use of unitialized memory\ninter: 0\nCPU: 3 PID: 1074 Comm: packet2 Tainted: G    B           4.8.0-rc6+ #1916\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011\n 0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48\n ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550\n 0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002\nCall Trace:\n [<     inline     >] __dump_stack lib/dump_stack.c:15\n [<ffffffff825759c8>] dump_stack+0x238/0x290 lib/dump_stack.c:51\n [<ffffffff818bdee6>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008\n [<ffffffff818bf0fb>] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424\n [<ffffffff822dae71>] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288\n [<ffffffff8229357c>] security_socket_bind+0x1ec/0x240 security/security.c:1240\n [<ffffffff84265d98>] SYSC_bind+0x358/0x5f0 net/socket.c:1366\n [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356\n [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292\n [<ffffffff8518217c>] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?\nchained origin: 00000000ba6009bb\n [<ffffffff810bb7a7>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67\n [<     inline     >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322\n [<     inline     >] kmsan_save_stack mm/kmsan/kmsan.c:337\n [<ffffffff818bd2b8>] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530\n [<ffffffff818bf033>] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380\n [<ffffffff84265b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356\n [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356\n [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292\n [<ffffffff8518217c>] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?\norigin description: ----address@SYSC_bind (origin=00000000b8c00900)\n==================================================================\n\n(the line numbers are relative to 4.8-rc6, but the bug persists upstream)\n\n, when I run the following program as root:\n\n=======================================================\n  #include <string.h>\n  #include <sys/socket.h>\n  #include <netinet/in.h>\n\n  int main(int argc, char *argv[]) {\n    struct sockaddr addr;\n    int size = 0;\n    if (argc > 1) {\n      size = atoi(argv[1]);\n    }\n    memset(&addr, 0, sizeof(addr));\n    int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);\n    bind(fd, &addr, size);\n    return 0;\n  }\n=======================================================\n\n(for different values of |size| other error reports are printed).\n\nThis happens because bind() unconditionally copies |size| bytes of\n|addr| to the kernel, leaving the rest uninitialized. Then\nsecurity_socket_bind() reads the IP address bytes, including the\nuninitialized ones, to determine the port, or e.g. pass them further to\nsel_netnode_find(), which uses them to calculate a hash.\n\nSigned-off-by: Alexander Potapenko <glider@google.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\n[PM: fixed some whitespace damage]\nSigned-off-by: Paul Moore <paul@paul-moore.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/989dcfa4923324a2aa0c9607f3c771f77ec605c1"},{"sha":"c5978a681d430ef683cc4c7efbd8d624e869faff","author":{"name":"Stephane Eranian","email":"6af721cad58040b3048c3e3443075fb31c49e8ff@google.com"},"message":"perf tools: Make perf_event__synthesize_mmap_events() scale\n\n\n[ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ]\n\nThis patch significantly improves the execution time of\nperf_event__synthesize_mmap_events() when running perf record on systems\nwhere processes have lots of threads.\n\nIt just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to\ngenerate each map line in the maps file.  If you have 1000 threads, then you\nhave necessarily 1000 stacks.  For each vma, you need to check if it\ncorresponds to a thread's stack.  With a large number of threads, this can take\na very long time. I have seen latencies >> 10mn.\n\nAs of today, perf does not use the fact that a mapping is a stack, therefore we\ncan work around the issue by using /proc/pid/tasks/pid/maps.  This entry does\nnot try to map a vma to stack and is thus much faster with no loss of\nfunctonality.\n\nThe proc-map-timeout logic is kept in case users still want some upper limit.\n\nIn V2, we fix the file path from /proc/pid/tasks/pid/maps to actual\n/proc/pid/task/pid/maps, tasks -> task.  Thanks Arnaldo for catching this.\n\nCommitter note:\n\nThis problem seems to have been elliminated in the kernel since commit :\nb18cb64ead40 (\"fs/proc: Stop trying to report thread stacks\").\n\nSigned-off-by: Stephane Eranian <eranian@google.com>\nAcked-by: Jiri Olsa <jolsa@redhat.com>\nCc: Andy Lutomirski <luto@kernel.org>\nCc: Namhyung Kim <namhyung@kernel.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/20170315135059.GC2177@redhat.com\nLink: http://lkml.kernel.org/r/1489598233-25586-1-git-send-email-eranian@google.com\nSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/c5978a681d430ef683cc4c7efbd8d624e869faff"},{"sha":"0d3a8543e56ec544b342120348430f0b279d2e53","author":{"name":"Quan Nguyen","email":"81659e9f1d76e3796e782a8b71512bfcb94cf33e@apm.com"},"message":"drivers: net: xgene: Fix hardware checksum setting\n\n\n[ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ]\n\nThis patch fixes the hardware checksum settings by properly program\nthe classifier. Otherwise, packet may be received with checksum error\non X-Gene1 SoC.\n\nSigned-off-by: Quan Nguyen <qnguyen@apm.com>\nSigned-off-by: Iyappan Subramanian <isubramanian@apm.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/0d3a8543e56ec544b342120348430f0b279d2e53"},{"sha":"514b0fe569130d18a8e94f4064ea58ac624cab1a","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)\n\n\n[ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ]\n\nOn vblank instant-off systems, we can get into a situation where the cost\nof enabling and disabling the vblank IRQ around a drmWaitVblank query\ndominates. And with the advent of even deeper hardware sleep state,\ntouching registers becomes ever more expensive.  However, we know that if\nthe user wants the current vblank counter, they are also very likely to\nimmediately queue a vblank wait and so we can keep the interrupt around\nand only turn it off if we have no further vblank requests queued within\nthe interrupt interval.\n\nAfter vblank event delivery, this patch adds a shadow of one vblank where\nthe interrupt is kept alive for the user to query and queue another vblank\nevent. Similarly, if the user is using blocking drmWaitVblanks, the\ninterrupt will be disabled on the IRQ following the wait completion.\nHowever, if the user is simply querying the current vblank counter and\ntimestamp, the interrupt will be disabled after every IRQ and the user\nwill enabled it again on the first query following the IRQ.\n\nv2: Mario Kleiner -\nAfter testing this, one more thing that would make sense is to move\nthe disable block at the end of drm_handle_vblank() instead of at the\ntop.\n\nTurns out that if high precision timestaming is disabled or doesn't\nwork for some reason (as can be simulated by echo 0 >\n/sys/module/drm/parameters/timestamp_precision_usec), then with your\ndelayed disable code at its current place, the vblank counter won't\nincrement anymore at all for instant queries, ie. with your other\n\"instant query\" patches. Clients which repeatedly query the counter\nand wait for it to progress will simply hang, spinning in an endless\nquery loop. There's that comment in vblank_disable_and_save:\n\n\"* Skip this step if there isn't any high precision timestamp\n * available. In that case we can't account for this and just\n * hope for the best.\n */\n\nWith the disable happening after leading edge of vblank (== hw counter\nincrement already happened) but before the vblank counter/timestamp\nhandling in drm_handle_vblank, that step is needed to keep the counter\nprogressing, so skipping it is bad.\n\nNow without high precision timestamping support, a kms driver must not\nset dev->vblank_disable_immediate = true, as this would cause problems\nfor clients, so this shouldn't matter, but it would be good to still\nmake this robust against a future kms driver which might have\nunreliable high precision timestamping, e.g., high precision\ntimestamping that intermittently doesn't work.\n\nv3: Patch before coffee needs extra coffee.\n\nTestcase: igt/kms_vblank\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCc: Daniel Vetter <daniel@ffwll.ch>\nCc: Michel Dänzer <michel@daenzer.net>\nCc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nCc: Dave Airlie <airlied@redhat.com>,\nCc: Mario Kleiner <mario.kleiner.de@gmail.com>\nReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nLink: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/514b0fe569130d18a8e94f4064ea58ac624cab1a"},{"sha":"acc107682567d0223c3fe103509655db9d6495e8","author":{"name":"Mohammed Shafi Shajakhan","email":"4abf9d4e9fb909a6b0c1689ab80ea0e519567492@qti.qualcomm.com"},"message":"ath10k: disallow DFS simulation if DFS channel is not enabled\n\n\n[ Upstream commit ca07baab0b1e627ae1d4a55d190fb1c9d32a3445 ]\n\nIf DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall\nnot be available for use even though the hardware may have the capability\nto support DFS. With this configuration (DFS disabled in hostapd) trying to\nbring up ath10k device in DFS channel for AP mode fails and trying to\nsimulate DFS in ath10k debugfs results in a warning in cfg80211 complaining\ninvalid channel and this should be avoided in the driver itself rather than\nfalse propogating RADAR detection to mac80211/cfg80211. Fix this by\nchecking for the first vif 'is_started' state(should work for client mode\nas well) as all the vifs shall be configured for the same channel\n\nsys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar\n\nWARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60\nWorkqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]\n[<c022f2d4>] (warn_slowpath_null) from\n[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])\n[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from\n[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])\n[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from\n[<c0242320>] (process_one_work+0x20c/0x32c)\n\nWARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc\n Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]\n[<c022f2d4>] (warn_slowpath_null) from\n[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])\n[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from\n[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])\n[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from\n[<c0242320>] (process_one_work+0x20c/0x32c)\n\nSigned-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>\nSigned-off-by: Kalle Valo <kvalo@qca.qualcomm.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/acc107682567d0223c3fe103509655db9d6495e8"},{"sha":"20617945ee157e5fdca0cbec1f9c37c1cef5577c","author":{"name":"Tomasz Kramkowski","email":"528479d158dcd5d1b9a6a6984af40758cf7e2a93@the-tk.com"},"message":"HID: clamp input to logical range if no null state\n\n\n[ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ]\n\nThis patch fixes an issue in drivers/hid/hid-input.c where values\noutside of the logical range are not clamped when \"null state\" bit of\nthe input control is not set.\n\nThis was discussed on the lists [1] and this change stems from the fact\ndue to the ambiguity of the HID specification it might be appropriate to\nfollow Microsoft's own interpretation of the specification. As noted in\nMicrosoft's documentation [2] in the section titled \"Required HID usages\nfor digitizers\" it is noted that values reported outside the logical\nrange \"will be considered as invalid data and the value will be changed\nto the nearest boundary value (logical min/max).\"\n\nThis patch fixes an issue where the (1292:4745) Innomedia INNEX\nGENESIS/ATARI reports out of range values for its X and Y axis of the\nDPad which, due to the null state bit being unset, are forwarded to\nuserspace as is. Now these values will get clamped to the logical range\nbefore being forwarded to userspace. This device was also used to test\nthis patch.\n\nThis patch expands on commit 3f3752705dbd (\"HID: reject input outside\nlogical range only if null state is set\").\n\n[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local\n[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp\n\nSigned-off-by: Tomasz Kramkowski <tk@the-tk.com>\nAcked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/20617945ee157e5fdca0cbec1f9c37c1cef5577c"},{"sha":"3b95754fa839d753a6f680c3ecd308ff385a45b9","author":{"name":"Linus Walleij","email":"b0d9e537b6c72323d8ac72352e58c452d7c4fc88@linaro.org"},"message":"ARM: dts: Adjust moxart IRQ controller and flags\n\n\n[ Upstream commit c2a736b698008d296c5010ec39077eeb5796109f ]\n\nThe moxart interrupt line flags were not respected in previous\ndriver: instead of assigning them per-consumer, a fixes mask\nwas set in the controller.\n\nWith the migration to a standard Faraday driver we need to\nset up and handle the consumer flags correctly. Also remove\nthe Moxart-specific flags when switching to using real consumer\nflags.\n\nExtend the register window to 0x100 bytes as we may have a few\nmore registers in there and it doesn't hurt.\n\nTested-by: Jonas Jensen <jonas.jensen@gmail.com>\nSigned-off-by: Jonas Jensen <jonas.jensen@gmail.com>\nSigned-off-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Olof Johansson <olof@lixom.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/3b95754fa839d753a6f680c3ecd308ff385a45b9"},{"sha":"756e89e23452f65eb704e1f79369ab69ffcd5276","author":{"name":"Andreas Pape","email":"4ab0383aab0466481c22c6e06f8ce92ca11abed3@phoenixcontact.com"},"message":"batman-adv: handle race condition for claims between gateways\n\n\n[ Upstream commit a3a5129e122709306cfa6409781716c2933df99b ]\n\nConsider the following situation which has been found in a test setup:\nGateway B has claimed client C and gateway A has the same backbone\nnetwork as B. C sends a broad- or multicast to B and directly after\nthis packet decides to send another packet to A due to a better TQ\nvalue. B will forward the broad-/multicast into the backbone as it is\nthe responsible gw and after that A will claim C as it has been\nchosen by C as the best gateway. If it now happens that A claims C\nbefore it has received the broad-/multicast forwarded by B (due to\nbackbone topology or due to some delay in B when forwarding the\npacket) we get a critical situation: in the current code A will\nimmediately unclaim C when receiving the multicast due to the\nroaming client scenario although the position of C has not changed\nin the mesh. If this happens the multi-/broadcast forwarded by B\nwill be sent back into the mesh by A and we have looping packets\nuntil one of the gateways claims C again.\nIn order to prevent this, unclaiming of a client due to the roaming\nclient scenario is only done after a certain time is expired after\nthe last claim of the client. 100 ms are used here, which should be\nslow enough for big backbones and slow gateways but fast enough not\nto break the roaming client use case.\n\nAcked-by: Simon Wunderlich <sw@simonwunderlich.de>\nSigned-off-by: Andreas Pape <apape@phoenixcontact.com>\n[sven@narfation.org: fix conflicts with current version]\nSigned-off-by: Sven Eckelmann <sven@narfation.org>\nSigned-off-by: Simon Wunderlich <sw@simonwunderlich.de>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/756e89e23452f65eb704e1f79369ab69ffcd5276"},{"sha":"2bca684a62bd01aa3c412c690608c808f5ecc6fc","author":{"name":"Rob Herring","email":"b1c4db6d7090d3e65a0bb8b2af31f7af91ca5a05@kernel.org"},"message":"of: fix of_device_get_modalias returned length when truncating buffers\n\n\n[ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ]\n\nIf the length of the modalias is greater than the buffer size, then the\nmodalias is truncated. However the untruncated length is returned which\nwill cause an error. Fix this to return the truncated length. If an error\nin the case was desired, then then we should just return -ENOMEM.\n\nThe reality is no device will ever have 4KB of compatible strings to hit\nthis case.\n\nSigned-off-by: Rob Herring <robh@kernel.org>\nCc: Frank Rowand <frowand.list@gmail.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/2bca684a62bd01aa3c412c690608c808f5ecc6fc"},{"sha":"89390b1997b9ff7f49d1180976af8c23002280a8","author":{"name":"Brian King","email":"cf155b27024ff05df2a628d0587a84b619e7ad17@linux.vnet.ibm.com"},"message":"scsi: ipr: Fix missed EH wakeup\n\n\n[ Upstream commit 66a0d59cdd12546ddf01d229de28b07ccf6d637f ]\n\nFollowing a command abort or device reset, ipr's EH handlers wait for\nthe commands getting aborted to get sent back from the adapter prior to\nreturning from the EH handler. This fixes up some cases where the\ncompletion handler was not getting called, which would have resulted in\nthe EH thread waiting until it timed out, greatly extending EH time.\n\nSigned-off-by: Brian King <brking@linux.vnet.ibm.com>\nReviewed-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>\nTested-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/89390b1997b9ff7f49d1180976af8c23002280a8"},{"sha":"016f92f24f6ca219c863ef34deb72a0426ad3ab5","author":{"name":"Janusz Krzysztofik","email":"c18742df4df7bd5dec1a47b0b39e813dfd97c905@gmail.com"},"message":"media: i2c/soc_camera: fix ov6650 sensor getting wrong clock\n\n\n[ Upstream commit 54449af0e0b2ea43a8166611c95b730c850c3184 ]\n\nAfter changes to v4l2_clk API introduced in v4.1 by commits a37462b919\n'[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb\n'[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor\nstopped responding because v4l2_clk_get(), still called with\ndepreciated V4L2 clock name \"mclk\", started to return respective CCF\nclock instead of the V4l2 one registered by soc_camera. Fix it by\ncalling v4l2_clk_get() with NULL clock name.\n\nCreated and tested on Amstrad Delta against Linux-4.7-rc3 with\nomap1_camera fixes.\n\nSigned-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>\nSigned-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/016f92f24f6ca219c863ef34deb72a0426ad3ab5"},{"sha":"92bddcee738ef4db4f014378e9916826783df9b9","author":{"name":"David Engraf","email":"d9d6d7eddfcbe707fd8f2fd347ce148d8efd30a8@sysgo.com"},"message":"timers, sched_clock: Update timeout for clock wrap\n\n\n[ Upstream commit 1b8955bc5ac575009835e371ae55e7f3af2197a9 ]\n\nThe scheduler clock framework may not use the correct timeout for the clock\nwrap. This happens when a new clock driver calls sched_clock_register()\nafter the kernel called sched_clock_postinit(). In this case the clock wrap\ntimeout is too long thus sched_clock_poll() is called too late and the clock\nalready wrapped.\n\nOn my ARM system the scheduler was no longer scheduling any other task than\nthe idle task because the sched_clock() wrapped.\n\nSigned-off-by: David Engraf <david.engraf@sysgo.com>\nSigned-off-by: John Stultz <john.stultz@linaro.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/92bddcee738ef4db4f014378e9916826783df9b9"},{"sha":"1680be15892bd0bec6316b99a54046c2afb3ae8d","author":{"name":"Davide Caratti","email":"6f31f02d035d14420e3dc1e73aa793505bdcbcd7@redhat.com"},"message":"sched: act_csum: don't mangle TCP and UDP GSO packets\n\n\n[ Upstream commit add641e7dee31b36aee83412c29e39dd1f5e0c9c ]\n\nafter act_csum computes the checksum on skbs carrying GSO TCP/UDP packets,\nsubsequent segmentation fails because skb_needs_check(skb, true) returns\ntrue. Because of that, skb_warn_bad_offload() is invoked and the following\nmessage is displayed:\n\nWARNING: CPU: 3 PID: 28 at net/core/dev.c:2553 skb_warn_bad_offload+0xf0/0xfd\n<...>\n\n  [<ffffffff8171f486>] skb_warn_bad_offload+0xf0/0xfd\n  [<ffffffff8161304c>] __skb_gso_segment+0xec/0x110\n  [<ffffffff8161340d>] validate_xmit_skb+0x12d/0x2b0\n  [<ffffffff816135d2>] validate_xmit_skb_list+0x42/0x70\n  [<ffffffff8163c560>] sch_direct_xmit+0xd0/0x1b0\n  [<ffffffff8163c760>] __qdisc_run+0x120/0x270\n  [<ffffffff81613b3d>] __dev_queue_xmit+0x23d/0x690\n  [<ffffffff81613fa0>] dev_queue_xmit+0x10/0x20\n\nSince GSO is able to compute checksum on individual segments of such skbs,\nwe can simply skip mangling the packet.\n\nSigned-off-by: Davide Caratti <dcaratti@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/1680be15892bd0bec6316b99a54046c2afb3ae8d"},{"sha":"4ae1886a08161aafb98099a9621643072d872ba0","author":{"name":"Akinobu Mita","email":"15be0a9890f61d62fbf53b5816376eea81782ed9@gmail.com"},"message":"spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer\n\n\n[ Upstream commit 812613591cb652344186c4cd912304ed02138566 ]\n\nWhen running the spi-loopback-test with slower clock rate like 10 KHz,\nthe test for 251 bytes transfer was failed.  This failure triggered an\nspi-omap2-mcspi's error message \"DMA RX last word empty\".\n\nThis message means that PIO for reading the remaining bytes due to the\nDMA transfer length reduction is failed.  This problem can be fixed by\npolling OMAP2_MCSPI_CHSTAT_RXS bit in channel status register to wait\nuntil the receive buffer register is filled.\n\nCc: Mark Brown <broonie@kernel.org>\nSigned-off-by: Akinobu Mita <akinobu.mita@gmail.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/4ae1886a08161aafb98099a9621643072d872ba0"},{"sha":"65c161cb56c9987897b97429c242cbc27bb0f773","author":{"name":"Gao Feng","email":"a965c44740368ac055fd57e1ddf8942162e92a66@ikuai8.com"},"message":"tcp: sysctl: Fix a race to avoid unexpected 0 window from space\n\n\n[ Upstream commit c48367427a39ea0b85c7cf018fe4256627abfd9e ]\n\nBecause sysctl_tcp_adv_win_scale could be changed any time, so there\nis one race in tcp_win_from_space.\nFor example,\n1.sysctl_tcp_adv_win_scale<=0 (sysctl_tcp_adv_win_scale is negative now)\n2.space>>(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now)\n\nAs a result, tcp_win_from_space returns 0. It is unexpected.\n\nCertainly if the compiler put the sysctl_tcp_adv_win_scale into one\nregister firstly, then use the register directly, it would be ok.\nBut we could not depend on the compiler behavior.\n\nSigned-off-by: Gao Feng <fgao@ikuai8.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/65c161cb56c9987897b97429c242cbc27bb0f773"},{"sha":"bbb325e7ebaf068d27b9a94c0aefcaf30926223b","author":{"name":"Kirill A. Shutemov","email":"e4d0c2966af3c70025b28e24a0f33104c6291010@linux.intel.com"},"message":"mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative()\n\n\n[ Upstream commit 591a3d7c09fa08baff48ad86c2347dbd28a52753 ]\n\n0day testing by Fengguang Wu triggered this crash while running Trinity:\n\n  kernel BUG at include/linux/pagemap.h:151!\n  ...\n  CPU: 0 PID: 458 Comm: trinity-c0 Not tainted 4.11.0-rc2-00251-g2947ba0 #1\n  ...\n  Call Trace:\n   __get_user_pages_fast()\n   get_user_pages_fast()\n   get_futex_key()\n   futex_requeue()\n   do_futex()\n   SyS_futex()\n   do_syscall_64()\n   entry_SYSCALL64_slow_path()\n\nIt' VM_BUG_ON() due to false-negative in_atomic(). We call\npage_cache_get_speculative() with disabled local interrupts.\nIt should be atomic enough.\n\nSo let's check for disabled interrupts in the VM_BUG_ON() condition\ntoo, to resolve this.\n\n( This got triggered by the conversion of the x86 GUP code to the\n  generic GUP code. )\n\nReported-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nCc: Kirill A. Shutemov <kirill@shutemov.name>\nCc: LKP <lkp@01.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-mm@kvack.org\nLink: http://lkml.kernel.org/r/20170324114709.pcytvyb3d6ajux33@black.fi.intel.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/bbb325e7ebaf068d27b9a94c0aefcaf30926223b"},{"sha":"7cf6102fef4b4acfe5e8262926da99e4b8eabef8","author":{"name":"Shaohua Li","email":"78841d68de820ce65a8f2019d48ffc5e6c8a1f78@fb.com"},"message":"blk-throttle: make sure expire time isn't too big\n\n\n[ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ]\n\ncgroup could be throttled to a limit but when all cgroups cross high\nlimit, queue enters a higher state and so the group should be throttled\nto a higher limit. It's possible the cgroup is sleeping because of\nthrottle and other cgroups don't dispatch IO any more. In this case,\nnobody can trigger current downgrade/upgrade logic. To fix this issue,\nwe could either set up a timer to wakeup the cgroup if other cgroups are\nidle or make sure this cgroup doesn't sleep too long. Setting up a timer\nmeans we must change the timer very frequently. This patch chooses the\nlatter. Making cgroup sleep time not too big wouldn't change cgroup\nbps/iops, but could make it wakeup more frequently, which isn't a big\nissue because throtl_slice * 8 is already quite big.\n\nSigned-off-by: Shaohua Li <shli@fb.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Sasha Levin <alexander.levin@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nathanchance/android_kernel_oneplus_msm8996/commits/7cf6102fef4b4acfe5e8262926da99e4b8eabef8"}]}
{"actor":{"display_login":"nathanchance"}}