commit 933cf1c2c075f44c7b6837b6201e0db2d488835a Author: Greg Kroah-Hartman Date: Thu Sep 3 11:27:11 2020 +0200 Linux 5.4.62 Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 54ee77961e795d9747be3c164d631148057887c0 Author: Xin Yin Date: Tue Sep 1 20:12:52 2020 -0600 io_uring: Fix NULL pointer dereference in io_sq_wq_submit_work() the commit <1c4404efcf2c0> ("") caused a crash in io_sq_wq_submit_work(). when io_ring-wq get a req form async_list, which not have been added to task_list. Then try to delete the req from task_list will caused a "NULL pointer dereference". Ensure add req to async_list and task_list at the sametime. The crash log looks like this: [95995.973638] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [95995.979123] pgd = c20c8964 [95995.981803] [00000000] *pgd=1c72d831, *pte=00000000, *ppte=00000000 [95995.988043] Internal error: Oops: 817 [#1] SMP ARM [95995.992814] Modules linked in: bpfilter(-) [95995.996898] CPU: 1 PID: 15661 Comm: kworker/u8:5 Not tainted 5.4.56 #2 [95996.003406] Hardware name: Amlogic Meson platform [95996.008108] Workqueue: io_ring-wq io_sq_wq_submit_work [95996.013224] PC is at io_sq_wq_submit_work+0x1f4/0x5c4 [95996.018261] LR is at walk_stackframe+0x24/0x40 [95996.022685] pc : [] lr : [] psr: 600f0093 [95996.028936] sp : dc6f7e88 ip : dc6f7df0 fp : dc6f7ef4 [95996.034148] r10: deff9800 r9 : dc1d1694 r8 : dda58b80 [95996.039358] r7 : dc6f6000 r6 : dc6f7ebc r5 : dc1d1600 r4 : deff99c0 [95996.045871] r3 : 0000cb5d r2 : 00000000 r1 : ef6b9b80 r0 : c059b88c [95996.052385] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [95996.059593] Control: 10c5387d Table: 22be804a DAC: 00000055 [95996.065325] Process kworker/u8:5 (pid: 15661, stack limit = 0x78013c69) [95996.071923] Stack: (0xdc6f7e88 to 0xdc6f8000) [95996.076268] 7e80: dc6f7ecc dc6f7e98 00000000 c1f06c08 de9dc800 deff9a04 [95996.084431] 7ea0: 00000000 dc6f7f7c 00000000 c1f65808 0000080c dc677a00 c1ee9bd0 dc6f7ebc [95996.092594] 7ec0: dc6f7ebc d085c8f6 c0445a90 dc1d1e00 e008f300 c0288400 e4ef7100 00000000 [95996.100757] 7ee0: c20d45b0 e4ef7115 dc6f7f34 dc6f7ef8 c03725f0 c059b6b0 c0288400 c0288400 [95996.108921] 7f00: c0288400 00000001 c0288418 e008f300 c0288400 e008f314 00000088 c0288418 [95996.117083] 7f20: c1f03d00 dc6f6038 dc6f7f7c dc6f7f38 c0372df8 c037246c dc6f7f5c 00000000 [95996.125245] 7f40: c1f03d00 c1f03d00 c20d3cbe c0288400 dc6f7f7c e1c43880 e4fa7980 00000000 [95996.133409] 7f60: e008f300 c0372d9c e48bbe74 e1c4389c dc6f7fac dc6f7f80 c0379244 c0372da8 [95996.141570] 7f80: 600f0093 e4fa7980 c0379108 00000000 00000000 00000000 00000000 00000000 [95996.149734] 7fa0: 00000000 dc6f7fb0 c03010ac c0379114 00000000 00000000 00000000 00000000 [95996.157897] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [95996.166060] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [95996.174217] Backtrace: [95996.176662] [] (io_sq_wq_submit_work) from [] (process_one_work+0x190/0x4c0) [95996.185425] r10:e4ef7115 r9:c20d45b0 r8:00000000 r7:e4ef7100 r6:c0288400 r5:e008f300 [95996.193237] r4:dc1d1e00 [95996.195760] [] (process_one_work) from [] (worker_thread+0x5c/0x5bc) [95996.203836] r10:dc6f6038 r9:c1f03d00 r8:c0288418 r7:00000088 r6:e008f314 r5:c0288400 [95996.211647] r4:e008f300 [95996.214173] [] (worker_thread) from [] (kthread+0x13c/0x168) [95996.221554] r10:e1c4389c r9:e48bbe74 r8:c0372d9c r7:e008f300 r6:00000000 r5:e4fa7980 [95996.229363] r4:e1c43880 [95996.231888] [] (kthread) from [] (ret_from_fork+0x14/0x28) [95996.239088] Exception stack(0xdc6f7fb0 to 0xdc6f7ff8) [95996.244127] 7fa0: 00000000 00000000 00000000 00000000 [95996.252291] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [95996.260453] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [95996.267054] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0379108 [95996.274866] r4:e4fa7980 r3:600f0093 [95996.278430] Code: eb3a59e1 e5952098 e5951094 e5812004 (e5821000) Signed-off-by: Xin Yin Signed-off-by: Greg Kroah-Hartman commit 44cf62d388fb5854c47fa8f27313841a490fa37b Author: Hector Martin Date: Sun Aug 16 17:44:31 2020 +0900 ALSA: usb-audio: Update documentation comment for MS2109 quirk commit 74a2a7de81a2ef20732ec02087314e92692a7a1b upstream. As the recent fix addressed the channel swap problem more properly, update the comment as well. Fixes: 1b7ecc241a67 ("ALSA: usb-audio: work around streaming quirk for MacroSilicon MS2109") Signed-off-by: Hector Martin Link: https://lore.kernel.org/r/20200816084431.102151-1-marcan@marcan.st Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 851d0813ab80b47d3d85617d81836891bfb59094 Author: Peilin Ye Date: Wed Jul 29 07:37:12 2020 -0400 HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage() commit 25a097f5204675550afb879ee18238ca917cba7a upstream. `uref->usage_index` is not always being properly checked, causing hiddev_ioctl_usage() to go out of bounds under some cases. Fix it. Reported-by: syzbot+34ee1b45d88571c2fa8b@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=f2aebe90b8c56806b050a20b36f51ed6acabe802 Reviewed-by: Dan Carpenter Signed-off-by: Peilin Ye Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c98b6ebd9b555db3ddc7751d31e5e424c1c81245 Author: Denis Efremov Date: Mon Jun 8 12:59:44 2020 +0300 kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables commit e4a42c82e943b97ce124539fcd7a47445b43fa0d upstream. Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp. GZIP, BZIP2, LZOP env variables are reserved by the tools. The original attempt to redefine them internally doesn't work in makefiles/scripts intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in broken builds. There can be other broken build commands because of this, so the universal solution is to use non-reserved env variables for the compression tools. Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools") Signed-off-by: Denis Efremov Tested-by: Guenter Roeck Signed-off-by: Masahiro Yamada Cc: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit 37432a83faab68c0bc89d6a4395ff063eaa14f3b Author: Denis Efremov Date: Fri Jun 5 10:39:55 2020 +0300 kbuild: add variables for compression tools commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream. Allow user to use alternative implementations of compression tools, such as pigz, pbzip2, pxz. For example, multi-threaded tools to speed up the build: $ make GZIP=pigz BZIP2=pbzip2 Variables _GZIP, _BZIP2, _LZOP are used internally because original env vars are reserved by the tools. The use of GZIP in gzip tool is obsolete since 2015. However, alternative implementations (e.g., pigz) still rely on it. BZIP2, BZIP, LZOP vars are not obsolescent. The credit goes to @grsecurity. As a sidenote, for multi-threaded lzma, xz compression one can use: $ export XZ_OPT="--threads=0" Signed-off-by: Denis Efremov Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit 47a41f65afb6a14467445a1746b41fcedcbfe064 Author: Masahiro Yamada Date: Tue Oct 8 21:05:56 2019 +0900 kheaders: explain why include/config/autoconf.h is excluded from md5sum commit f276031b4e2f4c961ed6d8a42f0f0124ccac2e09 upstream. This comment block explains why include/generated/compile.h is omitted, but nothing about include/generated/autoconf.h, which might be more difficult to understand. Add more comments. Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit 7caddaa9f88b37eb732c36bb9d9bd2fac84b02b5 Author: Masahiro Yamada Date: Tue Oct 8 21:05:55 2019 +0900 kheaders: remove the last bashism to allow sh to run it commit 1463f74f492eea7191f0178e01f3d38371a48210 upstream. 'pushd' ... 'popd' is the last bash-specific code in this script. One way to avoid it is to run the code in a sub-shell. With that addressed, you can run this script with sh. I replaced $(BASH) with $(CONFIG_SHELL), and I changed the hashbang to #!/bin/sh. Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit 18f48708c3f597cdd1de2fec9b03213d06bbf365 Author: Masahiro Yamada Date: Tue Oct 8 21:05:54 2019 +0900 kheaders: optimize header copy for in-tree builds commit ea79e5168be644fdaf7d4e6a73eceaf07b3da76a upstream. This script copies headers by the cpio command twice; first from srctree, and then from objtree. However, when we building in-tree, we know the srctree and the objtree are the same. That is, all the headers copied by the first cpio are overwritten by the second one. Skip the first cpio when we are building in-tree. Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit a1d0c6e2f334963d381f45b5fa65196a0f4ee7b4 Author: Masahiro Yamada Date: Tue Oct 8 21:05:53 2019 +0900 kheaders: optimize md5sum calculation for in-tree builds commit 0e11773e76098729552b750ccff79374d1e62002 upstream. This script computes md5sum of headers in srctree and in objtree. However, when we are building in-tree, we know the srctree and the objtree are the same. That is, we end up with the same computation twice. In fact, the first two lines of kernel/kheaders.md5 are always the same for in-tree builds. Unify the two md5sum calculations. For in-tree builds ($building_out_of_srctree is empty), we check only two directories, "include", and "arch/$SRCARCH/include". For out-of-tree builds ($building_out_of_srctree is 1), we check 4 directories, "$srctree/include", "$srctree/arch/$SRCARCH/include", "include", and "arch/$SRCARCH/include" since we know they are all different. Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit eb914bae6e174b68c4050899af8b8b0109399ca5 Author: Masahiro Yamada Date: Tue Oct 8 21:05:52 2019 +0900 kheaders: remove unneeded 'cat' command piped to 'head' / 'tail' commit 9a066357184485784f782719093ff804d05b85db upstream. The 'head' and 'tail' commands can take a file path directly. So, you do not need to run 'cat'. cat kernel/kheaders.md5 | head -1 ... is equivalent to: head -1 kernel/kheaders.md5 and the latter saves forking one process. While I was here, I replaced 'head -1' with 'head -n 1'. I also replaced '==' with '=' since we do not have a good reason to use the bashism. Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman commit 376810e5e9e148648c8b6e4aa8dc6306e9364f49 Author: Tetsuo Handa Date: Thu Jul 30 19:47:14 2020 +0900 fbmem: pull fbcon_update_vcs() out of fb_set_var() [ Upstream commit d88ca7e1a27eb2df056bbf37ddef62e1c73d37ea ] syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy() based on outdated old_{rows,row_size} values, for resize_screen() can recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates old_{rows,row_size} values which were saved before calling resize_screen(). Daniel Vetter explained that resize_screen() should not recurse into fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set when calling resize_screen(). Instead of masking FBINFO_MISC_USEREVENT before calling fbcon_update_vcs(), we can remove FBINFO_MISC_USEREVENT by calling fbcon_update_vcs() only if fb_set_var() returned 0. This change assumes that it is harmless to call fbcon_update_vcs() when fb_set_var() returned 0 without reaching fb_notifier_call_chain(). [1] https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e Reported-and-tested-by: syzbot Suggested-by: Daniel Vetter Signed-off-by: Tetsuo Handa Reported-by: kernel test robot for missing #include Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/075b7e37-3278-cd7d-31ab-c5073cfa8e92@i-love.sakura.ne.jp Signed-off-by: Sasha Levin commit 6a862aa31ec36c21502d3edcbeabc6d0c47681dc Author: Thinh Nguyen Date: Thu Aug 6 19:46:35 2020 -0700 usb: dwc3: gadget: Handle ZLP for sg requests [ Upstream commit bc9a2e226ea95e1699f7590845554de095308b75 ] Currently dwc3 doesn't handle usb_request->zero for SG requests. This change checks and prepares extra TRBs for the ZLP for SG requests. Cc: # v4.5+ Fixes: 04c03d10e507 ("usb: dwc3: gadget: handle request->zero") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 7c8b5685662b5fe7ec57ee875aad62da11226b5d Author: Thinh Nguyen Date: Thu Aug 6 19:46:29 2020 -0700 usb: dwc3: gadget: Fix handling ZLP [ Upstream commit d2ee3ff79e6a3d4105e684021017d100524dc560 ] The usb_request->zero doesn't apply for isoc. Also, if we prepare a 0-length (ZLP) TRB for the OUT direction, we need to prepare an extra TRB to pad up to the MPS alignment. Use the same bounce buffer for the ZLP TRB and the extra pad TRB. Cc: # v4.5+ Fixes: d6e5a549cc4d ("usb: dwc3: simplify ZLP handling") Fixes: 04c03d10e507 ("usb: dwc3: gadget: handle request->zero") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 4bc5d90a7dce113f95a85e6454773a8232019dc3 Author: Thinh Nguyen Date: Thu Aug 6 19:46:23 2020 -0700 usb: dwc3: gadget: Don't setup more than requested [ Upstream commit 5d187c0454ef4c5e046a81af36882d4d515922ec ] The SG list may be set up with entry size more than the requested length. Check the usb_request->length and make sure that we don't setup the TRBs to send/receive more than requested. This case may occur when the SG entry is allocated up to a certain minimum size, but the request length is less than that. It can also occur when the request is reused for a different request length. Cc: # v4.18+ Fixes: a31e63b608ff ("usb: dwc3: gadget: Correct handling of scattergather lists") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f8e4c5297fcdf4635d98b4dbd501453a25ad0ce0 Author: Mika Kuoppala Date: Mon Aug 17 22:59:26 2020 +0300 drm/i915: Fix cmd parser desc matching with masks [ Upstream commit e5f10d6385cda083037915c12b130887c8831d2b ] Our variety of defined gpu commands have the actual command id field and possibly length and flags applied. We did start to apply the mask during initialization of the cmd descriptors but forgot to also apply it on comparisons. Fix comparisons in order to properly deny access with associated commands. v2: fix lri with correct mask (Chris) References: 926abff21a8f ("drm/i915/cmdparser: Ignore Length operands during command matching") Reported-by: Nicolai Stange Cc: stable@vger.kernel.org # v5.4+ Cc: Miroslav Benes Cc: Takashi Iwai Cc: Tyler Hicks Cc: Jon Bloomfield Cc: Chris Wilson Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20200817195926.12671-1-mika.kuoppala@linux.intel.com (cherry picked from commit 3b4efa148da36f158cce3f662e831af2834b8e0f) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 73992639ec789cd1652037fc6161d52d3d3ac0db Author: Alan Stern Date: Wed Aug 26 10:32:29 2020 -0400 usb: storage: Add unusual_uas entry for Sony PSZ drives commit 20934c0de13b49a072fb1e0ca79fe0fe0e40eae5 upstream. The PSZ-HA* family of USB disk drives from Sony can't handle the REPORT OPCODES command when using the UAS protocol. This patch adds an appropriate quirks entry. Reported-and-tested-by: Till Dörges Signed-off-by: Alan Stern CC: Link: https://lore.kernel.org/r/20200826143229.GB400430@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 2add73c8c00dc1f0a8ac326b60c297e7fc374a8d Author: Tom Rix Date: Sat Aug 1 08:21:54 2020 -0700 USB: cdc-acm: rework notification_buffer resizing commit f4b9d8a582f738c24ebeabce5cc15f4b8159d74e upstream. Clang static analysis reports this error cdc-acm.c:409:3: warning: Use of memory after it is freed acm_process_notification(acm, (unsigned char *)dr); There are three problems, the first one is that dr is not reset The variable dr is set with if (acm->nb_index) dr = (struct usb_cdc_notification *)acm->notification_buffer; But if the notification_buffer is too small it is resized with if (acm->nb_size) { kfree(acm->notification_buffer); acm->nb_size = 0; } alloc_size = roundup_pow_of_two(expected_size); /* * kmalloc ensures a valid notification_buffer after a * use of kfree in case the previous allocation was too * small. Final freeing is done on disconnect. */ acm->notification_buffer = kmalloc(alloc_size, GFP_ATOMIC); dr should point to the new acm->notification_buffer. The second problem is any data in the notification_buffer is lost when the pointer is freed. In the normal case, the current data is accumulated in the notification_buffer here. memcpy(&acm->notification_buffer[acm->nb_index], urb->transfer_buffer, copy_size); When a resize happens, anything before notification_buffer[acm->nb_index] is garbage. The third problem is the acm->nb_index is not reset on a resizing buffer error. So switch resizing to using krealloc and reassign dr and reset nb_index. Fixes: ea2583529cd1 ("cdc-acm: reassemble fragmented notifications") Signed-off-by: Tom Rix Cc: stable Acked-by: Oliver Neukum Link: https://lore.kernel.org/r/20200801152154.20683-1-trix@redhat.com Signed-off-by: Greg Kroah-Hartman commit e2e02f260496ae8f31cde7c12c0c6a1864ef71de Author: Andy Shevchenko Date: Wed Aug 26 22:21:19 2020 +0300 USB: gadget: u_f: Unbreak offset calculation in VLAs commit bfd08d06d978d0304eb6f7855b548aa2cd1c5486 upstream. Inadvertently the commit b1cd1b65afba ("USB: gadget: u_f: add overflow checks to VLA macros") makes VLA macros to always return 0 due to different scope of two variables of the same name. Obviously we need to have only one. Fixes: b1cd1b65afba ("USB: gadget: u_f: add overflow checks to VLA macros") Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Andy Shevchenko Cc: Brooke Basile Cc: stable Link: https://lore.kernel.org/r/20200826192119.56450-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4f529c4d1e436230d3af7c09a3239677a14d2b46 Author: Brooke Basile Date: Tue Aug 25 09:07:27 2020 -0400 USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb() commit 2b74b0a04d3e9f9f08ff026e5663dce88ff94e52 upstream. Some values extracted by ncm_unwrap_ntb() could possibly lead to several different out of bounds reads of memory. Specifically the values passed to netdev_alloc_skb_ip_align() need to be checked so that memory is not overflowed. Resolve this by applying bounds checking to a number of different indexes and lengths of the structure parsing logic. Reported-by: Ilja Van Sprundel Signed-off-by: Brooke Basile Acked-by: Felipe Balbi Cc: stable Signed-off-by: Greg Kroah-Hartman commit f47ab852bea3fc6e531ecadd7fc7dbb987701b90 Author: Brooke Basile Date: Tue Aug 25 09:05:08 2020 -0400 USB: gadget: u_f: add overflow checks to VLA macros commit b1cd1b65afba95971fa457dfdb2c941c60d38c5b upstream. size can potentially hold an overflowed value if its assigned expression is left unchecked, leading to a smaller than needed allocation when vla_group_size() is used by callers to allocate memory. To fix this, add a test for saturation before declaring variables and an overflow check to (n) * sizeof(type). If the expression results in overflow, vla_group_size() will return SIZE_MAX. Reported-by: Ilja Van Sprundel Suggested-by: Kees Cook Signed-off-by: Brooke Basile Acked-by: Felipe Balbi Cc: stable Signed-off-by: Greg Kroah-Hartman commit 2534d3dec37698e58cdb8efbb4ac8dbecdc80912 Author: Tang Bin Date: Wed Aug 26 22:49:31 2020 +0800 usb: host: ohci-exynos: Fix error handling in exynos_ohci_probe() commit 1d4169834628d18b2392a2da92b7fbf5e8e2ce89 upstream. If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in exynos_ohci_probe(). And when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Fixes: 62194244cf87 ("USB: Add Samsung Exynos OHCI diver") Signed-off-by: Zhang Shengju Cc: stable Signed-off-by: Tang Bin Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200826144931.1828-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman commit de24343880a61cf5660343647877d5b3cda45ff6 Author: Cyril Roelandt Date: Tue Aug 25 23:22:31 2020 +0200 USB: Ignore UAS for JMicron JMS567 ATA/ATAPI Bridge commit 9aa37788e7ebb3f489fb4b71ce07adadd444264a upstream. This device does not support UAS properly and a similar entry already exists in drivers/usb/storage/unusual_uas.h. Without this patch, storage_probe() defers the handling of this device to UAS, which cannot handle it either. Tested-by: Brice Goglin Fixes: bc3bdb12bbb3 ("usb-storage: Disable UAS on JMicron SATA enclosure") Acked-by: Alan Stern CC: Signed-off-by: Cyril Roelandt Link: https://lore.kernel.org/r/20200825212231.46309-1-tipecaml@gmail.com Signed-off-by: Greg Kroah-Hartman commit ca29a2a53953bee3b136ce58c01202822a6634f4 Author: Alan Stern Date: Wed Aug 26 15:46:24 2020 -0400 USB: quirks: Ignore duplicate endpoint on Sound Devices MixPre-D commit 068834a2773b6a12805105cfadbb3d4229fc6e0a upstream. The Sound Devices MixPre-D audio card suffers from the same defect as the Sound Devices USBPre2: an endpoint shared between a normal audio interface and a vendor-specific interface, in violation of the USB spec. Since the USB core now treats duplicated endpoints as bugs and ignores them, the audio endpoint isn't available and the card can't be used for audio capture. Along the same lines as commit bdd1b147b802 ("USB: quirks: blacklist duplicate ep on Sound Devices USBPre2"), this patch adds a quirks entry saying to ignore ep5in for interface 1, leaving it available for use with standard audio interface 2. Reported-and-tested-by: Jean-Christophe Barnoud Signed-off-by: Alan Stern CC: Fixes: 3e4f8e21c4f2 ("USB: core: fix check for duplicate endpoints") Link: https://lore.kernel.org/r/20200826194624.GA412633@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 20b3564c67481bf217c6c6a764a677010eabae21 Author: Kai-Heng Feng Date: Fri Jul 31 13:16:20 2020 +0800 USB: quirks: Add no-lpm quirk for another Raydium touchscreen commit 5967116e8358899ebaa22702d09b0af57fef23e1 upstream. There's another Raydium touchscreen needs the no-lpm quirk: [ 1.339149] usb 1-9: New USB device found, idVendor=2386, idProduct=350e, bcdDevice= 0.00 [ 1.339150] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1.339151] usb 1-9: Product: Raydium Touch System [ 1.339152] usb 1-9: Manufacturer: Raydium Corporation ... [ 6.450497] usb 1-9: can't set config #1, error -110 BugLink: https://bugs.launchpad.net/bugs/1889446 Signed-off-by: Kai-Heng Feng Cc: stable Link: https://lore.kernel.org/r/20200731051622.28643-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman commit b32ec919ee37d76531b1a2901d530c9bda6d06de Author: Thinh Nguyen Date: Tue Aug 18 19:27:47 2020 -0700 usb: uas: Add quirk for PNY Pro Elite commit 9a469bc9f32dd33c7aac5744669d21a023a719cd upstream. PNY Pro Elite USB 3.1 Gen 2 device (SSD) doesn't respond to ATA_12 pass-through command (i.e. it just hangs). If it doesn't support this command, it should respond properly to the host. Let's just add a quirk to be able to move forward with other operations. Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/2b0585228b003eedcc82db84697b31477df152e0.1597803605.git.thinhn@synopsys.com Signed-off-by: Greg Kroah-Hartman commit ad0bc424fc0ac112d8726e4f7584eb2e2e8904a5 Author: Alan Stern Date: Mon Aug 10 14:29:54 2020 -0400 USB: yurex: Fix bad gfp argument commit f176ede3a3bde5b398a6777a7f9ff091baa2d3ff upstream. The syzbot fuzzer identified a bug in the yurex driver: It passes GFP_KERNEL as a memory-allocation flag to usb_submit_urb() at a time when its state is TASK_INTERRUPTIBLE, not TASK_RUNNING: do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000370c7c68>] prepare_to_wait+0xb1/0x2a0 kernel/sched/wait.c:247 WARNING: CPU: 1 PID: 340 at kernel/sched/core.c:7253 __might_sleep+0x135/0x190 kernel/sched/core.c:7253 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 340 Comm: syz-executor677 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xf6/0x16e lib/dump_stack.c:118 panic+0x2aa/0x6e1 kernel/panic.c:231 __warn.cold+0x20/0x50 kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x41/0x80 arch/x86/kernel/traps.c:234 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:__might_sleep+0x135/0x190 kernel/sched/core.c:7253 Code: 65 48 8b 1c 25 40 ef 01 00 48 8d 7b 10 48 89 fe 48 c1 ee 03 80 3c 06 00 75 2b 48 8b 73 10 48 c7 c7 e0 9e 06 86 e8 ed 12 f6 ff <0f> 0b e9 46 ff ff ff e8 1f b2 4b 00 e9 29 ff ff ff e8 15 b2 4b 00 RSP: 0018:ffff8881cdb77a28 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881c6458000 RCX: 0000000000000000 RDX: ffff8881c6458000 RSI: ffffffff8129ec93 RDI: ffffed1039b6ef37 RBP: ffffffff86fdade2 R08: 0000000000000001 R09: ffff8881db32f54f R10: 0000000000000000 R11: 0000000030343354 R12: 00000000000001f2 R13: 0000000000000000 R14: 0000000000000068 R15: ffffffff83c1b1aa slab_pre_alloc_hook.constprop.0+0xea/0x200 mm/slab.h:498 slab_alloc_node mm/slub.c:2816 [inline] slab_alloc mm/slub.c:2900 [inline] kmem_cache_alloc_trace+0x46/0x220 mm/slub.c:2917 kmalloc include/linux/slab.h:554 [inline] dummy_urb_enqueue+0x7a/0x880 drivers/usb/gadget/udc/dummy_hcd.c:1251 usb_hcd_submit_urb+0x2b2/0x22d0 drivers/usb/core/hcd.c:1547 usb_submit_urb+0xb4e/0x13e0 drivers/usb/core/urb.c:570 yurex_write+0x3ea/0x820 drivers/usb/misc/yurex.c:495 This patch changes the call to use GFP_ATOMIC instead of GFP_KERNEL. Reported-and-tested-by: syzbot+c2c3302f9c601a4b1be2@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Link: https://lore.kernel.org/r/20200810182954.GB307778@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 3623dab2959e1bd93e46029a88d43c975a4e7bac Author: Evan Quan Date: Tue Aug 25 10:35:11 2020 +0800 drm/amd/pm: correct the thermal alert temperature limit settings commit 28e628645333b7e581c4a7b04d958e4804ea10fe upstream. Do the maths in celsius degree. This can fix the issues caused by the changes below: drm/amd/pm: correct Vega20 swctf limit setting drm/amd/pm: correct Vega12 swctf limit setting drm/amd/pm: correct Vega10 swctf limit setting Signed-off-by: Evan Quan Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 85ca6f199c77e01ee060710f68c44c936169fa5f Author: Evan Quan Date: Fri Aug 21 12:21:30 2020 +0800 drm/amd/pm: correct Vega20 swctf limit setting commit 9b51c4b2ba31396f3894ccc7df8bdf067243e9f5 upstream. Correct the Vega20 thermal swctf limit. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9afabefd42fc97bbbad89f258733badbc1b4f79c Author: Evan Quan Date: Fri Aug 21 12:18:58 2020 +0800 drm/amd/pm: correct Vega12 swctf limit setting commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream. Correct the Vega12 thermal swctf limit. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 60cffee2d9516b8b524a6751a6b90a665c1f1b8a Author: Evan Quan Date: Fri Aug 21 12:05:03 2020 +0800 drm/amd/pm: correct Vega10 swctf limit setting commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream. Correct the Vega10 thermal swctf limit. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267 Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2809cf7f6eba781073b31bd78de27edb9e672a76 Author: Nicholas Kazlauskas Date: Fri Aug 14 11:49:13 2020 -0400 drm/amd/powerplay: Fix hardmins not being sent to SMU for RV commit e2bf3723db563457c0abe4eaeedac25bbbbd1d76 upstream. [Why] DC uses these to raise the voltage as needed for higher dispclk/dppclk and to ensure that we have enough bandwidth to drive the displays. There's a bug preventing these from actuially sending messages since it's checking the actual clock (which is 0) instead of the incoming clock (which shouldn't be 0) when deciding to send the hardmin. [How] Check the clocks != 0 instead of the actual clocks. Fixes: 9ed9203c3ee7 ("drm/amd/powerplay: rv dal-pplib interface refactor powerplay part") Signed-off-by: Nicholas Kazlauskas Reviewed-by: Alex Deucher Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 20700b352d10a90a6393d70c32e7888ce0362789 Author: Jiansong Chen Date: Mon Aug 24 18:44:09 2020 +0800 drm/amdgpu/gfx10: refine mgcg setting commit de7a1b0b8753e1b0000084f0e339ffab295d27ef upstream. 1. enable ENABLE_CGTS_LEGACY to fix specviewperf11 random hang. 2. remove obsolete RLC_CGTT_SCLK_OVERRIDE workaround. Signed-off-by: Jiansong Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8fc7a66619e1f56f5601b4ce6a27bd3e953d169a Author: Alex Deucher Date: Tue Aug 25 11:43:45 2020 -0400 drm/amdgpu: Fix buffer overflow in INFO ioctl commit b5b97cab55eb71daba3283c8b1d2cce456d511a1 upstream. The values for "se_num" and "sh_num" come from the user in the ioctl. They can be in the 0-255 range but if they're more than AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in an out of bounds read. Reported-by: Dan Carpenter Acked-by: Dan Carpenter Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1adf8c19f974b210c243f96cb4d694497f96506d Author: Ashok Raj Date: Wed Aug 26 21:12:10 2020 -0700 x86/hotplug: Silence APIC only after all interrupts are migrated commit 52d6b926aabc47643cd910c85edb262b7f44c168 upstream. There is a race when taking a CPU offline. Current code looks like this: native_cpu_disable() { ... apic_soft_disable(); /* * Any existing set bits for pending interrupt to * this CPU are preserved and will be sent via IPI * to another CPU by fixup_irqs(). */ cpu_disable_common(); { .... /* * Race window happens here. Once local APIC has been * disabled any new interrupts from the device to * the old CPU are lost */ fixup_irqs(); // Too late to capture anything in IRR. ... } } The fix is to disable the APIC *after* cpu_disable_common(). Testing was done with a USB NIC that provided a source of frequent interrupts. A script migrated interrupts to a specific CPU and then took that CPU offline. Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead") Reported-by: Evan Green Signed-off-by: Ashok Raj Signed-off-by: Thomas Gleixner Tested-by: Mathias Nyman Tested-by: Evan Green Reviewed-by: Evan Green Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/875zdarr4h.fsf@nanos.tec.linutronix.de/ Link: https://lore.kernel.org/r/1598501530-45821-1-git-send-email-ashok.raj@intel.com Signed-off-by: Greg Kroah-Hartman commit 47c8387a963e5c2061a27ea3dfee0609268e83e9 Author: qiuguorui1 Date: Thu Aug 20 11:16:29 2020 +0800 irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake commit e579076ac0a3bebb440fab101aef3c42c9f4c709 upstream. In the current code, when the eoi callback of the exti clears the pending bit of the current interrupt, it will first read the values of fpr and rpr, then logically OR the corresponding bit of the interrupt number, and finally write back to fpr and rpr. We found through experiments that if two exti interrupts, we call them int1/int2, arrive almost at the same time. in our scenario, the time difference is 30 microseconds, assuming int1 is triggered first. there will be an extreme scenario: both int's pending bit are set to 1, the irq handle of int1 is executed first, and eoi handle is then executed, at this moment, all pending bits are cleared, but the int 2 has not finally been reported to the cpu yet, which eventually lost int2. According to stm32's TRM description about rpr and fpr: Writing a 1 to this bit will trigger a rising edge event on event x, Writing 0 has no effect. Therefore, when clearing the pending bit, we only need to clear the pending bit of the irq. Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain") Signed-off-by: qiuguorui1 Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org # v4.18+ Link: https://lore.kernel.org/r/20200820031629.15582-1-qiuguorui1@huawei.com Signed-off-by: Greg Kroah-Hartman commit 927aa9a10f126be74cc11e7d39f41adff704b565 Author: Thomas Gleixner Date: Sun Aug 30 19:07:53 2020 +0200 genirq/matrix: Deal with the sillyness of for_each_cpu() on UP commit 784a0830377d0761834e385975bc46861fea9fa0 upstream. Most of the CPU mask operations behave the same way, but for_each_cpu() and it's variants ignore the cpumask argument and claim that CPU0 is always in the mask. This is historical, inconsistent and annoying behaviour. The matrix allocator uses for_each_cpu() and can be called on UP with an empty cpumask. The calling code does not expect that this succeeds but until commit e027fffff799 ("x86/irq: Unbreak interrupt affinity setting") this went unnoticed. That commit added a WARN_ON() to catch cases which move an interrupt from one vector to another on the same CPU. The warning triggers on UP. Add a check for the cpumask being empty to prevent this. Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator") Reported-by: kernel test robot Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 70957a10e1dbc72382994a8c630b7a0c0b55b515 Author: Herbert Xu Date: Thu Aug 27 17:14:36 2020 +1000 crypto: af_alg - Work around empty control messages without MSG_MORE commit c195d66a8a75c60515819b101975f38b7ec6577f upstream. The iwd daemon uses libell which sets up the skcipher operation with two separate control messages. As the first control message is sent without MSG_MORE, it is interpreted as an empty request. While libell should be fixed to use MSG_MORE where appropriate, this patch works around the bug in the kernel so that existing binaries continue to work. We will print a warning however. A separate issue is that the new kernel code no longer allows the control message to be sent twice within the same request. This restriction is obviously incompatible with what iwd was doing (first setting an IV and then sending the real control message). This patch changes the kernel so that this is explicitly allowed. Reported-by: Caleb Jorden Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit aca10ab0568aeb784b2ff47ca611e0fdc0c7f241 Author: Heikki Krogerus Date: Fri Aug 21 13:53:42 2020 +0300 device property: Fix the secondary firmware node handling in set_primary_fwnode() commit c15e1bdda4365a5f17cdadf22bf1c1df13884a9e upstream. When the primary firmware node pointer is removed from a device (set to NULL) the secondary firmware node pointer, when it exists, is made the primary node for the device. However, the secondary firmware node pointer of the original primary firmware node is never cleared (set to NULL). To avoid situation where the secondary firmware node pointer is pointing to a non-existing object, clearing it properly when the primary node is removed from a device in set_primary_fwnode(). Fixes: 97badf873ab6 ("device property: Make it possible to use secondary firmware nodes") Cc: All applicable Signed-off-by: Heikki Krogerus Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit df2a6a4a9d688e29ee4847871451d48248b4c89f Author: Alexey Kardashevskiy Date: Tue Jun 2 12:56:12 2020 +1000 powerpc/perf: Fix crashes with generic_compat_pmu & BHRB commit b460b512417ae9c8b51a3bdcc09020cd6c60ff69 upstream. The bhrb_filter_map ("The Branch History Rolling Buffer") callback is only defined in raw CPUs' power_pmu structs. The "architected" CPUs use generic_compat_pmu, which does not have this callback, and crashes occur if a user tries to enable branch stack for an event. This add a NULL pointer check for bhrb_filter_map() which behaves as if the callback returned an error. This does not add the same check for config_bhrb() as the only caller checks for cpuhw->bhrb_users which remains zero if bhrb_filter_map==0. Fixes: be80e758d0c2 ("powerpc/perf: Add generic compat mode pmu driver") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Alexey Kardashevskiy Reviewed-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200602025612.62707-1-aik@ozlabs.ru Signed-off-by: Greg Kroah-Hartman commit b260fb2a02b584b3203eaa2c8915a1b2269a063f Author: Rafael J. Wysocki Date: Mon Aug 24 19:35:31 2020 +0200 PM: sleep: core: Fix the handling of pending runtime resume requests commit e3eb6e8fba65094328b8dca635d00de74ba75b45 upstream. It has been reported that system-wide suspend may be aborted in the absence of any wakeup events due to unforseen interactions of it with the runtume PM framework. One failing scenario is when there are multiple devices sharing an ACPI power resource and runtime-resume needs to be carried out for one of them during system-wide suspend (for example, because it needs to be reconfigured before the whole system goes to sleep). In that case, the runtime-resume of that device involves turning the ACPI power resource "on" which in turn causes runtime-resume requests to be queued up for all of the other devices sharing it. Those requests go to the runtime PM workqueue which is frozen during system-wide suspend, so they are not actually taken care of until the resume of the whole system, but the pm_runtime_barrier() call in __device_suspend() sees them and triggers system wakeup events for them which then cause the system-wide suspend to be aborted if wakeup source objects are in active use. Of course, the logic that leads to triggering those wakeup events is questionable in the first place, because clearly there are cases in which a pending runtime resume request for a device is not connected to any real wakeup events in any way (like the one above). Moreover, it is racy, because the device may be resuming already by the time the pm_runtime_barrier() runs and so if the driver doesn't take care of signaling the wakeup event as appropriate, it will be lost. However, if the driver does take care of that, the extra pm_wakeup_event() call in the core is redundant. Accordingly, drop the conditional pm_wakeup_event() call fron __device_suspend() and make the latter call pm_runtime_barrier() alone. Also modify the comment next to that call to reflect the new code and extend it to mention the need to avoid unwanted interactions between runtime PM and system-wide device suspend callbacks. Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Reported-by: Utkarsh H Patel Tested-by: Utkarsh H Patel Tested-by: Pengfei Xu Cc: All applicable Signed-off-by: Greg Kroah-Hartman commit 7ded78a8c89ecd69de8b57d420f71e524df0c17e Author: Frank van der Linden Date: Thu Aug 27 23:40:12 2020 +0000 arm64: vdso32: make vdso32 install conditional commit 5d28ba5f8a0cfa3a874fa96c33731b8fcd141b3a upstream. vdso32 should only be installed if CONFIG_COMPAT_VDSO is enabled, since it's not even supposed to be compiled otherwise, and arm64 builds without a 32bit crosscompiler will fail. Fixes: 8d75785a8142 ("ARM64: vdso32: Install vdso32 from vdso_install") Signed-off-by: Frank van der Linden Cc: stable@vger.kernel.org [5.4+] Link: https://lore.kernel.org/r/20200827234012.19757-1-fllinden@amazon.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 3b7087e077300606a6324e4ea632f22df63fabe3 Author: Ding Hui Date: Fri Aug 21 12:15:49 2020 +0300 xhci: Always restore EP_SOFT_CLEAR_TOGGLE even if ep reset failed commit f1ec7ae6c9f8c016db320e204cb519a1da1581b8 upstream. Some device drivers call libusb_clear_halt when target ep queue is not empty. (eg. spice client connected to qemu for usb redir) Before commit f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset"), that works well. But now, we got the error log: EP not empty, refuse reset xhci_endpoint_reset failed and left ep_state's EP_SOFT_CLEAR_TOGGLE bit still set So all the subsequent urb sumbits to the ep will fail with the warn log: Can't enqueue URB while manually clearing toggle We need to clear ep_state EP_SOFT_CLEAR_TOGGLE bit after xhci_endpoint_reset, even if it failed. Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable # v4.17+ Signed-off-by: Ding Hui Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200821091549.20556-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 02166fea639fe40a07b586b866f155dbdb550c97 Author: Kai-Heng Feng Date: Fri Aug 21 12:15:48 2020 +0300 xhci: Do warm-reset when both CAS and XDEV_RESUME are set commit 904df64a5f4d5ebd670801d869ca0a6d6a6e8df6 upstream. Sometimes re-plugging a USB device during system sleep renders the device useless: [ 173.418345] xhci_hcd 0000:00:14.0: Get port status 2-4 read: 0x14203e2, return 0x10262 ... [ 176.496485] usb 2-4: Waited 2000ms for CONNECT [ 176.496781] usb usb2-port4: status 0000.0262 after resume, -19 [ 176.497103] usb 2-4: can't resume, status -19 [ 176.497438] usb usb2-port4: logical disconnect Because PLS equals to XDEV_RESUME, xHCI driver reports U3 to usbcore, despite of CAS bit is flagged. So proritize CAS over XDEV_RESUME to let usbcore handle warm-reset for the port. Cc: stable Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200821091549.20556-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3ac8545b29aedbe152f768f73f0843079780c5c9 Author: Li Jun Date: Fri Aug 21 12:15:47 2020 +0300 usb: host: xhci: fix ep context print mismatch in debugfs commit 0077b1b2c8d9ad5f7a08b62fb8524cdb9938388f upstream. dci is 0 based and xhci_get_ep_ctx() will do ep index increment to get the ep context. [rename dci to ep_index -Mathias] Cc: stable # v4.15+ Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver") Signed-off-by: Li Jun Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200821091549.20556-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4d3e2a3a0c64d19f1461d187b18a53966bc378ea Author: Thomas Gleixner Date: Tue Aug 25 17:22:58 2020 +0200 XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information. commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream. handler data is meant for interrupt handlers and not for storing irq chip specific information as some devices require handler data to store internal per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers. This obviously creates a conflict of interests and crashes the machine because the XEN pointer is overwritten by the driver pointer. As the XEN data is not handler specific it should be stored in irqdesc::irq_data::chip_data instead. A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that. Cc: stable@vger.kernel.org Reported-by: Roman Shaposhnik Signed-off-by: Thomas Gleixner Tested-by: Roman Shaposhnik Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/87lfi2yckt.fsf@nanos.tec.linutronix.de Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 6623c19042b63018230e9468ac16cd1be01abaa3 Author: Jan Kara Date: Fri May 29 16:08:58 2020 +0200 writeback: Fix sync livelock due to b_dirty_time processing commit f9cae926f35e8230330f28c7b743ad088611a8de upstream. When we are processing writeback for sync(2), move_expired_inodes() didn't set any inode expiry value (older_than_this). This can result in writeback never completing if there's steady stream of inodes added to b_dirty_time list as writeback rechecks dirty lists after each writeback round whether there's more work to be done. Fix the problem by using sync(2) start time is inode expiry value when processing b_dirty_time list similarly as for ordinarily dirtied inodes. This requires some refactoring of older_than_this handling which simplifies the code noticeably as a bonus. Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option") CC: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit cb0c74450072f9e5fb6e8b0bd2833225c7cfb0ce Author: Jan Kara Date: Fri May 29 15:05:22 2020 +0200 writeback: Avoid skipping inode writeback commit 5afced3bf28100d81fb2fe7e98918632a08feaf5 upstream. Inode's i_io_list list head is used to attach inode to several different lists - wb->{b_dirty, b_dirty_time, b_io, b_more_io}. When flush worker prepares a list of inodes to writeback e.g. for sync(2), it moves inodes to b_io list. Thus it is critical for sync(2) data integrity guarantees that inode is not requeued to any other writeback list when inode is queued for processing by flush worker. That's the reason why writeback_single_inode() does not touch i_io_list (unless the inode is completely clean) and why __mark_inode_dirty() does not touch i_io_list if I_SYNC flag is set. However there are two flaws in the current logic: 1) When inode has only I_DIRTY_TIME set but it is already queued in b_io list due to sync(2), concurrent __mark_inode_dirty(inode, I_DIRTY_SYNC) can still move inode back to b_dirty list resulting in skipping writeback of inode time stamps during sync(2). 2) When inode is on b_dirty_time list and writeback_single_inode() races with __mark_inode_dirty() like: writeback_single_inode() __mark_inode_dirty(inode, I_DIRTY_PAGES) inode->i_state |= I_SYNC __writeback_single_inode() inode->i_state |= I_DIRTY_PAGES; if (inode->i_state & I_SYNC) bail if (!(inode->i_state & I_DIRTY_ALL)) - not true so nothing done We end up with I_DIRTY_PAGES inode on b_dirty_time list and thus standard background writeback will not writeback this inode leading to possible dirty throttling stalls etc. (thanks to Martijn Coenen for this analysis). Fix these problems by tracking whether inode is queued in b_io or b_more_io lists in a new I_SYNC_QUEUED flag. When this flag is set, we know flush worker has queued inode and we should not touch i_io_list. On the other hand we also know that once flush worker is done with the inode it will requeue the inode to appropriate dirty list. When I_SYNC_QUEUED is not set, __mark_inode_dirty() can (and must) move inode to appropriate dirty list. Reported-by: Martijn Coenen Reviewed-by: Martijn Coenen Tested-by: Martijn Coenen Reviewed-by: Christoph Hellwig Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 8eab2b531fd3a1e2a16c15601f7c612bbf0e38b2 Author: Jan Kara Date: Wed Jun 10 17:36:03 2020 +0200 writeback: Protect inode->i_io_list with inode->i_lock commit b35250c0816c7cf7d0a8de92f5fafb6a7508a708 upstream. Currently, operations on inode->i_io_list are protected by wb->list_lock. In the following patches we'll need to maintain consistency between inode->i_state and inode->i_io_list so change the code so that inode->i_lock protects also all inode's i_io_list handling. Reviewed-by: Martijn Coenen Reviewed-by: Christoph Hellwig CC: stable@vger.kernel.org # Prerequisite for "writeback: Avoid skipping inode writeback" Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2e76a3a1667c41686501de38831aad12ab797d1f Author: Sergey Senozhatsky Date: Mon Aug 17 11:26:46 2020 +0900 serial: 8250: change lock order in serial8250_do_startup() commit 205d300aea75623e1ae4aa43e0d265ab9cf195fd upstream. We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain #1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain #2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain #1 and chain #2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf Signed-off-by: Sergey Senozhatsky Fixes: 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck Reported-by: Raul Rangel BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko Reviewed-by: Guenter Roeck Tested-by: Guenter Roeck Cc: stable Link: https://lore.kernel.org/r/20200817022646.1484638-1-sergey.senozhatsky@gmail.com Signed-off-by: Greg Kroah-Hartman commit f53ebc7c292299b2026b048c320018248bb93ed9 Author: Valmer Huhn Date: Thu Aug 13 12:52:55 2020 -0400 serial: 8250_exar: Fix number of ports for Commtech PCIe cards commit c6b9e95dde7b54e6a53c47241201ab5a4035c320 upstream. The following in 8250_exar.c line 589 is used to determine the number of ports for each Exar board: nr_ports = board->num_ports ? board->num_ports : pcidev->device & 0x0f; If the number of ports a card has is not explicitly specified, it defaults to the rightmost 4 bits of the PCI device ID. This is prone to error since not all PCI device IDs contain a number which corresponds to the number of ports that card provides. This particular case involves COMMTECH_4222PCIE, COMMTECH_4224PCIE and COMMTECH_4228PCIE cards with device IDs 0x0022, 0x0020 and 0x0021. Currently the multiport cards receive 2, 0 and 1 port instead of 2, 4 and 8 ports respectively. To fix this, each Commtech Fastcom PCIe card is given a struct where the number of ports is explicitly specified. This ensures 'board->num_ports' is used instead of the default 'pcidev->device & 0x0f'. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Valmer Huhn Tested-by: Valmer Huhn Cc: stable Link: https://lore.kernel.org/r/20200813165255.GC345440@icarus.concurrent-rt.com Signed-off-by: Greg Kroah-Hartman commit fbb55ec82dd6ed4ce5faadc7722b6ee2f6c0fed5 Author: Holger Assmann Date: Thu Aug 13 17:27:57 2020 +0200 serial: stm32: avoid kernel warning on absence of optional IRQ commit fdf16d78941b4f380753053d229955baddd00712 upstream. stm32_init_port() of the stm32-usart may trigger a warning in platform_get_irq() when the device tree specifies no wakeup interrupt. The wakeup interrupt is usually a board-specific GPIO and the driver functions correctly in its absence. The mainline stm32mp151.dtsi does not specify it, so all mainline device trees trigger an unnecessary kernel warning. Use of platform_get_irq_optional() avoids this. Fixes: 2c58e56096dd ("serial: stm32: fix the get_irq error case") Signed-off-by: Holger Assmann Cc: stable Link: https://lore.kernel.org/r/20200813152757.32751-1-h.assmann@pengutronix.de Signed-off-by: Greg Kroah-Hartman commit 64a05aadf936190545f05722862a5ae0343cd810 Author: Lukas Wunner Date: Thu Aug 13 12:59:54 2020 +0200 serial: pl011: Don't leak amba_ports entry on driver register error commit 89efbe70b27dd325d8a8c177743a26b885f7faec upstream. pl011_probe() calls pl011_setup_port() to reserve an amba_ports[] entry, then calls pl011_register_port() to register the uart driver with the tty layer. If registration of the uart driver fails, the amba_ports[] entry is not released. If this happens 14 times (value of UART_NR macro), then all amba_ports[] entries will have been leaked and driver probing is no longer possible. (To be fair, that can only happen if the DeviceTree doesn't contain alias IDs since they cause the same entry to be used for a given port.) Fix it. Fixes: ef2889f7ffee ("serial: pl011: Move uart_register_driver call to device") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.15+ Cc: Tushar Behera Link: https://lore.kernel.org/r/138f8c15afb2f184d8102583f8301575566064a6.1597316167.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 0806b49bba20b0fa14917d62e9c3d6d62a4b5b4c Author: Lukas Wunner Date: Thu Aug 13 12:52:40 2020 +0200 serial: pl011: Fix oops on -EPROBE_DEFER commit 27afac93e3bd7fa89749cf11da5d86ac9cde4dba upstream. If probing of a pl011 gets deferred until after free_initmem(), an oops ensues because pl011_console_match() is called which has been freed. Fix by removing the __init attribute from the function and those it calls. Commit 10879ae5f12e ("serial: pl011: add console matching function") introduced pl011_console_match() not just for early consoles but regular preferred consoles, such as those added by acpi_parse_spcr(). Regular consoles may be registered after free_initmem() for various reasons, one being deferred probing, another being dynamic enablement of serial ports using a DeviceTree overlay. Thus, pl011_console_match() must not be declared __init and the functions it calls mustn't either. Stack trace for posterity: Unable to handle kernel paging request at virtual address 80c38b58 Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM PC is at pl011_console_match+0x0/0xfc LR is at register_console+0x150/0x468 [<80187004>] (register_console) [<805a8184>] (uart_add_one_port) [<805b2b68>] (pl011_register_port) [<805b3ce4>] (pl011_probe) [<80569214>] (amba_probe) [<805ca088>] (really_probe) [<805ca2ec>] (driver_probe_device) [<805ca5b0>] (__device_attach_driver) [<805c8060>] (bus_for_each_drv) [<805c9dfc>] (__device_attach) [<805ca630>] (device_initial_probe) [<805c90a8>] (bus_probe_device) [<805c95a8>] (deferred_probe_work_func) Fixes: 10879ae5f12e ("serial: pl011: add console matching function") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.10+ Cc: Aleksey Makarov Cc: Peter Hurley Cc: Russell King Cc: Christopher Covington Link: https://lore.kernel.org/r/f827ff09da55b8c57d316a1b008a137677b58921.1597315557.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit daae6b962a1343ea2038c78c022f386df5a56b92 Author: Tamseel Shams Date: Mon Aug 10 08:30:21 2020 +0530 serial: samsung: Removes the IRQ not found warning commit 8c6c378b0cbe0c9f1390986b5f8ffb5f6ff7593b upstream. In few older Samsung SoCs like s3c2410, s3c2412 and s3c2440, UART IP is having 2 interrupt lines. However, in other SoCs like s3c6400, s5pv210, exynos5433, and exynos4210 UART is having only 1 interrupt line. Due to this, "platform_get_irq(platdev, 1)" call in the driver gives the following false-positive error: "IRQ index 1 not found" on newer SoC's. This patch adds the condition to check for Tx interrupt only for the those SoC's which have 2 interrupt lines. Tested-by: Alim Akhtar Tested-by: Marek Szyprowski Reviewed-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Signed-off-by: Tamseel Shams Cc: stable Link: https://lore.kernel.org/r/20200810030021.45348-1-m.shams@samsung.com Signed-off-by: Greg Kroah-Hartman commit 7c57237d74a02fe31757d9c6897cf0d337a4888f Author: George Kennedy Date: Fri Jul 31 12:33:12 2020 -0400 vt_ioctl: change VT_RESIZEX ioctl to check for error return from vc_resize() commit bc5269ca765057a1b762e79a1cfd267cd7bf1c46 upstream. vc_resize() can return with an error after failure. Change VT_RESIZEX ioctl to save struct vc_data values that are modified and restore the original values in case of error. Signed-off-by: George Kennedy Cc: stable Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/1596213192-6635-2-git-send-email-george.kennedy@oracle.com Signed-off-by: Greg Kroah-Hartman commit adb76f3f7732fde77442e78d4713d9c01088a858 Author: Tetsuo Handa Date: Wed Jul 29 23:57:01 2020 +0900 vt: defer kfree() of vc_screenbuf in vc_do_resize() commit f8d1653daec02315e06d30246cff4af72e76e54e upstream. syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin(). Unfortunately, in set_origin(), vc->vc_sw->con_set_origin() might access vc->vc_pos when scroll is involved in order to manipulate cursor, but vc->vc_pos refers already released vc->vc_screenbuf until vc->vc_pos gets updated based on the result of vc->vc_sw->con_set_origin(). Preserving old buffer and tolerating outdated vc members until set_origin() completes would be easier than preventing vc->vc_sw->con_set_origin() from accessing outdated vc members. [1] https://syzkaller.appspot.com/bug?id=6649da2081e2ebdc65c0642c214b27fe91099db3 Reported-by: syzbot Signed-off-by: Tetsuo Handa Cc: stable Link: https://lore.kernel.org/r/1596034621-4714-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit db1bb352cc08d5f148f8caf4efe2ac1590bb2264 Author: Evgeny Novikov Date: Wed Aug 5 12:06:43 2020 +0300 USB: lvtest: return proper error code in probe commit 531412492ce93ea29b9ca3b4eb5e3ed771f851dd upstream. lvs_rh_probe() can return some nonnegative value from usb_control_msg() when it is less than "USB_DT_HUB_NONVAR_SIZE + 2" that is considered as a failure. Make lvs_rh_probe() return -EINVAL in this case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Cc: stable Link: https://lore.kernel.org/r/20200805090643.3432-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 96e41fc29e8af5c5085fb8a79cab8d0d00bab86c Author: George Kennedy Date: Fri Jul 31 12:33:11 2020 -0400 fbcon: prevent user font height or width change from causing potential out-of-bounds access commit 39b3cffb8cf3111738ea993e2757ab382253d86a upstream. Add a check to fbcon_resize() to ensure that a possible change to user font height or user font width will not allow a font data out-of-bounds access. NOTE: must use original charcount in calculation as font charcount can change and cannot be used to determine the font data allocated size. Signed-off-by: George Kennedy Cc: stable Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/1596213192-6635-1-git-send-email-george.kennedy@oracle.com Signed-off-by: Greg Kroah-Hartman commit cd1d270e3e4f7fa1446c63427144fba451383f7b Author: Boris Burkov Date: Tue Aug 18 11:00:05 2020 -0700 btrfs: detect nocow for swap after snapshot delete commit a84d5d429f9eb56f81b388609841ed993f0ddfca upstream. can_nocow_extent and btrfs_cross_ref_exist both rely on a heuristic for detecting a must cow condition which is not exactly accurate, but saves unnecessary tree traversal. The incorrect assumption is that if the extent was created in a generation smaller than the last snapshot generation, it must be referenced by that snapshot. That is true, except the snapshot could have since been deleted, without affecting the last snapshot generation. The original patch claimed a performance win from this check, but it also leads to a bug where you are unable to use a swapfile if you ever snapshotted the subvolume it's in. Make the check slower and more strict for the swapon case, without modifying the general cow checks as a compromise. Turning swap on does not seem to be a particularly performance sensitive operation, so incurring a possibly unnecessary btrfs_search_slot seems worthwhile for the added usability. Note: Until the snapshot is competely cleaned after deletion, check_committed_refs will still cause the logic to think that cow is necessary, so the user must until 'btrfs subvolu sync' finished before activating the swapfile swapon. CC: stable@vger.kernel.org # 5.4+ Suggested-by: Omar Sandoval Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit eb576fc43a43b1419f7b915de3d0828bf22ae17b Author: Filipe Manana Date: Fri Aug 14 11:04:09 2020 +0100 btrfs: fix space cache memory leak after transaction abort commit bbc37d6e475eee8ffa2156ec813efc6bbb43c06d upstream. If a transaction aborts it can cause a memory leak of the pages array of a block group's io_ctl structure. The following steps explain how that can happen: 1) Transaction N is committing, currently in state TRANS_STATE_UNBLOCKED and it's about to start writing out dirty extent buffers; 2) Transaction N + 1 already started and another task, task A, just called btrfs_commit_transaction() on it; 3) Block group B was dirtied (extents allocated from it) by transaction N + 1, so when task A calls btrfs_start_dirty_block_groups(), at the very beginning of the transaction commit, it starts writeback for the block group's space cache by calling btrfs_write_out_cache(), which allocates the pages array for the block group's io_ctl with a call to io_ctl_init(). Block group A is added to the io_list of transaction N + 1 by btrfs_start_dirty_block_groups(); 4) While transaction N's commit is writing out the extent buffers, it gets an IO error and aborts transaction N, also setting the file system to RO mode; 5) Task A has already returned from btrfs_start_dirty_block_groups(), is at btrfs_commit_transaction() and has set transaction N + 1 state to TRANS_STATE_COMMIT_START. Immediately after that it checks that the filesystem was turned to RO mode, due to transaction N's abort, and jumps to the "cleanup_transaction" label. After that we end up at btrfs_cleanup_one_transaction() which calls btrfs_cleanup_dirty_bgs(). That helper finds block group B in the transaction's io_list but it never releases the pages array of the block group's io_ctl, resulting in a memory leak. In fact at the point when we are at btrfs_cleanup_dirty_bgs(), the pages array points to pages that were already released by us at __btrfs_write_out_cache() through the call to io_ctl_drop_pages(). We end up freeing the pages array only after waiting for the ordered extent to complete through btrfs_wait_cache_io(), which calls io_ctl_free() to do that. But in the transaction abort case we don't wait for the space cache's ordered extent to complete through a call to btrfs_wait_cache_io(), so that's why we end up with a memory leak - we wait for the ordered extent to complete indirectly by shutting down the work queues and waiting for any jobs in them to complete before returning from close_ctree(). We can solve the leak simply by freeing the pages array right after releasing the pages (with the call to io_ctl_drop_pages()) at __btrfs_write_out_cache(), since we will never use it anymore after that and the pages array points to already released pages at that point, which is currently not a problem since no one will use it after that, but not a good practice anyway since it can easily lead to use-after-free issues. So fix this by freeing the pages array right after releasing the pages at __btrfs_write_out_cache(). This issue can often be reproduced with test case generic/475 from fstests and kmemleak can detect it and reports it with the following trace: unreferenced object 0xffff9bbf009fa600 (size 512): comm "fsstress", pid 38807, jiffies 4298504428 (age 22.028s) hex dump (first 32 bytes): 00 a0 7c 4d 3d ed ff ff 40 a0 7c 4d 3d ed ff ff ..|M=...@.|M=... 80 a0 7c 4d 3d ed ff ff c0 a0 7c 4d 3d ed ff ff ..|M=.....|M=... backtrace: [<00000000f4b5cfe2>] __kmalloc+0x1a8/0x3e0 [<0000000028665e7f>] io_ctl_init+0xa7/0x120 [btrfs] [<00000000a1f95b2d>] __btrfs_write_out_cache+0x86/0x4a0 [btrfs] [<00000000207ea1b0>] btrfs_write_out_cache+0x7f/0xf0 [btrfs] [<00000000af21f534>] btrfs_start_dirty_block_groups+0x27b/0x580 [btrfs] [<00000000c3c23d44>] btrfs_commit_transaction+0xa6f/0xe70 [btrfs] [<000000009588930c>] create_subvol+0x581/0x9a0 [btrfs] [<000000009ef2fd7f>] btrfs_mksubvol+0x3fb/0x4a0 [btrfs] [<00000000474e5187>] __btrfs_ioctl_snap_create+0x119/0x1a0 [btrfs] [<00000000708ee349>] btrfs_ioctl_snap_create_v2+0xb0/0xf0 [btrfs] [<00000000ea60106f>] btrfs_ioctl+0x12c/0x3130 [btrfs] [<000000005c923d6d>] __x64_sys_ioctl+0x83/0xb0 [<0000000043ace2c9>] do_syscall_64+0x33/0x80 [<00000000904efbce>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1d08edc70154e096bb8a641f8c8ac075a21628ba Author: Josef Bacik Date: Mon Aug 10 17:31:16 2020 -0400 btrfs: check the right error variable in btrfs_del_dir_entries_in_log commit fb2fecbad50964b9f27a3b182e74e437b40753ef upstream. With my new locking code dbench is so much faster that I tripped over a transaction abort from ENOSPC. This turned out to be because btrfs_del_dir_entries_in_log was checking for ret == -ENOSPC, but this function sets err on error, and returns err. So instead of properly marking the inode as needing a full commit, we were returning -ENOSPC and aborting in __btrfs_unlink_inode. Fix this by checking the proper variable so that we return the correct thing in the case of ENOSPC. The ENOENT needs to be checked, because btrfs_lookup_dir_item_index() can return -ENOENT if the dir item isn't in the tree log (which would happen if we hadn't fsync'ed this guy). We actually handle that case in __btrfs_unlink_inode, so it's an expected error to get back. Fixes: 4a500fd178c8 ("Btrfs: Metadata ENOSPC handling for tree log") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ add note and comment about ENOENT ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8a3509486f08cd85122bf077b2555270702778c6 Author: Marcos Paulo de Souza Date: Mon Aug 3 16:55:01 2020 -0300 btrfs: reset compression level for lzo on remount commit 282dd7d7718444679b046b769d872b188818ca35 upstream. Currently a user can set mount "-o compress" which will set the compression algorithm to zlib, and use the default compress level for zlib (3): relatime,compress=zlib:3,space_cache If the user remounts the fs using "-o compress=lzo", then the old compress_level is used: relatime,compress=lzo:3,space_cache But lzo does not expose any tunable compression level. The same happens if we set any compress argument with different level, also with zstd. Fix this by resetting the compress_level when compress=lzo is specified. With the fix applied, lzo is shown without compress level: relatime,compress=lzo,space_cache CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Marcos Paulo de Souza Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b1a83ee0cbbf168c41be3e6a1c8cf045eeca07a1 Author: Ming Lei Date: Mon Aug 17 18:01:15 2020 +0800 blk-mq: order adding requests to hctx->dispatch and checking SCHED_RESTART commit d7d8535f377e9ba87edbf7fbbd634ac942f3f54f upstream. SCHED_RESTART code path is relied to re-run queue for dispatch requests in hctx->dispatch. Meantime the SCHED_RSTART flag is checked when adding requests to hctx->dispatch. memory barriers have to be used for ordering the following two pair of OPs: 1) adding requests to hctx->dispatch and checking SCHED_RESTART in blk_mq_dispatch_rq_list() 2) clearing SCHED_RESTART and checking if there is request in hctx->dispatch in blk_mq_sched_restart(). Without the added memory barrier, either: 1) blk_mq_sched_restart() may miss requests added to hctx->dispatch meantime blk_mq_dispatch_rq_list() observes SCHED_RESTART, and not run queue in dispatch side or 2) blk_mq_dispatch_rq_list still sees SCHED_RESTART, and not run queue in dispatch side, meantime checking if there is request in hctx->dispatch from blk_mq_sched_restart() is missed. IO hang in ltp/fs_fill test is reported by kernel test robot: https://lkml.org/lkml/2020/7/26/77 Turns out it is caused by the above out-of-order OPs. And the IO hang can't be observed any more after applying this patch. Fixes: bd166ef183c2 ("blk-mq-sched: add framework for MQ capable IO schedulers") Reported-by: kernel test robot Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Cc: Bart Van Assche Cc: Christoph Hellwig Cc: David Jeffery Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c2035d1e55aa3e005fe9ca5f15f56398575b44cb Author: Hans de Goede Date: Tue Aug 11 15:39:58 2020 +0200 HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands commit eef4016243e94c438f177ca8226876eb873b9c75 upstream. Before this commit i2c_hid_parse() consists of the following steps: 1. Send power on cmd 2. usleep_range(1000, 5000) 3. Send reset cmd 4. Wait for reset to complete (device interrupt, or msleep(100)) 5. Send power on cmd 6. Try to read HID descriptor Notice how there is an usleep_range(1000, 5000) after the first power-on command, but not after the second power-on command. Testing has shown that at least on the BMAX Y13 laptop's i2c-hid touchpad, not having a delay after the second power-on command causes the HID descriptor to read as all zeros. In case we hit this on other devices too, the descriptor being all zeros can be recognized by the following message being logged many, many times: hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 At the same time as the BMAX Y13's touchpad issue was debugged, Kai-Heng was working on debugging some issues with Goodix i2c-hid touchpads. It turns out that these need a delay after a PWR_ON command too, otherwise they stop working after a suspend/resume cycle. According to Goodix a delay of minimal 60ms is needed. Having multiple cases where we need a delay after sending the power-on command, seems to indicate that we should always sleep after the power-on command. This commit fixes the mentioned issues by moving the existing 1ms sleep to the i2c_hid_set_power() function and changing it to a 60ms sleep. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208247 Reported-by: Kai-Heng Feng Reported-and-tested-by: Andrea Borgia Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit db4542b6617b60810315fe72f40a623e73ee1b66 Author: Ming Lei Date: Mon Aug 17 18:01:30 2020 +0800 block: loop: set discard granularity and alignment for block device backed loop commit bcb21c8cc9947286211327d663ace69f07d37a76 upstream. In case of block device backend, if the backend supports write zeros, the loop device will set queue flag of QUEUE_FLAG_DISCARD. However, limits.discard_granularity isn't setup, and this way is wrong, see the following description in Documentation/ABI/testing/sysfs-block: A discard_granularity of 0 means that the device does not support discard functionality. Especially 9b15d109a6b2 ("block: improve discard bio alignment in __blkdev_issue_discard()") starts to take q->limits.discard_granularity for computing max discard sectors. And zero discard granularity may cause kernel oops, or fail discard request even though the loop queue claims discard support via QUEUE_FLAG_DISCARD. Fix the issue by setup discard granularity and alignment. Fixes: c52abf563049 ("loop: Better discard support for block devices") Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Acked-by: Coly Li Cc: Hannes Reinecke Cc: Xiao Ni Cc: Martin K. Petersen Cc: Evan Green Cc: Gwendal Grignou Cc: Chaitanya Kulkarni Cc: Andrzej Pietrasiewicz Cc: Christoph Hellwig Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f09dbec9c0c68f354eef157c0fe7aa1c6704ecd2 Author: Keith Busch Date: Thu Aug 6 14:58:37 2020 -0700 block: fix get_max_io_size() commit e4b469c66f3cbb81c2e94d31123d7bcdf3c1dabd upstream. A previous commit aligning splits to physical block sizes inadvertently modified one return case such that that it now returns 0 length splits when the number of sectors doesn't exceed the physical offset. This later hits a BUG in bio_split(). Restore the previous working behavior. Fixes: 9cc5169cd478b ("block: Improve physical block alignment of split bios") Reported-by: Eric Deal Signed-off-by: Keith Busch Cc: Bart Van Assche Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2f4b202eb1b127300859f03fdb5afbe9c3cab7e8 Author: Marc Zyngier Date: Fri Jul 31 18:38:24 2020 +0100 arm64: Allow booting of late CPUs affected by erratum 1418040 [ Upstream commit bf87bb0881d0f59181fe3bbcf29c609f36483ff8 ] As we can now switch from a system that isn't affected by 1418040 to a system that globally is affected, let's allow affected CPUs to come in at a later time. Signed-off-by: Marc Zyngier Tested-by: Sai Prakash Ranjan Reviewed-by: Stephen Boyd Reviewed-by: Suzuki K Poulose Acked-by: Will Deacon Link: https://lore.kernel.org/r/20200731173824.107480-3-maz@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 82b05f0838aa43281782cac2fb58c29144c66643 Author: Marc Zyngier Date: Fri Jul 31 18:38:23 2020 +0100 arm64: Move handling of erratum 1418040 into C code [ Upstream commit d49f7d7376d0c0daf8680984a37bd07581ac7d38 ] Instead of dealing with erratum 1418040 on each entry and exit, let's move the handling to __switch_to() instead, which has several advantages: - It can be applied when it matters (switching between 32 and 64 bit tasks). - It is written in C (yay!) - It can rely on static keys rather than alternatives Signed-off-by: Marc Zyngier Tested-by: Sai Prakash Ranjan Reviewed-by: Stephen Boyd Acked-by: Will Deacon Link: https://lore.kernel.org/r/20200731173824.107480-2-maz@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 7d44b707aaff05630bc6b5c5b497e696730a15e3 Author: Athira Rajeev Date: Thu Aug 6 08:46:32 2020 -0400 powerpc/perf: Fix soft lockups due to missed interrupt accounting [ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ] Performance monitor interrupt handler checks if any counter has overflown and calls record_and_restart() in core-book3s which invokes perf_event_overflow() to record the sample information. Apart from creating sample, perf_event_overflow() also does the interrupt and period checks via perf_event_account_interrupt(). Currently we record information only if the SIAR (Sampled Instruction Address Register) valid bit is set (using siar_valid() check) and hence the interrupt check. But it is possible that we do sampling for some events that are not generating valid SIAR, and hence there is no chance to disable the event if interrupts are more than max_samples_per_tick. This leads to soft lockup. Fix this by adding perf_event_account_interrupt() in the invalid SIAR code path for a sampling event. ie if SIAR is invalid, just do interrupt check and don't record the sample information. Reported-by: Alexey Kardashevskiy Signed-off-by: Athira Rajeev Tested-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 9c0305c0cfa22b4f5325c678ddc6b9198dc84837 Author: Sumera Priyadarsini