{"push_id":1939077347,"size":47,"distinct_size":46,"ref":"refs/heads/merge","head":"b3ef6cc0338a921c9517360a954d059d1489f5b6","before":"513c176e8002435309e0aecd7506aaafdc96c570","commits":[{"sha":"29178c1473fd4ad9c523b41bb18a047749c66d11","author":{"name":"Krzysztof Kozlowski","email":"78adc4ba6cc2031356f8548133d287acb43ad851@kernel.org"},"message":"ARC: defconfig: Cleanup from old Kconfig options\n\nRemove old, dead Kconfig option INET_LRO. It is gone since\ncommit 7bbf3cae65b6 (\"ipv4: Remove inet_lro library\").\n\nSigned-off-by: Krzysztof Kozlowski <krzk@kernel.org>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/29178c1473fd4ad9c523b41bb18a047749c66d11"},{"sha":"f862b31514bad66e48d9d4ff6036ee051cf36a6f","author":{"name":"Eugeniy Paltsev","email":"6e97fb54271524d81b0cff31ef7ccf2ef297afe7@public.gmane.org"},"message":"ARC: [plat-axs10x]: prepare dts files for enabling PAE40 on axs103\n\nEnable 64bit adressing, where it needed, to make possible\nenabling PAE40 on axs103.\n\nThis patch doesn't affect on any functionality.\n\nSigned-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/f862b31514bad66e48d9d4ff6036ee051cf36a6f"},{"sha":"33460f86ad2c982f3172a10b17948ccaf923f07f","author":{"name":"Vineet Gupta","email":"a7e6bac69589bd9c485fe09b6cb3c1c86c8546ec@synopsys.com"},"message":"ARC: [plat-sim] Include this platform unconditionally\n\nEssentially remove CONFIG_ARC_PLAT_SIM\n\nThere is no need for any platform specific code, just the board DTS\nmatch strings which we can include unconditionally\n\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/33460f86ad2c982f3172a10b17948ccaf923f07f"},{"sha":"b37174d95b0251611a80ef60abf03752e9d66d67","author":{"name":"Alexey Brodkin","email":"00e1475b58c40168fd81030071cb38630a735fc1@synopsys.com"},"message":"ARCv2: SLC: Make sure busy bit is set properly for region ops\n\nc70c473396cb \"ARCv2: SLC: Make sure busy bit is set properly on SLC flushing\"\nfixes problem for entire SLC operation where the problem was initially\ncaught. But given a nature of the issue it is perfectly possible for\nbusy bit to be read incorrectly even when region operation was started.\n\nSo extending initial fix for regional operation as well.\n\nSigned-off-by: Alexey Brodkin <abrodkin@synopsys.com>\nCc: stable@vger.kernel.org   #4.10\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/b37174d95b0251611a80ef60abf03752e9d66d67"},{"sha":"2e332fec2f2c996f8d5447b0946ca43bb0ae4b42","author":{"name":"Vineet Gupta","email":"a7e6bac69589bd9c485fe09b6cb3c1c86c8546ec@synopsys.com"},"message":"ARC: dma: implement dma_unmap_page and sg variant\n\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/2e332fec2f2c996f8d5447b0946ca43bb0ae4b42"},{"sha":"7d79cee2c6540ea64dd917a14e2fd63d4ac3d3c0","author":{"name":"Alexey Brodkin","email":"622a4dc4d126934e8a732fb98e268f020a2b4d1e@synopsys.com"},"message":"ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses\n\nIt is necessary to explicitly set both SLC_AUX_RGN_START1 and SLC_AUX_RGN_END1\nwhich hold MSB bits of the physical address correspondingly of region start\nand end otherwise SLC region operation is executed in unpredictable manner\n\nWithout this patch, SLC flushes on HSDK (IOC disabled) were taking\nseconds.\n\nCc: stable@vger.kernel.org   #4.4+\nReported-by: Vladimir Kondratiev <vladimir.kondratiev@intel.com>\nSigned-off-by: Alexey Brodkin <abrodkin@synopsys.com>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>\n[vgupta: PAR40 regs only written if PAE40 exist]","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/7d79cee2c6540ea64dd917a14e2fd63d4ac3d3c0"},{"sha":"b5ddb6d54729d814356937572d6c9b599f10c29f","author":{"name":"Vineet Gupta","email":"a7e6bac69589bd9c485fe09b6cb3c1c86c8546ec@synopsys.com"},"message":"ARCv2: PAE40: set MSB even if !CONFIG_ARC_HAS_PAE40 but PAE exists in SoC\n\nPAE40 confiuration in hardware extends some of the address registers\nfor TLB/cache ops to 2 words.\n\nSo far kernel was NOT setting the higher word if feature was not enabled\nin software which is wrong. Those need to be set to 0 in such case.\n\nNormally this would be done in the cache flush / tlb ops, however since\nthese registers only exist conditionally, this would have to be\nconditional to a flag being set on boot which is expensive/ugly -\nspecially for the more common case of PAE exists but not in use.\nOptimize that by zero'ing them once at boot - nobody will write to\nthem afterwards\n\nCc: stable@vger.kernel.org   #4.4+\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/b5ddb6d54729d814356937572d6c9b599f10c29f"},{"sha":"9157259d16a8ee8116a98d32f29b797689327e8d","author":{"name":"Zi Yan","email":"62dc7ec108be0228f72ebf1e050ade18f8acc412@cs.rutgers.edu"},"message":"mm: add pmd_t initializer __pmd() to work around a GCC bug.\n\nTHP migration is added but only supports x86_64 at the moment. For all\nother architectures, swp_entry_to_pmd() only returns a zero pmd_t.\n\nDue to a GCC zero initializer bug #53119, the standard (pmd_t){0}\ninitializer is not accepted by all GCC versions. __pmd() is a feasible\nworkaround. In addition, sparc32's pmd_t is an array instead of a single\nvalue, so we need (pmd_t){ {0}, } instead of (pmd_t){0}. Thus,\na different __pmd() definition is needed in sparc32.\n\nSigned-off-by: Zi Yan <zi.yan@cs.rutgers.edu>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/9157259d16a8ee8116a98d32f29b797689327e8d"},{"sha":"a8ec3ee861b6e4e6b82a98777c65510ae63766c1","author":{"name":"Alexey Brodkin","email":"622a4dc4d126934e8a732fb98e268f020a2b4d1e@synopsys.com"},"message":"arc: Mask individual IRQ lines during core INTC init\n\nARC cores on reset have all interrupt lines of built-in INTC enabled.\nWhich means once we globally enable interrupts (very early on boot)\nfaulty hardware blocks may trigger an interrupt that Linux kernel\ncannot handle yet as corresponding handler is not yet installed.\n\nIn that case system falls in \"interrupt storm\" and basically never\ndoes anything useful except entering and exiting generic IRQ handling\ncode.\n\nOne real example of that kind of problematic hardware is DW GMAC which\nalso has interrupts enabled on reset and if Ethernet PHY informs GMAC\nabout link state, GMAC immediately reports that upstream to ARC core\nand here we are.\n\nNow with that change we mask all individual IRQ lines making entire\nsystem more fool-proof.\n\n[This patch was motivated by Adaptrum platform support]\n\nSigned-off-by: Alexey Brodkin <abrodkin@synopsys.com>\nCc: Eugeniy Paltsev <paltsev@synopsys.com>\nTested-by: Alexandru Gagniuc <alex.g@adaptrum.com>\nSigned-off-by: Vineet Gupta <vgupta@synopsys.com>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/a8ec3ee861b6e4e6b82a98777c65510ae63766c1"},{"sha":"79db795833bf5c3e798bcd7a5aeeee3fb0505927","author":{"name":"David S. Miller","email":"79caf591e37e1438a2d55ae59670d5cd0d717764@davemloft.net"},"message":"sparc64: Don't clibber fixed registers in __multi4.\n\n%g4 and %g5 are fixed registers used by the kernel for the thread\npointer and the per-cpu offset.  Use %o4 and %g7 instead.\n\nDiagnosis by Anthony Yznaga.\n\nFixes: 1b4af13ff2cc (\"sparc64: Add __multi3 for gcc 7.x and later.\")\nReported-by: Anatoly Pugachev <matorola@gmail.com>\nTested-by: Anatoly Pugachev <matorola@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/79db795833bf5c3e798bcd7a5aeeee3fb0505927"},{"sha":"c7b725be84985532161bcb4fbecd056326998a77","author":{"name":"David Ahern","email":"e0d419a0ba2bdeef0ad5e59f7813befeb3252a55@gmail.com"},"message":"net: igmp: Use ingress interface rather than vrf device\n\nAnuradha reported that statically added groups for interfaces enslaved\nto a VRF device were not persisting. The problem is that igmp queries\nand reports need to use the data in the in_dev for the real ingress\ndevice rather than the VRF device. Update igmp_rcv accordingly.\n\nFixes: e58e41596811 (\"net: Enable support for VRF with ipv4 multicast\")\nReported-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>\nSigned-off-by: David Ahern <dsahern@gmail.com>\nReviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/c7b725be84985532161bcb4fbecd056326998a77"},{"sha":"6170a506899aee3dd4934c928426505e47b1b466","author":{"name":"Tushar Dave","email":"5fd31bff9e56176dfb43df72b02ecb5b706733f2@oracle.com"},"message":"sparc64: remove unnecessary log message\n\nThere is no need to log message if ATU hvapi couldn't get register.\nUnlike PCI hvapi, ATU hvapi registration failure is not hard error.\nEven if ATU hvapi registration fails (on system with ATU or without\nATU) system continues with legacy IOMMU. So only log message when\nATU hvapi successfully get registered.\n\nSigned-off-by: Tushar Dave <tushar.n.dave@oracle.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/6170a506899aee3dd4934c928426505e47b1b466"},{"sha":"494bea39f3201776cdfddc232705f54a0bd210c4","author":{"name":"Liping Zhang","email":"5172c2e8f5e3c16ed9d51bfc012aefe573d818e4@gmail.com"},"message":"openvswitch: fix skb_panic due to the incorrect actions attrlen\n\nFor sw_flow_actions, the actions_len only represents the kernel part's\nsize, and when we dump the actions to the userspace, we will do the\nconvertions, so it's true size may become bigger than the actions_len.\n\nBut unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len\nto alloc the skbuff, so the user_skb's size may become insufficient and\noops will happen like this:\n  skbuff: skb_over_panic: text:ffffffff8148fabf len:1749 put:157 head:\n  ffff881300f39000 data:ffff881300f39000 tail:0x6d5 end:0x6c0 dev:<NULL>\n  ------------[ cut here ]------------\n  kernel BUG at net/core/skbuff.c:129!\n  [...]\n  Call Trace:\n   <IRQ>\n   [<ffffffff8148be82>] skb_put+0x43/0x44\n   [<ffffffff8148fabf>] skb_zerocopy+0x6c/0x1f4\n   [<ffffffffa0290d36>] queue_userspace_packet+0x3a3/0x448 [openvswitch]\n   [<ffffffffa0292023>] ovs_dp_upcall+0x30/0x5c [openvswitch]\n   [<ffffffffa028d435>] output_userspace+0x132/0x158 [openvswitch]\n   [<ffffffffa01e6890>] ? ip6_rcv_finish+0x74/0x77 [ipv6]\n   [<ffffffffa028e277>] do_execute_actions+0xcc1/0xdc8 [openvswitch]\n   [<ffffffffa028e3f2>] ovs_execute_actions+0x74/0x106 [openvswitch]\n   [<ffffffffa0292130>] ovs_dp_process_packet+0xe1/0xfd [openvswitch]\n   [<ffffffffa0292b77>] ? key_extract+0x63c/0x8d5 [openvswitch]\n   [<ffffffffa029848b>] ovs_vport_receive+0xa1/0xc3 [openvswitch]\n  [...]\n\nAlso we can find that the actions_len is much little than the orig_len:\n  crash> struct sw_flow_actions 0xffff8812f539d000\n  struct sw_flow_actions {\n    rcu = {\n      next = 0xffff8812f5398800,\n      func = 0xffffe3b00035db32\n    },\n    orig_len = 1384,\n    actions_len = 592,\n    actions = 0xffff8812f539d01c\n  }\n\nSo as a quick fix, use the orig_len instead of the actions_len to alloc\nthe user_skb.\n\nLast, this oops happened on our system running a relative old kernel, but\nthe same risk still exists on the mainline, since we use the wrong\nactions_len from the beginning.\n\nFixes: ccea74457bbd (\"openvswitch: include datapath actions with sampled-packet upcall to userspace\")\nCc: Neil McKee <neil.mckee@inmon.com>\nSigned-off-by: Liping Zhang <zlpnobody@gmail.com>\nAcked-by: Pravin B Shelar <pshelar@ovn.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/494bea39f3201776cdfddc232705f54a0bd210c4"},{"sha":"120e9dabaf551c6dc03d3a10a1f026376cb1811c","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"dccp: defer ccid_hc_tx_delete() at dismantle time\n\nsyszkaller team reported another problem in DCCP [1]\n\nProblem here is that the structure holding RTO timer\n(ccid2_hc_tx_rto_expire() handler) is freed too soon.\n\nWe can not use del_timer_sync() to cancel the timer\nsince this timer wants to grab socket lock (that would risk a dead lock)\n\nSolution is to defer the freeing of memory when all references to\nthe socket were released. Socket timers do own a reference, so this\nshould fix the issue.\n\n[1]\n\n==================================================================\nBUG: KASAN: use-after-free in ccid2_hc_tx_rto_expire+0x51c/0x5c0 net/dccp/ccids/ccid2.c:144\nRead of size 4 at addr ffff8801d2660540 by task kworker/u4:7/3365\n\nCPU: 1 PID: 3365 Comm: kworker/u4:7 Not tainted 4.13.0-rc4+ #3\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: events_unbound call_usermodehelper_exec_work\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:16 [inline]\n dump_stack+0x194/0x257 lib/dump_stack.c:52\n print_address_description+0x73/0x250 mm/kasan/report.c:252\n kasan_report_error mm/kasan/report.c:351 [inline]\n kasan_report+0x24e/0x340 mm/kasan/report.c:409\n __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429\n ccid2_hc_tx_rto_expire+0x51c/0x5c0 net/dccp/ccids/ccid2.c:144\n call_timer_fn+0x233/0x830 kernel/time/timer.c:1268\n expire_timers kernel/time/timer.c:1307 [inline]\n __run_timers+0x7fd/0xb90 kernel/time/timer.c:1601\n run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614\n __do_softirq+0x2f5/0xba3 kernel/softirq.c:284\n invoke_softirq kernel/softirq.c:364 [inline]\n irq_exit+0x1cc/0x200 kernel/softirq.c:405\n exiting_irq arch/x86/include/asm/apic.h:638 [inline]\n smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:1044\n apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:702\nRIP: 0010:arch_local_irq_enable arch/x86/include/asm/paravirt.h:824 [inline]\nRIP: 0010:__raw_write_unlock_irq include/linux/rwlock_api_smp.h:267 [inline]\nRIP: 0010:_raw_write_unlock_irq+0x56/0x70 kernel/locking/spinlock.c:343\nRSP: 0018:ffff8801cd50eaa8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff10\nRAX: dffffc0000000000 RBX: ffffffff85a090c0 RCX: 0000000000000006\nRDX: 1ffffffff0b595f3 RSI: 1ffff1003962f989 RDI: ffffffff85acaf98\nRBP: ffff8801cd50eab0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffff8801cc96ea60\nR13: dffffc0000000000 R14: ffff8801cc96e4c0 R15: ffff8801cc96e4c0\n </IRQ>\n release_task+0xe9e/0x1a40 kernel/exit.c:220\n wait_task_zombie kernel/exit.c:1162 [inline]\n wait_consider_task+0x29b8/0x33c0 kernel/exit.c:1389\n do_wait_thread kernel/exit.c:1452 [inline]\n do_wait+0x441/0xa90 kernel/exit.c:1523\n kernel_wait4+0x1f5/0x370 kernel/exit.c:1665\n SYSC_wait4+0x134/0x140 kernel/exit.c:1677\n SyS_wait4+0x2c/0x40 kernel/exit.c:1673\n call_usermodehelper_exec_sync kernel/kmod.c:286 [inline]\n call_usermodehelper_exec_work+0x1a0/0x2c0 kernel/kmod.c:323\n process_one_work+0xbf3/0x1bc0 kernel/workqueue.c:2097\n worker_thread+0x223/0x1860 kernel/workqueue.c:2231\n kthread+0x35e/0x430 kernel/kthread.c:231\n ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:425\n\nAllocated by task 21267:\n save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59\n save_stack+0x43/0xd0 mm/kasan/kasan.c:447\n set_track mm/kasan/kasan.c:459 [inline]\n kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551\n kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489\n kmem_cache_alloc+0x127/0x750 mm/slab.c:3561\n ccid_new+0x20e/0x390 net/dccp/ccid.c:151\n dccp_hdlr_ccid+0x27/0x140 net/dccp/feat.c:44\n __dccp_feat_activate+0x142/0x2a0 net/dccp/feat.c:344\n dccp_feat_activate_values+0x34e/0xa90 net/dccp/feat.c:1538\n dccp_rcv_request_sent_state_process net/dccp/input.c:472 [inline]\n dccp_rcv_state_process+0xed1/0x1620 net/dccp/input.c:677\n dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:679\n sk_backlog_rcv include/net/sock.h:911 [inline]\n __release_sock+0x124/0x360 net/core/sock.c:2269\n release_sock+0xa4/0x2a0 net/core/sock.c:2784\n inet_wait_for_connect net/ipv4/af_inet.c:557 [inline]\n __inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643\n inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682\n SYSC_connect+0x204/0x470 net/socket.c:1642\n SyS_connect+0x24/0x30 net/socket.c:1623\n entry_SYSCALL_64_fastpath+0x1f/0xbe\n\nFreed by task 3049:\n save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59\n save_stack+0x43/0xd0 mm/kasan/kasan.c:447\n set_track mm/kasan/kasan.c:459 [inline]\n kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524\n __cache_free mm/slab.c:3503 [inline]\n kmem_cache_free+0x77/0x280 mm/slab.c:3763\n ccid_hc_tx_delete+0xc5/0x100 net/dccp/ccid.c:190\n dccp_destroy_sock+0x1d1/0x2b0 net/dccp/proto.c:225\n inet_csk_destroy_sock+0x166/0x3f0 net/ipv4/inet_connection_sock.c:833\n dccp_done+0xb7/0xd0 net/dccp/proto.c:145\n dccp_time_wait+0x13d/0x300 net/dccp/minisocks.c:72\n dccp_rcv_reset+0x1d1/0x5b0 net/dccp/input.c:160\n dccp_rcv_state_process+0x8fc/0x1620 net/dccp/input.c:663\n dccp_v4_do_rcv+0xeb/0x160 net/dccp/ipv4.c:679\n sk_backlog_rcv include/net/sock.h:911 [inline]\n __sk_receive_skb+0x33e/0xc00 net/core/sock.c:521\n dccp_v4_rcv+0xef1/0x1c00 net/dccp/ipv4.c:871\n ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216\n NF_HOOK include/linux/netfilter.h:248 [inline]\n ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257\n dst_input include/net/dst.h:477 [inline]\n ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397\n NF_HOOK include/linux/netfilter.h:248 [inline]\n ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488\n __netif_receive_skb_core+0x19af/0x33d0 net/core/dev.c:4417\n __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4455\n process_backlog+0x203/0x740 net/core/dev.c:5130\n napi_poll net/core/dev.c:5527 [inline]\n net_rx_action+0x792/0x1910 net/core/dev.c:5593\n __do_softirq+0x2f5/0xba3 kernel/softirq.c:284\n\nThe buggy address belongs to the object at ffff8801d2660100\n which belongs to the cache ccid2_hc_tx_sock of size 1240\nThe buggy address is located 1088 bytes inside of\n 1240-byte region [ffff8801d2660100, ffff8801d26605d8)\nThe buggy address belongs to the page:\npage:ffffea0007499800 count:1 mapcount:0 mapping:ffff8801d2660100 index:0x0 compound_mapcount: 0\nflags: 0x200000000008100(slab|head)\nraw: 0200000000008100 ffff8801d2660100 0000000000000000 0000000100000005\nraw: ffffea00075271a0 ffffea0007538820 ffff8801d3aef9c0 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff8801d2660400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8801d2660480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n>ffff8801d2660500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                           ^\n ffff8801d2660580: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc\n ffff8801d2660600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n==================================================================\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nCc: Gerrit Renker <gerrit@erg.abdn.ac.uk>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/120e9dabaf551c6dc03d3a10a1f026376cb1811c"},{"sha":"81fbfe8adaf38d4f5a98c19bebfd41c5d6acaee8","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"ptr_ring: use kmalloc_array()\n\nAs found by syzkaller, malicious users can set whatever tx_queue_len\non a tun device and eventually crash the kernel.\n\nLets remove the ALIGN(XXX, SMP_CACHE_BYTES) thing since a small\nring buffer is not fast anyway.\n\nFixes: 2e0ab8ca83c1 (\"ptr_ring: array based FIFO for pointers\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nReported-by: Dmitry Vyukov <dvyukov@google.com>\nCc: Michael S. Tsirkin <mst@redhat.com>\nCc: Jason Wang <jasowang@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/81fbfe8adaf38d4f5a98c19bebfd41c5d6acaee8"},{"sha":"c780a049f9bf442314335372c9abc4548bfe3e44","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"ipv4: better IP_MAX_MTU enforcement\n\nWhile working on yet another syzkaller report, I found\nthat our IP_MAX_MTU enforcements were not properly done.\n\ngcc seems to reload dev->mtu for min(dev->mtu, IP_MAX_MTU), and\nfinal result can be bigger than IP_MAX_MTU :/\n\nThis is a problem because device mtu can be changed on other cpus or\nthreads.\n\nWhile this patch does not fix the issue I am working on, it is\nprobably worth addressing it.\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/c780a049f9bf442314335372c9abc4548bfe3e44"},{"sha":"014cd0a368dc6351c65d51e4ee34f8573a4a1543","author":{"name":"Michael Ellerman","email":"703f314094b6de2227245178d929368b49dccb12@ellerman.id.au"},"message":"bpf: Update sysctl documentation to list all supported architectures\n\nThe sysctl documentation states that the JIT is only available on\nx86_64, which is no longer correct.\n\nUpdate the list, and break it out to indicate which architectures\nsupport the cBPF JIT (via HAVE_CBPF_JIT) or the eBPF JIT\n(HAVE_EBPF_JIT).\n\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nAcked-by: Daniel Borkmann <daniel@iogearbox.net>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/014cd0a368dc6351c65d51e4ee34f8573a4a1543"},{"sha":"1a92a80ad386a1a6e3b36d576d52a1a456394b70","author":{"name":"Benjamin Herrenschmidt","email":"58942ee662d0fe5d44043b40ceefc845bad5a84d@kernel.crashing.org"},"message":"powerpc/mm: Ensure cpumask update is ordered\n\nThere is no guarantee that the various isync's involved with\nthe context switch will order the update of the CPU mask with\nthe first TLB entry for the new context being loaded by the HW.\n\nBe safe here and add a memory barrier to order any subsequent\nload/store which may bring entries into the TLB.\n\nThe corresponding barrier on the other side already exists as\npte updates use pte_xchg() which uses __cmpxchg_u64 which has\na sync after the atomic operation.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nReviewed-by: Nicholas Piggin <npiggin@gmail.com>\n[mpe: Add comments in the code]\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>","distinct":false,"url":"https://api.github.com/repos/linuxppc/linux/commits/1a92a80ad386a1a6e3b36d576d52a1a456394b70"},{"sha":"acc8b31665b4cc17b35c4fa445427f7e2f6dc86b","author":{"name":"Jiri Pirko","email":"a7e702c6c67814648a4f7569508b76ff202ca280@mellanox.com"},"message":"net: sched: fix p_filter_chain check in tcf_chain_flush\n\nThe dereference before check is wrong and leads to an oops when\np_filter_chain is NULL. The check needs to be done on the pointer to\nprevent NULL dereference.\n\nFixes: f93e1cdcf42c (\"net/sched: fix filter flushing\")\nSigned-off-by: Jiri Pirko <jiri@mellanox.com>\nAcked-by: Cong Wang <xiyou.wangcong@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/acc8b31665b4cc17b35c4fa445427f7e2f6dc86b"},{"sha":"eac2c68d663effb077210218788952b5a0c1f60e","author":{"name":"Colin Ian King","email":"61b69653f478c16de27cbf2a77617b5a614a704a@canonical.com"},"message":"nfp: fix infinite loop on umapping cleanup\n\nThe while loop that performs the dma page unmapping never decrements\nindex counter f and hence loops forever. Fix this with a pre-decrement\non f.\n\nDetected by CoverityScan, CID#1357309 (\"Infinite loop\")\n\nFixes: 4c3523623dc0 (\"net: add driver for Netronome NFP4000/NFP6000 NIC VFs\")\nSigned-off-by: Colin Ian King <colin.king@canonical.com>\nAcked-by: Jakub Kicinski <jakub.kicinski@netronome.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/linuxppc/linux/commits/eac2c68d663effb077210218788952b5a0c1f60e"}]}
{"actor":{"display_login":"mpe"}}