{"push_id":1076536583,"size":38,"distinct_size":38,"ref":"refs/heads/MA-E3xx/linux-3.14.y","head":"a98969133faf786290bd173a2ffb8573ddcd3d38","before":"cca4a7a0f30d758b539c59a7b34df20a2081368b","commits":[{"sha":"a0132681fab64c47e07feb944e27b90e96cc21b1","author":{"email":"ba324ca7b1c77fc20bb970d5aff6eea9377918a5@roeck-us.net","name":"Guenter Roeck"},"message":"hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated\n\ncommit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f upstream.\n\narm:pxa_defconfig can result in the following crash if the max1111 driver\nis not instantiated.\n\nUnhandled fault: page domain fault (0x01b) at 0x00000000\npgd = c0004000\n[00000000] *pgd=00000000\nInternal error: : 1b [#1] PREEMPT ARM\nModules linked in:\nCPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10\nHardware name: SHARP Akita\nWorkqueue: events sharpsl_charge_toggle\ntask: c390a000 ti: c391e000 task.ti: c391e000\nPC is at max1111_read_channel+0x20/0x30\nLR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c\npc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013\n...\n[<c03aaab0>] (max1111_read_channel) from [<c0024b50>]\n\t\t\t\t\t(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)\n[<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]\n\t\t\t\t\t(spitzpm_read_devdata+0x5c/0xc4)\n[<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]\n\t\t\t\t\t(sharpsl_check_battery_temp+0x78/0x110)\n[<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]\n\t\t\t\t\t(sharpsl_charge_toggle+0x48/0x110)\n[<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]\n\t\t\t\t\t(process_one_work+0x14c/0x48c)\n[<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)\n[<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)\n[<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)\n\nThis can occur because the SPI controller driver (SPI_PXA2XX) is built as\nmodule and thus not necessarily loaded. While building SPI_PXA2XX into the\nkernel would make the problem disappear, it appears prudent to ensure that\nthe driver is instantiated before accessing its data structures.\n\nCc: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/a0132681fab64c47e07feb944e27b90e96cc21b1"},{"sha":"e2e26bf7be49e583aab8046807230c00f42390fb","author":{"email":"5b1e7895819cf7d6bc77091b09bbfd6d330a4e74@gmx.de","name":"Helge Deller"},"message":"parisc: Avoid function pointers for kernel exception routines\n\ncommit e3893027a300927049efc1572f852201eb785142 upstream.\n\nWe want to avoid the kernel module loader to create function pointers\nfor the kernel fixup routines of get_user() and put_user(). Changing\nthe external reference from function type to int type fixes this.\n\nThis unbreaks exception handling for get_user() and put_user() when\ncalled from a kernel module.\n\nSigned-off-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/e2e26bf7be49e583aab8046807230c00f42390fb"},{"sha":"7b5b3bf5638221359c03d71589b8784e1735b4db","author":{"email":"5b1e7895819cf7d6bc77091b09bbfd6d330a4e74@gmx.de","name":"Helge Deller"},"message":"parisc: Fix kernel crash with reversed copy_from_user()\n\ncommit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 upstream.\n\nThe kernel module testcase (lib/test_user_copy.c) exhibited a kernel\ncrash on parisc if the parameters for copy_from_user were reversed\n(\"illegal reversed copy_to_user\" testcase).\n\nFix this potential crash by checking the fault handler if the faulting\naddress is in the exception table.\n\nSigned-off-by: Helge Deller <deller@gmx.de>\nCc: Kees Cook <keescook@chromium.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/7b5b3bf5638221359c03d71589b8784e1735b4db"},{"sha":"f0c3c0e137da84c0201eb5ba8f847991f1bb48ef","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: timer: Use mod_timer() for rearming the system timer\n\ncommit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream.\n\nALSA system timer backend stops the timer via del_timer() without sync\nand leaves del_timer_sync() at the close instead.  This is because of\nthe restriction by the design of ALSA timer: namely, the stop callback\nmay be called from the timer handler, and calling the sync shall lead\nto a hangup.  However, this also triggers a kernel BUG() when the\ntimer is rearmed immediately after stopping without sync:\n kernel BUG at kernel/time/timer.c:966!\n Call Trace:\n  <IRQ>\n  [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0\n  [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0\n  [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290\n  [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120\n  [<ffffffff81296b72>] call_timer_fn+0x162/0x520\n  [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520\n  [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0\n  ....\n\nIt's the place where add_timer() checks the pending timer.  It's clear\nthat this may happen after the immediate restart without sync in our\ncases.\n\nSo, the workaround here is just to use mod_timer() instead of\nadd_timer().  This looks like a band-aid fix, but it's a right move,\nas snd_timer_interrupt() takes care of the continuous rearm of timer.\n\nReported-by: Jiri Slaby <jslaby@suse.cz>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/f0c3c0e137da84c0201eb5ba8f847991f1bb48ef"},{"sha":"37f2c8b804e9299238f0b5774f202f46121c998e","author":{"email":"dd58e6c73de42ea3812c4e45cc983f071455d7f2@huawei.com","name":"Xishi Qiu"},"message":"mm: fix invalid node in alloc_migrate_target()\n\ncommit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 upstream.\n\nIt is incorrect to use next_node to find a target node, it will return\nMAX_NUMNODES or invalid node.  This will lead to crash in buddy system\nallocation.\n\nFixes: c8721bbbdd36 (\"mm: memory-hotplug: enable memory hotplug to handle hugepage\")\nSigned-off-by: Xishi Qiu <qiuxishi@huawei.com>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\nAcked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>\nCc: Joonsoo Kim <js1304@gmail.com>\nCc: David Rientjes <rientjes@google.com>\nCc: \"Laura Abbott\" <lauraa@codeaurora.org>\nCc: Hui Zhu <zhuhui@xiaomi.com>\nCc: Wang Xiaoqiang <wangxq10@lzu.edu.cn>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/37f2c8b804e9299238f0b5774f202f46121c998e"},{"sha":"b29ddd02cdfa8316e7b54fe438cbf01e10eef7e7","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5\n\ncommit f971f2263deaa4a441e377b385c11aee0f3b3f9a upstream.\n\nbug:\nhttps://bugs.freedesktop.org/show_bug.cgi?id=94692\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/b29ddd02cdfa8316e7b54fe438cbf01e10eef7e7"},{"sha":"c59ffbe17b2b6c9f68bf4f101e4d6b16b5254aa5","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/radeon: add a dpm quirk for all R7 370 parts\n\ncommit 0e5585dc870af947fab2af96a88c2d8b4270247c upstream.\n\nHigher mclk values are not stable due to a bug somewhere.\nLimit them for now.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/c59ffbe17b2b6c9f68bf4f101e4d6b16b5254aa5"},{"sha":"f808d9a02c64110f29218c3f4437f4d9282998ad","author":{"email":"b41c17b861974b03cec38e3ec2992769b9bfae55@oracle.com","name":"Boris Ostrovsky"},"message":"xen/events: Mask a moving irq\n\ncommit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream.\n\nMoving an unmasked irq may result in irq handler being invoked on both\nsource and target CPUs.\n\nWith 2-level this can happen as follows:\n\nOn source CPU:\n        evtchn_2l_handle_events() ->\n            generic_handle_irq() ->\n                handle_edge_irq() ->\n                   eoi_pirq():\n                       irq_move_irq(data);\n\n                       /***** WE ARE HERE *****/\n\n                       if (VALID_EVTCHN(evtchn))\n                           clear_evtchn(evtchn);\n\nIf at this moment target processor is handling an unrelated event in\nevtchn_2l_handle_events()'s loop it may pick up our event since target's\ncpu_evtchn_mask claims that this event belongs to it *and* the event is\nunmasked and still pending. At the same time, source CPU will continue\nexecuting its own handle_edge_irq().\n\nWith FIFO interrupt the scenario is similar: irq_move_irq() may result\nin a EVTCHNOP_unmask hypercall which, in turn, may make the event\npending on the target CPU.\n\nWe can avoid this situation by moving and clearing the event while\nkeeping event masked.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nSigned-off-by: David Vrabel <david.vrabel@citrix.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/f808d9a02c64110f29218c3f4437f4d9282998ad"},{"sha":"1911c25b643550cdcb0e49652d57250eb00eef07","author":{"email":"71e8a0d513c0f8ed1c2f4bdbf843bdfe8b124ca4@gmail.com","name":"Diego Viola"},"message":"net: jme: fix suspend/resume on JMC260\n\n[ Upstream commit ee50c130c82175eaa0820c96b6d3763928af2241 ]\n\nThe JMC260 network card fails to suspend/resume because the call to\njme_start_irq() was too early, moving the call to jme_start_irq() after\nthe call to jme_reset_link() makes it work.\n\nPrior this change suspend/resume would fail unless /sys/power/pm_async=0\nwas explicitly specified.\n\nRelevant bug report: https://bugzilla.kernel.org/show_bug.cgi?id=112351\n\nSigned-off-by: Diego Viola <diego.viola@gmail.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/centurysys/linux-kernel-MAE/commits/1911c25b643550cdcb0e49652d57250eb00eef07"},{"sha":"893ec5b72193fba1d3aca768e5b1796b45fd60b3","author":{"email":"ed9bd6f22d2a1e0b1507d3ddc300dc248265d19a@gmail.com","name":"Xin Long"},"message":"sctp: lack the check for ports in sctp_v6_cmp_addr\n\n[ Upstream commit 40b4f0fd74e46c017814618d67ec9127ff20f157 ]\n\nAs the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check\nthe port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by\nsctp_cmp_addr_exact().\n\nNow sctp_v6_cmp_addr just check the port when two addresses have different\nfamily, and lack the port check for two ipv6 addresses. that will make\nsctp_hash_cmp() cannot work well.\n\nso fix it by adding ports comparison in sctp_v6_cmp_addr().\n\nSigned-off-by: Xin Long <lucien.xin@gmail.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/centurysys/linux-kernel-MAE/commits/893ec5b72193fba1d3aca768e5b1796b45fd60b3"},{"sha":"369b2427aabaf9d7ec7dc66b5e55b12c83c6770c","author":{"email":"cef439e78636cdab99cd2923826c5065a0743e5b@strlen.de","name":"Florian Westphal"},"message":"ipv6: re-enable fragment header matching in ipv6_find_hdr\n\n[ Upstream commit 5d150a985520bbe3cb2aa1ceef24a7e32f20c15f ]\n\nWhen ipv6_find_hdr is used to find a fragment header\n(caller specifies target NEXTHDR_FRAGMENT) we erronously return\n-ENOENT for all fragments with nonzero offset.\n\nBefore commit 9195bb8e381d, when target was specified, we did not\nenter the exthdr walk loop as nexthdr == target so this used to work.\n\nNow we do (so we can skip empty route headers). When we then stumble upon\na frag with nonzero frag_off we must return -ENOENT (\"header not found\")\nonly if the caller did not specifically request NEXTHDR_FRAGMENT.\n\nThis allows nfables exthdr expression to match ipv6 fragments, e.g. via\n\nnft add rule ip6 filter input frag frag-off gt 0\n\nFixes: 9195bb8e381d (\"ipv6: improve ipv6_find_hdr() to skip empty routing headers\")\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/centurysys/linux-kernel-MAE/commits/369b2427aabaf9d7ec7dc66b5e55b12c83c6770c"},{"sha":"3aec7e0989d2ea5bec73c36081b28b0f11258c6f","author":{"email":"8a2957e0063f2abf61bd145b6236a74a3708ac54@mork.no","name":"Bjørn Mork"},"message":"cdc_ncm: toggle altsetting to force reset before setup\n\n[ Upstream commit 48906f62c96cc2cd35753e59310cb70eb08cc6a5 ]\n\nSome devices will silently fail setup unless they are reset first.\nThis is necessary even if the data interface is already in\naltsetting 0, which it will be when the device is probed for the\nfirst time.  Briefly toggling the altsetting forces a function\nreset regardless of the initial state.\n\nThis fixes a setup problem observed on a number of Huawei devices,\nappearing to operate in NTB-32 mode even if we explicitly set them\nto NTB-16 mode.\n\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\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/centurysys/linux-kernel-MAE/commits/3aec7e0989d2ea5bec73c36081b28b0f11258c6f"},{"sha":"7f3216bee081816d415566a86a5bd3fcf2d5dcd7","author":{"email":"bfee72d94d376f4e00f72b756466867d7f9eb24e@suse.com","name":"Oliver Neukum"},"message":"usbnet: cleanup after bind() in probe()\n\n[ Upstream commit 1666984c8625b3db19a9abc298931d35ab7bc64b ]\n\nIn case bind() works, but a later error forces bailing\nin probe() in error cases work and a timer may be scheduled.\nThey must be killed. This fixes an error case related to\nthe double free reported in\nhttp://www.spinics.net/lists/netdev/msg367669.html\nand needs to go on top of Linus' fix to cdc-ncm.\n\nSigned-off-by: Oliver Neukum <ONeukum@suse.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/centurysys/linux-kernel-MAE/commits/7f3216bee081816d415566a86a5bd3fcf2d5dcd7"},{"sha":"1a6602079d4afd08cdf62d211b8b86a3c8bbcf85","author":{"email":"70aaaf655d0feac4b3f8d8fdbf8890db79ce40d3@google.com","name":"Bill Sommerfeld"},"message":"udp6: fix UDP/IPv6 encap resubmit path\n\n[ Upstream commit 59dca1d8a6725a121dae6c452de0b2611d5865dc ]\n\nIPv4 interprets a negative return value from a protocol handler as a\nrequest to redispatch to a new protocol.  In contrast, IPv6 interprets a\nnegative value as an error, and interprets a positive value as a request\nfor redispatch.\n\nUDP for IPv6 was unaware of this difference.  Change __udp6_lib_rcv() to\nreturn a positive value for redispatch.  Note that the socket's\nencap_rcv hook still needs to return a negative value to request\ndispatch, and in the case of IPv6 packets, adjust IP6CB(skb)->nhoff to\nidentify the byte containing the next protocol.\n\nSigned-off-by: Bill Sommerfeld <wsommerfeld@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/centurysys/linux-kernel-MAE/commits/1a6602079d4afd08cdf62d211b8b86a3c8bbcf85"},{"sha":"3b199517879d1db45a75aa1d9072a1374f661380","author":{"email":"d8c69075be49b0738b690ec4af0e9025b8c97c9e@cogentembedded.com","name":"Sergei Shtylyov"},"message":"sh_eth: fix NULL pointer dereference in sh_eth_ring_format()\n\n[ Upstream commit c1b7fca65070bfadca94dd53a4e6b71cd4f69715 ]\n\nIn a low memory situation, if netdev_alloc_skb() fails on a first RX ring\nloop iteration  in sh_eth_ring_format(), 'rxdesc' is still NULL.  Avoid\nkernel oops by adding the 'rxdesc' check after the loop.\n\nReported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>\nSigned-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.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/centurysys/linux-kernel-MAE/commits/3b199517879d1db45a75aa1d9072a1374f661380"},{"sha":"902b916d00ba73095b58a9a8dfe926c6a7f635d5","author":{"email":"293abb6b76d7791c0732cc517d38c4b5c734b87f@redhat.com","name":"Arnaldo Carvalho de Melo"},"message":"net: Fix use after free in the recvmmsg exit path\n\n[ Upstream commit 34b88a68f26a75e4fded796f1a49c40f82234b7d ]\n\nThe syzkaller fuzzer hit the following use-after-free:\n\n  Call Trace:\n   [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295\n   [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261\n   [<     inline     >] SYSC_recvmmsg net/socket.c:2281\n   [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270\n   [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a\n  arch/x86/entry/entry_64.S:185\n\nAnd, as Dmitry rightly assessed, that is because we can drop the\nreference and then touch it when the underlying recvmsg calls return\nsome packets and then hit an error, which will make recvmmsg to set\nsock->sk->sk_err, oops, fix it.\n\nReported-and-Tested-by: Dmitry Vyukov <dvyukov@google.com>\nCc: Alexander Potapenko <glider@google.com>\nCc: Eric Dumazet <edumazet@google.com>\nCc: Kostya Serebryany <kcc@google.com>\nCc: Sasha Levin <sasha.levin@oracle.com>\nFixes: a2e2725541fa (\"net: Introduce recvmmsg socket syscall\")\nhttp://lkml.kernel.org/r/20160122211644.GC2470@redhat.com\nSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.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/centurysys/linux-kernel-MAE/commits/902b916d00ba73095b58a9a8dfe926c6a7f635d5"},{"sha":"26a628c5c79d35a0f121179beeed635f4930e801","author":{"email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de","name":"Arnd Bergmann"},"message":"farsync: fix off-by-one bug in fst_add_one\n\n[ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ]\n\ngcc-6 finds an out of bounds access in the fst_add_one function\nwhen calculating the end of the mmio area:\n\ndrivers/net/wan/farsync.c: In function 'fst_add_one':\ndrivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]\n #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))\n                                                     ^\ninclude/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'\n  __builtin_offsetof(a, b)\n                     ^\ndrivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'\n #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))\n                                     ^~~~~~~~\ndrivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'\n                                  + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);\n                                    ^~~~~~~~~~\n\nThe warning is correct, but not critical because this appears\nto be a write-only variable that is set by each WAN driver but\nnever accessed afterwards.\n\nI'm taking the minimal fix here, using the correct pointer by\npointing 'mem_end' to the last byte inside of the register area\nas all other WAN drivers do, rather than the first byte outside of\nit. An alternative would be to just remove the mem_end member\nentirely.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.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/centurysys/linux-kernel-MAE/commits/26a628c5c79d35a0f121179beeed635f4930e801"},{"sha":"d805f291ee2f594c015c9411d20d41e7e56f1bc6","author":{"email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de","name":"Arnd Bergmann"},"message":"ath9k: fix buffer overrun for ar9287\n\n[ Upstream commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 ]\n\nCode that was added back in 2.6.38 has an obvious overflow\nwhen accessing a static array, and at the time it was added\nonly a code comment was put in front of it as a reminder\nto have it reviewed properly.\n\nThis has not happened, but gcc-6 now points to the specific\noverflow:\n\ndrivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':\ndrivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]\n     maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];\n                   ~~~~~~~~~~~~~~~~~~~~~~~~~^~~\n\nIt turns out that the correct array length exists in the local\n'intercepts' variable of this function, so we can just use that\ninstead of hardcoding '4', so this patch changes all three\ninstances to use that variable. The other two instances were\nalready correct, but it's more consistent this way.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nFixes: 940cd2c12ebf (\"ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs\")\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/centurysys/linux-kernel-MAE/commits/d805f291ee2f594c015c9411d20d41e7e56f1bc6"},{"sha":"fd87f95c015280aa087f04cbc1f7d8061e3b34a8","author":{"email":"db299e8ee09bc137fc5ea17d686d0d8b9e8284b6@qlogic.com","name":"Manish Chopra"},"message":"qlge: Fix receive packets drop.\n\n[ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ]\n\nWhen running small packets [length < 256 bytes] traffic, packets were\nbeing dropped due to invalid data in those packets which were\ndelivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu\nensures copying latest and updated data into skb from the receive buffer.\n\nSigned-off-by: Sony Chacko <sony.chacko@qlogic.com>\nSigned-off-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/centurysys/linux-kernel-MAE/commits/fd87f95c015280aa087f04cbc1f7d8061e3b34a8"},{"sha":"821710a05056bee8a3560d54d64bf9320afda9c6","author":{"email":"6e4ffc2e3438feb7acb34f6b67e6ae17e700099c@redhat.com","name":"Paolo Abeni"},"message":"ipv4: fix broadcast packets reception\n\n[ Upstream commit ad0ea1989cc4d5905941d0a9e62c63ad6d859cef ]\n\nCurrently, ingress ipv4 broadcast datagrams are dropped since,\nin udp_v4_early_demux(), ip_check_mc_rcu() is invoked even on\nbcast packets.\n\nThis patch addresses the issue, invoking ip_check_mc_rcu()\nonly for mcast packets.\n\nFixes: 6e5403093261 (\"ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()\")\nSigned-off-by: Paolo Abeni <pabeni@redhat.com>\nAcked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/centurysys/linux-kernel-MAE/commits/821710a05056bee8a3560d54d64bf9320afda9c6"}]}