commit 10bd1f305f5f9945bac76a6ddc5371ed2d159bf2 Author: Greg Kroah-Hartman Date: Tue Jan 12 19:49:06 2021 +0100 Linux 4.9.251 Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210111130033.676306636@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 90dc59e67b275ea394307667eecff04daf518620 Author: Ying-Tsun Huang Date: Tue Dec 15 15:07:20 2020 +0800 x86/mtrr: Correct the range check before performing MTRR type lookups commit cb7f4a8b1fb426a175d1708f05581939c61329d4 upstream. In mtrr_type_lookup(), if the input memory address region is not in the MTRR, over 4GB, and not over the top of memory, a write-back attribute is returned. These condition checks are for ensuring the input memory address region is actually mapped to the physical memory. However, if the end address is just aligned with the top of memory, the condition check treats the address is over the top of memory, and write-back attribute is not returned. And this hits in a real use case with NVDIMM: the nd_pmem module tries to map NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM is the last of the DIMMs, the performance of this NVDIMM becomes very low since it is aligned with the top of memory and its memory type is uncached-minus. Move the input end address change to inclusive up into mtrr_type_lookup(), before checking for the top of memory in either mtrr_type_lookup_{variable,fixed}() helpers. [ bp: Massage commit message. ] Fixes: 0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()") Signed-off-by: Ying-Tsun Huang Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20201215070721.4349-1-ying-tsun.huang@amd.com Signed-off-by: Greg Kroah-Hartman commit e27bf5d572b5d9a71d911d94dcd0993026d47486 Author: Florian Westphal Date: Tue Dec 22 23:23:56 2020 +0100 netfilter: xt_RATEEST: reject non-null terminated string from userspace commit 6cb56218ad9e580e519dcd23bfb3db08d8692e5a upstream. syzbot reports: detected buffer overflow in strlen [..] Call Trace: strlen include/linux/string.h:325 [inline] strlcpy include/linux/string.h:348 [inline] xt_rateest_tg_checkentry+0x2a5/0x6b0 net/netfilter/xt_RATEEST.c:143 strlcpy assumes src is a c-string. Check info->name before its used. Reported-by: syzbot+e86f7c428c8c50db65b4@syzkaller.appspotmail.com Fixes: 5859034d7eb8793 ("[NETFILTER]: x_tables: add RATEEST target") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 0a4feb89b0acfb5ca53cc494204f0aaf22fed7bd Author: Vasily Averin Date: Thu Dec 17 17:53:18 2020 +0300 netfilter: ipset: fix shift-out-of-bounds in htable_bits() commit 5c8193f568ae16f3242abad6518dc2ca6c8eef86 upstream. htable_bits() can call jhash_size(32) and trigger shift-out-of-bounds UBSAN: shift-out-of-bounds in net/netfilter/ipset/ip_set_hash_gen.h:151:6 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 0 PID: 8498 Comm: syz-executor519 Not tainted 5.10.0-rc7-next-20201208-syzkaller #0 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 htable_bits net/netfilter/ipset/ip_set_hash_gen.h:151 [inline] hash_mac_create.cold+0x58/0x9b net/netfilter/ipset/ip_set_hash_gen.h:1524 ip_set_create+0x610/0x1380 net/netfilter/ipset/ip_set_core.c:1115 nfnetlink_rcv_msg+0xecc/0x1180 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x1ac/0x420 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2345 ___sys_sendmsg+0xf3/0x170 net/socket.c:2399 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This patch replaces htable_bits() by simple fls(hashsize - 1) call: it alone returns valid nbits both for round and non-round hashsizes. It is normal to set any nbits here because it is validated inside following htable_size() call which returns 0 for nbits>31. Fixes: 1feab10d7e6d("netfilter: ipset: Unified hash type generation") Reported-by: syzbot+d66bfadebca46cf61a2b@syzkaller.appspotmail.com Signed-off-by: Vasily Averin Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 00d2619b8fb4bdb0c0e99c00b9eabb77e0352c59 Author: Bard Liao Date: Tue Jan 5 17:11:45 2021 +0800 Revert "device property: Keep secondary firmware node secondary by type" commit 47f4469970d8861bc06d2d4d45ac8200ff07c693 upstream. While commit d5dcce0c414f ("device property: Keep secondary firmware node secondary by type") describes everything correct in its commit message, the change it made does the opposite and original commit c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") was fully correct. Revert the former one here and improve documentation in the next patch. Fixes: d5dcce0c414f ("device property: Keep secondary firmware node secondary by type") Signed-off-by: Bard Liao Reviewed-by: Andy Shevchenko Reviewed-by: Heikki Krogerus Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ca6efb442128709088771c3738e24880b4b001dd Author: bo liu Date: Tue Dec 29 11:52:26 2020 +0800 ALSA: hda/conexant: add a new hda codec CX11970 commit 744a11abc56405c5a106e63da30a941b6d27f737 upstream. The current kernel does not support the cx11970 codec chip. Add a codec configuration item to kernel. [ Minor coding style fix by tiwai ] Signed-off-by: bo liu Cc: Link: https://lore.kernel.org/r/20201229035226.62120-1-bo.liu@senarytech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 285e5029d8fcbbb0cb6522e31bd7d81cb551e08c Author: Dan Williams Date: Wed Dec 2 22:28:12 2020 -0800 x86/mm: Fix leak of pmd ptlock commit d1c5246e08eb64991001d97a3bd119c93edbc79a upstream. Commit 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") introduced a new location where a pmd was released, but neglected to run the pmd page destructor. In fact, this happened previously for a different pmd release path and was fixed by commit: c283610e44ec ("x86, mm: do not leak page->ptl for pmd page tables"). This issue was hidden until recently because the failure mode is silent, but commit: b2b29d6d0119 ("mm: account PMD tables like PTE tables") turns the failure mode into this signature: BUG: Bad page state in process lt-pmem-ns pfn:15943d page:000000007262ed7b refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x15943d flags: 0xaffff800000000() raw: 00affff800000000 dead000000000100 0000000000000000 0000000000000000 raw: 0000000000000000 ffff913a029bcc08 00000000fffffbff 0000000000000000 page dumped because: nonzero mapcount [..] dump_stack+0x8b/0xb0 bad_page.cold+0x63/0x94 free_pcp_prepare+0x224/0x270 free_unref_page+0x18/0xd0 pud_free_pmd_page+0x146/0x160 ioremap_pud_range+0xe3/0x350 ioremap_page_range+0x108/0x160 __ioremap_caller.constprop.0+0x174/0x2b0 ? memremap+0x7a/0x110 memremap+0x7a/0x110 devm_memremap+0x53/0xa0 pmem_attach_disk+0x4ed/0x530 [nd_pmem] ? __devm_release_region+0x52/0x80 nvdimm_bus_probe+0x85/0x210 [libnvdimm] Given this is a repeat occurrence it seemed prudent to look for other places where this destructor might be missing and whether a better helper is needed. try_to_free_pmd_page() looks like a candidate, but testing with setting up and tearing down pmd mappings via the dax unit tests is thus far not triggering the failure. As for a better helper pmd_free() is close, but it is a messy fit due to requiring an @mm arg. Also, ___pmd_free_tlb() wants to call paravirt_tlb_remove_table() instead of free_page(), so open-coded pgtable_pmd_page_dtor() seems the best way forward for now. Debugged together with Matthew Wilcox . Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Dan Williams Signed-off-by: Borislav Petkov Tested-by: Yi Zhang Acked-by: Peter Zijlstra (Intel) Cc: Link: https://lkml.kernel.org/r/160697689204.605323.17629854984697045602.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman commit ce4ea1f59369ff58df9a35368b5fa53a46b94c59 Author: Johan Hovold Date: Fri Jan 8 15:55:28 2021 +0100 USB: serial: keyspan_pda: remove unused variable Remove an unused variable which was mistakingly left by commit 37faf5061541 ("USB: serial: keyspan_pda: fix write-wakeup use-after-free") and only removed by a later change. This is needed to suppress a W=1 warning about the unused variable in the stable trees that the build bots triggers. Reported-by: kernel test robot Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 225330e682fa9aaa152287b49dea1ce50fbe0a92 Author: Eddie Hung Date: Tue Dec 29 18:53:35 2020 +0800 usb: gadget: configfs: Fix use-after-free issue with udc_name commit 64e6bbfff52db4bf6785fab9cffab850b2de6870 upstream. There is a use-after-free issue, if access udc_name in function gadget_dev_desc_UDC_store after another context free udc_name in function unregister_gadget. Context 1: gadget_dev_desc_UDC_store()->unregister_gadget()-> free udc_name->set udc_name to NULL Context 2: gadget_dev_desc_UDC_show()-> access udc_name Call trace: dump_backtrace+0x0/0x340 show_stack+0x14/0x1c dump_stack+0xe4/0x134 print_address_description+0x78/0x478 __kasan_report+0x270/0x2ec kasan_report+0x10/0x18 __asan_report_load1_noabort+0x18/0x20 string+0xf4/0x138 vsnprintf+0x428/0x14d0 sprintf+0xe4/0x12c gadget_dev_desc_UDC_show+0x54/0x64 configfs_read_file+0x210/0x3a0 __vfs_read+0xf0/0x49c vfs_read+0x130/0x2b4 SyS_read+0x114/0x208 el0_svc_naked+0x34/0x38 Add mutex_lock to protect this kind of scenario. Signed-off-by: Eddie Hung Signed-off-by: Macpaul Lin Reviewed-by: Peter Chen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1609239215-21819-1-git-send-email-macpaul.lin@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 1b1a692c82f1b11da2b94358acf499901c358949 Author: Chandana Kishori Chiluveru Date: Tue Dec 29 14:44:43 2020 -0800 usb: gadget: configfs: Preserve function ordering after bind failure commit 6cd0fe91387917be48e91385a572a69dfac2f3f7 upstream. When binding the ConfigFS gadget to a UDC, the functions in each configuration are added in list order. However, if usb_add_function() fails, the failed function is put back on its configuration's func_list and purge_configs_funcs() is called to further clean up. purge_configs_funcs() iterates over the configurations and functions in forward order, calling unbind() on each of the previously added functions. But after doing so, each function gets moved to the tail of the configuration's func_list. This results in reshuffling the original order of the functions within a configuration such that the failed function now appears first even though it may have originally appeared in the middle or even end of the list. At this point if the ConfigFS gadget is attempted to re-bind to the UDC, the functions will be added in a different order than intended, with the only recourse being to remove and relink the functions all over again. An example of this as follows: ln -s functions/mass_storage.0 configs/c.1 ln -s functions/ncm.0 configs/c.1 ln -s functions/ffs.adb configs/c.1 # oops, forgot to start adbd echo "" > UDC # fails start adbd echo "" > UDC # now succeeds, but... # bind order is # "ADB", mass_storage, ncm [30133.118289] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520 [30133.119875] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520 [30133.119974] using random self ethernet address [30133.120002] using random host ethernet address [30133.139604] usb0: HOST MAC 3e:27:46:ba:3e:26 [30133.140015] usb0: MAC 6e:28:7e:42:66:6a [30133.140062] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520 [30133.140081] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 --> -19 [30133.140098] configfs-gadget gadget: unbind function 'Mass Storage Function'/ffffff810af87200 [30133.140119] configfs-gadget gadget: unbind function 'cdc_network'/ffffff80f48d1a00 [30133.173201] configfs-gadget a600000.dwc3: failed to start g1: -19 [30136.661933] init: starting service 'adbd'... [30136.700126] read descriptors [30136.700413] read strings [30138.574484] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520 [30138.575497] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520 [30138.575554] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520 [30138.575631] using random self ethernet address [30138.575660] using random host ethernet address [30138.595338] usb0: HOST MAC 2e:cf:43:cd:ca:c8 [30138.597160] usb0: MAC 6a:f0:9f:ee:82:a0 [30138.791490] configfs-gadget gadget: super-speed config #1: c Fix this by reversing the iteration order of the functions in purge_config_funcs() when unbinding them, and adding them back to the config's func_list at the head instead of the tail. This ensures that we unbind and unwind back to the original list order. Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface") Signed-off-by: Chandana Kishori Chiluveru Signed-off-by: Jack Pham Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20201229224443.31623-1-jackp@codeaurora.org Cc: stable Signed-off-by: Greg Kroah-Hartman commit 5423d2adbf870257089a2873239ad93655db7e26 Author: Sriharsha Allenki Date: Wed Dec 2 18:32:20 2020 +0530 usb: gadget: Fix spinlock lockup on usb_function_deactivate commit 5cc35c224a80aa5a5a539510ef049faf0d6ed181 upstream. There is a spinlock lockup as part of composite_disconnect when it tries to acquire cdev->lock as part of usb_gadget_deactivate. This is because the usb_gadget_deactivate is called from usb_function_deactivate with the same spinlock held. This would result in the below call stack and leads to stall. rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: 3-...0: (1 GPs behind) idle=162/1/0x4000000000000000 softirq=10819/10819 fqs=2356 (detected by 2, t=5252 jiffies, g=20129, q=3770) Task dump for CPU 3: task:uvc-gadget_wlhe state:R running task stack: 0 pid: 674 ppid: 636 flags:0x00000202 Call trace: __switch_to+0xc0/0x170 _raw_spin_lock_irqsave+0x84/0xb0 composite_disconnect+0x28/0x78 configfs_composite_disconnect+0x68/0x70 usb_gadget_disconnect+0x10c/0x128 usb_gadget_deactivate+0xd4/0x108 usb_function_deactivate+0x6c/0x80 uvc_function_disconnect+0x20/0x58 uvc_v4l2_release+0x30/0x88 v4l2_release+0xbc/0xf0 __fput+0x7c/0x230 ____fput+0x14/0x20 task_work_run+0x88/0x140 do_notify_resume+0x240/0x6f0 work_pending+0x8/0x200 Fix this by doing an unlock on cdev->lock before the usb_gadget_deactivate call from usb_function_deactivate. The same lockup can happen in the usb_gadget_activate path. Fix that path as well. Reported-by: Peter Chen Link: https://lore.kernel.org/linux-usb/20201102094936.GA29581@b29397-desktop/ Tested-by: Peter Chen Signed-off-by: Sriharsha Allenki Cc: stable Link: https://lore.kernel.org/r/20201202130220.24926-1-sallenki@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit e80db09b76fb382d841ef4e0e4d46b7aa581c17f Author: Yang Yingliang Date: Tue Nov 17 17:29:55 2020 +0800 USB: gadget: legacy: fix return error code in acm_ms_bind() commit c91d3a6bcaa031f551ba29a496a8027b31289464 upstream. If usb_otg_descriptor_alloc() failed, it need return ENOMEM. Fixes: 578aa8a2b12c ("usb: gadget: acm_ms: allocate and init otg descriptor by otg capabilities") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Cc: stable Link: https://lore.kernel.org/r/20201117092955.4102785-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman commit 97d36b7be15c4368334afe93a6766b06ad53d3e6 Author: Zqiang Date: Thu Dec 10 10:01:48 2020 +0800 usb: gadget: function: printer: Fix a memory leak for interface descriptor commit 2cc332e4ee4febcbb685e2962ad323fe4b3b750a upstream. When printer driver is loaded, the printer_func_bind function is called, in this function, the interface descriptor be allocated memory, if after that, the error occurred, the interface descriptor memory need to be free. Reviewed-by: Peter Chen Cc: Signed-off-by: Zqiang Link: https://lore.kernel.org/r/20201210020148.6691-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman commit a927ba260508cd33fccd6c74bd58f6627096c121 Author: Jerome Brunet Date: Mon Dec 21 18:35:28 2020 +0100 usb: gadget: f_uac2: reset wMaxPacketSize commit 9389044f27081d6ec77730c36d5bf9a1288bcda2 upstream. With commit 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth") wMaxPacketSize is computed dynamically but the value is never reset. Because of this, the actual maximum packet size can only decrease each time the audio gadget is instantiated. Reset the endpoint maximum packet size and mark wMaxPacketSize as dynamic to solve the problem. Fixes: 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth") Signed-off-by: Jerome Brunet Cc: stable Link: https://lore.kernel.org/r/20201221173531.215169-2-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman commit c178afeee6523c07ef7b1373f9ec41862a024428 Author: Arnd Bergmann Date: Sun Jan 3 22:42:17 2021 +0100 usb: gadget: select CONFIG_CRC32 commit d7889c2020e08caab0d7e36e947f642d91015bd0 upstream. Without crc32 support, this driver fails to link: arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_eem.o: in function `eem_unwrap': f_eem.c:(.text+0x11cc): undefined reference to `crc32_le' arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_ncm.o:f_ncm.c:(.text+0x1e40): more undefined references to `crc32_le' follow Fixes: 6d3865f9d41f ("usb: gadget: NCM: Add transmit multi-frame.") Signed-off-by: Arnd Bergmann Cc: stable Link: https://lore.kernel.org/r/20210103214224.1996535-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit e52446c38f0b7c4c6b231dcd97bbfe1881a2c5be Author: Takashi Iwai Date: Wed Dec 23 18:45:57 2020 +0100 ALSA: usb-audio: Fix UBSAN warnings for MIDI jacks commit c06ccf3ebb7503706ea49fd248e709287ef385a3 upstream. The calculation of in_cables and out_cables bitmaps are done with the bit shift by the value from the descriptor, which is an arbitrary value, and can lead to UBSAN shift-out-of-bounds warnings. Fix it by filtering the bad descriptor values with the check of the upper bound 0x10 (the cable bitmaps are 16 bits). Reported-by: syzbot+92e45ae45543f89e8c88@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20201223174557.10249-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 885281cc1e32ebf4aee132b296e58b5816bf2277 Author: Johan Hovold Date: Mon Jan 4 15:53:02 2021 +0100 USB: usblp: fix DMA to stack commit 020a1f453449294926ca548d8d5ca970926e8dfd upstream. Stack-allocated buffers cannot be used for DMA (on all architectures). Replace the HP-channel macro with a helper function that allocates a dedicated transfer buffer so that it can continue to be used with arguments from the stack. Note that the buffer is cleared on allocation as usblp_ctrl_msg() returns success also on short transfers (the buffer is only used for debugging). Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210104145302.2087-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 49bb10692bb5eaf6310d036d05090d61d91a2274 Author: Johan Hovold Date: Mon Dec 14 11:30:53 2020 +0100 USB: yurex: fix control-URB timeout handling commit 372c93131998c0622304bed118322d2a04489e63 upstream. Make sure to always cancel the control URB in write() so that it can be reused after a timeout or spurious CMD_ACK. Currently any further write requests after a timeout would fail after triggering a WARN() in usb_submit_urb() when attempting to submit the already active URB. Reported-by: syzbot+e87ebe0f7913f71f2ea5@syzkaller.appspotmail.com Fixes: 6bc235a2e24a ("USB: add driver for Meywa-Denki & Kayac YUREX") Cc: stable # 2.6.37 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f617a85b20b5329f4ba2f9f42ff9412ec53d45ae Author: Daniel Palmer Date: Sun Dec 27 12:17:16 2020 +0900 USB: serial: option: add LongSung M5710 module support commit 0e2d6795e8dbe91c2f5473564c6b25d11df3778b upstream. Add a device-id entry for the LongSung M5710 module. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2df3 ProdID=9d03 Rev= 1.00 S: Manufacturer=Marvell S: Product=Mobile Composite Device Bus S: SerialNumber= C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03 I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=4096ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=4096ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=4096ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Daniel Palmer https://lore.kernel.org/r/20201227031716.1343300-1-daniel@0x0f.com [ johan: drop id defines, only bind to vendor class ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 54696754c3785169fef53d07f58cefa712d9a871 Author: Johan Hovold Date: Mon Jan 4 15:50:07 2021 +0100 USB: serial: iuu_phoenix: fix DMA from stack commit 54d0a3ab80f49f19ee916def62fe067596833403 upstream. Stack-allocated buffers cannot be used for DMA (on all architectures) so allocate the flush command buffer using kmalloc(). Fixes: 60a8fc017103 ("USB: add iuu_phoenix driver") Cc: stable # 2.6.25 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f725e36175fc4732c3082aa6ebaef4cdfacb2840 Author: Thinh Nguyen Date: Mon Jan 4 20:07:15 2021 -0800 usb: uas: Add PNY USB Portable SSD to unusual_uas commit 96ebc9c871d8a28fb22aa758dd9188a4732df482 upstream. Here's another variant PNY Pro Elite USB 3.1 Gen 2 portable SSD that hangs and doesn't respond to ATA_1x pass-through commands. If it doesn't support these commands, it should respond properly to the host. Add it to the unusual uas list to be able to move forward with other operations. Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Acked-by: Oliver Neukum Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/2edc7af892d0913bf06f5b35e49ec463f03d5ed8.1609819418.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 21a18965a863bd0cf186398953ccf98923488d4e Author: Michael Grzeschik Date: Tue Dec 15 20:31:47 2020 +0100 USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760 upstream. The commit 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit latency is too long") was constraining the xhci code not to allow U1/U2 sleep states if the latency to wake up from the U-states reached the service interval of an periodic endpoint. This fix was not taking into account that in case the quirk XHCI_INTEL_HOST is set, the wakeup time will be calculated and configured differently. It checks for u1_params.mel/u2_params.mel as a limit. But the code could decide to write another MEL into the hardware. This leads to broken cases where not enough bandwidth is available for other devices: usb 1-2: can't set config #1, error -28 This patch is fixing that case by checking for timeout_ns after the wakeup time was calculated depending on the quirks. Fixes: 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit latency is too long") Signed-off-by: Michael Grzeschik Cc: stable Link: https://lore.kernel.org/r/20201215193147.11738-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit dc8b2e0b09acf86188bd341691edb2a01500da33 Author: Yu Kuai Date: Tue Nov 17 09:14:30 2020 +0800 usb: chipidea: ci_hdrc_imx: add missing put_device() call in usbmisc_get_init_data() commit 83a43ff80a566de8718dfc6565545a0080ec1fb5 upstream. if of_find_device_by_node() succeed, usbmisc_get_init_data() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: ef12da914ed6 ("usb: chipidea: imx: properly check for usbmisc") Signed-off-by: Yu Kuai Cc: stable Link: https://lore.kernel.org/r/20201117011430.642589-1-yukuai3@huawei.com Signed-off-by: Greg Kroah-Hartman commit 627f08c16754eedbbd9cc64ff9601e13d58ab24f Author: Sean Young Date: Sun Dec 27 13:45:02 2020 +0000 USB: cdc-acm: blacklist another IR Droid device commit 0ffc76539e6e8d28114f95ac25c167c37b5191b3 upstream. This device is supported by the IR Toy driver. Reported-by: Georgi Bakalski Signed-off-by: Sean Young Acked-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20201227134502.4548-2-sean@mess.org Signed-off-by: Greg Kroah-Hartman commit a3aeeddf04bcacbfc37227d153e1e5a742ca7bb6 Author: taehyun.cho Date: Thu Jan 7 00:46:25 2021 +0900 usb: gadget: enable super speed plus commit e2459108b5a0604c4b472cae2b3cb8d3444c77fb upstream. Enable Super speed plus in configfs to support USB3.1 Gen2. This ensures that when a USB gadget is plugged in, it is enumerated as Gen 2 and connected at 10 Gbps if the host and cable are capable of it. Many in-tree gadget functions (fs, midi, acm, ncm, mass_storage, etc.) already have SuperSpeed Plus support. Tested: plugged gadget into Linux host and saw: [284907.385986] usb 8-2: new SuperSpeedPlus Gen 2 USB device number 3 using xhci_hcd Tested-by: Lorenzo Colitti Acked-by: Felipe Balbi Signed-off-by: taehyun.cho Signed-off-by: Lorenzo Colitti Link: https://lore.kernel.org/r/20210106154625.2801030-1-lorenzo@google.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 4fac8ce92d1c9ecf6b7902f29db4930e08b4a35f Author: Dexuan Cui Date: Sat Jan 9 14:53:58 2021 -0800 video: hyperv_fb: Fix the mmap() regression for v5.4.y and older db49200b1dad is backported from the mainline commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping the VRAM"), to v5.4.y and older stable branches, but unluckily db49200b1dad causes mmap() to fail for /dev/fb0 due to EINVAL: [ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back This means the v5.4.y kernel detects an incompatibility issue about the mapping type of the VRAM: db49200b1dad changes to use Write-Back when mapping the VRAM, while the mmap() syscall tries to use Uncached-minus. That’s to say, the kernel thinks Uncached-minus is incompatible with Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() -> vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() -> reserve_pfn_range(). Note: any v5.5 and newer kernel doesn't have the issue, because they have commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") , and when the hyperv_fb driver has the deferred_io support, fb_deferred_io_init() overrides info->fbops->fb_mmap with fb_deferred_io_mmap(), which doesn’t check the mapping type incompatibility. Note: since it's VRAM here, the checking is not really necessary. Fix the regression by ioremap_wc(), which uses Write-combining. The kernel thinks it's compatible with Uncached-minus. The VRAM mappped by ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is still significantly faster than by ioremap(). Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not working in the latest mainline yet, and when it works in future, the ARM64 support is unlikely to be backported to v5.4 and older, so using ioremap_wc() in v5.4 and older should be ok. Note: this fix is only targeted at the stable branches: v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y. Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM") Signed-off-by: Dexuan Cui Signed-off-by: Sasha Levin commit a07556e69b3fb38170749024356c01ad7b126780 Author: Changbin Du Date: Thu Jan 7 14:52:29 2021 -0800 scripts/gdb: fix lx-version string output commit b058809bfc8faeb7b7cae047666e23375a060059 upstream A bug is present in GDB which causes early string termination when parsing variables. This has been reported [0], but we should ensure that we can support at least basic printing of the core kernel strings. For current gdb version (has been tested with 7.3 and 8.1), 'lx-version' only prints one character. (gdb) lx-version L(gdb) This can be fixed by casting 'linux_banner' as (char *). (gdb) lx-version Linux version 4.19.0-rc1+ (changbin@acer) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21 SMP Sat Sep 1 21:43:30 CST 2018 [0] https://sourceware.org/bugzilla/show_bug.cgi?id=20077 [kbingham@kernel.org: add detail to commit message] Link: http://lkml.kernel.org/r/20181111162035.8356-1-kieran.bingham@ideasonboard.com Fixes: 2d061d999424 ("scripts/gdb: add version command") Signed-off-by: Du Changbin Signed-off-by: Kieran Bingham Acked-by: Jan Kiszka Cc: Jan Kiszka Cc: Jason Wessel Cc: Daniel Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit de8cc050430fe09af764cbf02532766b521ca6cf Author: Leonard Crestez Date: Thu Jan 7 14:52:28 2021 -0800 scripts/gdb: lx-dmesg: use explicit encoding=utf8 errors=replace commit 46d10a094353c05144f3b0530516bdac3ce7c435 upstream Use errors=replace because it is never desirable for lx-dmesg to fail on string decoding errors, not even if the log buffer is corrupt and we show incorrect info. The kernel will sometimes print utf8, for example the copyright symbol from jffs2. In order to make this work specify 'utf8' everywhere because python2 otherwise defaults to 'ascii'. In theory the second errors='replace' is not be required because everything that can be decoded as utf8 should also be encodable back to utf8. But it's better to be extra safe here. It's worth noting that this is definitely not true for encoding='ascii', unknown characters are replaced with U+FFFD REPLACEMENT CHARACTER and they fail to encode back to ascii. Link: http://lkml.kernel.org/r/acee067f3345954ed41efb77b80eebdc038619c6.1498481469.git.leonard.crestez@nxp.com Signed-off-by: Leonard Crestez Acked-by: Jan Kiszka Cc: Jason Wessel Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 393681bec3ce8157b62fd028c440619065c16c41 Author: Leonard Crestez Date: Thu Jan 7 14:52:27 2021 -0800 scripts/gdb: lx-dmesg: cast log_buf to void* for addr fetch commit c454756f47277b651ad41a5a163499294529e35d upstream In some cases it is possible for the str() conversion here to throw encoding errors because log_buf might not point to valid ascii. For example: (gdb) python print str(gdb.parse_and_eval("log_buf")) Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\u0303' in position 24: ordinal not in range(128) Avoid this by explicitly casting to (void *) inside the gdb expression. Link: http://lkml.kernel.org/r/ba6f85dbb02ca980ebd0e2399b0649423399b565.1498481469.git.leonard.crestez@nxp.com Signed-off-by: Leonard Crestez Reviewed-by: Jan Kiszka Cc: Jason Wessel Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 68ee6d808bbecf303cdcb52faa0b8f4f8433af1e Author: André Draszik Date: Thu Jan 7 14:52:26 2021 -0800 scripts/gdb: make lx-dmesg command work (reliably) commit d6c9708737c2107c38bd75f133d14d5801b8d6d5 upstream lx-dmesg needs access to the log_buf symbol from printk.c. Unfortunately, the symbol log_buf also exists in BPF's verifier.c and hence gdb can pick one or the other. If it happens to pick BPF's log_buf, lx-dmesg doesn't work: (gdb) lx-dmesg Python Exception Cannot access memory at address 0x0: Error occurred in Python command: Cannot access memory at address 0x0 (gdb) p log_buf $15 = 0x0 Luckily, GDB has a way to deal with this, see https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html (gdb) info variables ^log_buf$ All variables matching regular expression "^log_buf$": File /kernel/bpf/verifier.c: static char *log_buf; File /kernel/printk/printk.c: static char *log_buf; (gdb) p 'verifier.c'::log_buf $1 = 0x0 (gdb) p 'printk.c'::log_buf $2 = 0x811a6aa0 <__log_buf> "" (gdb) p &log_buf $3 = (char **) 0x8120fe40 (gdb) p &'verifier.c'::log_buf $4 = (char **) 0x8120fe40 (gdb) p &'printk.c'::log_buf $5 = (char **) 0x8048b7d0 By being explicit about the location of the symbol, we can make lx-dmesg work again. While at it, do the same for the other symbols we need from printk.c Link: http://lkml.kernel.org/r/20170526112222.3414-1-git@andred.net Signed-off-by: André Draszik Tested-by: Kieran Bingham Acked-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit df2799188642fdffece3e74a32b9b70e336899f6 Author: Jeff Dike Date: Tue Dec 22 21:54:21 2020 -0500 virtio_net: Fix recursive call to cpus_read_lock() [ Upstream commit de33212f768c5d9e2fe791b008cb26f92f0aa31c ] virtnet_set_channels can recursively call cpus_read_lock if CONFIG_XPS and CONFIG_HOTPLUG are enabled. The path is: virtnet_set_channels - calls get_online_cpus(), which is a trivial wrapper around cpus_read_lock() netif_set_real_num_tx_queues netif_reset_xps_queues_gt netif_reset_xps_queues - calls cpus_read_lock() This call chain and potential deadlock happens when the number of TX queues is reduced. This commit the removes netif_set_real_num_[tr]x_queues calls from inside the get/put_online_cpus section, as they don't require that it be held. Fixes: 47be24796c13 ("virtio-net: fix the set affinity bug when CPU IDs are not consecutive") Signed-off-by: Jeff Dike Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20201223025421.671-1-jdike@akamai.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 586692be691c9955b277219b8a8f8559594b391a Author: Randy Dunlap Date: Thu Dec 24 22:23:44 2020 -0800 net: sched: prevent invalid Scell_log shift count [ Upstream commit bd1248f1ddbc48b0c30565fce897a3b6423313b8 ] Check Scell_log shift size in red_check_params() and modify all callers of red_check_params() to pass Scell_log. This prevents a shift out-of-bounds as detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22 shift exponent 72 is too large for 32-bit type 'int' Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values") Signed-off-by: Randy Dunlap Reported-by: syzbot+97c5bd9cc81eca63d36e@syzkaller.appspotmail.com Cc: Nogah Frankel Cc: Jamal Hadi Salim Cc: Cong Wang Cc: Jiri Pirko Cc: netdev@vger.kernel.org Cc: "David S. Miller" Cc: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f1f4a514bbc6810574321cc1bc2b640ef8f347fb Author: Yunjian Wang Date: Tue Dec 29 10:01:48 2020 +0800 vhost_net: fix ubuf refcount incorrectly when sendmsg fails [ Upstream commit 01e31bea7e622f1890c274f4aaaaf8bccd296aa5 ] Currently the vhost_zerocopy_callback() maybe be called to decrease the refcount when sendmsg fails in tun. The error handling in vhost handle_tx_zerocopy() will try to decrease the same refcount again. This is wrong. To fix this issue, we only call vhost_net_ubuf_put() when vq->heads[nvq->desc].len == VHOST_DMA_IN_PROGRESS. Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support") Signed-off-by: Yunjian Wang Acked-by: Willem de Bruijn Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Link: https://lore.kernel.org/r/1609207308-20544-1-git-send-email-wangyunjian@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2e9e8bc39af5bfe56eb9b6496dcd1334070b5610 Author: Roland Dreier Date: Wed Dec 23 19:21:16 2020 -0800 CDC-NCM: remove "connected" log message [ Upstream commit 59b4a8fa27f5a895582ada1ae5034af7c94a57b5 ] The cdc_ncm driver passes network connection notifications up to usbnet_link_change(), which is the right place for any logging. Remove the netdev_info() duplicating this from the driver itself. This stops devices such as my "TRENDnet USB 10/100/1G/2.5G LAN" (ID 20f4:e02b) adapter from spamming the kernel log with cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected messages every 60 msec or so. Signed-off-by: Roland Dreier Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20201224032116.2453938-1-roland@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 09d88553e45b2472cf89fe2b3fa22c63a9599508 Author: Xie He Date: Sun Dec 27 18:53:39 2020 -0800 net: hdlc_ppp: Fix issues when mod_timer is called while timer is running [ Upstream commit 1fef73597fa545c35fddc953979013882fbd4e55 ] ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock" held. It may call mod_timer to add a new timer. However, at the same time ppp_timer may be already running and waiting for "ppp->lock". In this case, there's no need for ppp_timer to continue running and it can just exit. If we let ppp_timer continue running, it may call add_timer. This causes kernel panic because add_timer can't be called with a timer pending. This patch fixes this problem. Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic HDLC.") Cc: Krzysztof Halasa Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53f312094154acb5db489cac504eac8a1292e5e1 Author: Yunjian Wang Date: Sat Dec 26 16:10:05 2020 +0800 net: hns: fix return value check in __lb_other_process() [ Upstream commit 5ede3ada3da7f050519112b81badc058190b9f9f ] The function skb_copy() could return NULL, the return value need to be checked. Fixes: b5996f11ea54 ("net: add Hisilicon Network Subsystem basic ethernet support") Signed-off-by: Yunjian Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 85039b79b583d82edb65a7bae6249640c0b7b19a Author: Guillaume Nault Date: Thu Dec 24 20:01:09 2020 +0100 ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst() [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT(1) packets could be treated differently. $ ip netns add ns0 $ ip netns add ns1 $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev lo up $ ip -netns ns1 link set dev lo up $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10/24 dev veth01 $ ip -netns ns1 address add 192.0.2.11/24 dev veth10 $ ip -netns ns1 address add 192.0.2.21/32 dev lo $ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 src 192.0.2.21 $ ip netns exec ns1 sysctl -wq net.ipv4.icmp_echo_ignore_broadcasts=0 With TOS 4 and ECT(1), ns1 replies using source address 192.0.2.21 (ping uses -Q to set all TOS and ECN bits): $ ip netns exec ns0 ping -c 1 -b -Q 5 192.0.2.255 [...] 64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.544 ms But with TOS 4 and ECT(0), ns1 replies using source address 192.0.2.11 because the "tos 4" route isn't matched: $ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255 [...] 64 bytes from 192.0.2.11: icmp_seq=1 ttl=64 time=0.597 ms After this patch the ECN bits don't affect the result anymore: $ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255 [...] 64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.591 ms Fixes: 35ebf65e851c ("ipv4: Create and use fib_compute_spec_dst() helper.") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fed8d8df3187efe3c69320c78d80bf798b3e004a Author: Dinghao Liu Date: Wed Dec 23 19:06:12 2020 +0800 net: ethernet: Fix memleak in ethoc_probe [ Upstream commit 5d41f9b7ee7a5a5138894f58846a4ffed601498a ] When mdiobus_register() fails, priv->mdio allocated by mdiobus_alloc() has not been freed, which leads to memleak. Fixes: e7f4dc3536a4 ("mdio: Move allocation of interrupts into core") Signed-off-by: Dinghao Liu Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201223110615.31389-1-dinghao.liu@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8837315fd6c8cf648739998ed48dc598363f4edb Author: John Wang Date: Wed Dec 23 13:55:23 2020 +0800 net/ncsi: Use real net-device for response handler [ Upstream commit 427c940558560bff2583d07fc119a21094675982 ] When aggregating ncsi interfaces and dedicated interfaces to bond interfaces, the ncsi response handler will use the wrong net device to find ncsi_dev, so that the ncsi interface will not work properly. Here, we use the original net device to fix it. Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler") Signed-off-by: John Wang Link: https://lore.kernel.org/r/20201223055523.2069-1-wangzhiqiang.bj@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1b9071c0503ddde49bb7b71760f24341fa673f13 Author: Dan Carpenter Date: Sat Dec 19 14:01:44 2020 +0300 atm: idt77252: call pci_disable_device() on error path [ Upstream commit 8df66af5c1e5f80562fe728db5ec069b21810144 ] This error path needs to disable the pci device before returning. Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X93dmC4NX0vbTpGp@mwanda Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d33701e2d16e4e91db50849ea10dfc7938d8918e Author: Rasmus Villemoes Date: Fri Dec 18 11:55:38 2020 +0100 ethernet: ucc_geth: fix use-after-free in ucc_geth_remove() [ Upstream commit e925e0cd2a705aaacb0b907bb3691fcac3a973a4 ] ugeth is the netdiv_priv() part of the netdevice. Accessing the memory pointed to by ugeth (such as done by ucc_geth_memclean() and the two of_node_puts) after free_netdev() is thus use-after-free. Fixes: 80a9fad8e89a ("ucc_geth: fix module removal") Signed-off-by: Rasmus Villemoes Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f679fa0d018e40f3fd19168f8fd8d587ec5ef3d2 Author: Linus Torvalds Date: Mon Dec 28 11:40:22 2020 -0800 depmod: handle the case of /sbin/depmod without /sbin in PATH [ Upstream commit cedd1862be7e666be87ec824dabc6a2b05618f36 ] Commit 436e980e2ed5 ("kbuild: don't hardcode depmod path") stopped hard-coding the path of depmod, but in the process caused trouble for distributions that had that /sbin location, but didn't have it in the PATH (generally because /sbin is limited to the super-user path). Work around it for now by just adding /sbin to the end of PATH in the depmod.sh script. Reported-and-tested-by: Sedat Dilek Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 096d1ab748d810142af87d511397cd7da91a3457 Author: Huang Shijie Date: Tue Dec 29 15:14:58 2020 -0800 lib/genalloc: fix the overflow when size is too big [ Upstream commit 36845663843fc59c5d794e3dc0641472e3e572da ] Some graphic card has very big memory on chip, such as 32G bytes. In the following case, it will cause overflow: pool = gen_pool_create(PAGE_SHIFT, NUMA_NO_NODE); ret = gen_pool_add(pool, 0x1000000, SZ_32G, NUMA_NO_NODE); va = gen_pool_alloc(pool, SZ_4G); The overflow occurs in gen_pool_alloc_algo_owner(): .... size = nbits << order; .... The @nbits is "int" type, so it will overflow. Then the gen_pool_avail() will return the wrong value. This patch converts some "int" to "unsigned long", and changes the compare code in while. Link: https://lkml.kernel.org/r/20201229060657.3389-1-sjhuang@iluvatar.ai Signed-off-by: Huang Shijie Reported-by: Shi Jiasheng Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fe458773a3884664b94f8d06bd56191c96eec190 Author: Yunfeng Ye Date: Thu Nov 19 14:21:25 2020 +0800 workqueue: Kick a worker based on the actual activation of delayed works [ Upstream commit 01341fbd0d8d4e717fc1231cdffe00343088ce0b ] In realtime scenario, We do not want to have interference on the isolated cpu cores. but when invoking alloc_workqueue() for percpu wq on the housekeeping cpu, it kick a kworker on the isolated cpu. alloc_workqueue pwq_adjust_max_active wake_up_worker The comment in pwq_adjust_max_active() said: "Need to kick a worker after thawed or an unbound wq's max_active is bumped" So it is unnecessary to kick a kworker for percpu's wq when invoking alloc_workqueue(). this patch only kick a worker based on the actual activation of delayed works. Signed-off-by: Yunfeng Ye Reviewed-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9a54ced0a729f20d2197c97d44c9db34350eade4 Author: Dominique Martinet Date: Tue Dec 1 14:17:30 2020 +0100 kbuild: don't hardcode depmod path commit 436e980e2ed526832de822cbf13c317a458b78e1 upstream. depmod is not guaranteed to be in /sbin, just let make look for it in the path like all the other invoked programs Signed-off-by: Dominique Martinet Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman