commit 55c17a63e51a668438d3d9fa5ff8ef959fe90a4c Author: Greg Kroah-Hartman Date: Wed May 26 12:59:15 2021 +0200 Linux 5.12.7 Link: https://lore.kernel.org/r/20210524152334.857620285@linuxfoundation.org Tested-by: Rudi Heitbaum Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Justin M. Forbes Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 58cca5ec43be72a1af95f11966381e9953b0c9f5 Author: Luiz Augusto von Dentz Date: Wed Mar 10 14:13:08 2021 -0800 Bluetooth: SMP: Fail if remote and local public keys are identical commit 6d19628f539fccf899298ff02ee4c73e4bf6df3f upstream. This fails the pairing procedure when both remote and local non-debug public keys are identical. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 20a9b9fddb4818313885dc8e19c4fdcdba3c5e2a Author: Anirudh Rayabharam Date: Mon May 17 00:57:14 2021 +0530 video: hgafb: correctly handle card detect failure during probe commit 02625c965239b71869326dd0461615f27307ecb3 upstream. The return value of hga_card_detect() is not properly handled causing the probe to succeed even though hga_card_detect() failed. Since probe succeeds, hgafb_open() can be called which will end up operating on an unmapped hga_vram. This results in an out-of-bounds access as reported by kernel test robot [1]. To fix this, correctly detect failure of hga_card_detect() by checking for a non-zero error code. [1]: https://lore.kernel.org/lkml/20210516150019.GB25903@xsang-OptiPlex-9020/ Fixes: dc13cac4862c ("video: hgafb: fix potential NULL pointer dereference") Cc: stable Reported-by: kernel test robot Reviewed-by: Igor Matheus Andrade Torrente Signed-off-by: Anirudh Rayabharam Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210516192714.25823-1-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman commit cad3ad9d2094b6f7d798a9f4253fb2b36a4c215c Author: Hou Pu Date: Thu May 13 21:04:10 2021 +0800 nvmet: use new ana_log_size instead the old one commit e181811bd04d874fe48bbfa1165a82068b58144d upstream. The new ana_log_size should be used instead of the old one. Or kernel NULL pointer dereference will happen like below: [ 38.957849][ T69] BUG: kernel NULL pointer dereference, address: 000000000000003c [ 38.975550][ T69] #PF: supervisor write access in kernel mode [ 38.975955][ T69] #PF: error_code(0x0002) - not-present page [ 38.976905][ T69] PGD 0 P4D 0 [ 38.979388][ T69] Oops: 0002 [#1] SMP NOPTI [ 38.980488][ T69] CPU: 0 PID: 69 Comm: kworker/0:2 Not tainted 5.12.0+ #54 [ 38.981254][ T69] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 38.982502][ T69] Workqueue: events nvme_loop_execute_work [ 38.985219][ T69] RIP: 0010:memcpy_orig+0x68/0x10f [ 38.986203][ T69] Code: 83 c2 20 eb 44 48 01 d6 48 01 d7 48 83 ea 20 0f 1f 00 48 83 ea 20 4c 8b 46 f8 4c 8b 4e f0 4c 8b 56 e8 4c 8b 5e e0 48 8d 76 e0 <4c> 89 47 f8 4c 89 4f f0 4c 89 57 e8 4c 89 5f e0 48 8d 7f e0 73 d2 [ 38.987677][ T69] RSP: 0018:ffffc900001b7d48 EFLAGS: 00000287 [ 38.987996][ T69] RAX: 0000000000000020 RBX: 0000000000000024 RCX: 0000000000000010 [ 38.988327][ T69] RDX: ffffffffffffffe4 RSI: ffff8881084bc004 RDI: 0000000000000044 [ 38.988620][ T69] RBP: 0000000000000024 R08: 0000000100000000 R09: 0000000000000000 [ 38.988991][ T69] R10: 0000000100000000 R11: 0000000000000001 R12: 0000000000000024 [ 38.989289][ T69] R13: ffff8881084bc000 R14: 0000000000000000 R15: 0000000000000024 [ 38.989845][ T69] FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 [ 38.990234][ T69] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 38.990490][ T69] CR2: 000000000000003c CR3: 00000001085b2000 CR4: 00000000000006f0 [ 38.991105][ T69] Call Trace: [ 38.994157][ T69] sg_copy_buffer+0xb8/0xf0 [ 38.995357][ T69] nvmet_copy_to_sgl+0x48/0x6d [ 38.995565][ T69] nvmet_execute_get_log_page_ana+0xd4/0x1cb [ 38.995792][ T69] nvmet_execute_get_log_page+0xc9/0x146 [ 38.995992][ T69] nvme_loop_execute_work+0x3e/0x44 [ 38.996181][ T69] process_one_work+0x1c3/0x3c0 [ 38.996393][ T69] worker_thread+0x44/0x3d0 [ 38.996600][ T69] ? cancel_delayed_work+0x90/0x90 [ 38.996804][ T69] kthread+0xf7/0x130 [ 38.996961][ T69] ? kthread_create_worker_on_cpu+0x70/0x70 [ 38.997171][ T69] ret_from_fork+0x22/0x30 [ 38.997705][ T69] Modules linked in: [ 38.998741][ T69] CR2: 000000000000003c [ 39.000104][ T69] ---[ end trace e719927b609d0fa0 ]--- Fixes: 5e1f689913a4 ("nvme-multipath: fix double initialization of ANA state") Signed-off-by: Hou Pu Signed-off-by: Christoph Hellwig Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 46f5e618ccb77af14928bfab2fe30ffb29ac377e Author: Joerg Roedel Date: Fri Mar 12 13:38:23 2021 +0100 x86/boot/compressed/64: Check SEV encryption in the 32-bit boot-path commit fef81c86262879d4b1176ef51a834c15b805ebb9 upstream. Check whether the hypervisor reported the correct C-bit when running as an SEV guest. Using a wrong C-bit position could be used to leak sensitive data from the guest to the hypervisor. Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210312123824.306-8-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit 94d371473b7fc67f2345611ee65e354dfb2221f8 Author: Francois Gervais Date: Wed Mar 10 16:10:26 2021 -0500 rtc: pcf85063: fallback to parent of_node commit 03531606ef4cda25b629f500d1ffb6173b805c05 upstream. The rtc device node is always NULL. Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this will lead to a NULL pointer dereference. To fix this use the parent node which is the i2c client node as set by devm_rtc_allocate_device(). Using the i2c client node seems to be what other similar drivers do e.g. rtc-pcf8563.c. Signed-off-by: Francois Gervais Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210310211026.27299-1-fgervais@distech-controls.com Signed-off-by: Greg Kroah-Hartman commit 51a018320158e5536ede670ef391f44cd611fcdb Author: Christoph Hellwig Date: Thu Apr 29 14:18:53 2021 +0200 nvme-multipath: fix double initialization of ANA state commit 5e1f689913a4498e3081093670ef9d85b2c60920 upstream. nvme_init_identify and thus nvme_mpath_init can be called multiple times and thus must not overwrite potentially initialized or in-use fields. Split out a helper for the basic initialization when the controller is initialized and make sure the init_identify path does not blindly change in-use data structures. Fixes: 0d0b660f214d ("nvme: add ANA support") Reported-by: Martin Wilck Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Hannes Reinecke Signed-off-by: Greg Kroah-Hartman commit 5f72937db874606fdf6efe3016e4417231b650e0 Author: Jan Beulich Date: Thu May 20 13:42:42 2021 +0200 x86/Xen: swap NX determination and GDT setup on BSP commit ae897fda4f507e4b239f0bdfd578b3688ca96fb4 upstream. xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. [jgross] Note that this is a revert of 36104cb9012a82e73 ("x86/xen: Delay get_cpu_cap until stack canary is established"), which is possible now that we no longer support running as PV guest in 32-bit mode. Cc: # 5.9 Fixes: 36104cb9012a82e73 ("x86/xen: Delay get_cpu_cap until stack canary is established") Reported-by: Olaf Hering Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/12a866b0-9e89-59f7-ebeb-a2a6cec0987a@suse.com Signed-off-by: Juergen Gross commit 03bb19228fd51c0010351008fba5963c69a634ba Author: Mike Rapoport Date: Sun May 9 12:11:02 2021 +0300 openrisc: mm/init.c: remove unused memblock_region variable in map_ram() commit 4eff124347191d1548eb4e14e20e77513dcbd0fe upstream. Kernel test robot reports: cppcheck possible warnings: (new ones prefixed by >>, may not real problems) >> arch/openrisc/mm/init.c:125:10: warning: Uninitialized variable: region [uninitvar] region->base, region->base + region->size); ^ Replace usage of memblock_region fields with 'start' and 'end' variables that are initialized in for_each_mem_range() and remove the declaration of region. Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Reported-by: kernel test robot Signed-off-by: Mike Rapoport Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman commit 9d950576b3649fb9630d871ac3718c98c1b6d939 Author: Simon Rettberg Date: Mon Apr 26 16:11:24 2021 +0200 drm/i915/gt: Disable HiZ Raw Stall Optimization on broken gen7 commit 023dfa9602f561952c0e19d74f66614a56d7e57a upstream. When resetting CACHE_MODE registers, don't enable HiZ Raw Stall Optimization on Ivybridge GT1 and Baytrail, as it causes severe glitches when rendering any kind of 3D accelerated content. This optimization is disabled on these platforms by default according to official documentation from 01.org. Fixes: ef99a60ffd9b ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3081 BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3404 BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/3071 Reviewed-by: Manuel Bentele Signed-off-by: Simon Rettberg Reviewed-by: Dave Airlie Signed-off-by: Rodrigo Vivi [Rodrigo removed invalid Fixes line] Link: https://patchwork.freedesktop.org/patch/msgid/20210426161124.2b7fd708@dellnichtsogutkiste (cherry picked from commit 929b734ad34b717d6a1b8de97f53bb5616040147) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 48c1afbbd7e01e9c72b03ddb97fe130a62725fd9 Author: Tetsuo Handa Date: Sat May 15 03:00:37 2021 +0000 tty: vt: always invoke vc->vc_sw->con_resize callback commit ffb324e6f874121f7dce5bdae5e05d02baae7269 upstream. syzbot is reporting OOB write at vga16fb_imageblit() [1], for resize_screen() from ioctl(VT_RESIZE) returns 0 without checking whether requested rows/columns fit the amount of memory reserved for the graphical screen if current mode is KD_GRAPHICS. ---------- #include #include #include #include #include #include int main(int argc, char *argv[]) { const int fd = open("/dev/char/4:1", O_RDWR); struct vt_sizes vt = { 0x4100, 2 }; ioctl(fd, KDSETMODE, KD_GRAPHICS); ioctl(fd, VT_RESIZE, &vt); ioctl(fd, KDSETMODE, KD_TEXT); return 0; } ---------- Allow framebuffer drivers to return -EINVAL, by moving vc->vc_mode != KD_GRAPHICS check from resize_screen() to fbcon_resize(). Link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 [1] Reported-by: syzbot Suggested-by: Linus Torvalds Signed-off-by: Tetsuo Handa Tested-by: syzbot Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e8263abc836aa47144a7b2fa86cbf561439b0d77 Author: Maciej W. Rozycki Date: Thu May 13 11:51:50 2021 +0200 vt: Fix character height handling with VT_RESIZEX commit 860dafa902595fb5f1d23bbcce1215188c3341e6 upstream. Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 28cae8a1ceab12e6315c0198b3d3644796fc789e Author: Maciej W. Rozycki Date: Thu May 13 11:51:45 2021 +0200 vt_ioctl: Revert VT_RESIZEX parameter handling removal commit a90c275eb144c1b755f04769e1f29d832d6daeaf upstream. Revert the removal of code handling extra VT_RESIZEX ioctl's parameters beyond those that VT_RESIZE supports, fixing a functional regression causing `svgatextmode' not to resize the VT anymore. As a consequence of the reverted change when the video adapter is reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), the VT geometry does not get updated and only upper two thirds of the screen are used for the VT, and the lower part remains blank. The proportions change according to text mode geometries chosen. Revert the change verbatim then, bringing back previous VT resizing. Signed-off-by: Maciej W. Rozycki Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 727caaaf7a299b300d1616e3eb0c8817feca27a0 Author: Maciej W. Rozycki Date: Thu May 13 11:51:41 2021 +0200 vgacon: Record video mode changes with VT_RESIZEX commit d4d0ad57b3865795c4cde2fb5094c594c2e8f469 upstream. Fix an issue with VGA console font size changes made after the initial video text mode has been changed with a user tool like `svgatextmode' calling the VT_RESIZEX ioctl. As it stands in that case the original screen geometry continues being used to validate further VT resizing. Consequently when the video adapter is firstly reprogrammed from the original say 80x25 text mode using a 9x16 character cell (720x400 pixel resolution) to say 80x37 text mode and the same character cell (720x592 pixel resolution), and secondly the CRTC character cell updated to 9x8 (by loading a suitable font with the KD_FONT_OP_SET request of the KDFONTOP ioctl), the VT geometry does not get further updated from 80x37 and only upper half of the screen is used for the VT, with the lower half showing rubbish corresponding to whatever happens to be there in the video memory that maps to that part of the screen. Of course the proportions change according to text mode geometries and font sizes chosen. Address the problem then, by updating the text mode geometry defaults rather than checking against them whenever the VT is resized via a user ioctl. Signed-off-by: Maciej W. Rozycki Fixes: e400b6ec4ede ("vt/vgacon: Check if screen resize request comes from userspace") Cc: stable@vger.kernel.org # v2.6.24+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a31ef3d2e12f220ea217a46c26d23946fc4b6c9f Author: Igor Matheus Andrade Torrente Date: Mon May 3 13:57:06 2021 +0200 video: hgafb: fix potential NULL pointer dereference commit dc13cac4862cc68ec74348a80b6942532b7735fa upstream. The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference. The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect. Cc: Ferenc Bakonyi Cc: Bartlomiej Zolnierkiewicz Cc: stable Signed-off-by: Igor Matheus Andrade Torrente Link: https://lore.kernel.org/r/20210503115736.2104747-40-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit c999df38fa3b8972f66fd026616dd734e0574447 Author: Tom Seewald Date: Mon May 3 13:56:52 2021 +0200 qlcnic: Add null check after calling netdev_alloc_skb commit 84460f01cba382553199bc1361f69a872d5abed4 upstream. The function qlcnic_dl_lb_test() currently calls netdev_alloc_skb() without checking afterwards that the allocation succeeded. Fix this by checking if the skb is NULL and returning an error in such a case. Breaking out of the loop if the skb is NULL is not correct as no error would be reported to the caller and no message would be printed for the user. Cc: David S. Miller Cc: stable Signed-off-by: Tom Seewald Link: https://lore.kernel.org/r/20210503115736.2104747-26-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 83247d7a0fcebf2dac28180462f4d2a9bc081320 Author: Phillip Potter Date: Mon May 3 13:56:36 2021 +0200 leds: lp5523: check return value of lp5xx_read and jump to cleanup code commit 6647f7a06eb030a2384ec71f0bb2e78854afabfe upstream. Check return value of lp5xx_read and if non-zero, jump to code at end of the function, causing lp5523_stop_all_engines to be executed before returning the error value up the call chain. This fixes the original commit (248b57015f35) which was reverted due to the University of Minnesota problems. Cc: stable Acked-by: Jacek Anaszewski Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-10-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 4c1c304a77c274e767481dbbe4587eb3685aa0cd Author: Darrick J. Wong Date: Wed Apr 28 15:25:34 2021 -0700 ics932s401: fix broken handling of errors when word reading fails commit a73b6a3b4109ce2ed01dbc51a6c1551a6431b53c upstream. In commit b05ae01fdb89, someone tried to make the driver handle i2c read errors by simply zeroing out the register contents, but for some reason left unaltered the code that sets the cached register value the function call return value. The original patch was authored by a member of the Underhanded Mangle-happy Nerds, I'm not terribly surprised. I don't have the hardware anymore so I can't test this, but it seems like a pretty obvious API usage fix to me... Fixes: b05ae01fdb89 ("misc/ics932s401: Add a missing check to i2c_smbus_read_word_data") Signed-off-by: Darrick J. Wong Link: https://lore.kernel.org/r/20210428222534.GJ3122264@magnolia Cc: stable Signed-off-by: Greg Kroah-Hartman commit 10d0a8d1b9a4924d3a1058122883e77a2f2963b9 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:40 2021 +0200 net: rtlwifi: properly check for alloc_workqueue() failure commit 30b0e0ee9d02b97b68705c46b41444786effc40c upstream. If alloc_workqueue() fails, properly catch this and propagate the error to the calling functions, so that the devuce initialization will properly error out. Cc: Kalle Valo Cc: Bryan Brattlof Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-14-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 017fb1eaac4c53571340b9682007d3ed6a8c45b8 Author: Phillip Potter Date: Mon May 3 13:56:58 2021 +0200 scsi: ufs: handle cleanup correctly on devm_reset_control_get error commit 2f4a784f40f8d337d6590e2e93f46429052e15ac upstream. Move ufshcd_set_variant call in ufs_hisi_init_common to common error section at end of the function, and then jump to this from the error checking statements for both devm_reset_control_get and ufs_hisi_get_resource. This fixes the original commit (63a06181d7ce) which was reverted due to the University of Minnesota problems. Suggested-by: Greg Kroah-Hartman Cc: Avri Altman Cc: Martin K. Petersen Cc: stable Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-32-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit a04fe8f4b075717c46160b6f0414f1bd6ee012c4 Author: Anirudh Rayabharam Date: Mon May 3 13:56:48 2021 +0200 net: stmicro: handle clk_prepare() failure during init commit 0c32a96d000f260b5ebfabb4145a86ae1cd71847 upstream. In case clk_prepare() fails, capture and propagate the error code up the stack. If regulator_enable() was called earlier, properly unwind it by calling regulator_disable(). Signed-off-by: Anirudh Rayabharam Cc: David S. Miller Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-22-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 85eed97d8c50427fa3dcdcbeff2281acb84802fb Author: Du Cheng Date: Mon May 3 13:56:50 2021 +0200 ethernet: sun: niu: fix missing checks of niu_pci_eeprom_read() commit e6e337708c22f80824b82d4af645f20715730ad0 upstream. niu_pci_eeprom_read() may fail, so add checks to its return value and propagate the error up the callstack. An examination of the callstack up to niu_pci_eeprom_read shows that: niu_pci_eeprom_read() // returns int niu_pci_vpd_scan_props() // returns int niu_pci_vpd_fetch() // returns *void* niu_get_invariants() // returns int since niu_pci_vpd_fetch() returns void which breaks the bubbling up, change its return type to int so that error is propagated upwards. Signed-off-by: Du Cheng Cc: Shannon Nelson Cc: David S. Miller Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-24-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit cbc901a2b23b3a3497a49573310d2281cb382576 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:49 2021 +0200 Revert "niu: fix missing checks of niu_pci_eeprom_read" commit 7930742d6a0ff091c85b92ef4e076432d8d8cb79 upstream. This reverts commit 26fd962bde0b15e54234fe762d86bc0349df1de4. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The change here was incorrect. While it is nice to check if niu_pci_eeprom_read() succeeded or not when using the data, any error that might have happened was not propagated upwards properly, causing the kernel to assume that these reads were successful, which results in invalid data in the buffer that was to contain the successfully read data. Cc: Kangjie Lu Cc: Shannon Nelson Cc: David S. Miller Fixes: 26fd962bde0b ("niu: fix missing checks of niu_pci_eeprom_read") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-23-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit d55309c782efbac48d10b5f247bff9db6f4f1c52 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:51 2021 +0200 Revert "qlcnic: Avoid potential NULL pointer dereference" commit b95b57dfe7a142bf2446548eb7f49340fd73e78b upstream. This reverts commit 5bf7295fe34a5251b1d241b9736af4697b590670. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit does not properly detect if an error happens because the logic after this loop will not detect that there was a failed allocation. Cc: Aditya Pakki Cc: David S. Miller Fixes: 5bf7295fe34a ("qlcnic: Avoid potential NULL pointer dereference") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-25-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit bd9dd0ffe19461a1485e20340edf2de491e1c904 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:39 2021 +0200 Revert "rtlwifi: fix a potential NULL pointer dereference" commit 68c5634c4a7278672a3bed00eb5646884257c413 upstream. This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit is not correct, it should not have used unlikely() and is not propagating the error properly to the calling function, so it should be reverted at this point in time. Also, if the check failed, the work queue was still assumed to be allocated, so further accesses would have continued to fail, meaning this patch does nothing to solve the root issues at all. Cc: Kangjie Lu Cc: Kalle Valo Cc: Bryan Brattlof Fixes: 765976285a8c ("rtlwifi: fix a potential NULL pointer dereference") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-13-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 4650e0bbf2c8861e3d8fa433bef5ee3f4239720a Author: Greg Kroah-Hartman Date: Mon May 3 13:56:30 2021 +0200 Revert "media: rcar_drif: fix a memory disclosure" commit 3e465fc3846734e9489273d889f19cc17b4cf4bd upstream. This reverts commit d39083234c60519724c6ed59509a2129fd2aed41. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, it was determined that this commit is not needed at all as the media core already prevents memory disclosure on this codepath, so just drop the extra memset happening here. Cc: Kangjie Lu Cc: Geert Uytterhoeven Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Fixes: d39083234c60 ("media: rcar_drif: fix a memory disclosure") Cc: stable Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Fabrizio Castro Link: https://lore.kernel.org/r/20210503115736.2104747-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 8713e157b8668a5d199737178423fdce9540a53b Author: Greg Kroah-Hartman Date: Thu May 6 16:00:47 2021 +0200 cdrom: gdrom: initialize global variable at init time commit 9183f01b5e6e32eb3f17b5f3f8d5ad5ac9786c49 upstream. As Peter points out, if we were to disconnect and then reconnect this driver from a device, the "global" state of the device would contain odd values and could cause problems. Fix this up by just initializing the whole thing to 0 at probe() time. Ideally this would be a per-device variable, but given the age and the total lack of users of it, that would require a lot of s/./->/g changes for really no good reason. Reported-by: Peter Rosin Cc: Jens Axboe Reviewed-by: Peter Rosin Link: https://lore.kernel.org/r/YJP2j6AU82MqEY2M@kroah.com Signed-off-by: Greg Kroah-Hartman commit c8935240be5acf3c77e2ab85cdbdd42ec89bf274 Author: Atul Gopinathan Date: Mon May 3 13:56:54 2021 +0200 cdrom: gdrom: deallocate struct gdrom_unit fields in remove_gdrom commit d03d1021da6fe7f46efe9f2a7335564e7c9db5ab upstream. The fields, "toc" and "cd_info", of "struct gdrom_unit gd" are allocated in "probe_gdrom()". Prevent a memory leak by making sure "gd.cd_info" is deallocated in the "remove_gdrom()" function. Also prevent double free of the field "gd.toc" by moving it from the module's exit function to "remove_gdrom()". This is because, in "probe_gdrom()", the function makes sure to deallocate "gd.toc" in case of any errors, so the exit function invoked later would again free "gd.toc". The patch also maintains consistency by deallocating the above mentioned fields in "remove_gdrom()" along with another memory allocated field "gd.disk". Suggested-by: Jens Axboe Cc: Peter Rosin Cc: stable Signed-off-by: Atul Gopinathan Link: https://lore.kernel.org/r/20210503115736.2104747-28-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit b3f8eec4037071abe73d464af40541e802046fc0 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:53 2021 +0200 Revert "gdrom: fix a memory leak bug" commit 257343d3ed557f11d580d0b7c515dc154f64a42b upstream. This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase. Cc: Wenwen Wang Cc: Peter Rosin Cc: Jens Axboe Fixes: 093c48213ee3 ("gdrom: fix a memory leak bug") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-27-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 1ba5c1746f87815f75c6c50f9f7e921557d81a1c Author: Greg Kroah-Hartman Date: Mon May 3 13:56:57 2021 +0200 Revert "scsi: ufs: fix a missing check of devm_reset_control_get" commit 4d427b408c4c2ff1676966c72119a3a559f8e39b upstream. This reverts commit 63a06181d7ce169d09843645c50fea1901bc9f0a. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit is incorrect, it does not properly clean up on the error path, so I'll keep the revert and fix it up properly with a follow-on patch. Cc: Kangjie Lu Cc: Avri Altman Cc: Martin K. Petersen Fixes: 63a06181d7ce ("scsi: ufs: fix a missing check of devm_reset_control_get") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-31-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 68f6eeeb814d697c2d67b0f9cbbff2070cf367fd Author: Greg Kroah-Hartman Date: Mon May 3 13:57:15 2021 +0200 Revert "ecryptfs: replace BUG_ON with error handling code" commit e1436df2f2550bc89d832ffd456373fdf5d5b5d7 upstream. This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit log for this change was incorrect, no "error handling code" was added, things will blow up just as badly as before if any of these cases ever were true. As this BUG_ON() never fired, and most of these checks are "obviously" never going to be true, let's just revert to the original code for now until this gets unwound to be done correctly in the future. Cc: Aditya Pakki Fixes: 2c2a7552dd64 ("ecryptfs: replace BUG_ON with error handling code") Cc: stable Acked-by: Tyler Hicks Link: https://lore.kernel.org/r/20210503115736.2104747-49-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 36398a291bd5cd2e10fb1f0c366afc4c3d9d10f2 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:33 2021 +0200 Revert "video: imsttfb: fix potential NULL pointer dereferences" commit ed04fe8a0e87d7b5ea17d47f4ac9ec962b24814a upstream. This reverts commit 1d84353d205a953e2381044953b7fa31c8c9702d. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit here, while technically correct, did not fully handle all of the reported issues that the commit stated it was fixing, so revert it until it can be "fixed" fully. Note, ioremap() probably will never fail for old hardware like this, and if anyone actually used this hardware (a PowerMac era PCI display card), they would not be using fbdev anymore. Cc: Kangjie Lu Cc: Aditya Pakki Cc: Finn Thain Cc: Bartlomiej Zolnierkiewicz Reviewed-by: Rob Herring Fixes: 1d84353d205a ("video: imsttfb: fix potential NULL pointer dereferences") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-67-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit f65fe9bc54b424c4866661f534b9e37e8fb3ad34 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:31 2021 +0200 Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe" commit 99ae3417672a6d4a3bf68d4fc43d7c6ca074d477 upstream. This reverts commit 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, it was determined that this commit is not needed at all so just revert it. Also, the call to lm80_init_client() was not properly handled, so if error handling is needed in the lm80_probe() function, then it should be done properly, not half-baked like the commit being reverted here did. Cc: Kangjie Lu Fixes: 9aa3aa15f4c2 ("hwmon: (lm80) fix a missing check of bus read in lm80 probe") Cc: stable Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20210503115736.2104747-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit a9a5e6f4722323418cdc5676c876314960380008 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:35 2021 +0200 Revert "leds: lp5523: fix a missing check of return value of lp55xx_read" commit 8d1beda5f11953ffe135a5213287f0b25b4da41b upstream. This reverts commit 248b57015f35c94d4eae2fdd8c6febf5cd703900. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit does not properly unwind if there is an error condition so it needs to be reverted at this point in time. Cc: Kangjie Lu Cc: Jacek Anaszewski Cc: stable Fixes: 248b57015f35 ("leds: lp5523: fix a missing check of return value of lp55xx_read") Link: https://lore.kernel.org/r/20210503115736.2104747-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 58673abf25d9d4a340103902926ca9ee5e1aee49 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:47 2021 +0200 Revert "net: stmicro: fix a missing check of clk_prepare" commit bee1b0511844c8c79fccf1f2b13472393b6b91f7 upstream. This reverts commit f86a3b83833e7cfe558ca4d70b64ebc48903efec. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit causes a memory leak when it is trying to claim it is properly handling errors. Revert this change and fix it up properly in a follow-on commit. Cc: Kangjie Lu Cc: David S. Miller Fixes: f86a3b83833e ("net: stmicro: fix a missing check of clk_prepare") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-21-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6c8326b8411d72d1279b55715916e2f4ab99375f Author: Greg Kroah-Hartman Date: Mon May 3 13:57:05 2021 +0200 Revert "video: hgafb: fix potential NULL pointer dereference" commit 58c0cc2d90f1e37c4eb63ae7f164c83830833f78 upstream. This reverts commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This patch "looks" correct, but the driver keeps on running and will fail horribly right afterward if this error condition ever trips. So points for trying to resolve an issue, but a huge NEGATIVE value for providing a "fake" fix for the problem as nothing actually got resolved at all. I'll go fix this up properly... Cc: Kangjie Lu Cc: Aditya Pakki Cc: Ferenc Bakonyi Cc: Bartlomiej Zolnierkiewicz Fixes: ec7f6aad57ad ("video: hgafb: fix potential NULL pointer dereference") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-39-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 5c65f3a98b663a0c9fbdba7cf7409143de9eb27f Author: Arnd Bergmann Date: Fri May 14 16:00:08 2021 +0200 kcsan: Fix debugfs initcall return type commit 976aac5f882989e4f6c1b3a7224819bf0e801c6a upstream. clang with CONFIG_LTO_CLANG points out that an initcall function should return an 'int' due to the changes made to the initcall macros in commit 3578ad11f3fb ("init: lto: fix PREL32 relocations"): kernel/kcsan/debugfs.c:274:15: error: returning 'void' from a function with incompatible result type 'int' late_initcall(kcsan_debugfs_init); ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ include/linux/init.h:292:46: note: expanded from macro 'late_initcall' #define late_initcall(fn) __define_initcall(fn, 7) Fixes: e36299efe7d7 ("kcsan, debugfs: Move debugfs file creation out of early init") Cc: stable Reviewed-by: Greg Kroah-Hartman Reviewed-by: Marco Elver Reviewed-by: Nathan Chancellor Reviewed-by: Miguel Ojeda Signed-off-by: Arnd Bergmann Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit ac4bf514d5282b70ccae1598119d8317bffc4257 Author: Mikulas Patocka Date: Mon May 10 14:49:05 2021 -0400 dm snapshot: fix crash with transient storage and zero chunk size commit c699a0db2d62e3bbb7f0bf35c87edbc8d23e3062 upstream. The following commands will crash the kernel: modprobe brd rd_size=1048576 dmsetup create o --table "0 `blockdev --getsize /dev/ram0` snapshot-origin /dev/ram0" dmsetup create s --table "0 `blockdev --getsize /dev/ram0` snapshot /dev/ram0 /dev/ram1 N 0" The reason is that when we test for zero chunk size, we jump to the label bad_read_metadata without setting the "r" variable. The function snapshot_ctr destroys all the structures and then exits with "r == 0". The kernel then crashes because it falsely believes that snapshot_ctr succeeded. In order to fix the bug, we set the variable "r" to -EINVAL. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7c21d01b63cd8887d7a58d4ca66f7c52605a4d68 Author: Michal Hocko Date: Sat May 22 17:41:46 2021 -0700 Revert "mm/gup: check page posion status for coredump." commit f10628d2f613195132532e0fbda439eeed8d12a2 upstream. While reviewing [1] I came across commit d3378e86d182 ("mm/gup: check page posion status for coredump.") and noticed that this patch is broken in two ways. First it doesn't really prevent hwpoison pages from being dumped because hwpoison pages can be marked asynchornously at any time after the check. Secondly, and more importantly, the patch introduces a ref count leak because get_dump_page takes a reference on the page which is not released. It also seems that the patch was merged incorrectly because there were follow up changes not included as well as discussions on how to address the underlying problem [2] Therefore revert the original patch. Link: http://lkml.kernel.org/r/20210429122519.15183-4-david@redhat.com [1] Link: http://lkml.kernel.org/r/57ac524c-b49a-99ec-c1e4-ef5027bfb61b@redhat.com [2] Link: https://lkml.kernel.org/r/20210505135407.31590-1-mhocko@kernel.org Fixes: d3378e86d182 ("mm/gup: check page posion status for coredump.") Signed-off-by: Michal Hocko Reviewed-by: David Hildenbrand Cc: Aili Yao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5ce1a85a5d04bed7976e6be5ef2a3359ba0ff6c5 Author: Mike Kravetz Date: Sat May 22 17:42:11 2021 -0700 userfaultfd: hugetlbfs: fix new flag usage in error path commit e32905e57358fdfb82f9de024534f205b3af7dac upstream. In commit d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags") the use of PagePrivate to indicate a reservation count should be restored at free time was changed to the hugetlb specific flag HPageRestoreReserve. Changes to a userfaultfd error path as well as a VM_BUG_ON() in remove_inode_hugepages() were overlooked. Users could see incorrect hugetlb reserve counts if they experience an error with a UFFDIO_COPY operation. Specifically, this would be the result of an unlikely copy_huge_page_from_user error. There is not an increased chance of hitting the VM_BUG_ON. Link: https://lkml.kernel.org/r/20210521233952.236434-1-mike.kravetz@oracle.com Fixes: d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags") Signed-off-by: Mike Kravetz Reviewed-by: Mina Almasry Cc: Oscar Salvador Cc: Michal Hocko Cc: Muchun Song Cc: Naoya Horiguchi Cc: David Hildenbrand Cc: Matthew Wilcox Cc: Miaohe Lin Cc: Mina Almasry Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 807fa14536b26803b858da878b643be72952a097 Author: Varad Gautam Date: Sat May 22 17:41:49 2021 -0700 ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry commit a11ddb37bf367e6b5239b95ca759e5389bb46048 upstream. do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (`this` is `ewq_addr`.) 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see `state == STATE_READY` and break. 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.) 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a `struct ext_wait_queue *`, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten `ewq_addr` yet, `ewq_addr->task` is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash. do_mq_timedsend::__pipelined_op() should not dereference `this` after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing `this` which sits on the receiver's stack. As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way. Link: https://lkml.kernel.org/r/20210510102950.12551-1-varad.gautam@suse.com Fixes: c5b2cbdbdac563 ("ipc/mqueue.c: update/document memory barriers") Fixes: 8116b54e7e23ef ("ipc/sem.c: document and update memory barriers") Fixes: 0d97a82ba830d8 ("ipc/msg.c: update and document memory barriers") Signed-off-by: Varad Gautam Reported-by: Matthias von Faber Acked-by: Davidlohr Bueso Acked-by: Manfred Spraul Cc: Christian Brauner Cc: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6217e5411ba93365410ef720cbc4d2eddde11f36 Author: Jan Beulich Date: Tue May 18 18:14:07 2021 +0200 xen-pciback: reconfigure also from backend watch handler commit c81d3d24602540f65256f98831d0a25599ea6b87 upstream. When multiple PCI devices get assigned to a guest right at boot, libxl incrementally populates the backend tree. The writes for the first of the devices trigger the backend watch. In turn xen_pcibk_setup_backend() will set the XenBus state to Initialised, at which point no further reconfigures would happen unless a device got hotplugged. Arrange for reconfigure to also get triggered from the backend watch handler. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/2337cbd6-94b9-4187-9862-c03ea12e0c61@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 83db6e8514f459914b59421e5adc72eccfd74476 Author: Jan Beulich Date: Tue May 18 18:13:42 2021 +0200 xen-pciback: redo VF placement in the virtual topology commit 4ba50e7c423c29639878c00573288869aa627068 upstream. The commit referenced below was incomplete: It merely affected what would get written to the vdev- xenstore node. The guest would still find the function at the original function number as long as __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt __xen_pcibk_get_pcifront_dev(). Undo overriding the function to zero and instead make sure that VFs at function zero remain alone in their slot. This has the added benefit of improving overall capacity, considering that there's only a total of 32 slots available right now (PCI segment and bus can both only ever be zero at present). Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to separate virtual slots") Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/8def783b-404c-3452-196d-3f3fd4d72c9e@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit e8e342d44e931c45aec533f7f99821eb14307256 Author: Jon Hunter Date: Fri May 7 11:34:11 2021 +0100 gpio: tegra186: Don't set parent IRQ affinity commit bdbe871ef0caa660e16461a2a94579d9f9ef7ba4 upstream. When hotplugging CPUs on Tegra186 and Tegra194 errors such as the following are seen ... IRQ63: set affinity failed(-22). IRQ65: set affinity failed(-22). IRQ66: set affinity failed(-22). IRQ67: set affinity failed(-22). Looking at the /proc/interrupts the above are all interrupts associated with GPIOs. The reason why these error messages occur is because there is no 'parent_data' associated with any of the GPIO interrupts and so tegra186_irq_set_affinity() simply returns -EINVAL. To understand why there is no 'parent_data' it is first necessary to understand that in addition to the GPIO interrupts being routed to the interrupt controller (GIC), the interrupts for some GPIOs are also routed to the Tegra Power Management Controller (PMC) to wake up the system from low power states. In order to configure GPIO events as wake events in the PMC, the PMC is configured as IRQ parent domain for the GPIO IRQ domain. Originally the GIC was the IRQ parent domain of the PMC and although this was working, this started causing issues once commit 64a267e9a41c ("irqchip/gic: Configure SGIs as standard interrupts") was added, because technically, the GIC is not a parent of the PMC. Commit c351ab7bf2a5 ("soc/tegra: pmc: Don't create fake interrupt hierarchy levels") fixed this by severing the IRQ domain hierarchy for the Tegra GPIOs and hence, there may be no IRQ parent domain for the GPIOs. The GPIO controllers on Tegra186 and Tegra194 have either one or six interrupt lines to the interrupt controller. For GPIO controllers with six interrupts, the mapping of the GPIO interrupt to the controller interrupt is configurable within the GPIO controller. Currently a default mapping is used, however, it could be possible to use the set affinity callback for the Tegra186 GPIO driver to do something a bit more interesting. Currently, because interrupts for all GPIOs are have the same mapping and any attempts to configure the affinity for a given GPIO can conflict with another that shares the same IRQ, for now it is simpler to just remove set affinity support and this avoids the above warnings being seen. Cc: Fixes: c4e1f7d92cd6 ("gpio: tegra186: Set affinity callback to parent") Signed-off-by: Jon Hunter Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit c191a2c22da278eb41355490564c1d3a050394e4 Author: Neil Armstrong Date: Mon Apr 26 19:55:59 2021 +0200 mmc: meson-gx: also check SD_IO_RW_EXTENDED for scatterlist size alignment commit 9b81354d7ebc1fd17f666a168dcabf27dae290bd upstream. The brcmfmac driver can generate a scatterlist from a skb with each packets not aligned to the block size. This is not supported by the Amlogic Descriptor dma engine where each descriptor must match a multiple of the block size. The sg list is valid, since the sum of the sg buffers is a multiple of the block size, but we must discard those when in SD_IO_RW_EXTENDED mode since SDIO block mode can be used under the hood even with data->blocks == 1. Those transfers are very rare, thus can be replaced by a bounce buffer without real performance loss. Fixes: 7412dee9f1fd ("mmc: meson-gx: replace WARN_ONCE with dev_warn_once about scatterlist size alignment in block mode") Cc: stable@vger.kernel.org Reported-by: Christian Hewitt Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210426175559.3110575-2-narmstrong@baylibre.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6d8f00ab53c2a74a8c9e12b66a66cc67c8f615bd Author: Neil Armstrong Date: Mon Apr 26 19:55:58 2021 +0200 mmc: meson-gx: make replace WARN_ONCE with dev_warn_once about scatterlist offset alignment commit cabb1bb60e88ccaaa122ba01862403cd44e8e8f8 upstream. Some drivers like ath10k can sometimg give an sg buffer with an offset whose alignment is not compatible with the Amlogic DMA descriptor engine requirements. Simply replace with dev_warn_once() to inform user this should be fixed to avoid degraded performance. This should be ultimately fixed in ath10k, but since it's only a performance issue the warning should be removed. Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode") Cc: stable@vger.kernel.org Reported-by: Christian Hewitt Signed-off-by: Neil Armstrong Acked-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20210426175559.3110575-1-narmstrong@baylibre.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b80010d3b74627c78d1572c49ee6b8b3555c89b4 Author: Daniel Beer Date: Sat Apr 24 20:16:52 2021 +1200 mmc: sdhci-pci-gli: increase 1.8V regulator wait commit a1149a6c06ee094a6e62886b0c0e8e66967a728a upstream. Inserting an SD-card on an Intel NUC10i3FNK4 (which contains a GL9755) results in the message: mmc0: 1.8V regulator output did not become stable Following this message, some cards work (sometimes), but most cards fail with EILSEQ. This behaviour is observed on Debian 10 running kernel 4.19.188, but also with 5.8.18 and 5.11.15. The driver currently waits 5ms after switching on the 1.8V regulator for it to become stable. Increasing this to 10ms gets rid of the warning about stability, but most cards still fail. Increasing it to 20ms gets some cards working (a 32GB Samsung micro SD works, a 128GB ADATA doesn't). At 50ms, the ADATA works most of the time, and at 100ms both cards work reliably. Signed-off-by: Daniel Beer Acked-by: Ben Chuang Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210424081652.GA16047@nyquist.nev Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 77a843b121ff94cd132565b0cbd6e3137d684695 Author: Nicholas Piggin Date: Thu May 20 21:19:31 2021 +1000 powerpc/64s/syscall: Fix ptrace syscall info with scv syscalls commit d72500f992849d31ebae8f821a023660ddd0dcc2 upstream. The scv implementation missed updating syscall return value and error value get/set functions to deal with the changed register ABI. This broke ptrace PTRACE_GET_SYSCALL_INFO as well as some kernel auditing and tracing functions. Fix. tools/testing/selftests/ptrace/get_syscall_info now passes when scv is used. Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Reported-by: "Dmitry V. Levin" Signed-off-by: Nicholas Piggin Reviewed-by: Dmitry V. Levin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210520111931.2597127-2-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit a1c2e69fe08a4e71e92dddbb2e03dec16fef6e37 Author: Nicholas Piggin Date: Thu May 20 21:19:30 2021 +1000 powerpc/64s/syscall: Use pt_regs.trap to distinguish syscall ABI difference between sc and scv syscalls commit 5665bc35c1ed917ac8fd06cb651317bb47a65b10 upstream. The sc and scv 0 system calls have different ABI conventions, and ptracers need to know which system call type is being used if they want to look at the syscall registers. Document that pt_regs.trap can be used for this, and fix one in-tree user to work with scv 0 syscalls. Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Reported-by: "Dmitry V. Levin" Suggested-by: "Dmitry V. Levin" Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210520111931.2597127-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9396bad5103f9966e021147c38a004a44003b216 Author: Christian König Date: Mon May 17 13:20:17 2021 +0200 dma-buf: fix unintended pin/unpin warnings commit 7e008b02557ccece4d2c31fb0eaf6243cbc87121 upstream. DMA-buf internal users call the pin/unpin functions without having a dynamic attachment. Avoid the warning and backtrace in the logs. Signed-off-by: Christian König Bugs: https://gitlab.freedesktop.org/drm/intel/-/issues/3481 Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin") Reviewed-by: Alex Deucher Reviewed-by: Daniel Vetter CC: stable@kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210517115705.2141-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit a50d7925371122b0777270e4848fc885ca5f9e2d Author: Guchun Chen Date: Mon May 17 16:38:00 2021 +0800 drm/amdgpu: update sdma golden setting for Navi12 commit 77194d8642dd4cb7ea8ced77bfaea55610574c38 upstream. Current golden setting is out of date. Signed-off-by: Guchun Chen Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6c888ba03ccbe7baf027f3c0d92b8c1e91adc546 Author: Guchun Chen Date: Mon May 17 16:35:40 2021 +0800 drm/amdgpu: update gc golden setting for Navi12 commit 99c45ba5799d6b938bd9bd20edfeb6f3e3e039b9 upstream. Current golden setting is out of date. Signed-off-by: Guchun Chen Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9964c838496cf0cce0f2b6ad97f844514bd050c4 Author: Changfeng Date: Fri May 14 15:28:25 2021 +0800 drm/amdgpu: disable 3DCGCG on picasso/raven1 to avoid compute hang commit dbd1003d1252db5973dddf20b24bb0106ac52aa2 upstream. There is problem with 3DCGCG firmware and it will cause compute test hang on picasso/raven1. It needs to disable 3DCGCG in driver to avoid compute hang. Signed-off-by: Changfeng Reviewed-by: Alex Deucher Reviewed-by: Huang Rui Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f8baabd09e33d5d0c517fb9f46298d3fae96513f Author: Yi Li Date: Fri May 14 14:40:39 2021 +0800 drm/amdgpu: Fix GPU TLB update error when PAGE_SIZE > AMDGPU_PAGE_SIZE commit d53751568359e5b3ffb859b13cbd79dc77a571f1 upstream. When PAGE_SIZE is larger than AMDGPU_PAGE_SIZE, the number of GPU TLB entries which need to update in amdgpu_map_buffer() should be multiplied by AMDGPU_GPU_PAGES_IN_CPU_PAGE (PAGE_SIZE / AMDGPU_PAGE_SIZE). Reviewed-by: Christian König Signed-off-by: Yi Li Signed-off-by: Huacai Chen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ec1bd01b632ad748dce8a0eeb4c167bead71315f Author: Christian König Date: Wed May 12 10:36:43 2021 +0200 drm/radeon: use the dummy page for GART if needed commit 0c8df343c200529e6b9820bdfed01814140f75e4 upstream. Imported BOs don't have a pagelist any more. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Fixes: 0575ff3d33cd ("drm/radeon: stop using pages with drm_prime_sg_to_page_addr_arrays v2") CC: stable@vger.kernel.org # 5.12 Signed-off-by: Greg Kroah-Hartman commit 3ce618c8c6e9f56ddb999091426e8316c5178003 Author: Nikola Cornij Date: Thu May 6 22:46:52 2021 -0400 drm/amd/display: Use the correct max downscaling value for DCN3.x family commit 84c63d040938f64a7dc195696301166e75231bf5 upstream. [why] As per spec, DCN3.x can do 6:1 downscaling and DCN2.x can do 4:1. The max downscaling limit value for DCN2.x is 250, which means it's calculated as 1000 / 4 = 250. For DCN3.x this then gives 1000 / 6 = 167. [how] Set maximum downscaling limit to 167 for DCN3.x Signed-off-by: Nikola Cornij Reviewed-by: Charlene Liu Reviewed-by: Harry Wentland Acked-by: Stylon Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5645f1806780dce345588f4d5f2dad899a7ab4a3 Author: Chris Wilson Date: Mon May 17 09:46:40 2021 +0100 drm/i915/gem: Pin the L-shape quirked object as unshrinkable commit 036867e93ebf4d7e70eba6a8c72db74ee3760bc3 upstream. When instantiating a tiled object on an L-shaped memory machine, we mark the object as unshrinkable to prevent the shrinker from trying to swap out the pages. We have to do this as we do not know the swizzling on the individual pages, and so the data will be scrambled across swap out/in. Not only do we need to move the object off the shrinker list, we need to mark the object with shrink_pin so that the counter is consistent across calls to madvise. v2: in the madvise ioctl we need to check if the object is currently shrinkable/purgeable, not if the object type supports shrinking Fixes: 0175969e489a ("drm/i915/gem: Use shrinkable status for unknown swizzle quirks") References: https://gitlab.freedesktop.org/drm/intel/-/issues/3293 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3450 Reported-by: Ville Syrjälä Tested-by: Ville Syrjälä Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Cc: # v5.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20210517084640.18862-1-matthew.auld@intel.com (cherry picked from commit 8777d17b68dcfbfbd4d524f444adefae56f41225) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit c76c4e35626f9ba9bf1f6a1d7b4158ae5bb3c7cc Author: Joerg Roedel Date: Wed May 19 15:52:45 2021 +0200 x86/sev-es: Forward page-faults which happen during emulation commit c25bbdb564060adaad5c3a8a10765c13487ba6a3 upstream. When emulating guest instructions for MMIO or IOIO accesses, the #VC handler might get a page-fault and will not be able to complete. Forward the page-fault in this case to the correct handler instead of killing the machine. Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v5.10+ Link: https://lkml.kernel.org/r/20210519135251.30093-3-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit e2f96ca12a3148470bf0481d1ad9d16cbe997e9d Author: Joerg Roedel Date: Wed May 19 15:52:46 2021 +0200 x86/sev-es: Use __put_user()/__get_user() for data accesses commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream. The put_user() and get_user() functions do checks on the address which is passed to them. They check whether the address is actually a user-space address and whether its fine to access it. They also call might_fault() to indicate that they could fault and possibly sleep. All of these checks are neither wanted nor needed in the #VC exception handler, which can be invoked from almost any context and also for MMIO instructions from kernel space on kernel memory. All the #VC handler wants to know is whether a fault happened when the access was tried. This is provided by __put_user()/__get_user(), which just do the access no matter what. Also add comments explaining why __get_user() and __put_user() are the best choice here and why it is safe to use them in this context. Also explain why copy_to/from_user can't be used. In addition, also revert commit 7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly") because using __get_user()/__put_user() fixes the same problem while the above commit introduced several problems: 1) It uses access_ok() which is only allowed in task context. 2) It uses memcpy() which has no fault handling at all and is thus unsafe to use here. [ bp: Fix up commit ID of the reverted commit above. ] Fixes: f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image") Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v5.10+ Link: https://lkml.kernel.org/r/20210519135251.30093-4-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit efbfc33b0b1c241311553d3c2229974ec1d684e2 Author: Joerg Roedel Date: Wed May 19 15:52:44 2021 +0200 x86/sev-es: Don't return NULL from sev_es_get_ghcb() commit b250f2f7792d15bcde98e0456781e2835556d5fa upstream. sev_es_get_ghcb() is called from several places but only one of them checks the return value. The reaction to returning NULL is always the same: calling panic() and kill the machine. Instead of adding checks to all call sites, move the panic() into the function itself so that it will no longer return NULL. Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v5.10+ Link: https://lkml.kernel.org/r/20210519135251.30093-2-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit da416661864f1b1cd25ba82af394fce974741bd9 Author: Tom Lendacky Date: Mon May 17 12:42:33 2021 -0500 x86/sev-es: Invalidate the GHCB after completing VMGEXIT commit a50c5bebc99c525e7fbc059988c6a5ab8680cb76 upstream. Since the VMGEXIT instruction can be issued from userspace, invalidate the GHCB after performing VMGEXIT processing in the kernel. Invalidation is only required after userspace is available, so call vc_ghcb_invalidate() from sev_es_put_ghcb(). Update vc_ghcb_invalidate() to additionally clear the GHCB exit code so that it is always presented as 0 when VMGEXIT has been issued by anything else besides the kernel. Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman commit 05e0d825fff720a0a23a9d547dd36de2aefb28a9 Author: Tom Lendacky Date: Mon May 17 12:42:32 2021 -0500 x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch commit fea63d54f7a3e74f8ab489a8b82413a29849a594 upstream. Move the location of sev_es_put_ghcb() in preparation for an update to it in a follow-on patch. This will better highlight the changes being made to the function. No functional change. Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman commit 60bad834637643f09c6ad9edc83d44e35108953d Author: Nathan Chancellor Date: Tue May 18 12:01:06 2021 -0700 x86/build: Fix location of '-plugin-opt=' flags commit 0024430e920f2900654ad83cd081cf52e02a3ef5 upstream. Commit b33fff07e3e3 ("x86, build: allow LTO to be selected") added a couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model and stack alignment are not stored in LLVM bitcode. However, these flags were added to KBUILD_LDFLAGS prior to the emulation flag assignment, which uses ':=', so they were overwritten and never added to $(LD) invocations. The absence of these flags caused misalignment issues in the AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in general protection faults. Shuffle the assignment below the initial one so that the flags are properly passed along and all of the linker flags stay together. At the same time, avoid any future issues with clobbering flags by changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is already defined with ':=' in the main Makefile before being exported for modification here as a result of commit: ce99d0bf312d ("kbuild: clear LDFLAGS in the top Makefile") Fixes: b33fff07e3e3 ("x86, build: allow LTO to be selected") Reported-by: Anthony Ruhier Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Tested-by: Anthony Ruhier Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1374 Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit a37e62e8d894b194da02516fb156fd67861342ce Author: Sagi Grimberg Date: Mon May 17 14:07:45 2021 -0700 nvme-tcp: fix possible use-after-completion commit 825619b09ad351894d2c6fb6705f5b3711d145c7 upstream. Commit db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq context") added a second context that may perform a network send. This means that now RX and TX are not serialized in nvme_tcp_io_work and can run concurrently. While there is correct mutual exclusion in the TX path (where the send_mutex protect the queue socket send activity) RX activity, and more specifically request completion may run concurrently. This means we must guarantee that any mutation of the request state related to its lifetime, bytes sent must not be accessed when a completion may have possibly arrived back (and processed). The race may trigger when a request completion arrives, processed _and_ reused as a fresh new request, exactly in the (relatively short) window between the last data payload sent and before the request iov_iter is advanced. Consider the following race: 1. 16K write request is queued 2. The nvme command and the data is sent to the controller (in-capsule or solicited by r2t) 3. After the last payload is sent but before the req.iter is advanced, the controller sends back a completion. 4. The completion is processed, the request is completed, and reused to transfer a new request (write or read) 5. The new request is queued, and the driver reset the request parameters (nvme_tcp_setup_cmd_pdu). 6. Now context in (2) resumes execution and advances the req.iter ==> use-after-completion as this is already a new request. Fix this by making sure the request is not advanced after the last data payload send, knowing that a completion may have arrived already. An alternative solution would have been to delay the request completion or state change waiting for reference counting on the TX path, but besides adding atomic operations to the hot-path, it may present challenges in multi-stage R2T scenarios where a r2t handler needs to be deferred to an async execution. Reported-by: Narayan Ayalasomayajula Tested-by: Anil Mishra Reviewed-by: Keith Busch Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit d5e9a9f5a69cad889033f106cce5861daaee87d3 Author: Greg Kroah-Hartman Date: Mon May 3 13:56:32 2021 +0200 Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference" commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream. This reverts commit 32f47179833b63de72427131169809065db6745e. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be not be needed at all as the change was useless because this function can only be called when of_match_device matched on something. So it should be reverted. Cc: Aditya Pakki Cc: stable Fixes: 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference") Acked-by: Jiri Slaby Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 19624d88c3aeaa4ff59eba8219bb88e3bee56780 Author: Anirudh Rayabharam Date: Mon May 3 13:57:12 2021 +0200 rapidio: handle create_workqueue() failure commit 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf upstream. In case create_workqueue() fails, release all resources and return -ENOMEM to caller to avoid potential NULL pointer deref later. Move up the create_workequeue() call to return early and avoid unwinding the call to riocm_rx_fill(). Cc: Alexandre Bounine Cc: Matt Porter Cc: Andrew Morton Cc: Linus Torvalds Cc: stable Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 68f72384b05f237a1075aaa4a960c741c6ecdb23 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:11 2021 +0200 Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails" commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream. This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit has a memory leak on the error path here, it does not clean up everything properly. Cc: Kangjie Lu Cc: Alexandre Bounine Cc: Matt Porter Cc: Andrew Morton Cc: Linus Torvalds Fixes: 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit b83ad0a514f72b9b64444ac1dd3c0f5e26250b0c Author: Barnabás Pőcze Date: Fri May 7 23:53:44 2021 +0000 platform/x86: ideapad-laptop: fix method name typo commit b09aaa3f2c0edeeed670cd29961a0e35bddc78cf upstream. "smbc" should be "sbmc". `eval_smbc()` incorrectly called the SMBC ACPI method instead of SBMC. This resulted in partial loss of functionality. Rectify that by calling the correct ACPI method (SBMC), and also rename methods and constants. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212985 Fixes: 0b765671cb80 ("platform/x86: ideapad-laptop: group and separate (un)related constants into enums") Fixes: ff36b0d953dc ("platform/x86: ideapad-laptop: rework and create new ACPI helpers") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Barnabás Pőcze Link: https://lore.kernel.org/r/20210507235333.286505-1-pobrn@protonmail.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 5f59240cf25b2f7a0fdffc2701482a70310fec07 Author: Christophe JAILLET Date: Sun May 9 09:13:12 2021 +0200 uio_hv_generic: Fix another memory leak in error handling paths commit 0b0226be3a52dadd965644bc52a807961c2c26df upstream. Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman commit 53486c467e356e06aa37047c984fccd64d78c827 Author: Christophe JAILLET Date: Sun May 9 09:13:03 2021 +0200 uio_hv_generic: Fix a memory leak in error handling paths commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream. If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman commit 5e5ee72f4a07e3fa5145c1c6bb96c025650425db Author: Martin Ågren Date: Thu Apr 22 21:22:40 2021 +0200 uio/uio_pci_generic: fix return value changed in refactoring commit 156ed0215ef365604f2382d5164c36d3a1cfd98f upstream. Commit ef84928cff58 ("uio/uio_pci_generic: use device-managed function equivalents") was able to simplify various error paths thanks to no longer having to clean up on the way out. Some error paths were dropped, others were simplified. In one of those simplifications, the return value was accidentally changed from -ENODEV to -ENOMEM. Restore the old return value. Fixes: ef84928cff58 ("uio/uio_pci_generic: use device-managed function equivalents") Cc: stable Acked-by: Michael S. Tsirkin Signed-off-by: Martin Ågren Link: https://lore.kernel.org/r/20210422192240.1136373-1-martin.agren@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2754fb43a6a0045523e759207f524dcf935bb0e7 Author: Olivia Mackintosh Date: Sun Apr 18 17:59:01 2021 +0100 ALSA: usb-audio: DJM-750: ensure format is set commit e7df7df5a3809d733888db6ce6592a644acaac19 upstream. Add case statement to set sample-rate for the DJM-750 Pioneer mixer. This was included as part of another patch but I think it has been archived on Patchwork and hasn't been merged. Signed-off-by: Olivia Mackintosh Cc: Link: https://lore.kernel.org/r/20210418165901.25776-1-livvy@base.nu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae4248e2aa4c0b6cfb738e0b545a4e97b639f122 Author: Nicolas MURE Date: Mon Mar 1 16:27:28 2021 +0100 ALSA: usb-audio: Configure Pioneer DJM-850 samplerate commit 1a2a94a4392d5d1e5e25cc127573452f4c7fa9b8 upstream. Send an `URB_CONTROL out` USB frame to the device to configure its samplerate. This should be done before using the device for audio streaming (capture or playback). See https://github.com/nm2107/Pioneer-DJM-850-driver-reverse-engineering/blob/172fb9a61055960c88c67b7c416fe5bf3609807b/doc/windows-dvs/framerate-setting/README.md Signed-off-by: Nicolas MURE Link: https://lore.kernel.org/r/20210301152729.18094-4-nicolas.mure2019@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ede8bc8fcb85d5dca935efa9f5d7705fc726658 Author: Elia Devito Date: Tue May 11 14:46:49 2021 +0200 ALSA: hda/realtek: Add fixup for HP Spectre x360 15-df0xxx commit f2be77fee648ddd6d0d259d3527344ba0120e314 upstream. Fixup to enable all 4 speaker on HP Spectre x360 15-df0xxx and probably on similar models. 0x14 pin config override is required to enable all speakers and alc285-speaker2-to-dac1 fixup to enable volume adjustment. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=189331 Signed-off-by: Elia Devito Cc: Link: https://lore.kernel.org/r/20210511124651.4802-1-eliadevito@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 41a0d2db7b4f512689bd9054a3077a9af81c9513 Author: Takashi Iwai Date: Tue May 4 14:18:32 2021 +0200 ALSA: hda/realtek: Add fixup for HP OMEN laptop commit 5d84b5318d860c9d80ca5dfae0e971ede53b4921 upstream. HP OMEN dc0019-ur with codec SSID 103c:84da requires the pin config overrides and the existing mic/mute LED setup. This patch implements those in the fixup table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212733 Cc: Link: https://lore.kernel.org/r/20210504121832.4558-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e825729f6a7d414e11856d650bcde0531e388cb0 Author: Takashi Iwai Date: Tue May 4 10:20:57 2021 +0200 ALSA: hda/realtek: Fix silent headphone output on ASUS UX430UA commit 8eedd3a70a70f51fa963f3ad7fa97afd0c75bd44 upstream. It was reported that the headphone output on ASUS UX430UA (SSID 1043:1740) with ALC295 codec is silent while the speaker works. After the investigation, it turned out that the DAC assignment has to be fixed on this machine; unlike others, it expects DAC 0x02 to be assigned to the speaker pin 0x07 while DAC 0x03 to headphone pin 0x21. This patch provides a fixup for the fixed DAC/pin mapping for this device. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212933 Cc: Link: https://lore.kernel.org/r/20210504082057.6913-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 97b4051181f96381023d63eaa8c886fef8612798 Author: PeiSen Hou Date: Fri May 14 12:50:48 2021 +0200 ALSA: hda/realtek: Add some CLOVE SSIDs of ALC293 commit 1d5cfca286178ce81fb0c8a5f5777ef123cd69e4 upstream. Fix "use as headset mic, without its own jack detect" problen. Signed-off-by: PeiSen Hou Cc: Link: https://lore.kernel.org/r/d0746eaf29f248a5acc30313e3ba4f99@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit da1fbdf84d6e8eaeded368292891bbf90dbdac15 Author: Hui Wang Date: Fri May 7 10:44:52 2021 +0800 ALSA: hda/realtek: reset eapd coeff to default value for alc287 commit 8822702f6e4c8917c83ba79e0ebf2c8c218910d4 upstream. Ubuntu users reported an audio bug on the Lenovo Yoga Slim 7 14IIL05, he installed dual OS (Windows + Linux), if he booted to the Linux from Windows, the Speaker can't work well, it has crackling noise, if he poweroff the machine first after Windows, the Speaker worked well. Before rebooting or shutdown from Windows, the Windows changes the codec eapd coeff value, but the BIOS doesn't re-initialize its value, when booting into the Linux from Windows, the eapd coeff value is not correct. To fix it, set the codec default value to that coeff register in the alsa driver. BugLink: http://bugs.launchpad.net/bugs/1925057 Suggested-by: Kailang Yang Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210507024452.8300-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae29eb01a97e39e7c1891a5e27dc65100d7a15cd Author: Takashi Sakamoto Date: Thu May 13 21:56:50 2021 +0900 ALSA: firewire-lib: fix check for the size of isochronous packet payload commit 395f41e2cdac63e7581fb9574e5ac0f02556e34a upstream. The check for size of isochronous packet payload just cares of the size of IR context payload without the size of CIP header. Cc: Fixes: f11453c7cc01 ("ALSA: firewire-lib: use 16 bytes IR context header to separate CIP header") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210513125652.110249-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6bd227e369fc76264418023788963f3056c2ab84 Author: Greg Kroah-Hartman Date: Mon May 3 13:57:01 2021 +0200 Revert "ALSA: sb8: add a check for request_region" commit 94f88309f201821073f57ae6005caefa61bf7b7e upstream. This reverts commit dcd0feac9bab901d5739de51b3f69840851f8919. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit message for this change was incorrect as the code path can never result in a NULL dereference, alluding to the fact that whatever tool was used to "find this" is broken. It's just an optional resource reservation, so removing this check is fine. Cc: Kangjie Lu Acked-by: Takashi Iwai Fixes: dcd0feac9bab ("ALSA: sb8: add a check for request_region") Cc: stable Link: https://lore.kernel.org/r/20210503115736.2104747-35-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 55a32b53954822d04e735c88573ae6c0dd99f890 Author: Daniel Cordova A Date: Fri May 7 12:31:16 2021 -0500 ALSA: hda: fixup headset for ASUS GU502 laptop commit c1b55029493879f5bd585ff79f326e71f0bc05e3 upstream. The GU502 requires a few steps to make headset i/o works properly: pincfg, verbs to unmute headphone out and callback to toggle output between speakers and headphone using jack. Signed-off-by: Daniel Cordova A Cc: Link: https://lore.kernel.org/r/20210507173116.12043-1-danesc87@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3d913ed11fff6f019332a5f92d3fc06896c076f2 Author: Takashi Sakamoto Date: Thu May 13 21:56:49 2021 +0900 ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro commit 0edabdfe89581669609eaac5f6a8d0ae6fe95e7f upstream. Mackie d.2 has an extension card for IEEE 1394 communication, which uses BridgeCo DM1000 ASIC. On the other hand, Mackie d.4 Pro has built-in function for IEEE 1394 communication by Oxford Semiconductor OXFW971, according to schematic diagram available in Mackie website. Although I misunderstood that Mackie d.2 Pro would be also a model with OXFW971, it's wrong. Mackie d.2 Pro is a model which includes the extension card as factory settings. This commit fixes entries in Kconfig and comment in ALSA OXFW driver. Cc: Fixes: fd6f4b0dc167 ("ALSA: bebob: Add skelton for BeBoB based devices") Fixes: ec4dba5053e1 ("ALSA: oxfw: Add support for Behringer/Mackie devices") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210513125652.110249-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a135a4b717eb36cd749a00c8e288aff2a8293940 Author: Takashi Iwai Date: Mon May 10 17:06:59 2021 +0200 ALSA: usb-audio: Validate MS endpoint descriptors commit e84749a78dc82bc545f12ce009e3dbcc2c5a8a91 upstream. snd_usbmidi_get_ms_info() may access beyond the border when a malformed descriptor is passed. This patch adds the sanity checks of the given MS endpoint descriptors, and skips invalid ones. Reported-by: syzbot+6bb23a5d5548b93c94aa@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20210510150659.17710-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit de73920901b49ba65ab154ffedc2a7baadc389c3 Author: Takashi Sakamoto Date: Thu May 13 21:56:51 2021 +0900 ALSA: firewire-lib: fix calculation for size of IR context payload commit 1be4f21d9984fa9835fae5411a29465dc5aece6f upstream. The quadlets for CIP header is handled as a part of IR context header, thus it doesn't join in IR context payload. However current calculation includes the quadlets in IR context payload. Cc: Fixes: f11453c7cc01 ("ALSA: firewire-lib: use 16 bytes IR context header to separate CIP header") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210513125652.110249-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 422fecb77f5d26c71e1083b04993668ad1f263c4 Author: Takashi Sakamoto Date: Thu May 13 21:56:48 2021 +0900 ALSA: dice: fix stream format at middle sampling rate for Alesis iO 26 commit 1b6604896e78969baffc1b6cc6bc175f95929ac4 upstream. Alesis iO 26 FireWire has two pairs of digital optical interface. It delivers PCM frames from the interfaces by second isochronous packet streaming. Although both of the interfaces are available at 44.1/48.0 kHz, first one of them is only available at 88.2/96.0 kHz. It reduces the number of PCM samples to 4 in Multi Bit Linear Audio data channel of data blocks on the second isochronous packet streaming. This commit fixes hardcoded stream formats. Cc: Fixes: 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210513125652.110249-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3aa30f81e45ad2c4af9ef9d0fd0432aa007be8ff Author: Takashi Iwai Date: Tue May 18 10:39:39 2021 +0200 ALSA: line6: Fix racy initialization of LINE6 MIDI commit 05ca447630334c323c9e2b788b61133ab75d60d3 upstream. The initialization of MIDI devices that are found on some LINE6 drivers are currently done in a racy way; namely, the MIDI buffer instance is allocated and initialized in each private_init callback while the communication with the interface is already started via line6_init_cap_control() call before that point. This may lead to Oops in line6_data_received() when a spurious event is received, as reported by syzkaller. This patch moves the MIDI initialization to line6_init_cap_control() as well instead of the too-lately-called private_init for avoiding the race. Also this reduces slightly more lines, so it's a win-win change. Reported-by: syzbot+0d2b3feb0a2887862e06@syzkallerlkml..appspotmail.com Link: https://lore.kernel.org/r/000000000000a4be9405c28520de@google.com Link: https://lore.kernel.org/r/20210517132725.GA50495@hyeyoo Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Link: https://lore.kernel.org/r/20210518083939.1927-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 276f0ff9643492ab8dab5fe19d8447d77d1518b2 Author: Takashi Sakamoto Date: Thu May 13 21:56:52 2021 +0900 ALSA: firewire-lib: fix amdtp_packet tracepoints event for packet_index field commit 814b43127f4ac69332e809152e30773941438aff upstream. The snd_firewire_lib:amdtp_packet tracepoints event includes index of packet processed in a context handling. However in IR context, it is not calculated as expected. Cc: Fixes: 753e717986c2 ("ALSA: firewire-lib: use packet descriptor for IR context") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210513125652.110249-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 568b301b8902d65662d78bf1ee121db03573c282 Author: Takashi Iwai Date: Sun May 16 18:17:55 2021 +0200 ALSA: intel8x0: Don't update period unless prepared commit c1f0616124c455c5c762b6f123e40bba5df759e6 upstream. The interrupt handler of intel8x0 calls snd_intel8x0_update() whenever the hardware sets the corresponding status bit for each stream. This works fine for most cases as long as the hardware behaves properly. But when the hardware gives a wrong bit set, this leads to a zero- division Oops, and reportedly, this seems what happened on a VM. For fixing the crash, this patch adds a internal flag indicating that the stream is ready to be updated, and check it (as well as the flag being in suspended) to ignore such spurious update. Cc: Reported-and-tested-by: Sergey Senozhatsky Link: https://lore.kernel.org/r/s5h5yzi7uh0.wl-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 58a6d26cf806aaf2062f6b1fd711a60cc44e5240 Author: Takashi Sakamoto Date: Tue May 18 10:26:12 2021 +0900 ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency commit 4c6fe8c547e3c9e8c15dabdd23c569ee0df3adb1 upstream. At high sampling transfer frequency, TC Electronic Konnekt Live transfers/receives 6 audio data frames in multi bit linear audio data channel of data block in CIP payload. Current hard-coded stream format is wrong. Cc: Fixes: f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210518012612.37268-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2f0478af7af9947240a07a6baf65af56c22d083e Author: Hsin-Yi Wang Date: Tue Apr 20 21:30:50 2021 +0800 misc: eeprom: at24: check suspend status before disable regulator commit 2962484dfef8dbb7f9059822bc26ce8a04d0e47c upstream. cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables regulator in runtime suspend. If runtime suspend is called before regulator disable, it will results in regulator unbalanced disabling. Fixes: cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") Cc: stable Acked-by: Bartosz Golaszewski Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210420133050.377209-1-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman commit 88faee9b4a997d585945be899fa50fcccc30c18d Author: Christian Brauner Date: Tue May 11 16:30:15 2021 +0200 fs/mount_setattr: tighten permission checks commit 2ca4dcc4909d787ee153272f7efc2bff3b498720 upstream. We currently don't have any filesystems that support idmapped mounts which are mountable inside a user namespace. That was a deliberate decision for now as a userns root can just mount the filesystem themselves. So enforce this restriction explicitly until there's a real use-case for this. This way we can notice it and will have a chance to adapt and audit our translation helpers and fstests appropriately if we need to support such filesystems. Cc: Christoph Hellwig Cc: Al Viro Cc: stable@vger.kernel.org CC: linux-fsdevel@vger.kernel.org Suggested-by: Seth Forshee Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit f124e27ca984987cd78b1fd220e5ffc6d8092840 Author: Ronnie Sahlberg Date: Wed May 19 08:40:11 2021 +1000 cifs: fix memory leak in smb2_copychunk_range commit d201d7631ca170b038e7f8921120d05eec70d7c5 upstream. When using smb2_copychunk_range() for large ranges we will run through several iterations of a loop calling SMB2_ioctl() but never actually free the returned buffer except for the final iteration. This leads to memory leaks everytime a large copychunk is requested. Fixes: 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files") Cc: Reviewed-by: Aurelien Aptel Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6d0924c5b742036b4f20a0ffdf2b6cf3f963f5f6 Author: Filipe Manana Date: Wed May 12 16:27:16 2021 +0100 btrfs: fix removed dentries still existing after log is synced commit 54a40fc3a1da21b52dbf19f72fdc27a2ec740760 upstream. When we move one inode from one directory to another and both the inode and its previous parent directory were logged before, we are not supposed to have the dentry for the old parent if we have a power failure after the log is synced. Only the new dentry is supposed to exist. Generally this works correctly, however there is a scenario where this is not currently working, because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This case is better explained with the following example and reproducer: # The test requires a very specific layout of keys and items in the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported node/leaf size (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # "testdir" is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory "testdir" with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory "dira", inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to # the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 ("testdir") that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing to inode 1458 (directory "dira"). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. So for the sake of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is the crc32c of the # dentry's name). The value 2285968570 corresponds to the offset of # the first key of leaf 2 (which is of type BTRFS_DIR_ITEM_KEY); # # 2) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [4293818216, (u64)-1] (the offset here is the crc32c # of the dentry's name). The value 4293818216 corresponds to the # offset of the highest key of type BTRFS_DIR_ITEM_KEY plus 1 # (4293818215 + 1), which is located in leaf 2; # # 3) a key of type BTRFS_DIR_LOG_INDEX_KEY, with an offset of 1203, # which indicates the log is authoritative for all keys of type # BTRFS_DIR_INDEX_KEY that have an offset in the range # [1203, (u64)-1]. The value 1203 corresponds to the offset of the # last key of type BTRFS_DIR_INDEX_KEY plus 1 (1202 + 1), which is # located in leaf 3; # # Also, because "testdir" is a directory and inode 1458 ("dira") is a # child directory, we log inode 1458 too. $ xfs_io -c "fsync" /mnt/testdir # Now move "dira", inode 1458, to be a child of the root directory # (inode 256). # # Because this inode was previously logged, when "testdir" was fsynced, # the log is updated so that the old inode reference, referring to inode # 257 as the parent, is deleted and the new inode reference, referring # to inode 256 as the parent, is added to the log. $ mv /mnt/testdir/dira /mnt # Now change some file and fsync it. This guarantees the log changes # made by the previous move/rename operation are persisted. We do not # need to do any special modification to the file, just any change to # any file and sync the log. $ xfs_io -c "pwrite -S 0xab 0 64K" -c "fsync" /mnt/testdir/file1 # Simulate a power failure and then mount again the filesystem to # replay the log tree. We want to verify that we are able to mount the # filesystem, meaning log replay was successful, and that directory # inode 1458 ("dira") only has inode 256 (the filesystem's root) as # its parent (and no longer a child of inode 257). # # It used to happen that during log replay we would end up having # inode 1458 (directory "dira") with 2 hard links, being a child of # inode 257 ("testdir") and inode 256 (the filesystem's root). This # resulted in the tree checker detecting the issue and causing the # mount operation to fail (with -EIO). # # This happened because in the log we have the new name/parent for # inode 1458, which results in adding the new dentry with inode 256 # as the parent, but the previous dentry, under inode 257 was never # removed - this is because the ranges for dir items and dir indexes # of inode 257 for which the log is authoritative do not include the # old dir item and dir index for the dentry of inode 257 referring to # inode 1458: # # - for dir items, the log is authoritative for the ranges # [0, 2285968570] and [4293818216, (u64)-1]. The dir item at inode 257 # pointing to inode 1458 has a key of (257 DIR_ITEM 3724298081), as # previously mentioned, so the dir item is not deleted when the log # replay procedure processes the authoritative ranges, as 3724298081 # is outside both ranges; # # - for dir indexes, the log is authoritative for the range # [1203, (u64)-1], and the dir index item of inode 257 pointing to # inode 1458 has a key of (257 DIR_INDEX 1202), as previously # mentioned, so the dir index item is not deleted when the log # replay procedure processes the authoritative range. $ mount /dev/sdc /mnt mount: /mnt: can't read superblock on /dev/sdc. $ dmesg (...) [87849.840509] BTRFS info (device sdc): start tree-log replay [87849.875719] BTRFS critical (device sdc): corrupt leaf: root=5 block=30539776 slot=554 ino=1458, invalid nlink: has 2 expect no more than 1 for dir [87849.878084] BTRFS info (device sdc): leaf 30539776 gen 7 total ptrs 557 free space 2092 owner 5 [87849.879516] BTRFS info (device sdc): refs 1 lock_owner 0 current 2099108 [87849.880613] item 0 key (1181 1 0) itemoff 65275 itemsize 160 [87849.881544] inode generation 6 size 0 mode 100644 [87849.882692] item 1 key (1181 12 257) itemoff 65258 itemsize 17 (...) [87850.562549] item 556 key (1458 12 257) itemoff 16017 itemsize 14 [87850.563349] BTRFS error (device dm-0): block=30539776 write time tree block corruption detected [87850.564386] ------------[ cut here ]------------ [87850.564920] WARNING: CPU: 3 PID: 2099108 at fs/btrfs/disk-io.c:465 csum_one_extent_buffer+0xed/0x100 [btrfs] [87850.566129] Modules linked in: btrfs dm_zero dm_snapshot (...) [87850.573789] CPU: 3 PID: 2099108 Comm: mount Not tainted 5.12.0-rc8-btrfs-next-86 #1 (...) [87850.587481] Call Trace: [87850.587768] btree_csum_one_bio+0x244/0x2b0 [btrfs] [87850.588354] ? btrfs_bio_fits_in_stripe+0xd8/0x110 [btrfs] [87850.589003] btrfs_submit_metadata_bio+0xb7/0x100 [btrfs] [87850.589654] submit_one_bio+0x61/0x70 [btrfs] [87850.590248] submit_extent_page+0x91/0x2f0 [btrfs] [87850.590842] write_one_eb+0x175/0x440 [btrfs] [87850.591370] ? find_extent_buffer_nolock+0x1c0/0x1c0 [btrfs] [87850.592036] btree_write_cache_pages+0x1e6/0x610 [btrfs] [87850.592665] ? free_debug_processing+0x1d5/0x240 [87850.593209] do_writepages+0x43/0xf0 [87850.593798] ? __filemap_fdatawrite_range+0xa4/0x100 [87850.594391] __filemap_fdatawrite_range+0xc5/0x100 [87850.595196] btrfs_write_marked_extents+0x68/0x160 [btrfs] [87850.596202] btrfs_write_and_wait_transaction.isra.0+0x4d/0xd0 [btrfs] [87850.597377] btrfs_commit_transaction+0x794/0xca0 [btrfs] [87850.598455] ? _raw_spin_unlock_irqrestore+0x32/0x60 [87850.599305] ? kmem_cache_free+0x15a/0x3d0 [87850.600029] btrfs_recover_log_trees+0x346/0x380 [btrfs] [87850.601021] ? replay_one_extent+0x7d0/0x7d0 [btrfs] [87850.601988] open_ctree+0x13c9/0x1698 [btrfs] [87850.602846] btrfs_mount_root.cold+0x13/0xed [btrfs] [87850.603771] ? kmem_cache_alloc_trace+0x7c9/0x930 [87850.604576] ? vfs_parse_fs_string+0x5d/0xb0 [87850.605293] ? kfree+0x276/0x3f0 [87850.605857] legacy_get_tree+0x30/0x50 [87850.606540] vfs_get_tree+0x28/0xc0 [87850.607163] fc_mount+0xe/0x40 [87850.607695] vfs_kern_mount.part.0+0x71/0x90 [87850.608440] btrfs_mount+0x13b/0x3e0 [btrfs] (...) [87850.629477] ---[ end trace 68802022b99a1ea0 ]--- [87850.630849] BTRFS: error (device sdc) in btrfs_commit_transaction:2381: errno=-5 IO failure (Error while writing out transaction) [87850.632422] BTRFS warning (device sdc): Skipping commit of aborted transaction. [87850.633416] BTRFS: error (device sdc) in cleanup_transaction:1978: errno=-5 IO failure [87850.634553] BTRFS: error (device sdc) in btrfs_replay_log:2431: errno=-5 IO failure (Failed to recover log tree) [87850.637529] BTRFS error (device sdc): open_ctree failed In this example the inode we moved was a directory, so it was easy to detect the problem because directories can only have one hard link and the tree checker immediately detects that. If the moved inode was a file, then the log replay would succeed and we would end up having both the new hard link (/mnt/foo) and the old hard link (/mnt/testdir/foo) present, but only the new one should be present. Fix this by forcing re-logging of the old parent directory when logging the new name during a rename operation. This ensures we end up with a log that is authoritative for a range covering the keys for the old dentry, therefore causing the old dentry do be deleted when replaying the log. A test case for fstests will follow up soon. Fixes: 64d6b281ba4db0 ("btrfs: remove unnecessary check_parent_dirs_for_sync()") CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 03781d598f9596b77b7f9acb0babaded762db168 Author: Josef Bacik Date: Thu Apr 29 10:51:34 2021 -0400 btrfs: avoid RCU stalls while running delayed iputs commit 71795ee590111e3636cc3c148289dfa9fa0a5fc3 upstream. Generally a delayed iput is added when we might do the final iput, so usually we'll end up sleeping while processing the delayed iputs naturally. However there's no guarantee of this, especially for small files. In production we noticed 5 instances of RCU stalls while testing a kernel release overnight across 1000 machines, so this is relatively common: host count: 5 rcu: INFO: rcu_sched self-detected stall on CPU rcu: ....: (20998 ticks this GP) idle=59e/1/0x4000000000000002 softirq=12333372/12333372 fqs=3208 (t=21031 jiffies g=27810193 q=41075) NMI backtrace for cpu 1 CPU: 1 PID: 1713 Comm: btrfs-cleaner Kdump: loaded Not tainted 5.6.13-0_fbk12_rc1_5520_gec92bffc1ec9 #1 Call Trace: dump_stack+0x50/0x70 nmi_cpu_backtrace.cold.6+0x30/0x65 ? lapic_can_unplug_cpu.cold.30+0x40/0x40 nmi_trigger_cpumask_backtrace+0xba/0xca rcu_dump_cpu_stacks+0x99/0xc7 rcu_sched_clock_irq.cold.90+0x1b2/0x3a3 ? trigger_load_balance+0x5c/0x200 ? tick_sched_do_timer+0x60/0x60 ? tick_sched_do_timer+0x60/0x60 update_process_times+0x24/0x50 tick_sched_timer+0x37/0x70 __hrtimer_run_queues+0xfe/0x270 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x5e/0x120 apic_timer_interrupt+0xf/0x20 RIP: 0010:queued_spin_lock_slowpath+0x17d/0x1b0 RSP: 0018:ffffc9000da5fe48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000000 RBX: ffff889fa81d0cd8 RCX: 0000000000000029 RDX: ffff889fff86c0c0 RSI: 0000000000080000 RDI: ffff88bfc2da7200 RBP: ffff888f2dcdd768 R08: 0000000001040000 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff82a55560 R12: ffff88bfc2da7200 R13: 0000000000000000 R14: ffff88bff6c2a360 R15: ffffffff814bd870 ? kzalloc.constprop.57+0x30/0x30 list_lru_add+0x5a/0x100 inode_lru_list_add+0x20/0x40 iput+0x1c1/0x1f0 run_delayed_iput_locked+0x46/0x90 btrfs_run_delayed_iputs+0x3f/0x60 cleaner_kthread+0xf2/0x120 kthread+0x10b/0x130 Fix this by adding a cond_resched_lock() to the loop processing delayed iputs so we can avoid these sort of stalls. CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Rik van Riel Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 568b414574ed6f4d64e572be3406aa2137cb67ed Author: Alexey Kardashevskiy Date: Thu May 20 13:29:19 2021 +1000 powerpc: Fix early setup to make early_ioremap() work [ Upstream commit e2f5efd0f0e229bd110eab513e7c0331d61a4649 ] The immediate problem is that after commit 0bd3f9e953bd ("powerpc/legacy_serial: Use early_ioremap()") the kernel silently reboots on some systems. The reason is that early_ioremap() returns broken addresses as it uses slot_virt[] array which initialized with offsets from FIXADDR_TOP == IOREMAP_END+FIXADDR_SIZE == KERN_IO_END - FIXADDR_SIZ + FIXADDR_SIZE == __kernel_io_end which is 0 when early_ioremap_setup() is called. __kernel_io_end is initialized little bit later in early_init_mmu(). This fixes the initialization by swapping early_ioremap_setup() and early_init_mmu(). Fixes: 265c3491c4bc ("powerpc: Add support for GENERIC_EARLY_IOREMAP") Signed-off-by: Alexey Kardashevskiy Reviewed-by: Christophe Leroy [mpe: Drop unrelated cleanup & cleanup change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210520032919.358935-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 76aaa05c231e8037a886aebda5f4d2e17a4c00f2 Author: Zqiang Date: Mon May 17 11:40:05 2021 +0800 locking/mutex: clear MUTEX_FLAGS if wait_list is empty due to signal [ Upstream commit 3a010c493271f04578b133de977e0e5dd2848cea ] When a interruptible mutex locker is interrupted by a signal without acquiring this lock and removed from the wait queue. if the mutex isn't contended enough to have a waiter put into the wait queue again, the setting of the WAITER bit will force mutex locker to go into the slowpath to acquire the lock every time, so if the wait queue is empty, the WAITER bit need to be clear. Fixes: 040a0a371005 ("mutex: Add support for wound/wait style locks") Suggested-by: Peter Zijlstra Signed-off-by: Zqiang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210517034005.30828-1-qiang.zhang@windriver.com Signed-off-by: Sasha Levin commit 9b8317360b042144284a6f39cc7b422014897574 Author: Leo Yan Date: Wed May 12 20:09:37 2021 +0800 locking/lockdep: Correct calling tracepoints [ Upstream commit 89e70d5c583c55088faa2201d397ee30a15704aa ] The commit eb1f00237aca ("lockdep,trace: Expose tracepoints") reverses tracepoints for lock_contended() and lock_acquired(), thus the ftrace log shows the wrong locking sequence that "acquired" event is prior to "contended" event: -0 [001] d.s3 20803.501685: lock_acquire: 0000000008b91ab4 &sg_policy->update_lock -0 [001] d.s3 20803.501686: lock_acquired: 0000000008b91ab4 &sg_policy->update_lock -0 [001] d.s3 20803.501689: lock_contended: 0000000008b91ab4 &sg_policy->update_lock -0 [001] d.s3 20803.501690: lock_release: 0000000008b91ab4 &sg_policy->update_lock This patch fixes calling tracepoints for lock_contended() and lock_acquired(). Fixes: eb1f00237aca ("lockdep,trace: Expose tracepoints") Signed-off-by: Leo Yan Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210512120937.90211-1-leo.yan@linaro.org Signed-off-by: Sasha Levin commit 173282b917174ad28b4a2216ec0081743198cc57 Author: Like Xu Date: Fri Apr 30 13:22:46 2021 +0800 perf/x86: Avoid touching LBR_TOS MSR for Arch LBR [ Upstream commit 3317c26a4b413b41364f2c4b83c778c6aba1576d ] The Architecture LBR does not have MSR_LBR_TOS (0x000001c9). In a guest that should support Architecture LBR, check_msr() will be a non-related check for the architecture MSR 0x0 (IA32_P5_MC_ADDR) that is also not supported by KVM. The failure will cause x86_pmu.lbr_nr = 0, thereby preventing the initialization of the guest Arch LBR. Fix it by avoiding this extraneous check in intel_pmu_init() for Arch LBR. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Signed-off-by: Like Xu [peterz: simpler still] Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210430052247.3079672-1-like.xu@linux.intel.com Signed-off-by: Sasha Levin commit 16e58aa0b694915c1e49949c48a79a4a95f2a300 Author: Daniel Wagner Date: Wed May 12 16:50:05 2021 +0200 nvmet: seset ns->file when open fails [ Upstream commit 85428beac80dbcace5b146b218697c73e367dcf5 ] Reset the ns->file value to NULL also in the error case in nvmet_file_ns_enable(). The ns->file variable points either to file object or contains the error code after the filp_open() call. This can lead to following problem: When the user first setups an invalid file backend and tries to enable the ns, it will fail. Then the user switches over to a bdev backend and enables successfully the ns. The first received I/O will crash the system because the IO backend is chosen based on the ns->file value: static u16 nvmet_parse_io_cmd(struct nvmet_req *req) { [...] if (req->ns->file) return nvmet_file_parse_io_cmd(req); return nvmet_bdev_parse_io_cmd(req); } Reported-by: Enzo Matsumiya Signed-off-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ddbf562ae431610b35dbd7dcfacaaa084d1a5ca8 Author: Oleg Nesterov Date: Wed May 12 15:33:08 2021 +0200 ptrace: make ptrace() fail if the tracee changed its pid unexpectedly [ Upstream commit dbb5afad100a828c97e012c6106566d99f041db6 ] Suppose we have 2 threads, the group-leader L and a sub-theread T, both parked in ptrace_stop(). Debugger tries to resume both threads and does ptrace(PTRACE_CONT, T); ptrace(PTRACE_CONT, L); If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not resume the old leader L, it resumes the post-exec thread T which was actually now stopped in PTHREAD_EVENT_EXEC. In this case the PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the tracee changed its pid. This patch makes ptrace() fail in this case until debugger does wait() and consumes PTHREAD_EVENT_EXEC which reports old_pid. This affects all ptrace requests except the "asynchronous" PTRACE_INTERRUPT/KILL. The patch doesn't add the new PTRACE_ option to not complicate the API, and I _hope_ this won't cause any noticeable regression: - If debugger uses PTRACE_O_TRACEEXEC and the thread did an exec and the tracer does a ptrace request without having consumed the exec event, it's 100% sure that the thread the ptracer thinks it is targeting does not exist anymore, or isn't the same as the one it thinks it is targeting. - To some degree this patch adds nothing new. In the scenario above ptrace(L) can fail with -ESRCH if it is called after the execing sub-thread wakes the leader up and before it "steals" the leader's pid. Test-case: #include #include #include #include #include #include #include #include void *tf(void *arg) { execve("/usr/bin/true", NULL, NULL); assert(0); return NULL; } int main(void) { int leader = fork(); if (!leader) { kill(getpid(), SIGSTOP); pthread_t th; pthread_create(&th, NULL, tf, NULL); for (;;) pause(); return 0; } waitpid(leader, NULL, WSTOPPED); ptrace(PTRACE_SEIZE, leader, 0, PTRACE_O_TRACECLONE | PTRACE_O_TRACEEXEC); waitpid(leader, NULL, 0); ptrace(PTRACE_CONT, leader, 0,0); waitpid(leader, NULL, 0); int status, thread = waitpid(-1, &status, 0); assert(thread > 0 && thread != leader); assert(status == 0x80137f); ptrace(PTRACE_CONT, thread, 0,0); /* * waitid() because waitpid(leader, &status, WNOWAIT) does not * report status. Why ???? * * Why WEXITED? because we have another kernel problem connected * to mt-exec. */ siginfo_t info; assert(waitid(P_PID, leader, &info, WSTOPPED|WEXITED|WNOWAIT) == 0); assert(info.si_pid == leader && info.si_status == 0x0405); /* OK, it sleeps in ptrace(PTRACE_EVENT_EXEC == 0x04) */ assert(ptrace(PTRACE_CONT, leader, 0,0) == -1); assert(errno == ESRCH); assert(leader == waitpid(leader, &status, WNOHANG)); assert(status == 0x04057f); assert(ptrace(PTRACE_CONT, leader, 0,0) == 0); return 0; } Signed-off-by: Oleg Nesterov Reported-by: Simon Marchi Acked-by: "Eric W. Biederman" Acked-by: Pedro Alves Acked-by: Simon Marchi Acked-by: Jan Kratochvil Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a89e92a5a7dce742048b45a84358275178e991be Author: Nicholas Piggin Date: Sat May 8 20:14:52 2021 +1000 powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks [ Upstream commit 2c8c89b95831f46a2fb31a8d0fef4601694023ce ] The paravit queued spinlock slow path adds itself to the queue then calls pv_wait to wait for the lock to become free. This is implemented by calling H_CONFER to donate cycles. When hcall tracing is enabled, this H_CONFER call can lead to a spin lock being taken in the tracing code, which will result in the lock to be taken again, which will also go to the slow path because it queues behind itself and so won't ever make progress. An example trace of a deadlock: __pv_queued_spin_lock_slowpath trace_clock_global ring_buffer_lock_reserve trace_event_buffer_lock_reserve trace_event_buffer_reserve trace_event_raw_event_hcall_exit __trace_hcall_exit plpar_hcall_norets_trace __pv_queued_spin_lock_slowpath trace_clock_global ring_buffer_lock_reserve trace_event_buffer_lock_reserve trace_event_buffer_reserve trace_event_raw_event_rcu_dyntick rcu_irq_exit irq_exit __do_irq call_do_irq do_IRQ hardware_interrupt_common_virt Fix this by introducing plpar_hcall_norets_notrace(), and using that to make SPLPAR virtual processor dispatching hcalls by the paravirt spinlock code. Signed-off-by: Nicholas Piggin Reviewed-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210508101455.1578318-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit f4550f0c1729fc405c56d1945e3e2938d5c66878 Author: xinhui pan Date: Wed Feb 24 11:28:08 2021 +0800 drm/ttm: Do not add non-system domain BO into swap list [ Upstream commit ad2c28bd9a4083816fa45a7e90c2486cde8a9873 ] BO would be added into swap list if it is validated into system domain. If BO is validated again into non-system domain, say, VRAM domain. It actually should not be in the swap list. Signed-off-by: xinhui pan Acked-by: Guchun Chen Acked-by: Alex Deucher Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210224032808.150465-1-xinhui.pan@amd.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 928ffb16262a332d8d0e48f7593ed5b1f1540302 Author: Yang Yingliang Date: Sat May 22 17:41:53 2021 -0700 tools/testing/selftests/exec: fix link error [ Upstream commit 4d1cd3b2c5c1c32826454de3a18c6183238d47ed ] Fix the link error by adding '-static': gcc -Wall -Wl,-z,max-page-size=0x1000 -pie load_address.c -o /home/yang/linux/tools/testing/selftests/exec/load_address_4096 /usr/bin/ld: /tmp/ccopEGun.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `stderr@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccopEGun.o(.text+0x158): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17' /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make: *** [Makefile:25: tools/testing/selftests/exec/load_address_4096] Error 1 Link: https://lkml.kernel.org/r/20210514092422.2367367-1-yangyingliang@huawei.com Fixes: 206e22f01941 ("tools/testing/selftests: add self-test for verifying load alignment") Signed-off-by: Yang Yingliang Cc: Chris Kennelly Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a666bdf60c0c76f2f56b6028d59a7144542f20ef Author: Dan Carpenter Date: Fri May 14 17:18:10 2021 +0300 RDMA/uverbs: Fix a NULL vs IS_ERR() bug [ Upstream commit 463a3f66473b58d71428a1c3ce69ea52c05440e5 ] The uapi_get_object() function returns error pointers, it never returns NULL. Fixes: 149d3845f4a5 ("RDMA/uverbs: Add a method to introspect handles in a context") Link: https://lore.kernel.org/r/YJ6Got+U7lz+3n9a@mwanda Signed-off-by: Dan Carpenter Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9791fb42c22d3c11240d4ce6a04680a6025535c9 Author: Maor Gottlieb Date: Wed May 19 11:41:32 2021 +0300 RDMA/mlx5: Fix query DCT via DEVX [ Upstream commit cfa3b797118eda7d68f9ede9b1a0279192aca653 ] When executing DEVX command to query QP object, we need to take the QP type from the mlx5_ib_qp struct which hold the driver specific QP types as well, such as DC. Fixes: 34613eb1d2ad ("IB/mlx5: Enable modify and query verbs objects via DEVX") Link: https://lore.kernel.org/r/6eee15d63f09bb70787488e0cf96216e2957f5aa.1621413654.git.leonro@nvidia.com Reviewed-by: Yishai Hadas Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8d746ea7c687bab060a2c05a35c449302406cd52 Author: Hans de Goede Date: Tue May 18 14:50:27 2021 +0200 platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios [ Upstream commit 3a53587423d25c87af4b4126a806a0575104b45e ] init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this. Cc: Mario Limonciello Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Signed-off-by: Hans de Goede Reviewed-by: Mario Limonciello Reviewed-by: Mark Gross Link: https://lore.kernel.org/r/20210518125027.21824-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit bce24d9300c32be06939d4afa528f7e3fb7ac85e Author: Hans de Goede Date: Wed May 12 14:55:23 2021 +0200 platform/x86: intel_int0002_vgpio: Only call enable_irq_wake() when using s2idle [ Upstream commit b68e182a3062e326b891f47152a3a1b84abccf0f ] Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") stopped passing irq_set_wake requests on to the parents IRQ because this was breaking suspend (causing immediate wakeups) on an Asus E202SA. This workaround for the Asus E202SA is causing wakeup by USB keyboard to not work on other devices with Airmont CPU cores such as the Medion Akoya E1239T. In hindsight the problem with the Asus E202SA has nothing to do with Silvermont vs Airmont CPU cores, so the differentiation between the 2 types of CPU cores introduced by the previous fix is wrong. The real issue at hand is s2idle vs S3 suspend where the suspend is mostly handled by firmware. The parent IRQ for the INT0002 device is shared with the ACPI SCI and the real problem is that the INT0002 code should not be messing with the wakeup settings of that IRQ when suspend/resume is being handled by the firmware. Note that on systems which support both s2idle and S3 suspend, which suspend method to use can be changed at runtime. This patch fixes both the Asus E202SA spurious wakeups issue as well as the wakeup by USB keyboard not working on the Medion Akoya E1239T issue. These are both fixed by replacing the old workaround with delaying the enable_irq_wake(parent_irq) call till system-suspend time and protecting it with a !pm_suspend_via_firmware() check so that we still do not call it on devices using firmware-based (S3) suspend such as the Asus E202SA. Note rather then adding #ifdef CONFIG_PM_SLEEP, this commit simply adds a "depends on PM_SLEEP" to the Kconfig since this drivers whole purpose is to deal with wakeup events, so using it without CONFIG_PM_SLEEP makes no sense. Cc: Maxim Mikityanskiy Fixes: 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20210512125523.55215-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 0ef94da9232e4faff7b4c3de8b8eb4346c2166d5 Author: Liming Sun Date: Fri May 7 20:30:12 2021 -0400 platform/mellanox: mlxbf-tmfifo: Fix a memory barrier issue [ Upstream commit 1c0e5701c5e792c090aef0e5b9b8923c334d9324 ] The virtio framework uses wmb() when updating avail->idx. It guarantees the write order, but not necessarily loading order for the code accessing the memory. This commit adds a load barrier after reading the avail->idx to make sure all the data in the descriptor is visible. It also adds a barrier when returning the packet to virtio framework to make sure read/writes are visible to the virtio code. Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun Reviewed-by: Vadim Pasternak Link: https://lore.kernel.org/r/1620433812-17911-1-git-send-email-limings@nvidia.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0477af297d6abedd5d26e82d4c77c7080ce5fd72 Author: James Smart Date: Mon May 10 21:56:35 2021 -0700 nvme-fc: clear q_live at beginning of association teardown [ Upstream commit a7d139145a6640172516b193abf6d2398620aa14 ] The __nvmf_check_ready() routine used to bounce all filesystem io if the controller state isn't LIVE. However, a later patch changed the logic so that it rejection ends up being based on the Q live check. The FC transport has a slightly different sequence from rdma and tcp for shutting down queues/marking them non-live. FC marks its queue non-live after aborting all ios and waiting for their termination, leaving a rather large window for filesystem io to continue to hit the transport. Unfortunately this resulted in filesystem I/O or applications seeing I/O errors. Change the FC transport to mark the queues non-live at the first sign of teardown for the association (when I/O is initially terminated). Fixes: 73a5379937ec ("nvme-fabrics: allow to queue requests for live queues") Signed-off-by: James Smart Reviewed-by: Sagi Grimberg Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 6f2d1af9338825bf3e887762f5966b73c309b884 Author: Keith Busch Date: Mon May 17 15:36:43 2021 -0700 nvme-tcp: rerun io_work if req_list is not empty [ Upstream commit a0fdd1418007f83565d3f2e04b47923ba93a9b8c ] A possible race condition exists where the request to send data is enqueued from nvme_tcp_handle_r2t()'s will not be observed by nvme_tcp_send_all() if it happens to be running. The driver relies on io_work to send the enqueued request when it is runs again, but the concurrently running nvme_tcp_send_all() may not have released the send_mutex at that time. If no future commands are enqueued to re-kick the io_work, the request will timeout in the SEND_H2C state, resulting in a timeout error like: nvme nvme0: queue 1: timeout request 0x3 type 6 Ensure the io_work continues to run as long as the req_list is not empty. Fixes: db5ad6b7f8cdd ("nvme-tcp: try to send request in queue_rq context") Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 551ba08d4b7eb26f75758cdb9f15105b276517ad Author: Wu Bo Date: Wed May 19 13:01:10 2021 +0800 nvme-loop: fix memory leak in nvme_loop_create_ctrl() [ Upstream commit 03504e3b54cc8118cc26c064e60a0b00c2308708 ] When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label. Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver") Signed-off-by: Wu Bo Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit afb680ed7ecbb7fd66ddb43650e9b533fd8b4b9a Author: Wu Bo Date: Wed May 19 13:01:09 2021 +0800 nvmet: fix memory leak in nvmet_alloc_ctrl() [ Upstream commit fec356a61aa3d3a66416b4321f1279e09e0f256f ] When creating ctrl in nvmet_alloc_ctrl(), if the cntlid_min is larger than cntlid_max of the subsystem, and jumps to the "out_free_changed_ns_list" label, but the ctrl->sqs lack of be freed. Fix this by jumping to the "out_free_sqs" label. Fixes: 94a39d61f80f ("nvmet: make ctrl-id configurable") Signed-off-by: Wu Bo Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e062e2d2709c1140095b3981dced36dd052ce6b0 Author: Shay Drory Date: Tue May 11 08:48:28 2021 +0300 RDMA/core: Don't access cm_id after its destruction [ Upstream commit 889d916b6f8a48b8c9489fffcad3b78eedd01a51 ] restrack should only be attached to a cm_id while the ID has a valid device pointer. It is set up when the device is first loaded, but not cleared when the device is removed. There is also two copies of the device pointer, one private and one in the public API, and these were left out of sync. Make everything go to NULL together and manipulate restrack right around the device assignments. Found by syzcaller: BUG: KASAN: wild-memory-access in __list_del include/linux/list.h:112 [inline] BUG: KASAN: wild-memory-access in __list_del_entry include/linux/list.h:135 [inline] BUG: KASAN: wild-memory-access in list_del include/linux/list.h:146 [inline] BUG: KASAN: wild-memory-access in cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] BUG: KASAN: wild-memory-access in cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 Write of size 8 at addr dead000000000108 by task syz-executor716/334 CPU: 0 PID: 334 Comm: syz-executor716 Not tainted 5.11.0+ #271 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 __list_del include/linux/list.h:112 [inline] __list_del_entry include/linux/list.h:135 [inline] list_del include/linux/list.h:146 [inline] cma_cancel_listens drivers/infiniband/core/cma.c:1767 [inline] cma_cancel_operation drivers/infiniband/core/cma.c:1795 [inline] cma_cancel_operation+0x1f4/0x4b0 drivers/infiniband/core/cma.c:1783 _destroy_id+0x29/0x460 drivers/infiniband/core/cma.c:1862 ucma_close_id+0x36/0x50 drivers/infiniband/core/ucma.c:185 ucma_destroy_private_ctx+0x58d/0x5b0 drivers/infiniband/core/ucma.c:576 ucma_close+0x91/0xd0 drivers/infiniband/core/ucma.c:1797 __fput+0x169/0x540 fs/file_table.c:280 task_work_run+0xb7/0x100 kernel/task_work.c:140 exit_task_work include/linux/task_work.h:30 [inline] do_exit+0x7da/0x17f0 kernel/exit.c:825 do_group_exit+0x9e/0x190 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x2d/0x30 kernel/exit.c:931 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 255d0c14b375 ("RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count") Link: https://lore.kernel.org/r/3352ee288fe34f2b44220457a29bfc0548686363.1620711734.git.leonro@nvidia.com Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit abe31d25facdb9109fe2cf69890748295291570c Author: Leon Romanovsky Date: Tue May 11 08:48:31 2021 +0300 RDMA/rxe: Return CQE error if invalid lkey was supplied [ Upstream commit dc07628bd2bbc1da768e265192c28ebd301f509d ] RXE is missing update of WQE status in LOCAL_WRITE failures. This caused the following kernel panic if someone sent an atomic operation with an explicitly wrong lkey. [leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/11e7b553f3a6f5371c6bb3f57c494bb52b88af99.1620711734.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Acked-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aed15d4e59a0c4da7c499265f692e484045d9a7d Author: Bob Pearson Date: Thu Mar 25 16:24:26 2021 -0500 RDMA/rxe: Split MEM into MR and MW [ Upstream commit 364e282c4fe7e24a5f32cd6e93e1056c6a6e3d31 ] In the original rxe implementation it was intended to use a common object to represent MRs and MWs but they are different enough to separate these into two objects. This allows replacing the mem name with mr for MRs which is more consistent with the style for the other objects and less likely to be confusing. This is a long patch that mostly changes mem to mr where it makes sense and adds a new rxe_mw struct. Link: https://lore.kernel.org/r/20210325212425.2792-1-rpearson@hpe.com Signed-off-by: Bob Pearson Acked-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1af33ee66594356b86ae54a7be13009c7454fc45 Author: Maor Gottlieb Date: Tue May 11 08:48:29 2021 +0300 RDMA/mlx5: Recover from fatal event in dual port mode [ Upstream commit 97f30d324ce6645a4de4ffb71e4ae9b8ca36ff04 ] When there is fatal event on the slave port, the device is marked as not active. We need to mark it as active again when the slave is recovered to regain full functionality. Fixes: d69a24e03659 ("IB/mlx5: Move IB event processing onto a workqueue") Link: https://lore.kernel.org/r/8906754455bb23019ef223c725d2c0d38acfb80b.1620711734.git.leonro@nvidia.com Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 85d3b4eaf66d84d47d70f8c08b2ba34bb953d236 Author: Zhen Lei Date: Fri May 14 17:09:52 2021 +0800 scsi: qla2xxx: Fix error return code in qla82xx_write_flash_dword() [ Upstream commit 5cb289bf2d7c34ca1abd794ce116c4f19185a1d4 ] Fix to return a negative error code from the error handling case instead of 0 as done elsewhere in this function. Link: https://lore.kernel.org/r/20210514090952.6715-1-thunder.leizhen@huawei.com Fixes: a9083016a531 ("[SCSI] qla2xxx: Add ISP82XX support.") Reported-by: Hulk Robot Reviewed-by: Himanshu Madhani Signed-off-by: Zhen Lei Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 11014efcec378bb0050a6cf08eaf375e3693400a Author: Javed Hasan Date: Wed May 12 00:25:33 2021 -0700 scsi: qedf: Add pointer checks in qedf_update_link_speed() [ Upstream commit 73578af92a0fae6609b955fcc9113e50e413c80f ] The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference shost_data while updating supported_speeds. Add a NULL pointer check before dereferencing shost_data. Link: https://lore.kernel.org/r/20210512072533.23618-1-jhasan@marvell.com Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Reviewed-by: Himanshu Madhani Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1177bd83b78819467179e45c979f0862b8eadb40 Author: Bart Van Assche Date: Thu May 13 09:49:12 2021 -0700 scsi: ufs: core: Increase the usable queue depth [ Upstream commit d0b2b70eb12e9ffaf95e11b16b230a4e015a536c ] With the current implementation of the UFS driver active_queues is 1 instead of 0 if all UFS request queues are idle. That causes hctx_may_queue() to divide the queue depth by 2 when queueing a request and hence reduces the usable queue depth. The shared tag set code in the block layer keeps track of the number of active request queues. blk_mq_tag_busy() is called before a request is queued onto a hwq and blk_mq_tag_idle() is called some time after the hwq became idle. blk_mq_tag_idle() is called from inside blk_mq_timeout_work(). Hence, blk_mq_tag_idle() is only called if a timer is associated with each request that is submitted to a request queue that shares a tag set with another request queue. Adds a blk_mq_start_request() call in ufshcd_exec_dev_cmd(). This doubles the queue depth on my test setup from 16 to 32. In addition to increasing the usable queue depth, also fix the documentation of the 'timeout' parameter in the header above ufshcd_exec_dev_cmd(). Link: https://lore.kernel.org/r/20210513164912.5683-1-bvanassche@acm.org Fixes: 7252a3603015 ("scsi: ufs: Avoid busy-waiting by eliminating tag conflicts") Cc: Can Guo Cc: Alim Akhtar Cc: Avri Altman Cc: Stanley Chu Cc: Bean Huo Cc: Adrian Hunter Reviewed-by: Can Guo Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 03344e843ab6dd3b3f2cadfb65ed910590856c70 Author: Leon Romanovsky Date: Tue May 11 10:26:03 2021 +0300 RDMA/rxe: Clear all QP fields if creation failed [ Upstream commit 67f29896fdc83298eed5a6576ff8f9873f709228 ] rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones, but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error. refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/7bf8d548764d406dbbbaf4b574960ebfd5af8387.1620717918.git.leonro@nvidia.com Reported-by: syzbot+36a7f280de4e11c6f04e@syzkaller.appspotmail.com Signed-off-by: Leon Romanovsky Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit beab753fe3b4e087411a850a64c6cd748544d8a1 Author: Qiu Wenbo Date: Wed Apr 28 13:06:36 2021 +0800 platform/x86: ideapad-laptop: fix a NULL pointer dereference [ Upstream commit ff67dbd554b2aaa22be933eced32610ff90209dd ] The third parameter of dytc_cql_command should not be NULL since it will be dereferenced immediately. Fixes: ff36b0d953dc4 ("platform/x86: ideapad-laptop: rework and create new ACPI helpers") Signed-off-by: Qiu Wenbo Acked-by: Ike Panhc Link: https://lore.kernel.org/r/20210428050636.8003-1-qiuwenbo@kylinos.com.cn Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit e6871b4270c05f8b212e7d98aee82b357972c80a Author: Leon Romanovsky Date: Mon May 10 17:46:00 2021 +0300 RDMA/core: Prevent divide-by-zero error triggered by the user [ Upstream commit 54d87913f147a983589923c7f651f97de9af5be1 ] The user_entry_size is supplied by the user and later used as a denominator to calculate number of entries. The zero supplied by the user will trigger the following divide-by-zero error: divide error: 0000 [#1] SMP KASAN PTI CPU: 4 PID: 497 Comm: c_repro Not tainted 5.13.0-rc1+ #281 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE+0x1b1/0x510 Code: 87 59 03 00 00 e8 9f ab 1e ff 48 8d bd a8 00 00 00 e8 d3 70 41 ff 44 0f b7 b5 a8 00 00 00 e8 86 ab 1e ff 31 d2 4c 89 f0 31 ff <49> f7 f5 48 89 d6 48 89 54 24 10 48 89 04 24 e8 1b ad 1e ff 48 8b RSP: 0018:ffff88810416f828 EFLAGS: 00010246 RAX: 0000000000000008 RBX: 1ffff1102082df09 RCX: ffffffff82183f3d RDX: 0000000000000000 RSI: ffff888105f2da00 RDI: 0000000000000000 RBP: ffff88810416fa98 R08: 0000000000000001 R09: ffffed102082df5f R10: ffff88810416faf7 R11: ffffed102082df5e R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000008 R15: ffff88810416faf0 FS: 00007f5715efa740(0000) GS:ffff88811a700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000840 CR3: 000000010c2e0001 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ib_uverbs_handler_UVERBS_METHOD_INFO_HANDLES+0x4b0/0x4b0 ib_uverbs_cmd_verbs+0x1546/0x1940 ib_uverbs_ioctl+0x186/0x240 __x64_sys_ioctl+0x38a/0x1220 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 9f85cbe50aa0 ("RDMA/uverbs: Expose the new GID query API to user space") Link: https://lore.kernel.org/r/b971cc70a8b240a8b5eda33c99fa0558a0071be2.1620657876.git.leonro@nvidia.com Reviewed-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4d2efd50e8acad61de7cc3bf4388ce3e99758610 Author: Leon Romanovsky Date: Sun May 9 14:41:38 2021 +0300 RDMA/siw: Release xarray entry [ Upstream commit a3d83276d98886879b5bf7b30b7c29882754e4df ] The xarray entry is allocated in siw_qp_add(), but release was missed in case zero-sized SQ was discovered. Fixes: 661f385961f0 ("RDMA/siw: Fix handling of zero-sized Read and Receive Queues.") Link: https://lore.kernel.org/r/f070b59d5a1114d5a4e830346755c2b3f141cde5.1620560472.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Reviewed-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8abd8591e2b4d9ab2d78adb9235fbc8765758434 Author: Leon Romanovsky Date: Sun May 9 14:39:21 2021 +0300 RDMA/siw: Properly check send and receive CQ pointers [ Upstream commit a568814a55a0e82bbc7c7b51333d0c38e8fb5520 ] The check for the NULL of pointer received from container_of() is incorrect by definition as it points to some offset from NULL. Change such check with proper NULL check of SIW QP attributes. Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Link: https://lore.kernel.org/r/a7535a82925f6f4c1f062abaa294f3ae6e54bdd2.1620560310.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Reviewed-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b49f5af30b0e4064fbd91e83823a4bfcb2c7a3e7 Author: Lv Yunlong Date: Mon Apr 26 06:43:46 2021 -0700 habanalabs/gaudi: Fix a potential use after free in gaudi_memset_device_memory [ Upstream commit 115726c5d312b462c9d9931ea42becdfa838a076 ] Our code analyzer reported a uaf. In gaudi_memset_device_memory, cb is get via hl_cb_kernel_create() with 2 refcount. If hl_cs_allocate_job() failed, the execution runs into release_cb branch. One ref of cb is dropped by hl_cb_put(cb) and could be freed if other thread also drops one ref. Then cb is used by cb->id later, which is a potential uaf. My patch add a variable 'id' to accept the value of cb->id before the hl_cb_put(cb) is called, to avoid the potential uaf. Fixes: 423815bf02e25 ("habanalabs/gaudi: remove PCI access to SM block") Signed-off-by: Lv Yunlong Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit bf2c33ad6730b5b926d74ec7429e827e94769f50 Author: Rijo Thomas Date: Wed Apr 14 23:08:27 2021 +0530 tee: amdtee: unload TA only when its refcount becomes 0 [ Upstream commit 9f015b3765bf593b3ed5d3b588e409dc0ffa9f85 ] Same Trusted Application (TA) can be loaded in multiple TEE contexts. If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context. Therefore reference count TA and unload it when the count becomes zero. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Devaraj Rangasamy Signed-off-by: Rijo Thomas Acked-by: Dan Carpenter Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 27de83ae5933e03c67a6f250936770e128005340 Author: Christophe JAILLET Date: Fri Apr 23 17:09:28 2021 +0200 openrisc: Fix a memory leak [ Upstream commit c019d92457826bb7b2091c86f36adb5de08405f9 ] 'setup_find_cpu_node()' take a reference on the node it returns. This reference must be decremented when not needed anymore, or there will be a leak. Add the missing 'of_node_put(cpu)'. Note that 'setup_cpuinfo()' that also calls this function already has a correct 'of_node_put(cpu)' at its end. Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Signed-off-by: Christophe JAILLET Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 29cd1f094890e09f6e6e70280ae426278ddcce42 Author: Dan Carpenter Date: Thu Apr 22 12:02:29 2021 +0300 firmware: arm_scpi: Prevent the ternary sign expansion bug [ Upstream commit d9cd78edb2e6b7e26747c0ec312be31e7ef196fe ] How the type promotion works in ternary expressions is a bit tricky. The problem is that scpi_clk_get_val() returns longs, "ret" is a int which holds a negative error code, and le32_to_cpu() is an unsigned int. We want the negative error code to be cast to a negative long. But because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and becomes a high positive and then it is promoted to long and it is still a high positive value. Fix this by getting rid of the ternary. Link: https://lore.kernel.org/r/YIE7pdqV/h10tEAK@mwanda Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Reviewed-by: Cristian Marussi Signed-off-by: Dan Carpenter [sudeep.holla: changed to return 0 as clock rate on error] Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin