{"push_id":3170258229,"size":39,"distinct_size":39,"ref":"refs/heads/lineage-15.1","head":"abcb91aa5bac65b90b899efe99f82c2b4f7187d0","before":"1c4476d213433503cab7809850e6669af58c8a29","commits":[{"sha":"a0c61bf02f50cc9a4e3e3703bb98ce2658794bce","author":{"name":"Su Yanjun","email":"decfd529450e1b22121a34195991021c5d7b7c6a@cn.fujitsu.com"},"message":"net: 8139cp: fix a BUG triggered by changing mtu with network traffic\n\n[ Upstream commit a5d4a89245ead1f37ed135213653c5beebea4237 ]\n\nWhen changing mtu many times with traffic, a bug is triggered:\n\n[ 1035.684037] kernel BUG at lib/dynamic_queue_limits.c:26!\n[ 1035.684042] invalid opcode: 0000 [#1] SMP\n[ 1035.684049] Modules linked in: loop binfmt_misc 8139cp(OE) macsec\ntcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag tcp_lp\nfuse uinput xt_CHECKSUM iptable_mangle ipt_MASQUERADE\nnf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4\nnf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun\nbridge stp llc ebtable_filter ebtables ip6table_filter devlink\nip6_tables iptable_filter sunrpc snd_hda_codec_generic snd_hda_intel\nsnd_hda_codec snd_hda_core snd_hwdep ppdev snd_seq iosf_mbi crc32_pclmul\nparport_pc snd_seq_device ghash_clmulni_intel parport snd_pcm\naesni_intel joydev lrw snd_timer virtio_balloon sg gf128mul glue_helper\nablk_helper cryptd snd soundcore i2c_piix4 pcspkr ip_tables xfs\nlibcrc32c sr_mod sd_mod cdrom crc_t10dif crct10dif_generic ata_generic\n[ 1035.684102]  pata_acpi virtio_console qxl drm_kms_helper syscopyarea\nsysfillrect sysimgblt floppy fb_sys_fops crct10dif_pclmul\ncrct10dif_common ttm crc32c_intel serio_raw ata_piix drm libata 8139too\nvirtio_pci drm_panel_orientation_quirks virtio_ring virtio mii dm_mirror\ndm_region_hash dm_log dm_mod [last unloaded: 8139cp]\n[ 1035.684132] CPU: 9 PID: 25140 Comm: if-mtu-change Kdump: loaded\nTainted: G           OE  ------------ T 3.10.0-957.el7.x86_64 #1\n[ 1035.684134] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\n[ 1035.684136] task: ffff8f59b1f5a080 ti: ffff8f5a2e32c000 task.ti:\nffff8f5a2e32c000\n[ 1035.684149] RIP: 0010:[<ffffffffba3a40d0>]  [<ffffffffba3a40d0>]\ndql_completed+0x180/0x190\n[ 1035.684162] RSP: 0000:ffff8f5a75483e50  EFLAGS: 00010093\n[ 1035.684162] RAX: 00000000000000c2 RBX: ffff8f5a6f91c000 RCX:\n0000000000000000\n[ 1035.684162] RDX: 0000000000000000 RSI: 0000000000000184 RDI:\nffff8f599fea3ec0\n[ 1035.684162] RBP: ffff8f5a75483ea8 R08: 00000000000000c2 R09:\n0000000000000000\n[ 1035.684162] R10: 00000000000616ef R11: ffff8f5a75483b56 R12:\nffff8f599fea3e00\n[ 1035.684162] R13: 0000000000000001 R14: 0000000000000000 R15:\n0000000000000184\n[ 1035.684162] FS:  00007fa8434de740(0000) GS:ffff8f5a75480000(0000)\nknlGS:0000000000000000\n[ 1035.684162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1035.684162] CR2: 00000000004305d0 CR3: 000000024eb66000 CR4:\n00000000001406e0\n[ 1035.684162] Call Trace:\n[ 1035.684162]  <IRQ>\n[ 1035.684162]  [<ffffffffc08cbaf8>] ? cp_interrupt+0x478/0x580 [8139cp]\n[ 1035.684162]  [<ffffffffba14a294>]\n__handle_irq_event_percpu+0x44/0x1c0\n[ 1035.684162]  [<ffffffffba14a442>] handle_irq_event_percpu+0x32/0x80\n[ 1035.684162]  [<ffffffffba14a4cc>] handle_irq_event+0x3c/0x60\n[ 1035.684162]  [<ffffffffba14db29>] handle_fasteoi_irq+0x59/0x110\n[ 1035.684162]  [<ffffffffba02e554>] handle_irq+0xe4/0x1a0\n[ 1035.684162]  [<ffffffffba7795dd>] do_IRQ+0x4d/0xf0\n[ 1035.684162]  [<ffffffffba76b362>] common_interrupt+0x162/0x162\n[ 1035.684162]  <EOI>\n[ 1035.684162]  [<ffffffffba0c2ae4>] ? __wake_up_bit+0x24/0x70\n[ 1035.684162]  [<ffffffffba1e46f5>] ? do_set_pte+0xd5/0x120\n[ 1035.684162]  [<ffffffffba1b64fb>] unlock_page+0x2b/0x30\n[ 1035.684162]  [<ffffffffba1e4879>] do_read_fault.isra.61+0x139/0x1b0\n[ 1035.684162]  [<ffffffffba1e9134>] handle_pte_fault+0x2f4/0xd10\n[ 1035.684162]  [<ffffffffba1ebc6d>] handle_mm_fault+0x39d/0x9b0\n[ 1035.684162]  [<ffffffffba76f5e3>] __do_page_fault+0x203/0x500\n[ 1035.684162]  [<ffffffffba76f9c6>] trace_do_page_fault+0x56/0x150\n[ 1035.684162]  [<ffffffffba76ef42>] do_async_page_fault+0x22/0xf0\n[ 1035.684162]  [<ffffffffba76b788>] async_page_fault+0x28/0x30\n[ 1035.684162] Code: 54 c7 47 54 ff ff ff ff 44 0f 49 ce 48 8b 35 48 2f\n9c 00 48 89 77 58 e9 fe fe ff ff 0f 1f 80 00 00 00 00 41 89 d1 e9 ef fe\nff ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 55 8d 42 ff 48\n[ 1035.684162] RIP  [<ffffffffba3a40d0>] dql_completed+0x180/0x190\n[ 1035.684162]  RSP <ffff8f5a75483e50>\n\nIt's not the same as in 7fe0ee09 patch described.\nAs 8139cp uses shared irq mode, other device irq will trigger\ncp_interrupt to execute.\n\ncp_change_mtu\n -> cp_close\n -> cp_open\n\nIn cp_close routine  just before free_irq(), some interrupt may occur.\nIn my environment, cp_interrupt exectutes and IntrStatus is 0x4,\nexactly TxOk. That will cause cp_tx to wake device queue.\n\nAs device queue is started, cp_start_xmit and cp_open will run at same\ntime which will cause kernel BUG.\n\nFor example:\n[#] for tx descriptor\n\nAt start:\n\n[#][#][#]\nnum_queued=3\n\nAfter cp_init_hw->cp_start_hw->netdev_reset_queue:\n\n[#][#][#]\nnum_queued=0\n\nWhen 8139cp starts to work then cp_tx will check\nnum_queued mismatchs the complete_bytes.\n\nThe patch will check IntrMask before check IntrStatus in cp_interrupt.\nWhen 8139cp interrupt is disabled, just return.\n\nSigned-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/a0c61bf02f50cc9a4e3e3703bb98ce2658794bce"},{"sha":"5b0d097a69a5615e79fc64198ffb32b396798e44","author":{"name":"Christoph Paasch","email":"76034b3b6d3b031435cc9968b738d3b7190d594f@apple.com"},"message":"net: Prevent invalid access to skb->prev in __qdisc_drop_all\n\n[ Upstream commit 9410d386d0a829ace9558336263086c2fbbe8aed ]\n\n__qdisc_drop_all() accesses skb->prev to get to the tail of the\nsegment-list.\n\nWith commit 68d2f84a1368 (\"net: gro: properly remove skb from list\")\nthe skb-list handling has been changed to set skb->next to NULL and set\nthe list-poison on skb->prev.\n\nWith that change, __qdisc_drop_all() will panic when it tries to\ndereference skb->prev.\n\nSince commit 992cba7e276d (\"net: Add and use skb_list_del_init().\")\n__list_del_entry is used, leaving skb->prev unchanged (thus,\npointing to the list-head if it's the first skb of the list).\nThis will make __qdisc_drop_all modify the next-pointer of the list-head\nand result in a panic later on:\n\n[   34.501053] general protection fault: 0000 [#1] SMP KASAN PTI\n[   34.501968] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-rc2.mptcp #108\n[   34.502887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011\n[   34.504074] RIP: 0010:dev_gro_receive+0x343/0x1f90\n[   34.504751] Code: e0 48 c1 e8 03 42 80 3c 30 00 0f 85 4a 1c 00 00 4d 8b 24 24 4c 39 65 d0 0f 84 0a 04 00 00 49 8d 7c 24 38 48 89 f8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 04\n[   34.507060] RSP: 0018:ffff8883af507930 EFLAGS: 00010202\n[   34.507761] RAX: 0000000000000007 RBX: ffff8883970b2c80 RCX: 1ffff11072e165a6\n[   34.508640] RDX: 1ffff11075867008 RSI: ffff8883ac338040 RDI: 0000000000000038\n[   34.509493] RBP: ffff8883af5079d0 R08: ffff8883970b2d40 R09: 0000000000000062\n[   34.510346] R10: 0000000000000034 R11: 0000000000000000 R12: 0000000000000000\n[   34.511215] R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8883ac338008\n[   34.512082] FS:  0000000000000000(0000) GS:ffff8883af500000(0000) knlGS:0000000000000000\n[   34.513036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   34.513741] CR2: 000055ccc3e9d020 CR3: 00000003abf32000 CR4: 00000000000006e0\n[   34.514593] Call Trace:\n[   34.514893]  <IRQ>\n[   34.515157]  napi_gro_receive+0x93/0x150\n[   34.515632]  receive_buf+0x893/0x3700\n[   34.516094]  ? __netif_receive_skb+0x1f/0x1a0\n[   34.516629]  ? virtnet_probe+0x1b40/0x1b40\n[   34.517153]  ? __stable_node_chain+0x4d0/0x850\n[   34.517684]  ? kfree+0x9a/0x180\n[   34.518067]  ? __kasan_slab_free+0x171/0x190\n[   34.518582]  ? detach_buf+0x1df/0x650\n[   34.519061]  ? lapic_next_event+0x5a/0x90\n[   34.519539]  ? virtqueue_get_buf_ctx+0x280/0x7f0\n[   34.520093]  virtnet_poll+0x2df/0xd60\n[   34.520533]  ? receive_buf+0x3700/0x3700\n[   34.521027]  ? qdisc_watchdog_schedule_ns+0xd5/0x140\n[   34.521631]  ? htb_dequeue+0x1817/0x25f0\n[   34.522107]  ? sch_direct_xmit+0x142/0xf30\n[   34.522595]  ? virtqueue_napi_schedule+0x26/0x30\n[   34.523155]  net_rx_action+0x2f6/0xc50\n[   34.523601]  ? napi_complete_done+0x2f0/0x2f0\n[   34.524126]  ? kasan_check_read+0x11/0x20\n[   34.524608]  ? _raw_spin_lock+0x7d/0xd0\n[   34.525070]  ? _raw_spin_lock_bh+0xd0/0xd0\n[   34.525563]  ? kvm_guest_apic_eoi_write+0x6b/0x80\n[   34.526130]  ? apic_ack_irq+0x9e/0xe0\n[   34.526567]  __do_softirq+0x188/0x4b5\n[   34.527015]  irq_exit+0x151/0x180\n[   34.527417]  do_IRQ+0xdb/0x150\n[   34.527783]  common_interrupt+0xf/0xf\n[   34.528223]  </IRQ>\n\nThis patch makes sure that skb->prev is set to NULL when entering\nnetem_enqueue.\n\nCc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>\nCc: Tyler Hicks <tyhicks@canonical.com>\nCc: Eric Dumazet <eric.dumazet@gmail.com>\nFixes: 68d2f84a1368 (\"net: gro: properly remove skb from list\")\nSuggested-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: Christoph Paasch <cpaasch@apple.com>\nReviewed-by: Eric Dumazet <edumazet@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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/5b0d097a69a5615e79fc64198ffb32b396798e44"},{"sha":"f1d28c6ceedafb74856d2bded1492342384acdb2","author":{"name":"Eric Dumazet","email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com"},"message":"rtnetlink: ndo_dflt_fdb_dump() only work for ARPHRD_ETHER devices\n\n[ Upstream commit 688838934c231bb08f46db687e57f6d8bf82709c ]\n\nkmsan was able to trigger a kernel-infoleak using a gre device [1]\n\nnlmsg_populate_fdb_fill() has a hard coded assumption\nthat dev->addr_len is ETH_ALEN, as normally guaranteed\nfor ARPHRD_ETHER devices.\n\nA similar issue was fixed recently in commit da71577545a5\n(\"rtnetlink: Disallow FDB configuration for non-Ethernet device\")\n\n[1]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:143 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576\nCPU: 0 PID: 6697 Comm: syz-executor310 Not tainted 4.20.0-rc3+ #95\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x32d/0x480 lib/dump_stack.c:113\n kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683\n kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743\n kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634\n copyout lib/iov_iter.c:143 [inline]\n _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576\n copy_to_iter include/linux/uio.h:143 [inline]\n skb_copy_datagram_iter+0x4e2/0x1070 net/core/datagram.c:431\n skb_copy_datagram_msg include/linux/skbuff.h:3316 [inline]\n netlink_recvmsg+0x6f9/0x19d0 net/netlink/af_netlink.c:1975\n sock_recvmsg_nosec net/socket.c:794 [inline]\n sock_recvmsg+0x1d1/0x230 net/socket.c:801\n ___sys_recvmsg+0x444/0xae0 net/socket.c:2278\n __sys_recvmsg net/socket.c:2327 [inline]\n __do_sys_recvmsg net/socket.c:2337 [inline]\n __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334\n __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334\n do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291\n entry_SYSCALL_64_after_hwframe+0x63/0xe7\nRIP: 0033:0x441119\nCode: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007fffc7f008a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002f\nRAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441119\nRDX: 0000000000000040 RSI: 00000000200005c0 RDI: 0000000000000003\nRBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100\nR10: 0000000000000100 R11: 0000000000000207 R12: 0000000000402080\nR13: 0000000000402110 R14: 0000000000000000 R15: 0000000000000000\n\nUninit was stored to memory at:\n kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]\n kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]\n kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469\n kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344\n kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362\n __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162\n __nla_put lib/nlattr.c:744 [inline]\n nla_put+0x20a/0x2d0 lib/nlattr.c:802\n nlmsg_populate_fdb_fill+0x444/0x810 net/core/rtnetlink.c:3466\n nlmsg_populate_fdb net/core/rtnetlink.c:3775 [inline]\n ndo_dflt_fdb_dump+0x73a/0x960 net/core/rtnetlink.c:3807\n rtnl_fdb_dump+0x1318/0x1cb0 net/core/rtnetlink.c:3979\n netlink_dump+0xc79/0x1c90 net/netlink/af_netlink.c:2244\n __netlink_dump_start+0x10c4/0x11d0 net/netlink/af_netlink.c:2352\n netlink_dump_start include/linux/netlink.h:216 [inline]\n rtnetlink_rcv_msg+0x141b/0x1540 net/core/rtnetlink.c:4910\n netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477\n rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965\n netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]\n netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336\n netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917\n sock_sendmsg_nosec net/socket.c:621 [inline]\n sock_sendmsg net/socket.c:631 [inline]\n ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116\n __sys_sendmsg net/socket.c:2154 [inline]\n __do_sys_sendmsg net/socket.c:2163 [inline]\n __se_sys_sendmsg+0x305/0x460 net/socket.c:2161\n __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161\n do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291\n entry_SYSCALL_64_after_hwframe+0x63/0xe7\n\nUninit was created at:\n kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]\n kmsan_internal_poison_shadow+0x6d/0x130 mm/kmsan/kmsan.c:170\n kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186\n __kmalloc+0x14c/0x4d0 mm/slub.c:3825\n kmalloc include/linux/slab.h:551 [inline]\n __hw_addr_create_ex net/core/dev_addr_lists.c:34 [inline]\n __hw_addr_add_ex net/core/dev_addr_lists.c:80 [inline]\n __dev_mc_add+0x357/0x8a0 net/core/dev_addr_lists.c:670\n dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687\n ip_mc_filter_add net/ipv4/igmp.c:1128 [inline]\n igmp_group_added+0x4d4/0xb80 net/ipv4/igmp.c:1311\n __ip_mc_inc_group+0xea9/0xf70 net/ipv4/igmp.c:1444\n ip_mc_inc_group net/ipv4/igmp.c:1453 [inline]\n ip_mc_up+0x1c3/0x400 net/ipv4/igmp.c:1775\n inetdev_event+0x1d03/0x1d80 net/ipv4/devinet.c:1522\n notifier_call_chain kernel/notifier.c:93 [inline]\n __raw_notifier_call_chain kernel/notifier.c:394 [inline]\n raw_notifier_call_chain+0x13d/0x240 kernel/notifier.c:401\n __dev_notify_flags+0x3da/0x860 net/core/dev.c:1733\n dev_change_flags+0x1ac/0x230 net/core/dev.c:7569\n do_setlink+0x165f/0x5ea0 net/core/rtnetlink.c:2492\n rtnl_newlink+0x2ad7/0x35a0 net/core/rtnetlink.c:3111\n rtnetlink_rcv_msg+0x1148/0x1540 net/core/rtnetlink.c:4947\n netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477\n rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965\n netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]\n netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336\n netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917\n sock_sendmsg_nosec net/socket.c:621 [inline]\n sock_sendmsg net/socket.c:631 [inline]\n ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116\n __sys_sendmsg net/socket.c:2154 [inline]\n __do_sys_sendmsg net/socket.c:2163 [inline]\n __se_sys_sendmsg+0x305/0x460 net/socket.c:2161\n __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161\n do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291\n entry_SYSCALL_64_after_hwframe+0x63/0xe7\n\nBytes 36-37 of 105 are uninitialized\nMemory access of size 105 starts at ffff88819686c000\nData copied to user address 0000000020000380\n\nFixes: d83b06036048 (\"net: add fdb generic dump routine\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: John Fastabend <john.fastabend@gmail.com>\nCc: Ido Schimmel <idosch@mellanox.com>\nCc: David Ahern <dsahern@gmail.com>\nReviewed-by: Ido Schimmel <idosch@mellanox.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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/f1d28c6ceedafb74856d2bded1492342384acdb2"},{"sha":"eb75b9b7ec77ed5d11316ef99ee905a16b432430","author":{"name":"Nicolas Dichtel","email":"7864bb1e0e12322ea18ea731d051b95b75140567@6wind.com"},"message":"tun: forbid iface creation with rtnl ops\n\n[ Upstream commit 35b827b6d06199841a83839e8bb69c0cd13a28be ]\n\nIt's not supported right now (the goal of the initial patch was to support\n'ip link del' only).\n\nBefore the patch:\n$ ip link add foo type tun\n[  239.632660] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000\n[snip]\n[  239.636410] RIP: 0010:register_netdevice+0x8e/0x3a0\n\nThis panic occurs because dev->netdev_ops is not set by tun_setup(). But to\nhave something usable, it will require more than just setting\nnetdev_ops.\n\nFixes: f019a7a594d9 (\"tun: Implement ip link del tunXXX\")\nCC: Eric W. Biederman <ebiederm@xmission.com>\nSigned-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/eb75b9b7ec77ed5d11316ef99ee905a16b432430"},{"sha":"ba5720a0d3db9061a0cff3874ce3ab572c9eec6e","author":{"name":"Stefano Brivio","email":"efa1d7a1f7e06da157cba8418bde1140b06b0968@redhat.com"},"message":"neighbour: Avoid writing before skb->head in neigh_hh_output()\n\n[ Upstream commit e6ac64d4c4d095085d7dd71cbd05704ac99829b2 ]\n\nWhile skb_push() makes the kernel panic if the skb headroom is less than\nthe unaligned hardware header size, it will proceed normally in case we\ncopy more than that because of alignment, and we'll silently corrupt\nadjacent slabs.\n\nIn the case fixed by the previous patch,\n\"ipv6: Check available headroom in ip6_xmit() even without options\", we\nend up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware\nheader and write 16 bytes, starting 2 bytes before the allocated buffer.\n\nAlways check we're not writing before skb->head and, if the headroom is\nnot enough, warn and drop the packet.\n\nv2:\n - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet\n   (Eric Dumazet)\n - if we avoid the panic, though, we need to explicitly check the headroom\n   before the memcpy(), otherwise we'll have corrupted slabs on a running\n   kernel, after we warn\n - use __skb_push() instead of skb_push(), as the headroom check is\n   already implemented here explicitly (Eric Dumazet)\n\nSigned-off-by: Stefano Brivio <sbrivio@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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/ba5720a0d3db9061a0cff3874ce3ab572c9eec6e"},{"sha":"6699df6605891e6aa5d1d208fc0c0aff022a191b","author":{"name":"Stefano Brivio","email":"efa1d7a1f7e06da157cba8418bde1140b06b0968@redhat.com"},"message":"ipv6: Check available headroom in ip6_xmit() even without options\n\n[ Upstream commit 66033f47ca60294a95fc85ec3a3cc909dab7b765 ]\n\nEven if we send an IPv6 packet without options, MAX_HEADER might not be\nenough to account for the additional headroom required by alignment of\nhardware headers.\n\nOn a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL,\nsending short SCTP packets over IPv4 over L2TP over IPv6, we start with\n100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54\nbytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2().\n\nThose would be enough to append our 14 bytes header, but we're going to\nalign that to 16 bytes, and write 2 bytes out of the allocated slab in\nneigh_hh_output().\n\nKASan says:\n\n[  264.967848] ==================================================================\n[  264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70\n[  264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201\n[  264.967870]\n[  264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1\n[  264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)\n[  264.967887] Call Trace:\n[  264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0)\n[  264.967903]  [<00000000017e379c>] dump_stack+0x23c/0x290\n[  264.967912]  [<00000000007bc594>] print_address_description+0xf4/0x290\n[  264.967919]  [<00000000007bc8fc>] kasan_report+0x13c/0x240\n[  264.967927]  [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70\n[  264.967935]  [<000000000163f890>] ip6_finish_output+0x430/0x7f0\n[  264.967943]  [<000000000163fe44>] ip6_output+0x1f4/0x580\n[  264.967953]  [<000000000163882a>] ip6_xmit+0xfea/0x1ce8\n[  264.967963]  [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8\n[  264.968033]  [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core]\n[  264.968037]  [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth]\n[  264.968041]  [<0000000001220020>] dev_hard_start_xmit+0x268/0x928\n[  264.968069]  [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350\n[  264.968071]  [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478\n[  264.968075]  [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0\n[  264.968078]  [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8\n[  264.968081]  [<00000000013ddd1e>] ip_output+0x226/0x4c0\n[  264.968083]  [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938\n[  264.968100]  [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp]\n[  264.968116]  [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp]\n[  264.968131]  [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp]\n[  264.968146]  [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp]\n[  264.968161]  [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp]\n[  264.968177]  [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp]\n[  264.968192]  [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp]\n[  264.968208]  [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp]\n[  264.968212]  [<0000000001197942>] __sys_connect+0x21a/0x450\n[  264.968215]  [<000000000119aff8>] sys_socketcall+0x3d0/0xb08\n[  264.968218]  [<000000000184ea7a>] system_call+0x2a2/0x2c0\n\n[...]\n\nJust like ip_finish_output2() does for IPv4, check that we have enough\nheadroom in ip6_xmit(), and reallocate it if we don't.\n\nThis issue is older than git history.\n\nReported-by: Jianlin Shi <jishi@redhat.com>\nSigned-off-by: Stefano Brivio <sbrivio@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/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/6699df6605891e6aa5d1d208fc0c0aff022a191b"},{"sha":"8b0c50ca0218217aa42cf4e52c13da380d014d5d","author":{"name":"Nathan Chancellor","email":"f65d3f2dc139dcfe7b6f0b0a466af3bc5fed8fa7@gmail.com"},"message":"ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup\n\n[ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ]\n\nWhen building the kernel with Clang, the following section mismatch\nwarning appears:\n\nWARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from\nthe function omap44xx_prm_late_init() to the function\n.init.text:omap44xx_prm_enable_io_wakeup()\nThe function omap44xx_prm_late_init() references\nthe function __init omap44xx_prm_enable_io_wakeup().\nThis is often because omap44xx_prm_late_init lacks a __init\nannotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong.\n\nRemove the __init annotation from omap44xx_prm_enable_io_wakeup so there\nis no more mismatch.\n\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/8b0c50ca0218217aa42cf4e52c13da380d014d5d"},{"sha":"b8468796b6712275cdeb1e4684c8bb0da7ee239c","author":{"name":"Janusz Krzysztofik","email":"e8017e9f63237137f07462d2e367b72c56a67abb@gmail.com"},"message":"ARM: OMAP1: ams-delta: Fix possible use of uninitialized field\n\n[ Upstream commit cec83ff1241ec98113a19385ea9e9cfa9aa4125b ]\n\nWhile playing with initialization order of modem device, it has been\ndiscovered that under some circumstances (early console init, I\nbelieve) its .pm() callback may be called before the\nuart_port->private_data pointer is initialized from\nplat_serial8250_port->private_data, resulting in NULL pointer\ndereference.  Fix it by checking for uninitialized pointer before using\nit in modem_pm().\n\nFixes: aabf31737a6a (\"ARM: OMAP1: ams-delta: update the modem to use regulator API\")\nSigned-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/b8468796b6712275cdeb1e4684c8bb0da7ee239c"},{"sha":"b8115cdf32d41de013296e54d58e1b2ca81f35e2","author":{"name":"YueHaibing","email":"87ef4e6170d5e1d30adb7567acad1fcb98f93b6e@huawei.com"},"message":"sysv: return 'err' instead of 0 in __sysv_write_inode\n\n[ Upstream commit c4b7d1ba7d263b74bb72e9325262a67139605cde ]\n\nFixes gcc '-Wunused-but-set-variable' warning:\n\nfs/sysv/inode.c: In function '__sysv_write_inode':\nfs/sysv/inode.c:239:6: warning:\n variable 'err' set but not used [-Wunused-but-set-variable]\n\n__sysv_write_inode should return 'err' instead of 0\n\nFixes: 05459ca81ac3 (\"repair sysv_write_inode(), switch sysv to simple_fsync()\")\nSigned-off-by: YueHaibing <yuehaibing@huawei.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/b8115cdf32d41de013296e54d58e1b2ca81f35e2"},{"sha":"9453bca3441e67f70f1860a493d3989cd597aca2","author":{"name":"Thomas Richter","email":"8efd8ac704d21550d1708b5fda9fd8afae04d143@linux.ibm.com"},"message":"s390/cpum_cf: Reject request for sampling in event initialization\n\n[ Upstream commit 613a41b0d16e617f46776a93b975a1eeea96417c ]\n\nOn s390 command perf top fails\n[root@s35lp76 perf] # ./perf top -F100000  --stdio\n   Error:\n   cycles: PMU Hardware doesn't support sampling/overflow-interrupts.\n   \tTry 'perf stat'\n[root@s35lp76 perf] #\n\nUsing event -e rb0000 works as designed.  Event rb0000 is the event\nnumber of the sampling facility for basic sampling.\n\nDuring system start up the following PMUs are installed in the kernel's\nPMU list (from head to tail):\n   cpum_cf --> s390 PMU counter facility device driver\n   cpum_sf --> s390 PMU sampling facility device driver\n   uprobe\n   kprobe\n   tracepoint\n   task_clock\n   cpu_clock\n\nPerf top executes following functions and calls perf_event_open(2) system\ncall with different parameters many times:\n\ncmd_top\n--> __cmd_top\n    --> perf_evlist__add_default\n        --> __perf_evlist__add_default\n            --> perf_evlist__new_cycles (creates event type:0 (HW)\n\t\t\t    \t\tconfig 0 (CPU_CYCLES)\n\t        --> perf_event_attr__set_max_precise_ip\n\t\t    Uses perf_event_open(2) to detect correct\n\t\t    precise_ip level. Fails 3 times on s390 which is ok.\n\nThen functions cmd_top\n--> __cmd_top\n    --> perf_top__start_counters\n        -->perf_evlist__config\n\t   --> perf_can_comm_exec\n               --> perf_probe_api\n\t           This functions test support for the following events:\n\t\t   \"cycles:u\", \"instructions:u\", \"cpu-clock:u\" using\n\t\t   --> perf_do_probe_api\n\t\t       --> perf_event_open_cloexec\n\t\t           Test the close on exec flag support with\n\t\t\t   perf_event_open(2).\n\t               perf_do_probe_api returns true if the event is\n\t\t       supported.\n\t\t       The function returns true because event cpu-clock is\n\t\t       supported by the PMU cpu_clock.\n\t               This is achieved by many calls to perf_event_open(2).\n\nFunction perf_top__start_counters now calls perf_evsel__open() for every\nevent, which is the default event cpu_cycles (config:0) and type HARDWARE\n(type:0) which a predfined frequence of 4000.\n\nGiven the above order of the PMU list, the PMU cpum_cf gets called first\nand returns 0, which indicates support for this sampling. The event is\nfully allocated in the function perf_event_open (file kernel/event/core.c\nnear line 10521 and the following check fails:\n\n        event = perf_event_alloc(&attr, cpu, task, group_leader, NULL,\n\t\t                 NULL, NULL, cgroup_fd);\n\tif (IS_ERR(event)) {\n\t\terr = PTR_ERR(event);\n\t\tgoto err_cred;\n\t}\n\n        if (is_sampling_event(event)) {\n\t\tif (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) {\n\t\t\terr = -EOPNOTSUPP;\n\t\t\tgoto err_alloc;\n\t\t}\n\t}\n\nThe check for the interrupt capabilities fails and the system call\nperf_event_open() returns -EOPNOTSUPP (-95).\n\nAdd a check to return -ENODEV when sampling is requested in PMU cpum_cf.\nThis allows common kernel code in the perf_event_open() system call to\ntest the next PMU in above list.\n\nFixes: 97b1198fece0 (\" \"s390, perf: Use common PMU interrupt disabled code\")\nSigned-off-by: Thomas Richter <tmricht@linux.ibm.com>\nReviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/9453bca3441e67f70f1860a493d3989cd597aca2"},{"sha":"d2fc85f406b7d50bcc1f18d0db57379d71867a4d","author":{"name":"Huacai Chen","email":"bddc6ef64099649954804bf58f2e4dee9b3b798f@lemote.com"},"message":"hwmon: (w83795) temp4_type has writable permission\n\n[ Upstream commit 09aaf6813cfca4c18034fda7a43e68763f34abb1 ]\n\nBoth datasheet and comments of store_temp_mode() tell us that temp1~4_type\nis writable, so fix it.\n\nSigned-off-by: Yao Wang <wangyao@lemote.com>\nSigned-off-by: Huacai Chen <chenhc@lemote.com>\nFixes: 39deb6993e7c (\" hwmon: (w83795) Simplify temperature sensor type handling\")\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/d2fc85f406b7d50bcc1f18d0db57379d71867a4d"},{"sha":"e91a56155d83d512263f5a09ea0e53aee2488beb","author":{"name":"Robbie Ko","email":"3e8473ebda093339b57e9fa2dd0b2ba18a79d878@synology.com"},"message":"Btrfs: send, fix infinite loop due to directory rename dependencies\n\n[ Upstream commit a4390aee72713d9e73f1132bcdeb17d72fbbf974 ]\n\nWhen doing an incremental send, due to the need of delaying directory move\n(rename) operations we can end up in infinite loop at\napply_children_dir_moves().\n\nAn example scenario that triggers this problem is described below, where\ndirectory names correspond to the numbers of their respective inodes.\n\nParent snapshot:\n\n .\n |--- 261/\n       |--- 271/\n             |--- 266/\n                   |--- 259/\n                   |--- 260/\n                   |     |--- 267\n                   |\n                   |--- 264/\n                   |     |--- 258/\n                   |           |--- 257/\n                   |\n                   |--- 265/\n                   |--- 268/\n                   |--- 269/\n                   |     |--- 262/\n                   |\n                   |--- 270/\n                   |--- 272/\n                   |     |--- 263/\n                   |     |--- 275/\n                   |\n                   |--- 274/\n                         |--- 273/\n\nSend snapshot:\n\n .\n |-- 275/\n      |-- 274/\n           |-- 273/\n                |-- 262/\n                     |-- 269/\n                          |-- 258/\n                               |-- 271/\n                                    |-- 268/\n                                         |-- 267/\n                                              |-- 270/\n                                                   |-- 259/\n                                                   |    |-- 265/\n                                                   |\n                                                   |-- 272/\n                                                        |-- 257/\n                                                             |-- 260/\n                                                             |-- 264/\n                                                                  |-- 263/\n                                                                       |-- 261/\n                                                                            |-- 266/\n\nWhen processing inode 257 we delay its move (rename) operation because its\nnew parent in the send snapshot, inode 272, was not yet processed. Then\nwhen processing inode 272, we delay the move operation for that inode\nbecause inode 274 is its ancestor in the send snapshot. Finally we delay\nthe move operation for inode 274 when processing it because inode 275 is\nits new parent in the send snapshot and was not yet moved.\n\nWhen finishing processing inode 275, we start to do the move operations\nthat were previously delayed (at apply_children_dir_moves()), resulting in\nthe following iterations:\n\n1) We issue the move operation for inode 274;\n\n2) Because inode 262 depended on the move operation of inode 274 (it was\n   delayed because 274 is its ancestor in the send snapshot), we issue the\n   move operation for inode 262;\n\n3) We issue the move operation for inode 272, because it was delayed by\n   inode 274 too (ancestor of 272 in the send snapshot);\n\n4) We issue the move operation for inode 269 (it was delayed by 262);\n\n5) We issue the move operation for inode 257 (it was delayed by 272);\n\n6) We issue the move operation for inode 260 (it was delayed by 272);\n\n7) We issue the move operation for inode 258 (it was delayed by 269);\n\n8) We issue the move operation for inode 264 (it was delayed by 257);\n\n9) We issue the move operation for inode 271 (it was delayed by 258);\n\n10) We issue the move operation for inode 263 (it was delayed by 264);\n\n11) We issue the move operation for inode 268 (it was delayed by 271);\n\n12) We verify if we can issue the move operation for inode 270 (it was\n    delayed by 271). We detect a path loop in the current state, because\n    inode 267 needs to be moved first before we can issue the move\n    operation for inode 270. So we delay again the move operation for\n    inode 270, this time we will attempt to do it after inode 267 is\n    moved;\n\n13) We issue the move operation for inode 261 (it was delayed by 263);\n\n14) We verify if we can issue the move operation for inode 266 (it was\n    delayed by 263). We detect a path loop in the current state, because\n    inode 270 needs to be moved first before we can issue the move\n    operation for inode 266. So we delay again the move operation for\n    inode 266, this time we will attempt to do it after inode 270 is\n    moved (its move operation was delayed in step 12);\n\n15) We issue the move operation for inode 267 (it was delayed by 268);\n\n16) We verify if we can issue the move operation for inode 266 (it was\n    delayed by 270). We detect a path loop in the current state, because\n    inode 270 needs to be moved first before we can issue the move\n    operation for inode 266. So we delay again the move operation for\n    inode 266, this time we will attempt to do it after inode 270 is\n    moved (its move operation was delayed in step 12). So here we added\n    again the same delayed move operation that we added in step 14;\n\n17) We attempt again to see if we can issue the move operation for inode\n    266, and as in step 16, we realize we can not due to a path loop in\n    the current state due to a dependency on inode 270. Again we delay\n    inode's 266 rename to happen after inode's 270 move operation, adding\n    the same dependency to the empty stack that we did in steps 14 and 16.\n    The next iteration will pick the same move dependency on the stack\n    (the only entry) and realize again there is still a path loop and then\n    again the same dependency to the stack, over and over, resulting in\n    an infinite loop.\n\nSo fix this by preventing adding the same move dependency entries to the\nstack by removing each pending move record from the red black tree of\npending moves. This way the next call to get_pending_dir_moves() will\nnot return anything for the current parent inode.\n\nA test case for fstests, with this reproducer, follows soon.\n\nSigned-off-by: Robbie Ko <robbieko@synology.com>\nReviewed-by: Filipe Manana <fdmanana@suse.com>\n[Wrote changelog with example and more clear explanation]\nSigned-off-by: Filipe Manana <fdmanana@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/e91a56155d83d512263f5a09ea0e53aee2488beb"},{"sha":"d536c4e93c3dd0b215e80cc523b46ef9f9481a1c","author":{"name":"Peter Ujfalusi","email":"e5c0b4cdf99ae1d408b9c497159e74b54e02e008@ti.com"},"message":"ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE\n\n[ Upstream commit 373a500e34aea97971c9d71e45edad458d3da98f ]\n\nWe need to block sleep states which would require longer time to leave than\nthe time the DMA must react to the DMA request in order to keep the FIFO\nserviced without under of overrun.\n\nSigned-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>\nAcked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/d536c4e93c3dd0b215e80cc523b46ef9f9481a1c"},{"sha":"ba318581cddd7a254cf854fa9ad8bd5170edd18e","author":{"name":"Peter Ujfalusi","email":"e5c0b4cdf99ae1d408b9c497159e74b54e02e008@ti.com"},"message":"ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE\n\n[ Upstream commit ffdcc3638c58d55a6fa68b6e5dfd4fb4109652eb ]\n\nWe need to block sleep states which would require longer time to leave than\nthe time the DMA must react to the DMA request in order to keep the FIFO\nserviced without overrun.\n\nSigned-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>\nAcked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/ba318581cddd7a254cf854fa9ad8bd5170edd18e"},{"sha":"4eb2095c80a56fec125c06465a2f61dcc3ed5369","author":{"name":"Pan Bian","email":"10d7ad8858c5990f87a888a439b19a315f02cd42@163.com"},"message":"exportfs: do not read dentry after free\n\n[ Upstream commit 2084ac6c505a58f7efdec13eba633c6aaa085ca5 ]\n\nThe function dentry_connected calls dput(dentry) to drop the previously\nacquired reference to dentry. In this case, dentry can be released.\nAfter that, IS_ROOT(dentry) checks the condition\n(dentry == dentry->d_parent), which may result in a use-after-free bug.\nThis patch directly compares dentry with its parent obtained before\ndropping the reference.\n\nFixes: a056cc8934c(\"exportfs: stop retrying once we race with\nrename/remove\")\n\nSigned-off-by: Pan Bian <bianpan2016@163.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/4eb2095c80a56fec125c06465a2f61dcc3ed5369"},{"sha":"9ea692784b84a0e03ace94b6a20cc6496930b84a","author":{"name":"Aaro Koskinen","email":"13423a3f3006b5859cfceae66d59451f5eb4e205@iki.fi"},"message":"USB: omap_udc: use devm_request_irq()\n\n[ Upstream commit 286afdde1640d8ea8916a0f05e811441fbbf4b9d ]\n\nThe current code fails to release the third irq on the error path\n(observed by reading the code), and we get also multiple WARNs with\nfailing gadget drivers due to duplicate IRQ releases. Fix by using\ndevm_request_irq().\n\nSigned-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/9ea692784b84a0e03ace94b6a20cc6496930b84a"},{"sha":"3737d8b658159dca7fc48f542f3eda8c0a3145be","author":{"name":"Aaro Koskinen","email":"13423a3f3006b5859cfceae66d59451f5eb4e205@iki.fi"},"message":"USB: omap_udc: fix crashes on probe error and module removal\n\n[ Upstream commit 99f700366fcea1aa2fa3c49c99f371670c3c62f8 ]\n\nWe currently crash if usb_add_gadget_udc_release() fails, since the\nudc->done is not initialized until in the remove function.\nFurthermore, on module removal the udc data is accessed although\nthe release function is already triggered by usb_del_gadget_udc()\nearly in the function.\n\nFix by rewriting the release and remove functions, basically moving\nall the cleanup into the release function, and doing the completion\nonly in the module removal case.\n\nThe patch fixes omap_udc module probe with a failing gadged, and also\nallows the removal of omap_udc. Tested by running \"modprobe omap_udc;\nmodprobe -r omap_udc\" in a loop.\n\nSigned-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/3737d8b658159dca7fc48f542f3eda8c0a3145be"},{"sha":"0f5a5ea30702ed60f2183bdca44b2b5a8d4252a3","author":{"name":"Aaro Koskinen","email":"13423a3f3006b5859cfceae66d59451f5eb4e205@iki.fi"},"message":"USB: omap_udc: fix omap_udc_start() on 15xx machines\n\n[ Upstream commit 6ca6695f576b8453fe68865e84d25946d63b10ad ]\n\nOn OMAP 15xx machines there are no transceivers, and omap_udc_start()\nalways fails as it forgot to adjust the default return value.\n\nSigned-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/0f5a5ea30702ed60f2183bdca44b2b5a8d4252a3"},{"sha":"6d22ef74f416cc45567ebcb64fd0c780f9317077","author":{"name":"Aaro Koskinen","email":"13423a3f3006b5859cfceae66d59451f5eb4e205@iki.fi"},"message":"USB: omap_udc: fix USB gadget functionality on Palm Tungsten E\n\n[ Upstream commit 2c2322fbcab8102b8cadc09d66714700a2da42c2 ]\n\nOn Palm TE nothing happens when you try to use gadget drivers and plug\nthe USB cable. Fix by adding the board to the vbus sense quirk list.\n\nSigned-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/6d22ef74f416cc45567ebcb64fd0c780f9317077"},{"sha":"38c29898c6bfbf8d566f451fb74cb072929c8a8d","author":{"name":"Yi Wang","email":"1ffa8c64bbb3068d36b98b480f61fad719ecfb84@zte.com.cn"},"message":"KVM: x86: fix empty-body warnings\n\n[ Upstream commit 354cb410d87314e2eda344feea84809e4261570a ]\n\nWe get the following warnings about empty statements when building\nwith 'W=1':\n\narch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]\narch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]\narch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]\narch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]\n\nRework the debug helper macro to get rid of these warnings.\n\nSigned-off-by: Yi Wang <wang.yi59@zte.com.cn>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Sasha Levin <sashal@kernel.org>","distinct":true,"url":"https://api.github.com/repos/AdityaKevin/android_kernel_xiaomi_msm8937-1/commits/38c29898c6bfbf8d566f451fb74cb072929c8a8d"}]}
{"actor":{"display_login":"AdityaKevin"}}