commit 689e89aee55c565fe90fcdf8a7e53f2f976c5946 Author: Greg Kroah-Hartman Date: Wed May 19 10:13:20 2021 +0200 Linux 5.10.38 Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Joel Stanley Tested-by: Hulk Robot Tested-by: Sudip Mukherjee Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20210517140305.140529752@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit ed350825e89a3d23f5d88110c8dd32ac167894ad Author: Kuninori Morimoto Date: Thu Apr 8 13:28:47 2021 +0900 ASoC: rsnd: check all BUSIF status when error commit a4856e15e58b54977f1c0c0299309ad4d1f13365 upstream. commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") adds __rsnd_ssi_interrupt() checks for BUSIF status, but is using "break" at for loop. This means it is not checking all status. Let's check all BUSIF status. Fixes: commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/874kgh1jsw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cd709c8e06b6356c820297f583070884c60186c9 Author: Christoph Hellwig Date: Fri Apr 9 11:46:12 2021 +0200 nvme: do not try to reconfigure APST when the controller is not live commit 53fe2a30bc168db9700e00206d991ff934973cf1 upstream. Do not call nvme_configure_apst when the controller is not live, given that nvme_configure_apst will fail due the lack of an admin queue when the controller is being torn down and nvme_set_latency_tolerance is called from dev_pm_qos_hide_latency_tolerance. Fixes: 510a405d945b("nvme: fix memory leak for power latency tolerance") Reported-by: Peng Liu Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 054add24a869ab82b0211c5308c479b7ad5d64a1 Author: Arnd Bergmann Date: Fri Apr 9 22:12:05 2021 +0200 ext4: fix debug format string warning commit fcdf3c34b7abdcbb49690c94c7fa6ce224dc9749 upstream. Using no_printk() for jbd_debug() revealed two warnings: fs/jbd2/recovery.c: In function 'fc_do_one_pass': fs/jbd2/recovery.c:256:30: error: format '%d' expects a matching 'int' argument [-Werror=format=] 256 | jbd_debug(3, "Processing fast commit blk with seq %d"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/ext4/fast_commit.c: In function 'ext4_fc_replay_add_range': fs/ext4/fast_commit.c:1732:30: error: format '%d' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Werror=format=] 1732 | jbd_debug(1, "Converting from %d to %d %lld", The first one was added incorrectly, and was also missing a few newlines in debug output, and the second one happened when the type of an argument changed. Reported-by: kernel test robot Fixes: d556435156b7 ("jbd2: avoid -Wempty-body warnings") Fixes: 6db074618969 ("ext4: use BIT() macro for BH_** state bits") Fixes: 5b849b5f96b4 ("jbd2: fast commit recovery path") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210409201211.1866633-1-arnd@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c5dffd422145ee12ae0cd4a1aaf7b8c83624468a Author: Kees Cook Date: Mon Apr 5 14:39:59 2021 -0700 debugfs: Make debugfs_allow RO after init commit 312723a0b34d6d110aa4427a982536bb36ab8471 upstream. Since debugfs_allow is only set at boot time during __init, make it read-only after being set. Fixes: a24c6f7bc923 ("debugfs: Add access restriction option") Cc: Peter Enderborg Reviewed-by: Peter Enderborg Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210405213959.3079432-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman commit 81cb4f36d62c37ee0c81c57718b4afe12e2bece6 Author: Zhen Lei Date: Thu Apr 22 17:08:57 2021 +0800 dt-bindings: serial: 8250: Remove duplicated compatible strings commit a7277a73984114b38dcb62c8548850800ffe864e upstream. The compatible strings "mediatek,*" appears two times, remove one of them. Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema") Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210422090857.583-1-thunder.leizhen@huawei.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit c1514ad24c3e6e2beac1f0338f0d8fa2cfaee5f6 Author: Geert Uytterhoeven Date: Thu Apr 29 14:45:52 2021 +0200 dt-bindings: media: renesas,vin: Make resets optional on R-Car Gen1 commit 7935bb56e21b2add81149f4def8e59b4133fe57c upstream. The "resets" property is not present on R-Car Gen1 SoCs. Supporting it would require migrating from renesas,cpg-clocks to renesas,cpg-mssr. Fixes: 905fc6b1bfb4a631 ("dt-bindings: rcar-vin: Convert bindings to json-schema") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/217c8197efaee7d803b22d433abb0ea8e33b84c6.1619700314.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit c4e3d8cf615bf651ef39e24210e73700187244dd Author: Qii Wang Date: Sat Apr 17 14:46:50 2021 +0800 i2c: mediatek: Fix send master code at more than 1MHz commit 63ce8e3df8f6deca2da52eaf064751ad4018b46e upstream. There are some omissions in the previous patch about replacing I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and need to fix it. Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz") Signed-off-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 667627fa85a8bf02024319028b6c3121b3b494f0 Author: Fabio Estevam Date: Sat Mar 20 13:21:52 2021 +0100 media: rkvdec: Remove of_match_ptr() commit c2357dd9cbafc8ed37156e32c24884cfa8380b2f upstream. When building with CONFIG_OF not set, the following clang build warning is seen: >> drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 'of_rkvdec_match' [-Wunused-const-variable] Fix the warning by removing the unnecessary of_match_ptr(). Reported-by: kernel test robot Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Fabio Estevam Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b0402e78535169d178c86a5800c32f7a299d73fd Author: Paweł Chmiel Date: Sat Oct 24 17:43:46 2020 +0200 clk: exynos7: Mark aclk_fsys1_200 as critical commit 34138a59b92c1a30649a18ec442d2e61f3bc34dd upstream. This clock must be always enabled to allow access to any registers in fsys1 CMU. Until proper solution based on runtime PM is applied (similar to what was done for Exynos5433), mark that clock as critical so it won't be disabled. It was observed on Samsung Galaxy S6 device (based on Exynos7420), where UFS module is probed before pmic used to power that device. In this case defer probe was happening and that clock was disabled by UFS driver, causing whole boot to hang on next CMU access. Fixes: 753195a749a6 ("clk: samsung: exynos7: Correct CMU_FSYS1 clocks names") Signed-off-by: Paweł Chmiel Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/linux-clk/20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com [s.nawrocki: Added comment in the code] Signed-off-by: Sylwester Nawrocki Signed-off-by: Greg Kroah-Hartman commit 805c990a9c54b9451d3daff640b850909c31ab9d Author: Stéphane Marchesin Date: Thu Apr 29 03:10:21 2021 +0000 drm/i915: Fix crash in auto_retire commit 402be8a101190969fc7ff122d07e262df86e132b upstream. The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring kfifo_buf industrialio cros_ec_sensorhub 2021-04-24T18:03:53.804337Z WARNING kernel: [ 516.876972] cdc_ether usbnet iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev 2021-04-24T18:03:53.804337Z EMERG kernel: [ 516.879169] gsmi: Log Shutdown Reason 0x03 This change fixes this by aligning the function. Signed-off-by: Stéphane Marchesin Fixes: 229007e02d69 ("drm/i915: Wrap i915_active in a simple kreffed struct") Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20210429031021.1218091-1-marcheu@chromium.org (cherry picked from commit ca419f407b43cc89942ebc297c7a63d94abbcae4) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit cd47b861d2251235f5e2ef6a31930d71c147c387 Author: Tvrtko Ursulin Date: Thu Apr 29 09:35:29 2021 +0100 drm/i915/overlay: Fix active retire callback alignment commit a915fe5e9601c632417ef5261af70788d7d23a8a upstream. __i915_active_call annotation is required on the retire callback to ensure correct function alignment. Signed-off-by: Tvrtko Ursulin Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active tracking") Cc: Chris Wilson Cc: Matthew Auld Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210429083530.849546-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit d8e44e4dd221ee283ea60a6fb87bca08807aa0ab) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a67c80dcb4031c2188fd68e57e1b3b67077b69ce Author: Ville Syrjälä Date: Wed Apr 21 18:33:59 2021 +0300 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again commit 04d019961fd15de92874575536310243a0d4c5c5 upstream. We've defined C0DRB3/C1DRB3 as 16 bit registers, so access them as such. Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences") Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-3-ville.syrjala@linux.intel.com (cherry picked from commit f765a5b48c667bdada5e49d5e0f23f8c0687b21b) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 17928443db88bfafbf20b700cf2f65e722d67f6d Author: Lv Yunlong Date: Mon Apr 26 05:43:40 2021 -0700 drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp commit ea995218dddba171fecd05496c69617c5ef3c5b8 upstream. Our code analyzer reported a double free bug. In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base is freed by i915_gem_object_put() with a reference dropped. Then free_pd calls free_px() defined in intel_ppgtt.c, which calls i915_gem_object_put() to put pde->pt.base again. As pde->pt.base is protected by refcount, so the second put will not free pde->pt.base actually. But, maybe it is better to remove the first put? Fixes: 82adf901138cc ("drm/i915/gt: Shrink i915_page_directory's slab bucket") Signed-off-by: Lv Yunlong Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20210426124340.4238-1-lyl2019@mail.ustc.edu.cn (cherry picked from commit ac69496fe65cca0611d5917b7d232730ff605bc7) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 20530f7fde75c44721e4a7465d3179147180339f Author: Greg Kroah-Hartman Date: Mon Apr 5 11:48:52 2021 +0200 kobject_uevent: remove warning in init_uevent_argv() commit b4104180a2efb85f55e1ba1407885c9421970338 upstream. syzbot can trigger the WARN() in init_uevent_argv() which isn't the nicest as the code does properly recover and handle the error. So change the WARN() call to pr_warn() and provide some more information on what the buffer size that was needed. Link: https://lore.kernel.org/r/20201107082206.GA19079@kroah.com Cc: "Rafael J. Wysocki" Cc: linux-kernel@vger.kernel.org Reported-by: syzbot+92340f7b2b4789907fdb@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210405094852.1348499-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6ece86e9e88fb1e557ce1ef58e14d1d729aae59f Author: Badhri Jagan Sridharan Date: Wed Apr 14 22:01:21 2021 -0700 usb: typec: tcpm: Fix error while calculating PPS out values commit 374157ff88ae1a7f7927331cbc72c1ec11994e8a upstream. "usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply" introduced a regression for req_out_volt and req_op_curr calculation. req_out_volt should consider the newly calculated max voltage instead of previously accepted max voltage by the port partner. Likewise, req_op_curr should consider the newly calculated max current instead of previously accepted max current by the port partner. Fixes: e3a072022487 ("usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply") Reviewed-by: Guenter Roeck Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210415050121.1928298-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 5d2f09c44ff28ac792e24e8f2ff9e29ba210fcb4 Author: Ard Biesheuvel Date: Mon May 10 06:21:11 2021 -0700 ARM: 9027/1: head.S: explicitly map DT even if it lives in the first physical section commit 10fce53c0ef8f6e79115c3d9e0d7ea1338c3fa37 upstream The early ATAGS/DT mapping code uses SECTION_SHIFT to mask low order bits of R2, and decides that no ATAGS/DTB were provided if the resulting value is 0x0. This means that on systems where DRAM starts at 0x0 (such as Raspberry Pi), no explicit mapping of the DT will be created if R2 points into the first 1 MB section of memory. This was not a problem before, because the decompressed kernel is loaded at the base of DRAM and mapped using sections as well, and so as long as the DT is referenced via a virtual address that uses the same translation (the linear map, in this case), things work fine. However, commit 7a1be318f579 ("9012/1: move device tree mapping out of linear region") changes this, and now the DT is referenced via a virtual address that is disjoint from the linear mapping of DRAM, and so we need the early code to create the DT mapping unconditionally. So let's create the early DT mapping for any value of R2 != 0x0. Reported-by: "kernelci.org bot" Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit ac421c7f90c84362b6500eccaf4277b7122cc90a Author: Ard Biesheuvel Date: Mon May 10 06:21:10 2021 -0700 ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address commit fc2933c133744305236793025b00c2f7d258b687 upstream Commit 149a3ffe62b9dbc3 ("9012/1: move device tree mapping out of linear region") created a permanent, read-only section mapping of the device tree blob provided by the firmware, and added a set of macros to get the base and size of the virtually mapped FDT based on the physical address. However, while the mapping code uses the SECTION_SIZE macro correctly, the macros use PMD_SIZE instead, which means something entirely different on ARM when using short descriptors, and is therefore not the right quantity to use here. So replace PMD_SIZE with SECTION_SIZE. While at it, change the names of the macro and its parameter to clarify that it returns the virtual address of the start of the FDT, based on the physical address in memory. Tested-by: Joel Stanley Tested-by: Marek Szyprowski Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 1eb77569029da382924fda0f23ecaea8e10acac6 Author: Ard Biesheuvel Date: Mon May 10 06:21:09 2021 -0700 ARM: 9012/1: move device tree mapping out of linear region commit 7a1be318f5795cb66fa0dc86b3ace427fe68057f upstream On ARM, setting up the linear region is tricky, given the constraints around placement and alignment of the memblocks, and how the kernel itself as well as the DT are placed in physical memory. Let's simplify matters a bit, by moving the device tree mapping to the top of the address space, right between the end of the vmalloc region and the start of the the fixmap region, and create a read-only mapping for it that is independent of the size of the linear region, and how it is organized. Since this region was formerly used as a guard region, which will now be populated fully on LPAE builds by this read-only mapping (which will still be able to function as a guard region for stray writes), bump the start of the [underutilized] fixmap region by 512 KB as well, to ensure that there is always a proper guard region here. Doing so still leaves ample room for the fixmap space, even with NR_CPUS set to its maximum value of 32. Tested-by: Linus Walleij Reviewed-by: Linus Walleij Reviewed-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 6cdbafc2addd0a7c4e710a29b3ed2a8610add13a Author: Ard Biesheuvel Date: Mon May 10 06:21:08 2021 -0700 ARM: 9011/1: centralize phys-to-virt conversion of DT/ATAGS address commit e9a2f8b599d0bc22a1b13e69527246ac39c697b4 upstream Before moving the DT mapping out of the linear region, let's prepare for this change by removing all the phys-to-virt translations of the __atags_pointer variable, and perform this translation only once at setup time. Tested-by: Linus Walleij Reviewed-by: Linus Walleij Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 6d5fda434b1f46c22ce3cde04729005dfb2eb2d6 Author: Tony Lindgren Date: Tue Mar 23 09:43:26 2021 +0200 clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940 commit 25de4ce5ed02994aea8bc111d133308f6fd62566 upstream. There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm percpu timers instead. Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly. Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue". For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0": https://www.ti.com/lit/er/sprz429m/sprz429m.pdf The concept is based on earlier reference patches done by Tero Kristo and Keerthy. Cc: Keerthy Cc: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-3-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit 06470de53e4f95fd8f2e608115dbac440ccf9007 Author: Tony Lindgren Date: Tue Mar 23 09:43:25 2021 +0200 clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue commit 3efe7a878a11c13b5297057bfc1e5639ce1241ce upstream. There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days. To work around the issue, we need to use timer-ti-dm timers instead. Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes. Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210323074326.28302-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit 462049cfb342c4f5e8344452a205207fc5575f1b Author: Maciej W. Rozycki Date: Thu Apr 22 22:36:12 2021 +0200 MIPS: Avoid handcoded DIVU in `__div64_32' altogether commit 25ab14cbe9d1b66fda44c71a2db7582a31b6f5cd upstream. Remove the inline asm with a DIVU instruction from `__div64_32' and use plain C code for the intended DIVMOD calculation instead. GCC is smart enough to know that both the quotient and the remainder are calculated with single DIVU, so with ISAs up to R5 the same instruction is actually produced with overall similar code. For R6 compiled code will work, but separate DIVU and MODU instructions will be produced, which are also interlocked, so scalar implementations will likely not perform as well as older ISAs with their asynchronous MD unit. Likely still faster then the generic algorithm though. This removes a compilation error for R6 however where the original DIVU instruction is not supported anymore and the MDU accumulator registers have been removed and consequently GCC complains as to a constraint it cannot find a register for: In file included from ./include/linux/math.h:5, from ./include/linux/kernel.h:13, from mm/page-writeback.c:15: ./include/linux/math64.h: In function 'div_u64_rem': ./arch/mips/include/asm/div64.h:76:17: error: inconsistent operand constraints in an 'asm' 76 | __asm__("divu $0, %z1, %z2" \ | ^~~~~~~ ./include/asm-generic/div64.h:245:25: note: in expansion of macro '__div64_32' 245 | __rem = __div64_32(&(n), __base); \ | ^~~~~~~~~~ ./include/linux/math64.h:91:22: note: in expansion of macro 'do_div' 91 | *remainder = do_div(dividend, divisor); | ^~~~~~ This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0404s from 1.0445s with R3400 @40MHz. The module's MIPS I machine code has also shrunk by 12 bytes or 3 instructions. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit d17af8b19d99c400a484427c88f973e6b1f842aa Author: Maciej W. Rozycki Date: Tue Apr 20 04:50:48 2021 +0200 MIPS: Avoid DIVU in `__div64_32' is result would be zero commit c1d337d45ec0a802299688e17d568c4e3a585895 upstream. We already check the high part of the divident against zero to avoid the costly DIVU instruction in that case, needed to reduce the high part of the divident, so we may well check against the divisor instead and set the high part of the quotient to zero right away. We need to treat the high part the divident in that case though as the remainder that would be calculated by the DIVU instruction we avoided. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0445s and 0.2619s from 1.0668s and 0.2629s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit d2abb95bb1a438c8bcf2a7d1249ba5b94fe1e950 Author: Maciej W. Rozycki Date: Tue Apr 20 04:50:40 2021 +0200 MIPS: Reinstate platform `__div64_32' handler commit c49f71f60754acbff37505e1d16ca796bf8a8140 upstream. Our current MIPS platform `__div64_32' handler is inactive, because it is incorrectly only enabled for 64-bit configurations, for which generic `do_div' code does not call it anyway. The handler is not suitable for being called from there though as it only calculates 32 bits of the quotient under the assumption the 64-bit divident has been suitably reduced. Code for such reduction used to be there, however it has been incorrectly removed with commit c21004cd5b4c ("MIPS: Rewrite to work with gcc 4.4.0."), which should have only updated an obsoleted constraint for an inline asm involving $hi and $lo register outputs, while possibly wiring the original MIPS variant of the `do_div' macro as `__div64_32' handler for the generic `do_div' implementation Correct the handler as follows then: - Revert most of the commit referred, however retaining the current formatting, except for the final two instructions of the inline asm sequence, which the original commit missed. Omit the original 64-bit parts though. - Rename the original `do_div' macro to `__div64_32'. Use the combined `x' constraint referring to the MD accumulator as a whole, replacing the original individual `h' and `l' constraints used for $hi and $lo registers respectively, of which `h' has been obsoleted with GCC 4.4. Update surrounding code accordingly. We have since removed support for GCC versions before 4.9, so no need for a special arrangement here; GCC has supported the `x' constraint since forever anyway, or at least going back to 1991. - Rename the `__base' local variable in `__div64_32' to `__radix' to avoid a conflict with a local variable in `do_div'. - Actually enable this code for 32-bit rather than 64-bit configurations by qualifying it with BITS_PER_LONG being 32 instead of 64. Include for this macro rather than as we don't need anything else. - Finally include last rather than first. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0668s and 0.2629s from 2.1529s and 0.5647s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. For a reference 64-bit `do_div' code where we have the DDIVU instruction available to do the whole calculation right away averages at 0.0660s for the latter CPU. Fixes: c21004cd5b4c ("MIPS: Rewrite to work with gcc 4.4.0.") Reported-by: Huacai Chen Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.30+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit cfddf6a685e3bbdba0c9976563810ecb118fa516 Author: Matthew Wilcox (Oracle) Date: Fri May 14 17:27:24 2021 -0700 mm: fix struct page layout on 32-bit systems commit 9ddb3c14afba8bc5950ed297f02d4ae05ff35cd1 upstream. 32-bit architectures which expect 8-byte alignment for 8-byte integers and need 64-bit DMA addresses (arm, mips, ppc) had their struct page inadvertently expanded in 2019. When the dma_addr_t was added, it forced the alignment of the union to 8 bytes, which inserted a 4 byte gap between 'flags' and the union. Fix this by storing the dma_addr_t in one or two adjacent unsigned longs. This restores the alignment to that of an unsigned long. We always store the low bits in the first word to prevent the PageTail bit from being inadvertently set on a big endian platform. If that happened, get_user_pages_fast() racing against a page which was freed and reallocated to the page_pool could dereference a bogus compound_head(), which would be hard to trace back to this cause. Link: https://lkml.kernel.org/r/20210510153211.1504886-1-willy@infradead.org Fixes: c25fff7171be ("mm: add dma_addr_t to struct page") Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Ilias Apalodimas Acked-by: Jesper Dangaard Brouer Acked-by: Vlastimil Babka Tested-by: Matteo Croce Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 89bd620798704a8805fc9db0d71d7f812cf5b3d2 Author: Lu Baolu Date: Sat Mar 20 10:54:12 2021 +0800 iommu/vt-d: Remove WO permissions on second-level paging entries commit eea53c5816889ee8b64544fa2e9311a81184ff9c upstream. When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. Suggested-by: Ashok Raj Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210320025415.641201-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0160f627929c8b8b5efcd513e12ca014a5a99e35 Author: Lu Baolu Date: Fri Jan 15 08:42:02 2021 +0800 iommu/vt-d: Preset Access/Dirty bits for IOVA over FL commit a8ce9ebbecdfda3322bbcece6b3b25888217f8e3 upstream. The Access/Dirty bits in the first level page table entry will be set whenever a page table entry was used for address translation or write permission was successfully translated. This is always true when using the first-level page table for kernel IOVA. Instead of wasting hardware cycles to update the certain bits, it's better to set them up at the beginning. Suggested-by: Ashok Raj Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210115004202.953965-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit a282b76166b13496967c70bd61ea8f03609d8a76 Author: Greg Kroah-Hartman Date: Mon May 17 11:54:48 2021 +0200 Revert "iommu/vt-d: Preset Access/Dirty bits for IOVA over FL" This reverts commit 416fa531c8160151090206a51b829b9218b804d9 which is commit a8ce9ebbecdfda3322bbcece6b3b25888217f8e3 upstream as it was backported incorrectly and is causing problems for some systems. Reported-by: Wolfgang Müller Reported-by: Charles Wright Reported-by: Christoph Biedl Cc: Ashok Raj Cc: Lu Baolu Cc: Joerg Roedel Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1f2d0beab5c9dc4e4f0e1b4b046679fd239db6a Author: Greg Kroah-Hartman Date: Mon May 17 11:54:37 2021 +0200 Revert "iommu/vt-d: Remove WO permissions on second-level paging entries" This reverts commit c848416cc05afc1589edba04fe00b85c2f797ee3 which is eea53c5816889ee8b64544fa2e9311a81184ff9c upstream. Another iommu patch was backported incorrectly, causing problems, so drop this as well for the moment. Reported-by: Wolfgang Müller Cc: Ashok Raj Cc: Lu Baolu Cc: Joerg Roedel Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 31f29749ee970c251b3a7e5b914108425940d089 Author: Sean Christopherson Date: Tue May 4 10:17:24 2021 -0700 KVM: VMX: Disable preemption when probing user return MSRs commit 5104d7ffcf24749939bea7fdb5378d186473f890 upstream. Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit. Fixes: 4be534102624 ("KVM: VMX: Initialize vmx->guest_msrs[] right after allocation") Cc: stable@vger.kernel.org Cc: Xiaoyao Li Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-6-seanjc@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 79abde761e05ea1cb5996d458c0d31f0d80813f1 Author: Sean Christopherson Date: Tue May 4 10:17:20 2021 -0700 KVM: VMX: Do not advertise RDPID if ENABLE_RDTSCP control is unsupported commit 8aec21c04caa2000f91cf8822ae0811e4b0c3971 upstream. Clear KVM's RDPID capability if the ENABLE_RDTSCP secondary exec control is unsupported. Despite being enumerated in a separate CPUID flag, RDPID is bundled under the same VMCS control as RDTSCP and will #UD in VMX non-root if ENABLE_RDTSCP is not enabled. Fixes: 41cd02c6f7f6 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-2-seanjc@google.com> Reviewed-by: Jim Mattson Reviewed-by: Reiji Watanabe Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c8bf64e3fb77cc19bad146fbe26651985b117194 Author: Vitaly Kuznetsov Date: Mon May 3 17:08:51 2021 +0200 KVM: nVMX: Always make an attempt to map eVMCS after migration commit f5c7e8425f18fdb9bdb7d13340651d7876890329 upstream. When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). Fixes: f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") Signed-off-by: Vitaly Kuznetsov Message-Id: <20210503150854.1144255-2-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2f86dd3d2bcfda3e14e8ee734e970dc05287d5fc Author: Sean Christopherson Date: Tue May 4 10:17:23 2021 -0700 KVM: x86: Move RDPID emulation intercept to its own enum commit 2183de4161b90bd3851ccd3910c87b2c9adfc6ed upstream. Add a dedicated intercept enum for RDPID instead of piggybacking RDTSCP. Unlike VMX's ENABLE_RDTSCP, RDPID is not bound to SVM's RDTSCP intercept. Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-5-seanjc@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit abbf8c99a9e12182c350e93cb808de4599a2f701 Author: Sean Christopherson Date: Tue May 4 10:17:21 2021 -0700 KVM: x86: Emulate RDPID only if RDTSCP is supported commit 85d0011264da24be08ae907d7f29983a597ca9b1 upstream. Do not advertise emulation support for RDPID if RDTSCP is unsupported. RDPID emulation subtly relies on MSR_TSC_AUX to exist in hardware, as both vmx_get_msr() and svm_get_msr() will return an error if the MSR is unsupported, i.e. ctxt->ops->get_msr() will fail and the emulator will inject a #UD. Note, RDPID emulation also relies on RDTSCP being enabled in the guest, but this is a KVM bug and will eventually be fixed. Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-3-seanjc@google.com> Reviewed-by: Jim Mattson Reviewed-by: Reiji Watanabe Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8a7027f011c5127d2c6e756425a831445f763f0c Author: Juergen Gross Date: Fri Apr 23 07:40:38 2021 +0200 xen/gntdev: fix gntdev_mmap() error exit path commit 970655aa9b42461f8394e4457307005bdeee14d9 upstream. Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") introduced an error in gntdev_mmap(): in case the call of mmu_interval_notifier_insert_locked() fails the exit path should not call mmu_interval_notifier_remove(), as this might result in NULL dereferences. One reason for failure is e.g. a signal pending for the running process. Fixes: d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") Cc: stable@vger.kernel.org Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Reviewed-by: Luca Fancellu Link: https://lore.kernel.org/r/20210423054038.26696-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 652c9689f58900bcae9585f3c38d6596700898f0 Author: Oliver Neukum Date: Mon Apr 26 11:26:22 2021 +0200 cdc-wdm: untangle a circular dependency between callback and softint commit 18abf874367456540846319574864e6ff32752e2 upstream. We have a cycle of callbacks scheduling works which submit URBs with those callbacks. This needs to be blocked, stopped and unblocked to untangle the circle. Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20210426092622.20433-1-oneukum@suse.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 12d16c24f35f98f9dc083035a9a6d8dcf59fe198 Author: Colin Ian King Date: Fri May 7 19:30:41 2021 +0100 iio: tsl2583: Fix division by a zero lux_val commit af0e1871d79cfbb91f732d2c6fa7558e45c31038 upstream. The lux_val returned from tsl2583_get_lux can potentially be zero, so check for this to avoid a division by zero and an overflowed gain_trim_val. Fixes clang scan-build warning: drivers/iio/light/tsl2583.c:345:40: warning: Either the condition 'lux_val<0' is redundant or there is division by zero at line 345. [zerodivcond] Fixes: ac4f6eee8fe8 ("staging: iio: TAOS tsl258x: Device driver") Signed-off-by: Colin Ian King Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e8c6852bdba2995a9ed278e793a50159f53fa879 Author: Dmitry Osipenko Date: Fri Apr 23 05:09:59 2021 +0300 iio: gyro: mpu3050: Fix reported temperature value commit f73c730774d88a14d7b60feee6d0e13570f99499 upstream. The raw temperature value is a 16-bit signed integer. The sign casting is missing in the code, which results in a wrong temperature reported by userspace tools, fix it. Cc: stable@vger.kernel.org Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Datasheet: https://www.cdiweb.com/datasheets/invensense/mpu-3000a.pdf Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Svyatoslav Ryhel # Asus TF201 Reported-by: Svyatoslav Ryhel Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Signed-off-by: Dmitry Osipenko Acked-by: Jean-Baptiste Maneyrol Link: https://lore.kernel.org/r/20210423020959.5023-1-digetx@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 70698dda4bcab9ff1b8df0c657130ef2894f25b1 Author: Sandeep Singh Date: Wed May 12 11:08:16 2021 +0300 xhci: Add reset resume quirk for AMD xhci controller. commit 3c128781d8da463761495aaf8898c9ecb4e71528 upstream. One of AMD xhci controller require reset on resume. Occasionally AMD xhci controller does not respond to Stop endpoint command. Once the issue happens controller goes into bad state and in that case controller needs to be reset. Cc: Signed-off-by: Sandeep Singh Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9d9526cc3c01866943fb8f5b71ca0a767d16b1c3 Author: Christophe JAILLET Date: Wed May 12 11:08:14 2021 +0300 xhci: Do not use GFP_KERNEL in (potentially) atomic context commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream. 'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") Cc: Signed-off-by: Christophe JAILLET Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ca043cc02a88b893c8f43da03ef94fd3e8a711d0 Author: Abhijeet Rao Date: Wed May 12 11:08:12 2021 +0300 xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCI commit b813511135e8b84fa741afdfbab4937919100bef upstream. In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@vger.kernel.org Signed-off-by: Abhijeet Rao Signed-off-by: Nikunj A. Dadhania Signed-off-by: Azhar Shaikh Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fa4b1363256d2b0456a68e969fd416804726ef45 Author: Andy Shevchenko Date: Wed May 5 01:23:37 2021 +0300 usb: typec: ucsi: Put fwnode in any case during ->probe() commit b9a0866a5bdf6a4643a52872ada6be6184c6f4f2 upstream. device_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: Heikki Krogerus Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210504222337.3151726-1-andy.shevchenko@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit e5366bea0277425e1868ba20eeb27c879d5a6e2d Author: Jack Pham Date: Mon May 3 00:46:11 2021 -0700 usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 1f4642b72be79757f050924a9b9673b6a02034bc upstream. commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Fixes: 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") Cc: stable@vger.kernel.org Reported-and-tested-by: Subbaraman Narayanamurthy Reviewed-by: Heikki Krogerus Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210503074611.30973-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 9bd96a2e77fd71b39bfa3f710f6001f94da57c51 Author: Wesley Cheng Date: Fri May 7 10:55:19 2021 -0700 usb: dwc3: gadget: Return success always for kick transfer in ep queue commit 18ffa988dbae69cc6e9949cddd9606f6fe533894 upstream. If an error is received when issuing a start or update transfer command, the error handler will stop all active requests (including the current USB request), and call dwc3_gadget_giveback() to notify function drivers of the requests which have been stopped. Avoid returning an error for kick transfer during EP queue, to remove duplicate cleanup operations on the request being queued. Fixes: 8d99087c2db8 ("usb: dwc3: gadget: Properly handle failed kick_transfer") cc: stable@vger.kernel.org Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 45f37f54e7c16e2981ba3a847c0778fd561888c3 Author: Jack Pham Date: Wed Apr 28 02:01:10 2021 -0700 usb: dwc3: gadget: Enable suspend events commit d1d90dd27254c44d087ad3f8b5b3e4fff0571f45 upstream. commit 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") introduced (nearly 5 years ago!) an interrupt handler for U3/L1-L2 suspend events. The problem is that these events aren't currently enabled in the DEVTEN register so the handler is never even invoked. Fix this simply by enabling the corresponding bit in dwc3_gadget_enable_irq() using the same revision check as found in the handler. Fixes: 72704f876f50 ("dwc3: gadget: Implement the suspend entry event handler") Acked-by: Felipe Balbi Signed-off-by: Jack Pham Cc: stable Link: https://lore.kernel.org/r/20210428090111.3370-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 9238492b9a8402d388c9fe370d3cbee838f97c3a Author: Chunfeng Yun Date: Wed May 12 10:07:38 2021 +0800 usb: core: hub: fix race condition about TRSMRCY of resume commit 975f94c7d6c306b833628baa9aec3f79db1eb3a1 upstream. This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: Reported-by: Tianping Fang Acked-by: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 45ad6b592e644c1c3c4d0858a891cf977c5a10b7 Author: Phil Elwell Date: Thu May 6 12:22:00 2021 +0100 usb: dwc2: Fix gadget DMA unmap direction commit 75a41ce46bae6cbe7d3bb2584eb844291d642874 upstream. The dwc2 gadget support maps and unmaps DMA buffers as necessary. When mapping and unmapping it uses the direction of the endpoint to select the direction of the DMA transfer, but this fails for Control OUT transfers because the unmap occurs after the endpoint direction has been reversed for the status phase. A possible solution would be to unmap the buffer before the direction is changed, but a safer, less invasive fix is to remember the buffer direction independently of the endpoint direction. Fixes: fe0b94abcdf6 ("usb: dwc2: gadget: manage ep0 state in software") Acked-by: Minas Harutyunyan Cc: stable Signed-off-by: Phil Elwell Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman commit 7ad9256b49a6240f5344cfb0a069a7c9dba99567 Author: Maximilian Luz Date: Wed May 12 11:08:15 2021 +0300 usb: xhci: Increase timeout for HC halt commit ca09b1bea63ab83f4cca3a2ae8bc4f597ec28851 upstream. On some devices (specifically the SC8180x based Surface Pro X with QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding the xhci-hcd driver at some point later does not exhibit this behavior. To work around this, double XHCI_MAX_HALT_USEC, which also resolves this issue. Cc: Signed-off-by: Maximilian Luz Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 42bb80ae01657b8201ea8b5fa6ac96e272429383 Author: Ferry Toth Date: Sun Apr 25 17:09:47 2021 +0200 usb: dwc3: pci: Enable usb2-gadget-lpm-disable for Intel Merrifield commit 04357fafea9c7ed34525eb9680c760245c3bb958 upstream. On Intel Merrifield LPM is causing host to reset port after a timeout. By disabling LPM entirely this is prevented. Fixes: 066c09593454 ("usb: dwc3: pci: Enable extcon driver for Intel Merrifield") Reviewed-by: Andy Shevchenko Signed-off-by: Ferry Toth Cc: stable Link: https://lore.kernel.org/r/20210425150947.5862-1-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman commit 95e3da5b53baae5a75567be9b0449953d08545e2 Author: Marcel Hamer Date: Tue Apr 27 14:21:18 2021 +0200 usb: dwc3: omap: improve extcon initialization commit e17b02d4970913233d543c79c9c66e72cac05bdd upstream. When extcon is used in combination with dwc3, it is assumed that the dwc3 registers are untouched and as such are only configured if VBUS is valid or ID is tied to ground. In case VBUS is not valid or ID is floating, the registers are not configured as such during driver initialization, causing a wrong default state during boot. If the registers are not in a default state, because they are for instance touched by a boot loader, this can cause for a kernel error. Signed-off-by: Marcel Hamer Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se Cc: stable Signed-off-by: Greg Kroah-Hartman commit 3a96437f6bf85fa64e933cc100445f9278cee1ff Author: Bart Van Assche Date: Thu May 13 10:15:29 2021 -0700 blk-mq: Swap two calls in blk_mq_exit_queue() [ Upstream commit 630ef623ed26c18a457cdc070cf24014e50129c2 ] If a tag set is shared across request queues (e.g. SCSI LUNs) then the block layer core keeps track of the number of active request queues in tags->active_queues. blk_mq_tag_busy() and blk_mq_tag_idle() update that atomic counter if the hctx flag BLK_MQ_F_TAG_QUEUE_SHARED is set. Make sure that blk_mq_exit_queue() calls blk_mq_tag_idle() before that flag is cleared by blk_mq_del_queue_tag_set(). Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Fixes: 0d2602ca30e4 ("blk-mq: improve support for shared tags maps") Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20210513171529.7977-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c9c1ed08c174c2fa88fe1badbb876a7317a8224f Author: Ming Lei Date: Fri May 14 10:20:52 2021 +0800 blk-mq: plug request for shared sbitmap [ Upstream commit 03f26d8f11403295de445b6e4e0e57ac57755791 ] In case of shared sbitmap, request won't be held in plug list any more sine commit 32bc15afed04 ("blk-mq: Facilitate a shared sbitmap per tagset"), this way makes request merge from flush plug list & batching submission not possible, so cause performance regression. Yanhui reports performance regression when running sequential IO test(libaio, 16 jobs, 8 depth for each job) in VM, and the VM disk is emulated with image stored on xfs/megaraid_sas. Fix the issue by recovering original behavior to allow to hold request in plug list. Cc: Yanhui Ma Cc: John Garry Cc: Bart Van Assche Cc: kashyap.desai@broadcom.com Fixes: 32bc15afed04 ("blk-mq: Facilitate a shared sbitmap per tagset") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210514022052.1047665-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cde4b55cfb24522dcbba80bbdb0c082303e76c43 Author: Sun Ke Date: Wed May 12 19:43:30 2021 +0800 nbd: Fix NULL pointer in flush_workqueue [ Upstream commit 79ebe9110fa458d58f1fceb078e2068d7ad37390 ] Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Sun Ke Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20210512114331.1233964-2-sunke32@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a9fc163514d209e038cc447590e1057a125367f7 Author: Chao Yu Date: Mon May 10 17:30:32 2021 +0800 f2fs: compress: fix to assign cc.cluster_idx correctly [ Upstream commit 8bfbfb0ddd706b1ce2e89259ecc45f192c0ec2bf ] In f2fs_destroy_compress_ctx(), after f2fs_destroy_compress_ctx(), cc.cluster_idx will be cleared w/ NULL_CLUSTER, f2fs_cluster_blocks() may check wrong cluster metadata, fix it. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5639b73fd3bc6fc8ca72e3a9ac15aacaabd7ebff Author: Chao Yu Date: Mon May 10 17:30:31 2021 +0800 f2fs: compress: fix race condition of overwrite vs truncate [ Upstream commit a949dc5f2c5cfe0c910b664650f45371254c0744 ] pos_fsstress testcase complains a panic as belew: ------------[ cut here ]------------ kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Fix this by avoiding referencing updated page. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 72b0f3077ebdc83336fb48f381cbd84eb04a017e Author: Chao Yu Date: Thu May 6 17:00:43 2021 +0800 f2fs: compress: fix to free compress page correctly [ Upstream commit a12cc5b423d4f36dc1a1ea3911e49cf9dff43898 ] In error path of f2fs_write_compressed_pages(), it needs to call f2fs_compress_free_page() to release temporary page. Fixes: 5e6bbde95982 ("f2fs: introduce mempool for {,de}compress intermediate page allocation") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 64f3410c7bfc389b1a58611d0799f4a36ce4b6b5 Author: Michal Kalderon Date: Thu May 6 10:08:19 2021 +0300 nvmet-rdma: Fix NULL deref when SEND is completed with error [ Upstream commit 8cc365f9559b86802afc0208389f5c8d46b4ad61 ] When running some traffic and taking down the link on peer, a retry counter exceeded error is received. This leads to nvmet_rdma_error_comp which tried accessing the cq_context to obtain the queue. The cq_context is no longer valid after the fix to use shared CQ mechanism and should be obtained similar to how it is obtained in other functions from the wc->qp. [ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12). [ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 905.839919] PGD 0 P4D 0 [ 905.842464] Oops: 0000 1 SMP NOPTI [ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000 [ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 905.961857] PKRU: 55555554 [ 906.010315] Call Trace: [ 906.012778] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] process_one_work+0x1a7/0x360 [ 906.026182] ? create_worker+0x1a0/0x1a0 [ 906.030123] worker_thread+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40 Fixes: ca0f1a8055be2 ("nvmet-rdma: use new shared CQ mechanism") Signed-off-by: Shai Malin Signed-off-by: Michal Kalderon Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c98ecfb1829642daa063a541d81dc8384fda924b Author: Chaitanya Kulkarni Date: Thu May 6 18:51:35 2021 -0700 nvmet: fix inline bio check for bdev-ns [ Upstream commit 608a969046e6e0567d05a166be66c77d2dd8220b ] When handling rw commands, for inline bio case we only consider transfer size. This works well when req->sg_cnt fits into the req->inline_bvec, but it will result in the warning in __bio_add_page() when req->sg_cnt > NVMET_MAX_INLINE_BVEC. Consider an I/O size 32768 and first page is not aligned to the page boundary, then I/O is split in following manner :- [ 2206.256140] nvmet: sg->length 3440 sg->offset 656 [ 2206.256144] nvmet: sg->length 4096 sg->offset 0 [ 2206.256148] nvmet: sg->length 4096 sg->offset 0 [ 2206.256152] nvmet: sg->length 4096 sg->offset 0 [ 2206.256155] nvmet: sg->length 4096 sg->offset 0 [ 2206.256159] nvmet: sg->length 4096 sg->offset 0 [ 2206.256163] nvmet: sg->length 4096 sg->offset 0 [ 2206.256166] nvmet: sg->length 4096 sg->offset 0 [ 2206.256170] nvmet: sg->length 656 sg->offset 0 Now the req->transfer_size == NVMET_MAX_INLINE_DATA_LEN i.e. 32768, but the req->sg_cnt is (9) > NVMET_MAX_INLINE_BIOVEC which is (8). This will result in the following warning message :- nvmet_bdev_execute_rw() bio_add_page() __bio_add_page() WARN_ON_ONCE(bio_full(bio, len)); This scenario is very hard to reproduce on the nvme-loop transport only with rw commands issued with the passthru IOCTL interface from the host application and the data buffer is allocated with the malloc() and not the posix_memalign(). Fixes: 73383adfad24 ("nvmet: don't split large I/Os unconditionally") Signed-off-by: Chaitanya Kulkarni Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f8ae879b776c28fb8fc47ae97c4ad45edac0be24 Author: Chaitanya Kulkarni Date: Mon Jan 11 20:26:16 2021 -0800 nvmet: add lba to sect conversion helpers [ Upstream commit 193fcf371f9e3705c14a0bf1d4bfc44af0f7c124 ] In this preparation patch, we add helpers to convert lbas to sectors & sectors to lba. This is needed to eliminate code duplication in the ZBD backend. Use these helpers in the block device backend. Signed-off-by: Chaitanya Kulkarni Reviewed-by: Damien Le Moal Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 54dbe2d2c1fcabf650c7a8b747601da355cd7f9f Author: Omar Sandoval Date: Mon May 10 17:05:35 2021 -0700 kyber: fix out of bounds access when preempted [ Upstream commit efed9a3337e341bd0989161b97453b52567bc59d ] __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. Fixes: a6088845c2bf ("block: kyber: make kyber more friendly with merging") Reported-by: Jakub Kicinski Signed-off-by: Omar Sandoval Link: https://lore.kernel.org/r/c7598605401a48d5cfeadebb678abd10af22b83f.1620691329.git.osandov@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e2381174daeae0ca35eddffef02dcc8de8c1ef8a Author: Christophe JAILLET Date: Sat May 8 09:23:09 2021 +0200 ACPI: scan: Fix a memory leak in an error handling path [ Upstream commit 0c8bd174f0fc131bc9dfab35cd8784f59045da87 ] If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. Fixes: eb50aaf960e3 ("ACPI: scan: Use unique number for instance_no") Signed-off-by: Christophe JAILLET Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a8dc16bbfe29c49987b77ed9240b1f54e5af539b Author: Christophe JAILLET Date: Tue May 4 22:26:29 2021 +0200 usb: musb: Fix an error message [ Upstream commit d9ff1096a840dddea3d5cfa2149ff7da9f499fb2 ] 'ret' is known to be 0 here. Initialize 'ret' with the expected error code before using it. Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/69f514dc7134e3c917cad208e73cc650cb9e2bd6.1620159879.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 550473900f80945cb1a48c6d252d9da41ddc48ec Author: Eddie James Date: Thu Apr 29 10:13:36 2021 -0500 hwmon: (occ) Fix poll rate limiting [ Upstream commit 5216dff22dc2bbbbe6f00335f9fd2879670e753b ] The poll rate limiter time was initialized at zero. This breaks the comparison in time_after if jiffies is large. Switch to storing the next update time rather than the previous time, and initialize the time when the device is probed. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20210429151336.18980-1-eajames@linux.ibm.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0becd19b211aab0a0b017fb5fe584431482eab0a Author: Christophe JAILLET Date: Thu May 6 22:39:10 2021 +0200 usb: fotg210-hcd: Fix an error message [ Upstream commit a60a34366e0d09ca002c966dd7c43a68c28b1f82 ] 'retval' is known to be -ENODEV here. This is a hard-coded default error code which is not useful in the error message. Moreover, another error message is printed at the end of the error handling path. The corresponding error code (-ENOMEM) is more informative. So remove simplify the first error message. While at it, also remove the useless initialization of 'retval'. Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/94531bcff98e46d4f9c20183a90b7f47f699126c.1620333419.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2c3b4375e1189acaed2d831df9b46057daa71b4f Author: Alexandru Ardelean Date: Wed Apr 14 11:49:55 2021 +0300 iio: hid-sensors: select IIO_TRIGGERED_BUFFER under HID_SENSOR_IIO_TRIGGER [ Upstream commit 7061803522ee7876df1ca18cdd1e1551f761352d ] During commit 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger"), the iio_triggered_buffer_{setup,cleanup}() functions got moved under the hid-sensor-trigger module. The above change works fine, if any of the sensors get built. However, when only the common hid-sensor-trigger module gets built (and none of the drivers), then the IIO_TRIGGERED_BUFFER symbol isn't selected/enforced. Previously, each driver would enforce/select the IIO_TRIGGERED_BUFFER symbol. With this change the HID_SENSOR_IIO_TRIGGER (for the hid-sensor-trigger module) will enforce that IIO_TRIGGERED_BUFFER gets selected. All HID sensor drivers select the HID_SENSOR_IIO_TRIGGER symbol. So, this change removes the IIO_TRIGGERED_BUFFER enforcement from each driver. Fixes: 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger") Reported-by: Thomas Deutschmann Cc: Srinivas Pandruvada Signed-off-by: Alexandru Ardelean Acked-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210414084955.260117-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 020fe6f80f4f1cc672687cdb59d438f8c031ef70 Author: Dinghao Liu Date: Mon Apr 12 13:32:02 2021 +0800 iio: proximity: pulsedlight: Fix rumtime PM imbalance on error [ Upstream commit a2fa9242e89f27696515699fe0f0296bf1ac1815 ] When lidar_write_control() fails, a pairing PM usage counter decrement is needed to keep the counter balanced. Fixes: 4ac4e086fd8c5 ("iio: pulsedlight-lidar-lite: add runtime PM") Signed-off-by: Dinghao Liu Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210412053204.4889-1-dinghao.liu@zju.edu.cn Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9db8ba3cac0523308d70ac23739374d5af5c77a6 Author: Dinghao Liu Date: Wed Apr 7 11:49:27 2021 +0800 iio: light: gp2ap002: Fix rumtime PM imbalance on error [ Upstream commit 8edb79af88efc6e49e735f9baf61d9f0748b881f ] When devm_request_threaded_irq() fails, we should decrease the runtime PM counter to keep the counter balanced. But when iio_device_register() fails, we need not to decrease it because we have already decreased it before. Signed-off-by: Dinghao Liu Reviewed-by: Linus Walleij Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Link: https://lore.kernel.org/r/20210407034927.16882-1-dinghao.liu@zju.edu.cn Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1ea775021282d90e1d08d696b7ab54aa75d688e5 Author: Jack Pham Date: Sat May 1 02:35:58 2021 -0700 usb: dwc3: gadget: Free gadget structure only after freeing endpoints [ Upstream commit bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139 ] As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device's removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown callback for dwc3") also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate "del" and "put" components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Reviewed-by: Peter Chen Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210501093558.7375-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 26c777470d576d427c1f8efccfd1bd86cdfec7f8 Author: Jiri Olsa Date: Sat May 8 22:50:20 2021 +0200 perf tools: Fix dynamic libbpf link [ Upstream commit ad1237c30d975535a669746496cbed136aa5a045 ] Justin reported broken build with LIBBPF_DYNAMIC=1. When linking libbpf dynamically we need to use perf's hashmap object, because it's not exported in libbpf.so (only in libbpf.a). Following build is now passing: $ make LIBBPF_DYNAMIC=1 BUILD: Doing 'make -j8' parallel build ... $ ldd perf | grep libbpf libbpf.so.0 => /lib64/libbpf.so.0 (0x00007fa7630db000) Fixes: eee19501926d ("perf tools: Grab a copy of libbpf's hashmap") Reported-by: Justin M. Forbes Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Ian Rogers Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210508205020.617984-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1d8d7e02f6d0a70793f1c450c008b72979252f5f Author: Zhen Lei Date: Sat May 8 10:19:13 2021 +0800 xen/unpopulated-alloc: fix error return code in fill_list() [ Upstream commit dbc03e81586fc33e4945263fd6e09e22eb4b980f ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: a4574f63edc6 ("mm/memremap_pages: convert to 'struct range'") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20210508021913.1727-1-thunder.leizhen@huawei.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 0581225726765a66ff3adc88d8f5df3e72cbd556 Author: Dan Williams Date: Mon Dec 14 19:07:21 2020 -0800 xen/unpopulated-alloc: consolidate pgmap manipulation [ Upstream commit 3a250629d7325f27b278dad1aaf44eab00090e76 ] Cleanup fill_list() to keep all the pgmap manipulations in a single location of the function. Update the exit unwind path accordingly. Link: http://lore.kernel.org/r/6186fa28-d123-12db-6171-a75cb6e615a5@oracle.com Link: https://lkml.kernel.org/r/160272253442.3136502.16683842453317773487.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Reported-by: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9eaa10be0c08d99e8d5e6063f670b2f6e1e3f02b Author: Vivek Goyal Date: Wed Apr 28 15:03:14 2021 -0400 dax: Wake up all waiters after invalidating dax entry [ Upstream commit 237388320deffde7c2d65ed8fc9eef670dc979b3 ] I am seeing missed wakeups which ultimately lead to a deadlock when I am using virtiofs with DAX enabled and running "make -j". I had to mount virtiofs as rootfs and also reduce to dax window size to 256M to reproduce the problem consistently. So here is the problem. put_unlocked_entry() wakes up waiters only if entry is not null as well as !dax_is_conflict(entry). But if I call multiple instances of invalidate_inode_pages2() in parallel, then I can run into a situation where there are waiters on this index but nobody will wake these waiters. invalidate_inode_pages2() invalidate_inode_pages2_range() invalidate_exceptional_entry2() dax_invalidate_mapping_entry_sync() __dax_invalidate_entry() { xas_lock_irq(&xas); entry = get_unlocked_entry(&xas, 0); ... ... dax_disassociate_entry(entry, mapping, trunc); xas_store(&xas, NULL); ... ... put_unlocked_entry(&xas, entry); xas_unlock_irq(&xas); } Say a fault in in progress and it has locked entry at offset say "0x1c". Now say three instances of invalidate_inode_pages2() are in progress (A, B, C) and they all try to invalidate entry at offset "0x1c". Given dax entry is locked, all tree instances A, B, C will wait in wait queue. When dax fault finishes, say A is woken up. It will store NULL entry at index "0x1c" and wake up B. When B comes along it will find "entry=0" at page offset 0x1c and it will call put_unlocked_entry(&xas, 0). And this means put_unlocked_entry() will not wake up next waiter, given the current code. And that means C continues to wait and is not woken up. This patch fixes the issue by waking up all waiters when a dax entry has been invalidated. This seems to fix the deadlock I am facing and I can make forward progress. Reported-by: Sergio Lopez Fixes: ac401cc78242 ("dax: New fault locking") Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-4-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit e9e70b78e163f768aee90f621566a5b7055fce17 Author: Vivek Goyal Date: Wed Apr 28 15:03:13 2021 -0400 dax: Add a wakeup mode parameter to put_unlocked_entry() [ Upstream commit 4c3d043d271d4d629aa2328796cdfc96b37d3b3c ] As of now put_unlocked_entry() always wakes up next waiter. In next patches we want to wake up all waiters at one callsite. Hence, add a parameter to the function. This patch does not introduce any change of behavior. Reviewed-by: Greg Kurz Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-3-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit b93d3410e789b027dd6845362a8738d58382194a Author: Vivek Goyal Date: Wed Apr 28 15:03:12 2021 -0400 dax: Add an enum for specifying dax wakup mode [ Upstream commit 698ab77aebffe08b312fbcdddeb0e8bd08b78717 ] Dan mentioned that he is not very fond of passing around a boolean true/false to specify if only next waiter should be woken up or all waiters should be woken up. He instead prefers that we introduce an enum and make it very explicity at the callsite itself. Easier to read code. This patch should not introduce any change of behavior. Reviewed-by: Greg Kurz Reviewed-by: Jan Kara Suggested-by: Dan Williams Signed-off-by: Vivek Goyal Link: https://lore.kernel.org/r/20210428190314.1865312-2-vgoyal@redhat.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit b9c663dc9a83c655853bc56c99fc747fe1c72e98 Author: Thomas Gleixner Date: Thu May 6 15:21:37 2021 +0200 KVM: x86: Prevent deadlock against tk_core.seq [ Upstream commit 3f804f6d201ca93adf4c3df04d1bfd152c1129d6 ] syzbot reported a possible deadlock in pvclock_gtod_notify(): CPU 0 CPU 1 write_seqcount_begin(&tk_core.seq); pvclock_gtod_notify() spin_lock(&pool->lock); queue_work(..., &pvclock_gtod_work) ktime_get() spin_lock(&pool->lock); do { seq = read_seqcount_begin(tk_core.seq) ... } while (read_seqcount_retry(&tk_core.seq, seq); While this is unlikely to happen, it's possible. Delegate queue_work() to irq_work() which postpones it until the tk_core.seq write held region is left and interrupts are reenabled. Fixes: 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes") Reported-by: syzbot+6beae4000559d41d80f8@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Message-Id: <87h7jgm1zy.ffs@nanos.tec.linutronix.de> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 8aa7227a5d9b4ff8ea42bf653fbf8c08d7744e9d Author: Thomas Gleixner Date: Wed May 5 23:48:17 2021 +0200 KVM: x86: Cancel pvclock_gtod_work on module removal [ Upstream commit 594b27e677b35f9734b1969d175ebc6146741109 ] Nothing prevents the following: pvclock_gtod_notify() queue_work(system_long_wq, &pvclock_gtod_work); ... remove_module(kvm); ... work_queue_run() pvclock_gtod_work() <- UAF Ditto for any other operation on that workqueue list head which touches pvclock_gtod_work after module removal. Cancel the work in kvm_arch_exit() to prevent that. Fixes: 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes") Signed-off-by: Thomas Gleixner Message-Id: <87czu4onry.ffs@nanos.tec.linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 1fe269372244a1a9b7f7a3f7de929d744e7207f8 Author: Kuogee Hsieh Date: Wed Apr 21 16:37:36 2021 -0700 drm/msm/dp: initialize audio_comp when audio starts [ Upstream commit f2f46b878777e0d3f885c7ddad48f477b4dea247 ] Initialize audio_comp when audio starts and wait for audio_comp at dp_display_disable(). This will take care of both dongle unplugged and display off (suspend) cases. Changes in v2: -- add dp_display_signal_audio_start() Changes in v3: -- restore dp_display_handle_plugged_change() at dp_hpd_unplug_handle(). Changes in v4: -- none Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Fixes: c703d5789590 ("drm/msm/dp: trigger unplug event in msm_dp_display_disable") Link: https://lore.kernel.org/r/1619048258-8717-3-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 2e0ce36d0bf695477f7ce42a0bb3ab09aee7c89c Author: Wanpeng Li Date: Wed Apr 28 19:08:02 2021 +0800 KVM: LAPIC: Accurately guarantee busy wait for timer to expire when using hv_timer [ Upstream commit d981dd15498b188636ec5a7d8ad485e650f63d8d ] Commit ee66e453db13d (KVM: lapic: Busy wait for timer to expire when using hv_timer) tries to set ktime->expired_tscdeadline by checking ktime->hv_timer_in_use since lapic timer oneshot/periodic modes which are emulated by vmx preemption timer also get advanced, they leverage the same vmx preemption timer logic with tsc-deadline mode. However, ktime->hv_timer_in_use is cleared before apic_timer_expired() handling, let's delay this clearing in preemption-disabled region. Fixes: ee66e453db13d ("KVM: lapic: Busy wait for timer to expire when using hv_timer") Reviewed-by: Sean Christopherson Signed-off-by: Wanpeng Li Message-Id: <1619608082-4187-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ce7639252357be0e1f93a77abd6d81f39c800a91 Author: Benjamin Segall Date: Thu Apr 29 16:22:34 2021 +0000 kvm: exit halt polling on need_resched() as well commit 262de4102c7bb8e59f26a967a8ffe8cce85cc537 upstream. single_task_running() is usually more general than need_resched() but CFS_BANDWIDTH throttling will use resched_task() when there is just one task to get the task to block. This was causing long-need_resched warnings and was likely allowing VMs to overrun their quota when halt polling. Signed-off-by: Ben Segall Signed-off-by: Venkatesh Srinivas Message-Id: <20210429162233.116849-1-venkateshs@chromium.org> Signed-off-by: Paolo Bonzini Cc: stable@vger.kernel.org Reviewed-by: Jim Mattson Signed-off-by: Greg Kroah-Hartman commit 970c978d0591866249607255924fe4a8542684b8 Author: Ville Syrjälä Date: Wed Apr 21 18:33:58 2021 +0300 drm/i915: Avoid div-by-zero on gen2 commit 4819d16d91145966ce03818a95169df1fd56b299 upstream. Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size() can in fact return <4KiB, which leads to div-by-zero here. Avoid that. Not sure i915_gem_object_get_tile_row_size() is entirely sane anyway since it doesn't account for the different tile layouts on i8xx/i915... I'm not able to hit this before commit 6846895fde05 ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks like I also need to run recent version of Mesa. With those in place xonotic trips on this quite easily on my 85x. Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-2-ville.syrjala@linux.intel.com (cherry picked from commit ed52c62d386f764194e0184fdb905d5f24194cae) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 86cd6072157c3ac6ce8eb3376e19c99b20ecb6b6 Author: David Ward Date: Mon May 10 05:30:39 2021 -0400 drm/amd/display: Initialize attribute for hdcp_srm sysfs file commit fe1c97d008f86f672f0e9265f180c22451ca3b9f upstream. It is stored in dynamically allocated memory, so sysfs_bin_attr_init() must be called to initialize it. (Note: "initialization" only sets the .attr.key member in this struct; it does not change the value of any other members.) Otherwise, when CONFIG_DEBUG_LOCK_ALLOC=y this message appears during boot: BUG: key ffff9248900cd148 has not been registered! Fixes: 9037246bb2da ("drm/amd/display: Add sysfs interface for set/get srm") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1586 Reported-by: Mikhail Gavrilov Signed-off-by: David Ward Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5a6fe45a3a7ff7627c699dbf833d8e256ba695ac Author: Kai-Heng Feng Date: Fri Apr 30 12:56:56 2021 +0800 drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are connected commit 227545b9a08c68778ddd89428f99c351fc9315ac upstream. Screen flickers rapidly when two 4K 60Hz monitors are in use. This issue doesn't happen when one monitor is 4K 60Hz (pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz). The issue is gone after setting "power_dpm_force_performance_level" to "high". Following the indication, we found that the issue occurs when sclk is too low. So resolve the issue by disabling sclk switching when there are two monitors requires high pixelclock (> 297MHz). v2: - Only apply the fix to Oland. Signed-off-by: Kai-Heng Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bccb7dd137adea29ba406a936445dccc078e36cb Author: Filipe Manana Date: Tue Apr 27 11:27:20 2021 +0100 btrfs: fix race leading to unpersisted data and metadata on fsync commit 626e9f41f7c281ba3e02843702f68471706aa6d9 upstream. When doing a fast fsync on a file, there is a race which can result in the fsync returning success to user space without logging the inode and without durably persisting new data. The following example shows one possible scenario for this: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/bar $ xfs_io -f -c "pwrite -S 0xab 0 1M" -c "fsync" /mnt/baz # Now we have: # file bar == inode 257 # file baz == inode 258 $ mv /mnt/baz /mnt/foo # Now we have: # file bar == inode 257 # file foo == inode 258 $ xfs_io -c "pwrite -S 0xcd 0 1M" /mnt/foo # fsync bar before foo, it is important to trigger the race. $ xfs_io -c "fsync" /mnt/bar $ xfs_io -c "fsync" /mnt/foo # After this: # inode 257, file bar, is empty # inode 258, file foo, has 1M filled with 0xcd # Replay the log: $ mount /dev/sdc /mnt # After this point file foo should have 1M filled with 0xcd and not 0xab The following steps explain how the race happens: 1) Before the first fsync of inode 258, when it has the "baz" name, its ->logged_trans is 0, ->last_sub_trans is 0 and ->last_log_commit is -1. The inode also has the full sync flag set; 2) After the first fsync, we set inode 258 ->logged_trans to 6, which is the generation of the current transaction, and set ->last_log_commit to 0, which is the current value of ->last_sub_trans (done at btrfs_log_inode()). The full sync flag is cleared from the inode during the fsync. The log sub transaction that was committed had an ID of 0 and when we synced the log, at btrfs_sync_log(), we incremented root->log_transid from 0 to 1; 3) During the rename: We update inode 258, through btrfs_update_inode(), and that causes its ->last_sub_trans to be set to 1 (the current log transaction ID), and ->last_log_commit remains with a value of 0. After updating inode 258, because we have previously logged the inode in the previous fsync, we log again the inode through the call to btrfs_log_new_name(). This results in updating the inode's ->last_log_commit from 0 to 1 (the current value of its ->last_sub_trans). The ->last_sub_trans of inode 257 is updated to 1, which is the ID of the next log transaction; 4) Then a buffered write against inode 258 is made. This leaves the value of ->last_sub_trans as 1 (the ID of the current log transaction, stored at root->log_transid); 5) Then an fsync against inode 257 (or any other inode other than 258), happens. This results in committing the log transaction with ID 1, which results in updating root->last_log_commit to 1 and bumping root->log_transid from 1 to 2; 6) Then an fsync against inode 258 starts. We flush delalloc and wait only for writeback to complete, since the full sync flag is not set in the inode's runtime flags - we do not wait for ordered extents to complete. Then, at btrfs_sync_file(), we call btrfs_inode_in_log() before the ordered extent completes. The call returns true: static inline bool btrfs_inode_in_log(...) { bool ret = false; spin_lock(&inode->lock); if (inode->logged_trans == generation && inode->last_sub_trans <= inode->last_log_commit && inode->last_sub_trans <= inode->root->last_log_commit) ret = true; spin_unlock(&inode->lock); return ret; } generation has a value of 6 (fs_info->generation), ->logged_trans also has a value of 6 (set when we logged the inode during the first fsync and when logging it during the rename), ->last_sub_trans has a value of 1, set during the rename (step 3), ->last_log_commit also has a value of 1 (set in step 3) and root->last_log_commit has a value of 1, which was set in step 5 when fsyncing inode 257. As a consequence we don't log the inode, any new extents and do not sync the log, resulting in a data loss if a power failure happens after the fsync and before the current transaction commits. Also, because we do not log the inode, after a power failure the mtime and ctime of the inode do not match those we had before. When the ordered extent completes before we call btrfs_inode_in_log(), then the call returns false and we log the inode and sync the log, since at the end of ordered extent completion we update the inode and set ->last_sub_trans to 2 (the value of root->log_transid) and ->last_log_commit to 1. This problem is found after removing the check for the emptiness of the inode's list of modified extents in the recent commit 209ecbb8585bf6 ("btrfs: remove stale comment and logic from btrfs_inode_in_log()"), added in the 5.13 merge window. However checking the emptiness of the list is not really the way to solve this problem, and was never intended to, because while that solves the problem for COW writes, the problem persists for NOCOW writes because in that case the list is always empty. In the case of NOCOW writes, even though we wait for the writeback to complete before returning from btrfs_sync_file(), we end up not logging the inode, which has a new mtime/ctime, and because we don't sync the log, we never issue disk barriers (send REQ_PREFLUSH to the device) since that only happens when we sync the log (when we write super blocks at btrfs_sync_log()). So effectively, for a NOCOW case, when we return from btrfs_sync_file() to user space, we are not guaranteeing that the data is durably persisted on disk. Also, while the example above uses a rename exchange to show how the problem happens, it is not the only way to trigger it. An alternative could be adding a new hard link to inode 258, since that also results in calling btrfs_log_new_name() and updating the inode in the log. An example reproducer using the addition of a hard link instead of a rename operation: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/bar $ xfs_io -f -c "pwrite -S 0xab 0 1M" -c "fsync" /mnt/foo $ ln /mnt/foo /mnt/foo_link $ xfs_io -c "pwrite -S 0xcd 0 1M" /mnt/foo $ xfs_io -c "fsync" /mnt/bar $ xfs_io -c "fsync" /mnt/foo # Replay the log: $ mount /dev/sdc /mnt # After this point file foo often has 1M filled with 0xab and not 0xcd The reasons leading to the final fsync of file foo, inode 258, not persisting the new data are the same as for the previous example with a rename operation. So fix by never skipping logging and log syncing when there are still any ordered extents in flight. To avoid making the conditional if statement that checks if logging an inode is needed harder to read, place all the logic into an helper function with separate if statements to make it more manageable and easier to read. A test case for fstests will follow soon. For NOCOW writes, the problem existed before commit b5e6c3e170b770 ("btrfs: always wait on ordered extents at fsync time"), introduced in kernel 4.19, then it went away with that commit since we started to always wait for ordered extent completion before logging. The problem came back again once the fast fsync path was changed again to avoid waiting for ordered extent completion, in commit 487781796d3022 ("btrfs: make fast fsyncs wait only for writeback"), added in kernel 5.10. However, for COW writes, the race only happens after the recent commit 209ecbb8585bf6 ("btrfs: remove stale comment and logic from btrfs_inode_in_log()"), introduced in the 5.13 merge window. For NOCOW writes, the bug existed before that commit. So tag 5.10+ as the release for stable backports. CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit d6d66dbd5adc41b7469bf7ae87e7f8cc4006a28f Author: Catalin Marinas Date: Fri May 14 10:50:01 2021 +0100 arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache() commit 588a513d34257fdde95a9f0df0202e31998e85c6 upstream. To ensure that instructions are observable in a new mapping, the arm64 set_pte_at() implementation cleans the D-cache and invalidates the I-cache to the PoU. As an optimisation, this is only done on executable mappings and the PG_dcache_clean page flag is set to avoid future cache maintenance on the same page. When two different processes map the same page (e.g. private executable file or shared mapping) there's a potential race on checking and setting PG_dcache_clean via set_pte_at() -> __sync_icache_dcache(). While on the fault paths the page is locked (PG_locked), mprotect() does not take the page lock. The result is that one process may see the PG_dcache_clean flag set but the I/D cache maintenance not yet performed. Avoid test_and_set_bit(PG_dcache_clean) in favour of separate test_bit() and set_bit(). In the rare event of a race, the cache maintenance is done twice. Signed-off-by: Catalin Marinas Cc: Cc: Will Deacon Cc: Steven Price Reviewed-by: Steven Price Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210514095001.13236-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit d3bab7cbadfb9abef9c5df2c54eac23dba4241a7 Author: Peter Collingbourne Date: Fri May 7 11:59:05 2021 -0700 arm64: mte: initialize RGSR_EL1.SEED in __cpu_setup commit 37a8024d265564eba680575df6421f19db21dfce upstream. A valid implementation choice for the ChooseRandomNonExcludedTag() pseudocode function used by IRG is to behave in the same way as with GCR_EL1.RRND=0. This would mean that RGSR_EL1.SEED is used as an LFSR which must have a non-zero value in order for IRG to properly produce pseudorandom numbers. However, RGSR_EL1 is reset to an UNKNOWN value on soft reset and thus may reset to 0. Therefore we must initialize RGSR_EL1.SEED to a non-zero value in order to ensure that IRG behaves as expected. Signed-off-by: Peter Collingbourne Fixes: 3b714d24ef17 ("arm64: mte: CPU feature detection and initial sysreg configuration") Cc: # 5.10 Link: https://linux-review.googlesource.com/id/I2b089b6c7d6f17ee37e2f0db7df5ad5bcc04526c Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210507185905.1745402-1-pcc@google.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 70748bba55658f4bf61ba1686fec9879ca6559c9 Author: Tejun Heo Date: Tue May 11 21:38:36 2021 -0400 blk-iocost: fix weight updates of inner active iocgs commit e9f4eee9a0023ba22db9560d4cc6ee63f933dae8 upstream. When the weight of an active iocg is updated, weight_updated() is called which in turn calls __propagate_weights() to update the active and inuse weights so that the effective hierarchical weights are update accordingly. The current implementation is incorrect for inner active nodes. For an active leaf iocg, inuse can be any value between 1 and active and the difference represents how much the iocg is donating. When weight is updated, as long as inuse is clamped between 1 and the new weight, we're alright and this is what __propagate_weights() currently implements. However, that's not how an active inner node's inuse is set. An inner node's inuse is solely determined by the ratio between the sums of inuse's and active's of its children - ie. they're results of propagating the leaves' active and inuse weights upwards. __propagate_weights() incorrectly applies the same clamping as for a leaf when an active inner node's weight is updated. Consider a hierarchy which looks like the following with saturating workloads in AA and BB. R / \ A B | | AA BB 1. For both A and B, active=100, inuse=100, hwa=0.5, hwi=0.5. 2. echo 200 > A/io.weight 3. __propagate_weights() update A's active to 200 and leave inuse at 100 as it's already between 1 and the new active, making A:active=200, A:inuse=100. As R's active_sum is updated along with A's active, A:hwa=2/3, B:hwa=1/3. However, because the inuses didn't change, the hwi's remain unchanged at 0.5. 4. The weight of A is now twice that of B but AA and BB still have the same hwi of 0.5 and thus are doing the same amount of IOs. Fix it by making __propgate_weights() always calculate the inuse of an active inner iocg based on the ratio of child_inuse_sum to child_active_sum. Signed-off-by: Tejun Heo Reported-by: Dan Schatzberg Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Cc: stable@vger.kernel.org # v5.4+ Link: https://lore.kernel.org/r/YJsxnLZV1MnBcqjj@slm.duckdns.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 014868616d48cfee2d966a8b16e2d5e120c8dab3 Author: Peter Xu Date: Fri May 14 17:27:04 2021 -0700 mm/hugetlb: fix F_SEAL_FUTURE_WRITE commit 22247efd822e6d263f3c8bd327f3f769aea9b1d9 upstream. Patch series "mm/hugetlb: Fix issues on file sealing and fork", v2. Hugh reported issue with F_SEAL_FUTURE_WRITE not applied correctly to hugetlbfs, which I can easily verify using the memfd_test program, which seems that the program is hardly run with hugetlbfs pages (as by default shmem). Meanwhile I found another probably even more severe issue on that hugetlb fork won't wr-protect child cow pages, so child can potentially write to parent private pages. Patch 2 addresses that. After this series applied, "memfd_test hugetlbfs" should start to pass. This patch (of 2): F_SEAL_FUTURE_WRITE is missing for hugetlb starting from the first day. There is a test program for that and it fails constantly. $ ./memfd_test hugetlbfs memfd-hugetlb: CREATE memfd-hugetlb: BASIC memfd-hugetlb: SEAL-WRITE memfd-hugetlb: SEAL-FUTURE-WRITE mmap() didn't fail as expected Aborted (core dumped) I think it's probably because no one is really running the hugetlbfs test. Fix it by checking FUTURE_WRITE also in hugetlbfs_file_mmap() as what we do in shmem_mmap(). Generalize a helper for that. Link: https://lkml.kernel.org/r/20210503234356.9097-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20210503234356.9097-2-peterx@redhat.com Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Peter Xu Reported-by: Hugh Dickins Reviewed-by: Mike Kravetz Cc: Joel Fernandes (Google) Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fe5c0a63ad22cc61498f2bc3164449a233e8c774 Author: Peter Collingbourne Date: Fri May 14 17:27:27 2021 -0700 kasan: fix unit tests with CONFIG_UBSAN_LOCAL_BOUNDS enabled commit f649dc0e0d7b509c75570ee403723660f5b72ec7 upstream. These tests deliberately access these arrays out of bounds, which will cause the dynamic local bounds checks inserted by CONFIG_UBSAN_LOCAL_BOUNDS to fail and panic the kernel. To avoid this problem, access the arrays via volatile pointers, which will prevent the compiler from being able to determine the array bounds. These accesses use volatile pointers to char (char *volatile) rather than the more conventional pointers to volatile char (volatile char *) because we want to prevent the compiler from making inferences about the pointer itself (i.e. its array bounds), not the data that it refers to. Link: https://lkml.kernel.org/r/20210507025915.1464056-1-pcc@google.com Link: https://linux-review.googlesource.com/id/I90b1713fbfa1bf68ff895aef099ea77b98a7c3b9 Signed-off-by: Peter Collingbourne Tested-by: Alexander Potapenko Reviewed-by: Andrey Konovalov Cc: Peter Collingbourne Cc: George Popescu Cc: Elena Petrova Cc: Evgenii Stepanov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 140cfd9980124aecb6c03ef2e69c72d0548744de Author: Axel Rasmussen Date: Fri May 14 17:27:19 2021 -0700 userfaultfd: release page in error path to avoid BUG_ON commit 7ed9d238c7dbb1fdb63ad96a6184985151b0171c upstream. Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning. Link: https://lkml.kernel.org/r/20210428230858.348400-1-axelrasmussen@google.com Fixes: cb658a453b93 ("userfaultfd: shmem: avoid leaking blocks and used blocks in UFFDIO_COPY") Signed-off-by: Axel Rasmussen Reported-by: Hugh Dickins Acked-by: Hugh Dickins Reviewed-by: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2ed1d90162a0c0683ecbe0c4802187fa22d641c3 Author: Phillip Lougher Date: Fri May 14 17:27:16 2021 -0700 squashfs: fix divide error in calculate_skip() commit d6e621de1fceb3b098ebf435ef7ea91ec4838a1a upstream. Sysbot has reported a "divide error" which has been identified as being caused by a corrupted file_size value within the file inode. This value has been corrupted to a much larger value than expected. Calculate_skip() is passed i_size_read(inode) >> msblk->block_log. Due to the file_size value corruption this overflows the int argument/variable in that function, leading to the divide error. This patch changes the function to use u64. This will accommodate any unexpectedly large values due to corruption. The value returned from calculate_skip() is clamped to be never more than SQUASHFS_CACHED_BLKS - 1, or 7. So file_size corruption does not lead to an unexpectedly large return result here. Link: https://lkml.kernel.org/r/20210507152618.9447-1-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: Reported-by: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit adbd8a2a8cc05d9e501f93e5c95c59307874cc99 Author: Jouni Roivas Date: Fri May 14 17:27:33 2021 -0700 hfsplus: prevent corruption in shrinking truncate commit c3187cf32216313fb316084efac4dab3a8459b1d upstream. I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check. Link: https://lkml.kernel.org/r/20210429165139.3082828-1-jouni.roivas@tuxera.com Fixes: 31651c607151f ("hfsplus: avoid deadlock on file truncation") Signed-off-by: Jouni Roivas Reviewed-by: Anton Altaparmakov Cc: Anatoly Trosinenko Cc: Viacheslav Dubeyko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d2e3590ca39ccfd8a5a46d8c7f095cb6c7b9ae92 Author: Michael Ellerman Date: Thu May 6 14:49:59 2021 +1000 powerpc/64s: Fix crashes when toggling entry flush barrier commit aec86b052df6541cc97c5fca44e5934cbea4963b upstream. The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210506044959.1298123-2-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 51570beeb448c8db24dc6588202dcabc6b259d1b Author: Michael Ellerman Date: Thu May 6 14:49:58 2021 +1000 powerpc/64s: Fix crashes when toggling stf barrier commit 8ec7791bae1327b1c279c5cd6e929c3b12daaf0a upstream. The STF (store-to-load forwarding) barrier mitigation can be enabled/disabled at runtime via a debugfs file (stf_barrier), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: User access of kernel address (c00000003fff5af0) - exploit attempt? (uid: 0) segfault (11) at c00000003fff5af0 nip 7fff8ad12198 lr 7fff8ad121f8 code 1 code: 40820128 e93c00d0 e9290058 7c292840 40810058 38600000 4bfd9a81 e8410018 code: 2c030006 41810154 3860ffb6 e9210098 7d295279 39400000 40820a3c Shows that we returned to userspace without restoring the user r13 value, due to executing the partially patched STF exit code. Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. Fixes: a048a07d7f45 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit") Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210506044959.1298123-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit cb3e286f22ff369d656b2d1f93508216af32ee9e Author: Vladimir Isaev Date: Tue Apr 27 15:13:54 2021 +0300 ARC: mm: Use max_high_pfn as a HIGHMEM zone border commit 1d5e4640e5df15252398c1b621f6bd432f2d7f17 upstream. Commit 4af22ded0ecf ("arc: fix memory initialization for systems with two memory banks") fixed highmem, but for the PAE case it causes bug messages: | BUG: Bad page state in process swapper pfn:80000 | page:(ptrval) refcount:0 mapcount:1 mapping:00000000 index:0x0 pfn:0x80000 flags: 0x0() | raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 | raw: 00000000 | page dumped because: nonzero mapcount | Modules linked in: | CPU: 0 PID: 0 Comm: swapper Not tainted 5.12.0-rc5-00003-g1e43c377a79f #1 This is because the fix expects highmem to be always less than lowmem and uses min_low_pfn as an upper zone border for highmem. max_high_pfn should be ok for both highmem and highmem+PAE cases. Fixes: 4af22ded0ecf ("arc: fix memory initialization for systems with two memory banks") Signed-off-by: Vladimir Isaev Cc: Mike Rapoport Cc: stable@vger.kernel.org #5.8 onwards Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 969de0f6599e2c6fe1d39aaabaead865a76fc0b7 Author: Vladimir Isaev Date: Tue Apr 27 15:12:37 2021 +0300 ARC: mm: PAE: use 40-bit physical page mask commit c5f756d8c6265ebb1736a7787231f010a3b782e5 upstream. 32-bit PAGE_MASK can not be used as a mask for physical addresses when PAE is enabled. PAGE_MASK_PHYS must be used for physical addresses instead of PAGE_MASK. Without this, init gets SIGSEGV if pte_modify was called: | potentially unexpected fatal signal 11. | Path: /bin/busybox | CPU: 0 PID: 1 Comm: init Not tainted 5.12.0-rc5-00003-g1e43c377a79f-dirty | Insn could not be fetched | @No matching VMA found | ECR: 0x00040000 EFA: 0x00000000 ERET: 0x00000000 | STAT: 0x80080082 [IE U ] BTA: 0x00000000 | SP: 0x5f9ffe44 FP: 0x00000000 BLK: 0xaf3d4 | LPS: 0x000d093e LPE: 0x000d0950 LPC: 0x00000000 | r00: 0x00000002 r01: 0x5f9fff14 r02: 0x5f9fff20 | ... | Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Vladimir Isaev Reported-by: kernel test robot Cc: Vineet Gupta Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit af9e5364c617d25f34d11c90f6bc7e8f16c63804 Author: Vineet Gupta Date: Fri Apr 23 12:16:25 2021 -0700 ARC: entry: fix off-by-one error in syscall number validation commit 3433adc8bd09fc9f29b8baddf33b4ecd1ecd2cdc upstream. We have NR_syscall syscalls from [0 .. NR_syscall-1]. However the check for invalid syscall number is "> NR_syscall" as opposed to >=. This off-by-one error erronesously allows "NR_syscall" to be treated as valid syscall causeing out-of-bounds access into syscall-call table ensuing a crash (holes within syscall table have a invalid-entry handler but this is beyond the array implementing the table). This problem showed up on v5.6 kernel when testing glibc 2.33 (v5.10 kernel capable, includng faccessat2 syscall 439). The v5.6 kernel has NR_syscalls=439 (0 to 438). Due to the bug, 439 passed by glibc was not handled as -ENOSYS but processed leading to a crash. Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/48 Reported-by: Shahab Vahedi Cc: Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 23ecfe7f2c1f399eda6233809f9b8f550f7c7c38 Author: Chao Yu Date: Tue Nov 10 09:24:36 2020 +0800 f2fs: avoid unneeded data copy in f2fs_ioc_move_range() [ Upstream commit 3a1b9eaf727b4ab84ebf059e09c38fc6a53e5614 ] Fields in struct f2fs_move_range won't change in f2fs_ioc_move_range(), let's avoid copying this structure's data to userspace. Signed-off-by: Chao Yu Reviewed-by: Eric Biggers Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 758fd227ed84cb208a5e9eec9ad9f17e87e2d0f1 Author: Paolo Abeni Date: Thu May 6 17:16:38 2021 -0700 mptcp: fix splat when closing unaccepted socket [ Upstream commit 578c18eff1627d6a911f08f4cf351eca41fdcc7d ] If userspace exits before calling accept() on a listener that had at least one new connection ready, we get: Attempt to release TCP socket in state 8 This happens because the mptcp socket gets cloned when the TCP connection is ready, but the socket is never exposed to userspace. The client additionally sends a DATA_FIN, which brings connection into CLOSE_WAIT state. This in turn prevents the orphan+state reset fixup in mptcp_sock_destruct() from doing its job. Fixes: 3721b9b64676b ("mptcp: Track received DATA_FIN sequence number and add related helpers") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/185 Tested-by: Florian Westphal Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20210507001638.225468-1-mathew.j.martineau@linux.intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8cf51a36da2c3e21f72c5de171fc778f187b807 Author: Mateusz Palczewski Date: Tue Apr 13 14:43:07 2021 +0000 i40e: Fix PHY type identifiers for 2.5G and 5G adapters [ Upstream commit 15395ec4685bd45a43d1b54b8fd9846b87e2c621 ] Unlike other supported adapters, 2.5G and 5G use different PHY type identifiers for reading/writing PHY settings and for reading link status. This commit introduces separate PHY identifiers for these two operation types. Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards") Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Reviewed-by: Aleksandr Loktionov Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 06ef93b776f7fc81d706b19e984f8a4e1f50e80f Author: Jaroslaw Gawin Date: Tue Apr 13 14:19:40 2021 +0000 i40e: fix the restart auto-negotiation after FEC modified [ Upstream commit 61343e6da7810de81d6b826698946ae4f9070819 ] When FEC mode was changed the link didn't know it because the link was not reset and new parameters were not negotiated. Set a flag 'I40E_AQ_PHY_ENABLE_ATOMIC_LINK' in 'abilities' to restart the link and make it run with the new settings. Fixes: 1d96340196f1 ("i40e: Add support FEC configuration for Fortville 25G") Signed-off-by: Jaroslaw Gawin Signed-off-by: Mateusz Palczewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 829a713450b8fb127cbabfc1244c1d8179ec5107 Author: Yunjian Wang Date: Mon Apr 12 22:41:18 2021 +0800 i40e: Fix use-after-free in i40e_client_subtask() [ Upstream commit 38318f23a7ef86a8b1862e5e8078c4de121960c3 ] Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") Fixes: 7b0b1a6d0ac9 ("i40e: Disable iWARP VSI PETCP_ENA flag on netdev down events") Signed-off-by: Yunjian Wang Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2692bf13e646b06343b8f7b48536a7270757f77e Author: Magnus Karlsson Date: Mon Apr 26 13:14:01 2021 +0200 i40e: fix broken XDP support [ Upstream commit ae4393dfd472b194c90d75d2123105fb5ed59b04 ] Commit 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") broke XDP support in the i40e driver. That commit was fixing a sparse error in the code by introducing a new variable xdp_res instead of overloading this into the skb pointer. The problem is that the code later uses the skb pointer in if statements and these where not extended to also test for the new xdp_res variable. Fix this by adding the correct tests for xdp_res in these places. The skb pointer was used to store the result of the XDP program by overloading the results in the error pointer ERR_PTR(-result). Therefore, the allocation failure test that used to only test for !skb now need to be extended to also consider !xdp_res. i40e_cleanup_headers() had a check that based on the skb value being an error pointer, i.e. a result from the XDP program != XDP_PASS, and if so start to process a new packet immediately, instead of populating skb fields and sending the skb to the stack. This check is not needed anymore, since we have added an explicit test for xdp_res being set and if so just do continue to pick the next packet from the NIC. Fixes: 12738ac4754e ("i40e: Fix sparse errors in i40e_txrx.c") Acked-by: Jesper Dangaard Brouer Tested-by: Jesper Dangaard Brouer Reported-by: Jesper Dangaard Brouer Reviewed-by: Maciej Fijalkowski Signed-off-by: Magnus Karlsson Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7 Author: Eric Dumazet Date: Thu May 6 05:53:23 2021 -0700 netfilter: nftables: avoid overflows in nft_hash_buckets() [ Upstream commit a54754ec9891830ba548e2010c889e3c8146e449 ] Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 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+0x2d/0x70 arch/x86/entry/common.c:46 Fixes: 0ed6389c483d ("netfilter: nf_tables: rename set implementations") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f665dedeedc93089fd5cf3c9405fdfe5f72502ad Author: David Hildenbrand Date: Thu May 6 18:05:16 2021 -0700 kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources [ Upstream commit 3c9c797534364593b73ba6ab060a014af8934721 ] It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. IORESOURCE_SYSTEM_RAM is defined as IORESOURCE_MEM | IORESOURCE_SYSRAM and just a special type of IORESOURCE_MEM. The function walk_mem_res() only considers the first level and is used in arch/x86/mm/ioremap.c:__ioremap_check_mem() only. We currently fail to identify System RAM added by dax/kmem and virtio-mem as "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such "normal RAM" in __ioremap_caller(). Let's find all IORESOURCE_MEM | IORESOURCE_BUSY resources, making the function behave similar to walk_system_ram_res(). Link: https://lkml.kernel.org/r/20210325115326.7826-3-david@redhat.com Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: David Hildenbrand Reviewed-by: Dan Williams Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1ec19325527112c6e99ded2e83beda996d8ebd60 Author: David Hildenbrand Date: Thu May 6 18:05:12 2021 -0700 kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources [ Upstream commit 97f61c8f44ec9020708b97a51188170add4f3084 ] Patch series "kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree", v2. Playing with kdump+virtio-mem I noticed that kexec_file_load() does not consider System RAM added via dax/kmem and virtio-mem when preparing the elf header for kdump. Looking into the details, the logic used in walk_system_ram_res() and walk_mem_res() seems to be outdated. walk_system_ram_range() already does the right thing, let's change walk_system_ram_res() and walk_mem_res(), and clean up. Loading a kdump kernel via "kexec -p -s" ... will result in the kdump kernel to also dump dax/kmem and virtio-mem added System RAM now. Note: kexec-tools on x86-64 also have to be updated to consider this memory in the kexec_load() case when processing /proc/iomem. This patch (of 3): It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. We have two users of walk_system_ram_res(), which currently only consideres the first level: a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip IORESOURCE_SYSRAM_DRIVER_MANAGED resources via locate_mem_hole_callback(), so even after this change, we won't be placing kexec images onto dax/kmem and virtio-mem added memory. No change. b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently not adding relevant ranges to the crash elf header, resulting in them not getting dumped via kdump. This change fixes loading a crashkernel via kexec_file_load() and including dax/kmem and virtio-mem added System RAM in the crashdump on x86-64. Note that e.g,, arm64 relies on memblock data and, therefore, always considers all added System RAM already. Let's find all IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY resources, making the function behave like walk_system_ram_range(). Link: https://lkml.kernel.org/r/20210325115326.7826-1-david@redhat.com Link: https://lkml.kernel.org/r/20210325115326.7826-2-david@redhat.com Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: David Hildenbrand Reviewed-by: Dan Williams Acked-by: Baoquan He Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Hansen Cc: Keith Busch Cc: Michal Hocko Cc: Qian Cai Cc: Oscar Salvador Cc: Eric Biederman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Tom Lendacky Cc: Brijesh Singh Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0886bb143cbbc8eafe1bb7598f90de14a3cb7ac2 Author: Jia-Ju Bai Date: Thu May 6 18:04:38 2021 -0700 kernel: kexec_file: fix error return code of kexec_calculate_store_digests() [ Upstream commit 31d82c2c787d5cf65fedd35ebbc0c1bd95c1a679 ] When vzalloc() returns NULL to sha_regions, no error return code of kexec_calculate_store_digests() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Link: https://lkml.kernel.org/r/20210309083904.24321-1-baijiaju1990@gmail.com Fixes: a43cac0d9dc2 ("kexec: split kexec_file syscall code to kexec_file.c") Signed-off-by: Jia-Ju Bai Reported-by: TOTE Robot Acked-by: Baoquan He Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d43be02fc40b87b88426251e62f02b3bf55c99ee Author: Colin Ian King Date: Thu May 6 18:02:10 2021 -0700 fs/proc/generic.c: fix incorrect pde_is_permanent check [ Upstream commit f4bf74d82915708208bc9d0c9bd3f769f56bfbec ] Currently the pde_is_permanent() check is being run on root multiple times rather than on the next proc directory entry. This looks like a copy-paste error. Fix this by replacing root with next. Addresses-Coverity: ("Copy-paste error") Link: https://lkml.kernel.org/r/20210318122633.14222-1-colin.king@canonical.com Fixes: d919b33dafb3 ("proc: faster open/read/close with "permanent" files") Signed-off-by: Colin Ian King Acked-by: Christian Brauner Reviewed-by: Alexey Dobriyan Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f89b408d506e99583de2c56f32574b4c31cfb343 Author: Odin Ugedal Date: Sat May 1 16:19:50 2021 +0200 sched/fair: Fix unfairness caused by missing load decay [ Upstream commit 0258bdfaff5bd13c4d2383150b7097aecd6b6d82 ] This fixes an issue where old load on a cfs_rq is not properly decayed, resulting in strange behavior where fairness can decrease drastically. Real workloads with equally weighted control groups have ended up getting a respective 99% and 1%(!!) of cpu time. When an idle task is attached to a cfs_rq by attaching a pid to a cgroup, the old load of the task is attached to the new cfs_rq and sched_entity by attach_entity_cfs_rq. If the task is then moved to another cpu (and therefore cfs_rq) before being enqueued/woken up, the load will be moved to cfs_rq->removed from the sched_entity. Such a move will happen when enforcing a cpuset on the task (eg. via a cgroup) that force it to move. The load will however not be removed from the task_group itself, making it look like there is a constant load on that cfs_rq. This causes the vruntime of tasks on other sibling cfs_rq's to increase faster than they are supposed to; causing severe fairness issues. If no other task is started on the given cfs_rq, and due to the cpuset it would not happen, this load would never be properly unloaded. With this patch the load will be properly removed inside update_blocked_averages. This also applies to tasks moved to the fair scheduling class and moved to another cpu, and this path will also fix that. For fork, the entity is queued right away, so this problem does not affect that. This applies to cases where the new process is the first in the cfs_rq, issue introduced 3d30544f0212 ("sched/fair: Apply more PELT fixes"), and when there has previously been load on the cgroup but the cgroup was removed from the leaflist due to having null PELT load, indroduced in 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path"). For a simple cgroup hierarchy (as seen below) with two equally weighted groups, that in theory should get 50/50 of cpu time each, it often leads to a load of 60/40 or 70/30. parent/ cg-1/ cpu.weight: 100 cpuset.cpus: 1 cg-2/ cpu.weight: 100 cpuset.cpus: 1 If the hierarchy is deeper (as seen below), while keeping cg-1 and cg-2 equally weighted, they should still get a 50/50 balance of cpu time. This however sometimes results in a balance of 10/90 or 1/99(!!) between the task groups. $ ps u -C stress USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 18568 1.1 0.0 3684 100 pts/12 R+ 13:36 0:00 stress --cpu 1 root 18580 99.3 0.0 3684 100 pts/12 R+ 13:36 0:09 stress --cpu 1 parent/ cg-1/ cpu.weight: 100 sub-group/ cpu.weight: 1 cpuset.cpus: 1 cg-2/ cpu.weight: 100 sub-group/ cpu.weight: 10000 cpuset.cpus: 1 This can be reproduced by attaching an idle process to a cgroup and moving it to a given cpuset before it wakes up. The issue is evident in many (if not most) container runtimes, and has been reproduced with both crun and runc (and therefore docker and all its "derivatives"), and with both cgroup v1 and v2. Fixes: 3d30544f0212 ("sched/fair: Apply more PELT fixes") Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path") Signed-off-by: Odin Ugedal Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210501141950.23622-2-odin@uged.al Signed-off-by: Sasha Levin commit f7347c85490b92dd144fa1fba9e1eca501656ab3 Author: Quentin Perret Date: Fri Apr 30 15:14:12 2021 +0000 sched: Fix out-of-bound access in uclamp [ Upstream commit 6d2f8909a5fabb73fe2a63918117943986c39b6c ] Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. Fixes: 69842cba9ace ("sched/uclamp: Add CPU's clamp buckets refcounting") Suggested-by: Qais Yousef Signed-off-by: Quentin Perret Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Reviewed-by: Dietmar Eggemann Link: https://lkml.kernel.org/r/20210430151412.160913-1-qperret@google.com Signed-off-by: Sasha Levin commit 26359d362c93bdca3038f7f70d28d5ed46222a03 Author: Marc Kleine-Budde Date: Wed May 5 13:32:27 2021 +0200 can: m_can: m_can_tx_work_queue(): fix tx_skb race condition [ Upstream commit e04b2cfe61072c7966e1a5fb73dd1feb30c206ed ] The m_can_start_xmit() function checks if the cdev->tx_skb is NULL and returns with NETDEV_TX_BUSY in case tx_sbk is not NULL. There is a race condition in the m_can_tx_work_queue(), where first the skb is send to the driver and then the case tx_sbk is set to NULL. A TX complete IRQ might come in between and wake the queue, which results in tx_skb not being cleared yet. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Tested-by: Torin Cooper-Bennun Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21 Author: Frieder Schrempf Date: Wed May 5 09:14:15 2021 +0200 can: mcp251x: fix resume from sleep before interface was brought up [ Upstream commit 03c427147b2d3e503af258711af4fc792b89b0af ] Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. Fixes: 8ce8c0abcba3 ("can: mcp251x: only reset hardware as required") Link: https://lore.kernel.org/r/17d5d714-b468-482f-f37a-482e3d6df84e@kontron.de Signed-off-by: Frieder Schrempf Reviewed-by: Andy Shevchenko [mkl: fix error handling in mcp251x_stop()] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 02140d9d2712aadc0f39c0b8c9bed71180fafaf2 Author: Marc Kleine-Budde Date: Sun May 2 11:34:34 2021 +0200 can: mcp251xfd: mcp251xfd_probe(): add missing can_rx_offload_del() in error path [ Upstream commit 4376ea42db8bfcac2bc3a30bba93917244a8c2d4 ] This patch adds the missing can_rx_offload_del(), that must be called if mcp251xfd_register() fails. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20210504091838.1109047-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 2c784a500f5edd337258b0fdb2f31bc9abde1a23 Author: Pablo Neira Ayuso Date: Wed May 5 23:06:43 2021 +0200 netfilter: nftables: Fix a memleak from userdata error path in new objects [ Upstream commit 85dfd816fabfc16e71786eda0a33a7046688b5b0 ] Release object name if userdata allocation fails. Fixes: b131c96496b3 ("netfilter: nf_tables: add userdata support for nft_object") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 403ccad066ecf63f83e25d3f701d6f39cc0a9f7d Author: Pablo Neira Ayuso Date: Wed May 5 22:25:24 2021 +0200 netfilter: nfnetlink_osf: Fix a missing skb_header_pointer() NULL check [ Upstream commit 5e024c325406470d1165a09c6feaf8ec897936be ] Do not assume that the tcph->doff field is correct when parsing for TCP options, skb_header_pointer() might fail to fetch these bits. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cee6592d444ac61acd55aad6386e29e13ba545df Author: Cong Wang Date: Wed May 5 12:40:48 2021 -0700 smc: disallow TCP_ULP in smc_setsockopt() [ Upstream commit 8621436671f3a4bba5db57482e1ee604708bf1eb ] syzbot is able to setup kTLS on an SMC socket which coincidentally uses sk_user_data too. Later, kTLS treats it as psock so triggers a refcnt warning. The root cause is that smc_setsockopt() simply calls TCP setsockopt() which includes TCP_ULP. I do not think it makes sense to setup kTLS on top of SMC sockets, so we should just disallow this setup. It is hard to find a commit to blame, but we can apply this patch since the beginning of TCP_ULP. Reported-and-tested-by: syzbot+b54a1ce86ba4a623b7f0@syzkaller.appspotmail.com Fixes: 734942cc4ea6 ("tcp: ULP infrastructure") Cc: John Fastabend Signed-off-by: Karsten Graul Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d6c635a8cc6a0ed93444a43124ff752475ed0680 Author: Maciej Żenczykowski Date: Wed May 5 09:58:31 2021 -0700 net: fix nla_strcmp to handle more then one trailing null character [ Upstream commit 2c16db6c92b0ee4aa61e88366df82169e83c3f7e ] Android userspace has been using TCA_KIND with a char[IFNAMESIZ] many-null-terminated buffer containing the string 'bpf'. This works on 4.19 and ceases to work on 5.10. I'm not entirely sure what fixes tag to use, but I think the issue was likely introduced in the below mentioned 5.4 commit. Reported-by: Nucca Chen Cc: Cong Wang Cc: David Ahern Cc: David S. Miller Cc: Jakub Kicinski Cc: Jamal Hadi Salim Cc: Jiri Pirko Cc: Jiri Pirko Fixes: 62794fc4fbf5 ("net_sched: add max len check for TCA_KIND") Change-Id: I66dc281f165a2858fc29a44869a270a2d698a82b Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26b7924707a499168bf82a6cbb3c5753d7739941 Author: Fernando Fernandez Mancera Date: Wed May 5 00:47:14 2021 +0200 ethtool: fix missing NLM_F_MULTI flag when dumping [ Upstream commit cf754ae331be7cc192b951756a1dd031e9ed978a ] When dumping the ethtool information from all the interfaces, the netlink reply should contain the NLM_F_MULTI flag. This flag allows userspace tools to identify that multiple messages are expected. Link: https://bugzilla.redhat.com/1953847 Fixes: 365f9ae4ee36 ("ethtool: fix genlmsg_put() failure handling in ethnl_default_dumpit()") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 673422b97ef3766f944fed2dd1742a5cd351a61a Author: Pavel Tatashin Date: Tue May 4 18:38:49 2021 -0700 mm/gup: check for isolation errors [ Upstream commit 6e7f34ebb8d25d71ce7f4580ba3cbfc10b895580 ] It is still possible that we pin movable CMA pages if there are isolation errors and cma_page_list stays empty when we check again. Check for isolation errors, and return success only when there are no isolation errors, and cma_page_list is empty after checking. Because isolation errors are transient, we retry indefinitely. Link: https://lkml.kernel.org/r/20210215161349.246722-5-pasha.tatashin@soleen.com Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") Signed-off-by: Pavel Tatashin Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 096c9482cea201aef3fc7f532fcc209f51cbdefd Author: Pavel Tatashin Date: Tue May 4 18:38:46 2021 -0700 mm/gup: return an error on migration failure [ Upstream commit f0f4463837da17a89d965dcbe4e411629dbcf308 ] When migration failure occurs, we still pin pages, which means that we may pin CMA movable pages which should never be the case. Instead return an error without pinning pages when migration failure happens. No need to retry migrating, because migrate_pages() already retries 10 times. Link: https://lkml.kernel.org/r/20210215161349.246722-4-pasha.tatashin@soleen.com Signed-off-by: Pavel Tatashin Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7df511ef376df54e837f3f92c8c15bd71218917f Author: Pavel Tatashin Date: Tue May 4 18:38:42 2021 -0700 mm/gup: check every subpage of a compound page during isolation [ Upstream commit 83c02c23d0747a7bdcd71f99a538aacec94b146c ] When pages are isolated in check_and_migrate_movable_pages() we skip compound number of pages at a time. However, as Jason noted, it is not necessary correct that pages[i] corresponds to the pages that we skipped. This is because it is possible that the addresses in this range had split_huge_pmd()/split_huge_pud(), and these functions do not update the compound page metadata. The problem can be reproduced if something like this occurs: 1. User faulted huge pages. 2. split_huge_pmd() was called for some reason 3. User has unmapped some sub-pages in the range 4. User tries to longterm pin the addresses. The resulting pages[i] might end-up having pages which are not compound size page aligned. Link: https://lkml.kernel.org/r/20210215161349.246722-3-pasha.tatashin@soleen.com Fixes: aa712399c1e8 ("mm/gup: speed up check_and_migrate_cma_pages() on huge page") Signed-off-by: Pavel Tatashin Reported-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Cc: Dan Williams Cc: David Hildenbrand Cc: David Rientjes Cc: Ingo Molnar Cc: Ira Weiny Cc: James Morris Cc: Jason Gunthorpe Cc: John Hubbard Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal Hocko Cc: Michal Hocko Cc: Mike Kravetz Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt (VMware) Cc: Tyler Hicks Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 87c4e386b6125ac302c622abb0a833ace3d537ae Author: Miaohe Lin Date: Tue May 4 18:37:45 2021 -0700 ksm: fix potential missing rmap_item for stable_node [ Upstream commit c89a384e2551c692a9fe60d093fd7080f50afc51 ] When removing rmap_item from stable tree, STABLE_FLAG of rmap_item is cleared with head reserved. So the following scenario might happen: For ksm page with rmap_item1: cmp_and_merge_page stable_node->head = &migrate_nodes; remove_rmap_item_from_tree, but head still equal to stable_node; try_to_merge_with_ksm_page failed; return; For the same ksm page with rmap_item2, stable node migration succeed this time. The stable_node->head does not equal to migrate_nodes now. For ksm page with rmap_item1 again: cmp_and_merge_page stable_node->head != &migrate_nodes && rmap_item->head == stable_node return; We would miss the rmap_item for stable_node and might result in failed rmap_walk_ksm(). Fix this by set rmap_item->head to NULL when rmap_item is removed from stable tree. Link: https://lkml.kernel.org/r/20210330140228.45635-5-linmiaohe@huawei.com Fixes: 4146d2d673e8 ("ksm: make !merge_across_nodes migration safe") Signed-off-by: Miaohe Lin Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit aa0d6d1d3e77ead8c69df0ed69942dea4416e8d2 Author: Miaohe Lin Date: Tue May 4 18:37:10 2021 -0700 mm/migrate.c: fix potential indeterminate pte entry in migrate_vma_insert_page() [ Upstream commit 34f5e9b9d1990d286199084efa752530ee3d8297 ] If the zone device page does not belong to un-addressable device memory, the variable entry will be uninitialized and lead to indeterminate pte entry ultimately. Fix this unexpected case and warn about it. Link: https://lkml.kernel.org/r/20210325131524.48181-4-linmiaohe@huawei.com Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent with CPU") Signed-off-by: Miaohe Lin Reviewed-by: David Hildenbrand Cc: Alistair Popple Cc: Jerome Glisse Cc: Rafael Aquini Cc: Yang Shi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9639a754cce5f1ef884c4392f7d9449041944644 Author: Miaohe Lin Date: Tue May 4 18:34:38 2021 -0700 mm/hugeltb: handle the error case in hugetlb_fix_reserve_counts() [ Upstream commit da56388c4397878a65b74f7fe97760f5aa7d316b ] A rare out of memory error would prevent removal of the reserve map region for a page. hugetlb_fix_reserve_counts() handles this rare case to avoid dangling with incorrect counts. Unfortunately, hugepage_subpool_get_pages and hugetlb_acct_memory could possibly fail too. We should correctly handle these cases. Link: https://lkml.kernel.org/r/20210410072348.20437-5-linmiaohe@huawei.com Fixes: b5cec28d36f5 ("hugetlbfs: truncate_hugepages() takes a range of pages") Signed-off-by: Miaohe Lin Cc: Feilong Lin Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 14d45fb5a3fcae53df9ee0fe1e16e5c686778731 Author: Miaohe Lin Date: Tue May 4 18:33:46 2021 -0700 khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate() [ Upstream commit 74e579bf231a337ab3786d59e64bc94f45ca7b3f ] In writable and !referenced case, the result value should be SCAN_LACK_REFERENCED_PAGE for trace_mm_collapse_huge_page_isolate() instead of default 0 (SCAN_FAIL) here. Link: https://lkml.kernel.org/r/20210306032947.35921-5-linmiaohe@huawei.com Fixes: 7d2eba0557c1 ("mm: add tracepoint for scanning pages") Signed-off-by: Miaohe Lin Acked-by: Kirill A. Shutemov Cc: Dan Carpenter Cc: Ebru Akagunduz Cc: Mike Kravetz Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 51524fa8b5f7b879ba569227738375d283b79382 Author: Mark Rutland Date: Wed Apr 28 12:15:55 2021 +0100 arm64: entry: always set GIC_PRIO_PSR_I_SET during entry [ Upstream commit 4d6a38da8e79e94cbd1344aa90876f0f805db705 ] Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18 Fixes: 23529049c684 ("arm64: entry: fix non-NMI user<->kernel transitions") Fixes: 7cd1ea1010ac ("arm64: entry: fix non-NMI kernel<->kernel transitions") Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") Fixes: 2a9b3e6ac69a ("arm64: entry: fix EL1 debug transitions") Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com Signed-off-by: Mark Rutland Reported-by: Zenghui Yu Cc: Marc Zyngier Cc: Will Deacon Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20210428111555.50880-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit c9f43423c41efe151621a37c8cbeb9c9aeefc02a Author: Marc Zyngier Date: Mon Mar 15 11:56:27 2021 +0000 arm64: entry: factor irq triage logic into macros [ Upstream commit 9eb563cdabe1d583c262042d5d44cc256f644543 ] In subsequent patches we'll allow an FIQ handler to be registered, and FIQ exceptions will need to be triaged very similarly to IRQ exceptions. So that we can reuse the existing logic, this patch factors the IRQ triage logic out into macros that can be reused for FIQ. The macros are named to follow the elX_foo_handler scheme used by the C exception handlers. For consistency with other top-level exception handlers, the kernel_entry/kernel_exit logic is not moved into the macros. As FIQ will use a different C handler, this handler name is provided as an argument to the macros. There should be no functional change as a result of this patch. Signed-off-by: Marc Zyngier [Mark: rework macros, commit message, rebase before DAIF rework] Signed-off-by: Mark Rutland Tested-by: Hector Martin Cc: James Morse Cc: Thomas Gleixner Cc: Will Deacon Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210315115629.57191-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 93dcaa8cba6561f796bcc1d53e57b1e4c9ab33cc Author: Kees Cook Date: Sun May 2 22:06:08 2021 -0700 drm/radeon: Avoid power table parsing memory leaks [ Upstream commit c69f27137a38d24301a6b659454a91ad85dff4aa ] Avoid leaving a hanging pre-allocated clock_info if last mode is invalid, and avoid heap corruption if no valid modes are found. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211537 Fixes: 6991b8f2a319 ("drm/radeon/kms: fix segfault in pm rework") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 79208af94738664b554df27d7d24f85fa02020c0 Author: Kees Cook Date: Sun May 2 22:06:07 2021 -0700 drm/radeon: Fix off-by-one power_state index heap overwrite [ Upstream commit 5bbf219328849e83878bddb7c226d8d42e84affc ] An out of bounds write happens when setting the default power state. KASAN sees this as: [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 ================================================================== BUG: KASAN: slab-out-of-bounds in radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] Write of size 4 at addr ffff88810178d858 by task systemd-udevd/157 CPU: 0 PID: 157 Comm: systemd-udevd Not tainted 5.12.0-E620 #50 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x239 kasan_report+0x170/0x1a8 radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] radeon_atombios_get_power_modes+0x144/0x1888 [radeon] radeon_pm_init+0x1019/0x1904 [radeon] rs690_init+0x76e/0x84a [radeon] radeon_device_init+0x1c1a/0x21e5 [radeon] radeon_driver_load_kms+0xf5/0x30b [radeon] drm_dev_register+0x255/0x4a0 [drm] radeon_pci_probe+0x246/0x2f6 [radeon] pci_device_probe+0x1aa/0x294 really_probe+0x30e/0x850 driver_probe_device+0xe6/0x135 device_driver_attach+0xc1/0xf8 __driver_attach+0x13f/0x146 bus_for_each_dev+0xfa/0x146 bus_add_driver+0x2b3/0x447 driver_register+0x242/0x2c1 do_one_initcall+0x149/0x2fd do_init_module+0x1ae/0x573 load_module+0x4dee/0x5cca __do_sys_finit_module+0xf1/0x140 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Without KASAN, this will manifest later when the kernel attempts to allocate memory that was stomped, since it collides with the inline slab freelist pointer: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 PID: 781 Comm: openrc-run.sh Tainted: G W 5.10.12-gentoo-E620 #2 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 RIP: 0010:kfree+0x115/0x230 Code: 89 c5 e8 75 ea ff ff 48 8b 00 0f ba e0 09 72 63 e8 1f f4 ff ff 41 89 c4 48 8b 45 00 0f ba e0 10 72 0a 48 8b 45 08 a8 01 75 02 <0f> 0b 44 89 e1 48 c7 c2 00 f0 ff ff be 06 00 00 00 48 d3 e2 48 c7 RSP: 0018:ffffb42f40267e10 EFLAGS: 00010246 RAX: ffffd61280ee8d88 RBX: 0000000000000004 RCX: 000000008010000d RDX: 4000000000000000 RSI: ffffffffba1360b0 RDI: ffffd61280ee8d80 RBP: ffffd61280ee8d80 R08: ffffffffb91bebdf R09: 0000000000000000 R10: ffff8fe2c1047ac8 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000100 FS: 00007fe80eff6b68(0000) GS:ffff8fe339c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe80eec7bc0 CR3: 0000000038012000 CR4: 00000000000006f0 Call Trace: __free_fdtable+0x16/0x1f put_files_struct+0x81/0x9b do_exit+0x433/0x94d do_group_exit+0xa6/0xa6 __x64_sys_exit_group+0xf/0xf do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe80ef64bea Code: Unable to access opcode bytes at RIP 0x7fe80ef64bc0. RSP: 002b:00007ffdb1c47528 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fe80ef64bea RDX: 00007fe80ef64f60 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00007fe80ee2c620 R11: 0000000000000246 R12: 00007fe80eff41e0 R13: 00000000ffffffff R14: 0000000000000024 R15: 00007fe80edf9cd0 Modules linked in: radeon(+) ath5k(+) snd_hda_codec_realtek ... Use a valid power_state index when initializing the "flags" and "misc" and "misc2" fields. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211537 Reported-by: Erhard F. Fixes: a48b9b4edb8b ("drm/radeon/kms/pm: add asic specific callbacks for getting power state (v2)") Fixes: 79daedc94281 ("drm/radeon/kms: minor pm cleanups") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f551068f5f32d66d226ffd256a2ce8eb87f24d02 Author: Ramesh Babu B Date: Tue May 4 21:12:41 2021 +0530 net: stmmac: Clear receive all(RA) bit when promiscuous mode is off [ Upstream commit 4c7a94286ef7ac7301d633f17519fb1bb89d7550 ] In promiscuous mode Receive All bit is set in GMAC packet filter register, but outside promiscuous mode Receive All bit is not cleared, which resulted in all network packets are received when toggle (ON/OFF) the promiscuous mode. Fixes: e0f9956a3862 ("net: stmmac: Add option for VLAN filter fail queue enable") Signed-off-by: Ramesh Babu B Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 340de910d65e71a67a28eac0402d49b0c30eca9c Author: Xuan Zhuo Date: Wed Apr 28 17:44:24 2021 +0800 xsk: Fix for xp_aligned_validate_desc() when len == chunk_size [ Upstream commit ac31565c21937eee9117e43c9cd34f557f6f1cb8 ] When desc->len is equal to chunk_size, it is legal. But when the xp_aligned_validate_desc() got chunk_end from desc->addr + desc->len pointing to the next chunk during the check, it caused the check to fail. This problem was first introduced in bbff2f321a86 ("xsk: new descriptor addressing scheme"). Later in 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") this piece of code was moved into the new function called xp_aligned_validate_desc(). This function was then moved into xsk_queue.h via 26062b185eee ("xsk: Explicitly inline functions and move definitions"). Fixes: bbff2f321a86 ("xsk: new descriptor addressing scheme") Signed-off-by: Xuan Zhuo Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20210428094424.54435-1-xuanzhuo@linux.alibaba.com Signed-off-by: Sasha Levin commit 75ea982469035153cd494337b0de0f09b8e5bdf2 Author: Pablo Neira Ayuso Date: Fri Apr 30 14:00:13 2021 +0200 netfilter: xt_SECMARK: add new revision to fix structure layout [ Upstream commit c7d13358b6a2f49f81a34aa323a2d0878a0532a2 ] This extension breaks when trying to delete rules, add a new revision to fix this. Fixes: 5e6874cdb8de ("[SECMARK]: Add xtables SECMARK target") Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit db5f1c6f776d7f02e490ba2943d388a0b6140949 Author: Xin Long Date: Mon May 3 04:41:20 2021 +0800 sctp: fix a SCTP_MIB_CURRESTAB leak in sctp_sf_do_dupcook_b [ Upstream commit f282df0391267fb2b263da1cc3233aa6fb81defc ] Normally SCTP_MIB_CURRESTAB is always incremented once asoc enter into ESTABLISHED from the state < ESTABLISHED and decremented when the asoc is being deleted. However, in sctp_sf_do_dupcook_b(), the asoc's state can be changed to ESTABLISHED from the state >= ESTABLISHED where it shouldn't increment SCTP_MIB_CURRESTAB. Otherwise, one asoc may increment MIB_CURRESTAB multiple times but only decrement once at the end. I was able to reproduce it by using scapy to do the 4-way shakehands, after that I replayed the COOKIE-ECHO chunk with 'peer_vtag' field changed to different values, and SCTP_MIB_CURRESTAB was incremented multiple times and never went back to 0 even when the asoc was freed. This patch is to fix it by only incrementing SCTP_MIB_CURRESTAB when the state < ESTABLISHED in sctp_sf_do_dupcook_b(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7afdd6aba95c8a526038e7abe283eeac3e4320f1 Author: Lv Yunlong Date: Sun May 2 04:58:18 2021 -0700 ethernet:enic: Fix a use after free bug in enic_hard_start_xmit [ Upstream commit 643001b47adc844ae33510c4bb93c236667008a3 ] In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Fixes: fb7516d42478e ("enic: add sw timestamp support") Signed-off-by: Lv Yunlong Acked-by: Govindarajulu Varadarajan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d808916d256b49b971b55eebedece7b34e1d6a2 Author: Md Haris Iqbal Date: Wed Apr 28 08:13:58 2021 +0200 block/rnbd-clt: Check the return value of the function rtrs_clt_query [ Upstream commit 1056ad829ec43f9b705b507c2093b05e2088b0b7 ] In case none of the paths are in connected state, the function rtrs_clt_query returns an error. In such a case, error out since the values in the rtrs_attrs structure would be garbage. Fixes: f7a7a5c228d45 ("block/rnbd: client: main functionality") Signed-off-by: Md Haris Iqbal Reviewed-by: Guoqing Jiang Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Link: https://lore.kernel.org/r/20210428061359.206794-4-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c1a90296a9b5dad2afaf7f3802f4c8e9e8410c3d Author: Md Haris Iqbal Date: Wed Apr 28 08:13:56 2021 +0200 block/rnbd-clt: Change queue_depth type in rnbd_clt_session to size_t [ Upstream commit 80d43cbd46155744ee450d2476ee4fcf2917ae9b ] The member queue_depth in the structure rnbd_clt_session is read from the rtrs client side using the function rtrs_clt_query, which in turn is read from the rtrs_clt structure. It should really be of type size_t. Fixes: 90426e89f54db ("block/rnbd: client: private header with client structs and functions") Signed-off-by: Md Haris Iqbal Reviewed-by: Guoqing Jiang Signed-off-by: Gioh Kim Link: https://lore.kernel.org/r/20210428061359.206794-2-gi-oh.kim@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4aae6eb6af7d1ac2ee5762077892185884d8f169 Author: Brendan Jackman Date: Thu Apr 29 13:05:10 2021 +0000 libbpf: Fix signed overflow in ringbuf_process_ring [ Upstream commit 2a30f9440640c418bcfbea9b2b344d268b58e0a2 ] One of our benchmarks running in (Google-internal) CI pushes data through the ringbuf faster htan than userspace is able to consume it. In this case it seems we're actually able to get >INT_MAX entries in a single ring_buffer__consume() call. ASAN detected that cnt overflows in this case. Fix by using 64-bit counter internally and then capping the result to INT_MAX before converting to the int return type. Do the same for the ring_buffer__poll(). Fixes: bf99c936f947 (libbpf: Add BPF ring buffer support) Signed-off-by: Brendan Jackman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210429130510.1621665-1-jackmanb@google.com Signed-off-by: Sasha Levin commit 60bb2cecf47f642dcd5e51fc7cb3d7b29d670424 Author: Baptiste Lepers Date: Sat May 1 14:10:51 2021 +1000 sunrpc: Fix misplaced barrier in call_decode [ Upstream commit f8f7e0fb22b2e75be55f2f0c13e229e75b0eac07 ] Fix a misplaced barrier in call_decode. The struct rpc_rqst is modified as follows by xprt_complete_rqst: req->rq_private_buf.len = copied; /* Ensure all writes are done before we update */ /* req->rq_reply_bytes_recvd */ smp_wmb(); req->rq_reply_bytes_recvd = copied; And currently read as follows by call_decode: smp_rmb(); // misplaced if (!req->rq_reply_bytes_recvd) goto out; req->rq_rcv_buf.len = req->rq_private_buf.len; This patch places the smp_rmb after the if to ensure that rq_reply_bytes_recvd and rq_private_buf.len are read in order. Fixes: 9ba828861c56a ("SUNRPC: Don't try to parse incomplete RPC messages") Signed-off-by: Baptiste Lepers Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 208af7ffc3519723a344fd94a3ec6c3a5c0ea55f Author: Anup Patel Date: Thu Apr 15 14:25:22 2021 +0530 RISC-V: Fix error code returned by riscv_hartid_to_cpuid() [ Upstream commit 533b4f3a789d49574e7ae0f6ececed153f651f97 ] We should return a negative error code upon failure in riscv_hartid_to_cpuid() instead of NR_CPUS. This is also aligned with all uses of riscv_hartid_to_cpuid() which expect negative error code upon failure. Fixes: 6825c7a80f18 ("RISC-V: Add logical CPU indexing for RISC-V") Fixes: f99fb607fb2b ("RISC-V: Use Linux logical CPU number instead of hartid") Signed-off-by: Anup Patel Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit f01988ecf3654f805282dce2d3bb9afe68d2691e Author: Xin Long Date: Sat May 1 04:02:58 2021 +0800 sctp: do asoc update earlier in sctp_sf_do_dupcook_a [ Upstream commit 35b4f24415c854cd718ccdf38dbea6297f010aae ] There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this. Fixes: 145cb2f7177d ("sctp: Fix bundling of SHUTDOWN with COOKIE-ACK") Reported-by: Alexander Sverdlin Reported-by: syzbot+bbe538efd1046586f587@syzkaller.appspotmail.com Reported-by: Michal Tesar Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 65084886c6ee5f7f4e9cbe7afc79fb0243ab4099 Author: Yufeng Mo Date: Fri Apr 30 17:06:22 2021 +0800 net: hns3: disable phy loopback setting in hclge_mac_start_phy [ Upstream commit 472497d0bdae890a896013332a0b673f9acdf2bf ] If selftest and reset are performed at the same time, the phy loopback setting may be still in enable state after the reset, and device cannot link up. So fix this issue by disabling phy loopback before phy_start(). Fixes: 256727da7395 ("net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5aa957e2b5fce76c1e8c845cf5ea1022fe1fd178 Author: Peng Li Date: Fri Apr 30 17:06:20 2021 +0800 net: hns3: use netif_tx_disable to stop the transmit queue [ Upstream commit b416e872be06fdace3c36cf5210130509d0f0e72 ] Currently, netif_tx_stop_all_queues() is used to ensure that the xmit is not running, but for the concurrent case it will not take effect, since netif_tx_stop_all_queues() just sets a flag without locking to indicate that the xmit queue(s) should not be run. So use netif_tx_disable() to replace netif_tx_stop_all_queues(), it takes the xmit queue lock while marking the queue stopped. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Peng Li Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 90120c475dd7267541db416ce9490257f0bb15f7 Author: Hao Chen Date: Fri Apr 30 17:06:19 2021 +0800 net: hns3: fix for vxlan gpe tx checksum bug [ Upstream commit 905416f18fe74bdd4de91bf94ef5a790a36e4b99 ] When skb->ip_summed is CHECKSUM_PARTIAL, for non-tunnel udp packet, which has a dest port as the IANA assigned, the hardware is expected to do the checksum offload, but the hardware whose version is below V3 will not do the checksum offload when udp dest port is 4790. So fixes it by doing the checksum in software for this case. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Hao Chen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7a476a8a9cb69096ea37c8f71ec3455a4be3c948 Author: Jian Shen Date: Thu Apr 29 16:34:52 2021 +0800 net: hns3: add check for HNS3_NIC_STATE_INITED in hns3_reset_notify_up_enet() [ Upstream commit b4047aac4ec1066bab6c71950623746d7bcf7154 ] In some cases, the device is not initialized because reset failed. If another task calls hns3_reset_notify_up_enet() before reset retry, it will cause an error since uninitialized pointer access. So add check for HNS3_NIC_STATE_INITED before calling hns3_nic_net_open() in hns3_reset_notify_up_enet(). Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bd4d527ea5f757dba64a05368b691fd0e6378654 Author: Yufeng Mo Date: Thu Apr 29 16:34:51 2021 +0800 net: hns3: initialize the message content in hclge_get_link_mode() [ Upstream commit 568a54bdf70b143f3e0befa298e22ad469ffc732 ] The message sent to VF should be initialized, otherwise random value of some contents may cause improper processing by the target. So add a initialization to message in hclge_get_link_mode(). Fixes: 9194d18b0577 ("net: hns3: fix the problem that the supported port is empty") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d326e253501868538da2c7ac602ef797b3720b1 Author: Yufeng Mo Date: Thu Apr 29 16:34:50 2021 +0800 net: hns3: fix incorrect configuration for igu_egu_hw_err [ Upstream commit 2867298dd49ee84214b8721521dc7a5a6382520c ] According to the UM, the type and enable status of igu_egu_hw_err should be configured separately. Currently, the type field is incorrect when disable this error. So fix it by configuring these two fields separately. Fixes: bf1faf9415dd ("net: hns3: Add enable and process hw errors from IGU, EGU and NCSI") Signed-off-by: Yufeng Mo Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 494ade7aba117f8054f78addc5c36f1a622b17e8 Author: Nobuhiro Iwamatsu Date: Tue Apr 20 11:39:17 2021 +0900 rtc: ds1307: Fix wday settings for rx8130 [ Upstream commit 204756f016726a380bafe619438ed979088bd04a ] rx8130 wday specifies the bit position, not BCD. Fixes: ee0981be7704 ("rtc: ds1307: Add support for Epson RX8130CE") Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210420023917.1949066-1-nobuhiro1.iwamatsu@toshiba.co.jp Signed-off-by: Sasha Levin commit 5515b85e1a010153cb1fcba2290612540f94ce70 Author: Can Guo Date: Sun Apr 25 20:48:40 2021 -0700 scsi: ufs: core: Narrow down fast path in system suspend path [ Upstream commit ce4f62f9dd8cf43ac044045ed598a0b80ef33890 ] If spm_lvl is set to 0 or 1, when system suspend kicks start and HBA is runtime active, system suspend may just bail without doing anything (the fast path), leaving other contexts still running, e.g., clock gating and clock scaling. When system resume kicks start, concurrency can happen between ufshcd_resume() and these contexts, leading to various stability issues. Add a check against HBA's runtime state and allowing fast path only if HBA is runtime suspended, otherwise let system suspend go ahead call ufshcd_suspend(). This will guarantee that these contexts are stopped by either runtime suspend or system suspend. Link: https://lore.kernel.org/r/1619408921-30426-4-git-send-email-cang@codeaurora.org Fixes: 0b257734344a ("scsi: ufs: optimize system suspend handling") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e8295def80b7b318b6c2b3b10e6aa8fc5b1140f2 Author: Can Guo Date: Sun Apr 25 20:48:39 2021 -0700 scsi: ufs: core: Cancel rpm_dev_flush_recheck_work during system suspend [ Upstream commit 637822e63b79ee8a729f7ba2645a26cf5a524ee4 ] During ufs system suspend, leaving rpm_dev_flush_recheck_work running or pending is risky because concurrency may happen between system suspend/resume and runtime resume routine. Fix this by cancelling rpm_dev_flush_recheck_work synchronously during system suspend. Link: https://lore.kernel.org/r/1619408921-30426-3-git-send-email-cang@codeaurora.org Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 591602738e00f7f62befda6866266676cbc53eca Author: Can Guo Date: Sun Apr 25 20:48:38 2021 -0700 scsi: ufs: core: Do not put UFS power into LPM if link is broken [ Upstream commit 23043dd87b153d02eaf676e752d32429be5e5126 ] During resume, if link is broken due to AH8 failure, make sure ufshcd_resume() does not put UFS power back into LPM. Link: https://lore.kernel.org/r/1619408921-30426-2-git-send-email-cang@codeaurora.org Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths") Reviewed-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 429ac0fb8375ba2ded1097c4c564b512d3615cce Author: Anastasia Kovaleva Date: Thu Apr 22 18:34:14 2021 +0300 scsi: qla2xxx: Prevent PRLI in target mode [ Upstream commit fcb16d9a8ecf1e9bfced0fc654ea4e2caa7517f4 ] In a case when the initiator in P2P mode by some circumstances does not send PRLI, the target, in a case when the target port's WWPN is less than initiator's, changes the discovery state in DSC_GNL. When gnl completes it sends PRLI to the initiator. Usually the initiator in P2P mode always sends PRLI. We caught this issue on Linux stable v5.4.6 https://www.spinics.net/lists/stable/msg458515.html. Fix this particular corner case in the behaviour of the P2P mod target login state machine. Link: https://lore.kernel.org/r/20210422153414.4022-1-a.kovaleva@yadro.com Fixes: a9ed06d4e640 ("scsi: qla2xxx: Allow PLOGI in target mode") Reviewed-by: Roman Bolshakov Reviewed-by: Himanshu Madhani Signed-off-by: Anastasia Kovaleva Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bf45c9fe99aa8003d2703f1bd353f956dea47e40 Author: Jeff Layton Date: Fri Mar 26 09:21:53 2021 -0400 ceph: fix inode leak on getattr error in __fh_to_dentry [ Upstream commit 1775c7ddacfcea29051c67409087578f8f4d751b ] Fixes: 878dabb64117 ("ceph: don't return -ESTALE if there's still an open file") Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit a01572e21f0941a1c8b7d39369fec3bd9b7e5e85 Author: Claire Chang Date: Thu Apr 22 16:14:53 2021 +0800 swiotlb: Fix the type of index [ Upstream commit 95b079d8215b83b37fa59341fda92fcb9392f14a ] Fix the type of index from unsigned int to int since find_slots() might return -1. Fixes: 26a7e094783d ("swiotlb: refactor swiotlb_tbl_map_single") Reviewed-by: Christoph Hellwig Signed-off-by: Claire Chang Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit 04dad2ca1f5e460296b983d332cff642055c4def Author: Chuck Lever Date: Mon Apr 19 14:02:54 2021 -0400 xprtrdma: rpcrdma_mr_pop() already does list_del_init() [ Upstream commit 1363e6388c363d0433f9aa4e2f33efe047572687 ] The rpcrdma_mr_pop() earlier in the function has already cleared out mr_list, so it must not be done again in the error path. Fixes: 847568942f93 ("xprtrdma: Remove fr_state") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit eddae8be7944096419c2ae29477a45f767d0fcd4 Author: Chuck Lever Date: Mon Apr 19 14:02:41 2021 -0400 xprtrdma: Fix cwnd update ordering [ Upstream commit 35d8b10a25884050bb3b0149b62c3818ec59f77c ] After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv(). Fixes: 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 89a31bf85c7b99e8f501f5b8559577983017e27e Author: Chuck Lever Date: Mon Apr 19 14:02:03 2021 -0400 xprtrdma: Avoid Receive Queue wrapping [ Upstream commit 32e6b68167f1d446111c973d57e6f52aee11897a ] Commit e340c2d6ef2a ("xprtrdma: Reduce the doorbell rate (Receive)") increased the number of Receive WRs that are posted by the client, but did not increase the size of the Receive Queue allocated during transport set-up. This is usually not an issue because RPCRDMA_BACKWARD_WRS is defined as (32) when SUNRPC_BACKCHANNEL is defined. In cases where it isn't, there is a real risk of Receive Queue wrapping. Fixes: e340c2d6ef2a ("xprtrdma: Reduce the doorbell rate (Receive)") Signed-off-by: Chuck Lever Reviewed-by: Tom Talpey Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit b22e8f427c3de299c47350caae2a4f80f6d7eb61 Author: Uwe Kleine-König Date: Tue Apr 20 11:51:17 2021 +0200 pwm: atmel: Fix duty cycle calculation in .get_state() [ Upstream commit 453e8b3d8e36ddcb283b3d1698864a03ea45599a ] The CDTY register contains the number of inactive cycles. .apply() does this correctly, however .get_state() got this wrong. Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 0a9decf2dd4d859bdc791165abc2b646a85dd00f Author: Dan Carpenter Date: Thu Apr 22 12:14:37 2021 +0300 SUNRPC: fix ternary sign expansion bug in tracing [ Upstream commit cb579086536f6564f5846f89808ec394ef8b8621 ] This code is supposed to pass negative "err" values for tracing but it passes positive values instead. The problem is that the trace_svcsock_tcp_send() function takes a long but "err" is an int and "sent" is a u32. The negative is first type promoted to u32 so it becomes a high positive then it is promoted to long and it stays positive. Fix this by casting "err" directly to long. Fixes: 998024dee197 ("SUNRPC: Add more svcsock tracepoints") Signed-off-by: Dan Carpenter Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit dd41a0e515322221954258e2fd27b726bef6383a Author: Dave Jiang Date: Thu Apr 15 16:37:57 2021 -0700 dmaengine: idxd: fix cdev setup and free device lifetime issues [ Upstream commit 04922b7445a1950b86f130a1fe8c52cc27b3e30b ] The char device setup and cleanup has device lifetime issues regarding when parts are initialized and cleaned up. The initialization of struct device is done incorrectly. device_initialize() needs to be called on the 'struct device' and then additional changes can be added. The ->release() function needs to be setup via device_type before dev_set_name() to allow proper cleanup. The change re-parents the cdev under the wq->conf_dev to get natural reference inheritance. No known dependency on the old device path exists. Reported-by: Jason Gunthorpe Fixes: 42d279f9137a ("dmaengine: idxd: add char driver to expose submission portal to userland") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852987721.2203940.1478218825576630810.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 975c4b2b997659c47dfae1d8073cf4370f96e598 Author: Dave Jiang Date: Thu Apr 15 16:37:10 2021 -0700 dmaengine: idxd: fix dma device lifetime [ Upstream commit 397862855619271296e46d10f7dfa7bafe71eb81 ] The devm managed lifetime is incompatible with 'struct device' objects that resides in idxd context. This is one of the series that clean up the idxd driver 'struct device' lifetime. Remove embedding of dma_device and dma_chan in idxd since it's not the only interface that idxd will use. The freeing of the dma_device will be managed by the ->release() function. Reported-by: Jason Gunthorpe Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/161852983001.2203940.14817017492384561719.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5756f757c72501ef1a16f5f63f940623044180e9 Author: Colin Ian King Date: Thu Apr 15 12:06:54 2021 +0100 dmaengine: idxd: Fix potential null dereference on pointer status [ Upstream commit 28ac8e03c43dfc6a703aa420d18222540b801120 ] There are calls to idxd_cmd_exec that pass a null status pointer however a recent commit has added an assignment to *status that can end up with a null pointer dereference. The function expects a null status pointer sometimes as there is a later assignment to *status where status is first null checked. Fix the issue by null checking status before making the assignment. Addresses-Coverity: ("Explicit null dereferenced") Fixes: 89e3becd8f82 ("dmaengine: idxd: check device state before issue command") Signed-off-by: Colin Ian King Acked-by: Dave Jiang Link: https://lore.kernel.org/r/20210415110654.1941580-1-colin.king@canonical.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0f9d467ff1396c66f64e9bd2de3ec25bfc10b7a0 Author: Michael Walle Date: Wed Apr 14 10:40:06 2021 +0200 rtc: fsl-ftm-alarm: add MODULE_TABLE() [ Upstream commit 7fcb86185978661c9188397d474f90364745b8d9 ] The module doesn't load automatically. Fix it by adding the missing MODULE_TABLE(). Fixes: 7b0b551dbc1e ("rtc: fsl-ftm-alarm: add FTM alarm driver") Signed-off-by: Michael Walle Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210414084006.17933-1-michael@walle.cc Signed-off-by: Sasha Levin commit 90e8fa8bdfb38fa4c8425dbb92985441cb7467c0 Author: J. Bruce Fields Date: Fri Apr 16 14:00:14 2021 -0400 nfsd: ensure new clients break delegations [ Upstream commit 217fd6f625af591e2866bebb8cda778cf85bea2e ] If nfsd already has an open file that it plans to use for IO from another, it may not need to do another vfs open, but it still may need to break any delegations in case the existing opens are for another client. Symptoms are that we may incorrectly fail to break a delegation on a write open from a different client, when the delegation-holding client already has a write open. Fixes: 28df3d1539de ("nfsd: clients don't need to break their own delegations") Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b4bf335acaccd6de239bb00c1edebbb8612761e6 Author: Trond Myklebust Date: Thu Apr 15 15:09:41 2021 -0400 NFSv4.x: Don't return NFS4ERR_NOMATCHING_LAYOUT if we're unmounting [ Upstream commit 8926cc8302819be9e67f70409ed001ecb2c924a9 ] If the NFS super block is being unmounted, then we currently may end up telling the server that we've forgotten the layout while it is actually still in use by the client. In that case, just assume that the client will soon return the layout anyway, and so return NFS4ERR_DELAY in response to the layout recall. Fixes: 58ac3e59235f ("NFSv4/pnfs: Clean up nfs_layout_find_inode()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 5d254e17ca86fb51d9e5030578636d8bb0649a60 Author: Guangqing Zhu Date: Sun Apr 4 20:54:31 2021 +0800 thermal/drivers/tsens: Fix missing put_device error [ Upstream commit f4136863e8899fa0554343201b78b9e197c78a78 ] Fixes coccicheck error: drivers/thermal/qcom/tsens.c:759:4-10: ERROR: missing put_device; call of_find_device_by_node on line 715, but without a corresponding object release within this function. Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into tsens.c") Signed-off-by: Guangqing Zhu Reviewed-by: Bjorn Andersson Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210404125431.12208-1-zhuguangqing83@gmail.com Signed-off-by: Sasha Levin commit 4f86a0a5eb6158048040d8a8ffb112c92caa013f Author: Chris Dion Date: Sun Apr 4 21:29:26 2021 -0400 SUNRPC: Handle major timeout in xprt_adjust_timeout() [ Upstream commit 09252177d5f924f404551b4b4eded5daa7f04a3a ] Currently if a major timeout value is reached, but the minor value has not been reached, an ETIMEOUT will not be sent back to the caller. This can occur if the v4 server is not responding to requests and retrans is configured larger than the default of two. For example, A TCP mount with a configured timeout value of 50 and a retransmission count of 3 to a v4 server which is not responding: 1. Initial value and increment set to 5s, maxval set to 20s, retries at 3 2. Major timeout is set to 20s, minor timeout set to 5s initially 3. xport_adjust_timeout() is called after 5s, retry with 10s timeout, minor timeout is bumped to 10s 4. And again after another 10s, 15s total time with minor timeout set to 15s 5. After 20s total time xport_adjust_timeout is called as major timeout is reached, but skipped because the minor timeout is not reached - After this time the cpu spins continually calling xport_adjust_timeout() and returning 0 for 10 seconds. As seen on perf sched: 39243.913182 [0005] mount.nfs[3794] 4607.938 0.017 9746.863 6. This continues until the 15s minor timeout condition is reached (in this case for 10 seconds). After which the ETIMEOUT is processed back to the caller, the cpu spinning stops, and normal operations continue Fixes: 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset") Signed-off-by: Chris Dion Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 8efd19bf754b14c9456e60db57af72c52c28f636 Author: Chuck Lever Date: Wed Mar 31 16:03:08 2021 -0400 SUNRPC: Remove trace_xprt_transmit_queued [ Upstream commit 6cf23783f750634e10daeede48b0f5f5d64ebf3a ] This tracepoint can crash when dereferencing snd_task because when some transports connect, they put a cookie in that field instead of a pointer to an rpc_task. BUG: KASAN: use-after-free in trace_event_raw_event_xprt_writelock_event+0x141/0x18e [sunrpc] Read of size 2 at addr ffff8881a83bd3a0 by task git/331872 CPU: 11 PID: 331872 Comm: git Tainted: G S 5.12.0-rc2-00007-g3ab6e585a7f9 #1453 Hardware name: Supermicro SYS-6028R-T/X10DRi, BIOS 1.1a 10/16/2015 Call Trace: dump_stack+0x9c/0xcf print_address_description.constprop.0+0x18/0x239 kasan_report+0x174/0x1b0 trace_event_raw_event_xprt_writelock_event+0x141/0x18e [sunrpc] xprt_prepare_transmit+0x8e/0xc1 [sunrpc] call_transmit+0x4d/0xc6 [sunrpc] Fixes: 9ce07ae5eb1d ("SUNRPC: Replace dprintk() call site in xprt_prepare_transmit") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7b906077fd990b1888a5bd49ffb1782077ca6509 Author: Chuck Lever Date: Wed Mar 31 13:22:14 2021 -0400 SUNRPC: Move fault injection call sites [ Upstream commit 7638e0bfaed1b653d3ca663e560e9ffb44bb1030 ] I've hit some crashes that occur in the xprt_rdma_inject_disconnect path. It appears that, for some provides, rdma_disconnect() can take so long that the transport can disconnect and release its hardware resources while rdma_disconnect() is still running, resulting in a UAF in the provider. The transport's fault injection method may depend on the stability of transport data structures. That means it needs to be invoked only from contexts that hold the transport write lock. Fixes: 4a0682583988 ("SUNRPC: Transport fault injection") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit bfeb4e607d00a01586116a134f4090ceb23a4eb3 Author: Olga Kornievskaia Date: Wed Mar 31 15:30:25 2021 -0400 NFSv4.2 fix handling of sr_eof in SEEK's reply [ Upstream commit 73f5c88f521a630ea1628beb9c2d48a2e777a419 ] Currently the client ignores the value of the sr_eof of the SEEK operation. According to the spec, if the server didn't find the requested extent and reached the end of the file, the server would return sr_eof=true. In case the request for DATA and no data was found (ie in the middle of the hole), then the lseek expects that ENXIO would be returned. Fixes: 1c6dcbe5ceff8 ("NFS: Implement SEEK") Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 1fbea60ea658ab887fb899532d783732b04e53e6 Author: Nikola Livic Date: Mon Mar 29 11:56:49 2021 +0300 pNFS/flexfiles: fix incorrect size check in decode_nfs_fh() [ Upstream commit ed34695e15aba74f45247f1ee2cf7e09d449f925 ] We (adam zabrocki, alexander matrosov, alexander tereshkin, maksym bazalii) observed the check: if (fh->size > sizeof(struct nfs_fh)) should not use the size of the nfs_fh struct which includes an extra two bytes from the size field. struct nfs_fh { unsigned short size; unsigned char data[NFS_MAXFHSIZE]; } but should determine the size from data[NFS_MAXFHSIZE] so the memcpy will not write 2 bytes beyond destination. The proposed fix is to compare against the NFS_MAXFHSIZE directly, as is done elsewhere in fs code base. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Nikola Livic Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit fd65cac30d45305848f0ea1591b3cf011e3dd25a Author: Yang Yingliang Date: Wed Mar 31 16:40:12 2021 +0800 PCI: endpoint: Fix missing destroy_workqueue() [ Upstream commit acaef7981a218813e3617edb9c01837808de063c ] Add the missing destroy_workqueue() before return from pci_epf_test_init() in the error handling case and add destroy_workqueue() in pci_epf_test_exit(). Link: https://lore.kernel.org/r/20210331084012.2091010-1-yangyingliang@huawei.com Fixes: 349e7a85b25fa ("PCI: endpoint: functions: Add an EP function to test PCI") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit d21a5950cca69d5ac199f011752c90e171f6c5d1 Author: Trond Myklebust Date: Mon Mar 29 16:46:05 2021 -0400 NFS: Deal correctly with attribute generation counter overflow [ Upstream commit 9fdbfad1777cb4638f489eeb62d85432010c0031 ] We need to use unsigned long subtraction and then convert to signed in order to deal correcly with C overflow rules. Fixes: f5062003465c ("NFS: Set an attribute barrier on all updates") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cbc868ea28a8db2daab63cfb4d8c08ccafda5c10 Author: Trond Myklebust Date: Sun Mar 28 18:17:14 2021 -0400 NFSv4.2: Always flush out writes in nfs42_proc_fallocate() [ Upstream commit 99f23783224355e7022ceea9b8d9f62c0fd01bd8 ] Whether we're allocating or delallocating space, we should flush out the pending writes in order to avoid races with attribute updates. Fixes: 1e564d3dbd68 ("NFSv4.2: Fix a race in nfs42_proc_deallocate()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit a09afbb63620e9e36fd2a0c1536fb5a93be99c8f Author: Trond Myklebust Date: Sun Mar 28 18:12:03 2021 -0400 NFS: Fix attribute bitmask in _nfs42_proc_fallocate() [ Upstream commit e99812e1382f0bfb6149393262bc70645c9f537a ] We can't use nfs4_fattr_bitmap as a bitmask, because it hasn't been filtered to represent the attributes supported by the server. Instead, let's revert to using server->cache_consistency_bitmask after adding in the missing SPACE_USED attribute. Fixes: 913eca1aea87 ("NFS: Fallocate should use the nfs4_fattr_bitmap") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ce2b470addedf54ca508f024006a8f8e00c60864 Author: Trond Myklebust Date: Thu Mar 25 18:15:36 2021 -0400 NFS: nfs4_bitmask_adjust() must not change the server global bitmasks [ Upstream commit 332d1a0373be32a3a3c152756bca45ff4f4e11b5 ] As currently set, the calls to nfs4_bitmask_adjust() will end up overwriting the contents of the nfs_server cache_consistency_bitmask field. The intention here should be to modify a private copy of that mask in the close/delegreturn/write arguments. Fixes: 76bd5c016ef4 ("NFSv4: make cache consistency bitmask dynamic") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0627cbc9b8752382213fb87cfc6984b537146096 Author: Jia-Ju Bai Date: Sat Mar 6 05:36:24 2021 -0800 rpmsg: qcom_glink_native: fix error return code of qcom_glink_rx_data() [ Upstream commit 26594c6bbb60c6bc87e3762a86ceece57d164c66 ] When idr_find() returns NULL to intent, no error return code of qcom_glink_rx_data() is assigned. To fix this bug, ret is assigned with -ENOENT in this case. Fixes: 64f95f87920d ("rpmsg: glink: Use the local intents when receiving data") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20210306133624.17237-1-baijiaju1990@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b59194c7ca29cbfa29426aadc07ca043437178bc Author: Chao Yu Date: Fri Apr 2 17:22:23 2021 +0800 f2fs: fix to avoid accessing invalid fio in f2fs_allocate_data_block() [ Upstream commit 25ae837e61dee712b4b1df36602ebfe724b2a0b6 ] Callers may pass fio parameter with NULL value to f2fs_allocate_data_block(), so we should make sure accessing fio's field after fio's validation check. Fixes: f608c38c59c6 ("f2fs: clean up parameter of f2fs_allocate_data_block()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1fd6a0641040330eff8042b2ca9c4a2142dd237f Author: Yi Zhuang Date: Wed Mar 31 17:34:14 2021 +0800 f2fs: Fix a hungtask problem in atomic write [ Upstream commit be1ee45d51384161681ecf21085a42d316ae25f7 ] In the cache writing process, if it is an atomic file, increase the page count of F2FS_WB_CP_DATA, otherwise increase the page count of F2FS_WB_DATA. When you step into the hook branch due to insufficient memory in f2fs_write_begin, f2fs_drop_inmem_pages_all will be called to traverse all atomic inodes and clear the FI_ATOMIC_FILE mark of all atomic files. In f2fs_drop_inmem_pages,first acquire the inmem_lock , revoke all the inmem_pages, and then clear the FI_ATOMIC_FILE mark. Before this mark is cleared, other threads may hold inmem_lock to add inmem_pages to the inode that has just been emptied inmem_pages, and increase the page count of F2FS_WB_CP_DATA. When the IO returns, it is found that the FI_ATOMIC_FILE flag is cleared by f2fs_drop_inmem_pages_all, and f2fs_is_atomic_file returns false,which causes the page count of F2FS_WB_DATA to be decremented. The page count of F2FS_WB_CP_DATA cannot be cleared. Finally, hungtask is triggered in f2fs_wait_on_all_pages because get_pages will never return zero. process A: process B: f2fs_drop_inmem_pages_all ->f2fs_drop_inmem_pages of inode#1 ->mutex_lock(&fi->inmem_lock) ->__revoke_inmem_pages of inode#1 f2fs_ioc_commit_atomic_write ->mutex_unlock(&fi->inmem_lock) ->f2fs_commit_inmem_pages of inode#1 ->mutex_lock(&fi->inmem_lock) ->__f2fs_commit_inmem_pages ->f2fs_do_write_data_page ->f2fs_outplace_write_data ->do_write_page ->f2fs_submit_page_write ->inc_page_count(sbi, F2FS_WB_CP_DATA ) ->mutex_unlock(&fi->inmem_lock) ->spin_lock(&sbi->inode_lock[ATOMIC_FILE]); ->clear_inode_flag(inode, FI_ATOMIC_FILE) ->spin_unlock(&sbi->inode_lock[ATOMIC_FILE]) f2fs_write_end_io ->dec_page_count(sbi, F2FS_WB_DATA ); We can fix the problem by putting the action of clearing the FI_ATOMIC_FILE mark into the inmem_lock lock. This operation can ensure that no one will submit the inmem pages before the FI_ATOMIC_FILE mark is cleared, so that there will be no atomic writes waiting for writeback. Fixes: 57864ae5ce3a ("f2fs: limit # of inmemory pages") Signed-off-by: Yi Zhuang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 98ccee81fe9640eb646aa7f983b75a5419a43577 Author: Chao Yu Date: Fri Mar 26 09:46:22 2021 +0800 f2fs: fix to cover __allocate_new_section() with curseg_lock [ Upstream commit 823d13e12b6cbaef2f6e5d63c648643e7bc094dd ] In order to avoid race with f2fs_do_replace_block(). Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 105155a8146ddb54c119d8318964eef3859d109d Author: Chao Yu Date: Wed Mar 24 11:18:28 2021 +0800 f2fs: fix to avoid touching checkpointed data in get_victim() [ Upstream commit 61461fc921b756ae16e64243f72af2bfc2e620db ] In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment. Fixes: 4354994f097d ("f2fs: checkpoint disabling") Fixes: 093749e296e2 ("f2fs: support age threshold based garbage collection") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bbed83d7060e07a5d309104d25a00f0a24441428 Author: Shradha Todi Date: Wed Mar 24 15:46:09 2021 +0530 PCI: endpoint: Fix NULL pointer dereference for ->get_features() [ Upstream commit 6613bc2301ba291a1c5a90e1dc24cf3edf223c03 ] get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ end trace a438e3c5a24f9df0 ]--- Link: https://lore.kernel.org/r/20210324101609.79278-1-shradha.t@samsung.com Fixes: 2c04c5b8eef79 ("PCI: pci-epf-test: Use pci_epc_get_features() to get EPC features") Signed-off-by: Sriram Dash Signed-off-by: Shradha Todi Signed-off-by: Lorenzo Pieralisi Reviewed-by: Pankaj Dubey Reviewed-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit d5e85b92b4574aac500153bc55a287f0b6947b50 Author: Kishon Vijay Abraham I Date: Tue Feb 2 01:27:56 2021 +0530 PCI: endpoint: Make *_free_bar() to return error codes on failure [ Upstream commit 0e27aeccfa3d1bab7c6a29fb8e6fcedbad7b09a8 ] Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to return error values if there are no free BARs available. Link: https://lore.kernel.org/r/20210201195809.7342-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit d98bfd4cc25886bb5691321df6735c6772e834de Author: Kishon Vijay Abraham I Date: Tue Feb 2 01:27:55 2021 +0530 PCI: endpoint: Add helper API to get the 'next' unreserved BAR [ Upstream commit fa8fef0e104a23efe568b835d9e7e188d1d97610 ] Add an API to get the next unreserved BAR starting from a given BAR number that can be used by the endpoint function. Link: https://lore.kernel.org/r/20210201195809.7342-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 5974766170d8debdc970f9cf9e3dca6be40f8440 Author: Kishon Vijay Abraham I Date: Tue Feb 2 01:27:54 2021 +0530 PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR [ Upstream commit 959a48d0eac0321948c9f3d1707ba22c100e92d5 ] pci_epc_get_first_free_bar() uses only "reserved_bar" member in epc_features to get the first unreserved BAR. However if the reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be returned (since 64-bit BAR uses two BARs). Make pci_epc_get_first_free_bar() take into account 64 bit BAR while returning the first free unreserved BAR. Link: https://lore.kernel.org/r/20210201195809.7342-3-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 8c8f7c49930dd93f5eb0653baed6f165a2e7601c Author: Chao Yu Date: Wed Mar 24 11:24:33 2021 +0800 f2fs: fix to update last i_size if fallocate partially succeeds [ Upstream commit 88f2cfc5fa90326edb569b4a81bb38ed4dcd3108 ] In the case of expanding pinned file, map.m_lblk and map.m_len will update in each round of section allocation, so in error path, last i_size will be calculated with wrong m_lblk and m_len, fix it. Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 74d2b0e74c3f5bccfe71e3466356f4a08a0bc73e Author: Chao Yu Date: Fri Mar 5 17:56:01 2021 +0800 f2fs: fix to align to section for fallocate() on pinned file [ Upstream commit e1175f02291141bbd924fc578299305fcde35855 ] Now, fallocate() on a pinned file only allocates blocks which aligns to segment rather than section, so GC may try to migrate pinned file's block, and after several times of failure, pinned file's block could be migrated to other place, however user won't be aware of such condition, and then old obsolete block address may be readed/written incorrectly. To avoid such condition, let's try to allocate pinned file's blocks with section alignment. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 630146203108bf6b8934eec0dfdb3e46dcb917de Author: Zhen Lei Date: Thu Feb 18 03:00:05 2021 +0100 ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook [ Upstream commit a506bd5756290821a4314f502b4bafc2afcf5260 ] The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ Fixes: 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") Signed-off-by: Zhen Lei Cc: Wang Nan Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Sasha Levin commit ee93cdcbe0b553b6c1e457ad33c64dd90600ad97 Author: Dmitry Baryshkov Date: Mon Jan 25 02:28:26 2021 +0300 PCI: Release OF node in pci_scan_device()'s error path [ Upstream commit c99e755a4a4c165cad6effb39faffd0f3377c02d ] In pci_scan_device(), if pci_setup_device() fails for any reason, the code will not release device's of_node by calling pci_release_of_node(). Fix that by calling the release function. Fixes: 98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically") Link: https://lore.kernel.org/r/20210124232826.1879-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c5c0ede221d768c600b7154d0afee05cb3554d86 Author: Pali Rohár Date: Wed Mar 3 15:22:02 2021 +0100 PCI: iproc: Fix return value of iproc_msi_irq_domain_alloc() [ Upstream commit 1e83130f01b04c16579ed5a5e03d729bcffc4c5d ] IRQ domain alloc function should return zero on success. Non-zero value indicates failure. Link: https://lore.kernel.org/r/20210303142202.25780-1-pali@kernel.org Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Krzysztof Wilczyński Acked-by: Ray Jui Acked-by: Marc Zyngier Signed-off-by: Sasha Levin commit 1ce0d1d3656b50bca56c8ff2688235eb5348f841 Author: Bjorn Andersson Date: Fri Mar 12 15:20:02 2021 -0800 remoteproc: qcom_q6v5_mss: Validate p_filesz in ELF loader [ Upstream commit 3d2ee78906af5f08d499d6aa3aa504406fa38106 ] Analog to the issue in the common mdt_loader code the MSS ELF loader does not validate that p_filesz bytes will fit in the memory region and that the loaded segments are not truncated. Fix this in the same way as proposed for the mdt_loader. Reviewed-by: Mathieu Poirier Fixes: 135b9e8d1cd8 ("remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load") Link: https://lore.kernel.org/r/20210312232002.3466791-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2ec65063e45ab5faa775c1516026c653cff7f066 Author: Sibi Sankar Date: Wed Nov 4 12:33:41 2020 +0530 remoteproc: qcom_q6v5_mss: Replace ioremap with memremap [ Upstream commit 04ff5d19cf6e2f9dbdf137c0c6eb44934d46a99c ] Fix the sparse warnings reported by the kernel test bot by replacing ioremap calls with memremap. Reviewed-by: Bjorn Andersson Reported-by: kernel test robot Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/1604473422-29639-1-git-send-email-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2d6d5b4fc498f2e429ae5b6439780ae5d900a3f9 Author: Colin Ian King Date: Thu Mar 4 09:21:18 2021 +0000 f2fs: fix a redundant call to f2fs_balance_fs if an error occurs [ Upstream commit 28e18ee636ba28532dbe425540af06245a0bbecb ] The uninitialized variable dn.node_changed does not get set when a call to f2fs_get_node_page fails. This uninitialized value gets used in the call to f2fs_balance_fs() that may or not may not balances dirty node and dentry pages depending on the uninitialized state of the variable. Fix this by only calling f2fs_balance_fs if err is not set. Thanks to Jaegeuk Kim for suggesting an appropriate fix. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 2a3407607028 ("f2fs: call f2fs_balance_fs only when node was changed") Signed-off-by: Colin Ian King Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1c20a4896409f5ca1c770e1880c33d0a28a8b10f Author: Chao Yu Date: Sat Feb 20 17:35:41 2021 +0800 f2fs: fix panic during f2fs_resize_fs() [ Upstream commit 3ab0598e6d860ef49d029943ba80f627c15c15d6 ] f2fs_resize_fs() hangs in below callstack with testcase: - mkfs 16GB image & mount image - dd 8GB fileA - dd 8GB fileB - sync - rm fileA - sync - resize filesystem to 8GB kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range(). Fixes: b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 81ba1634d1b61cd4023a470c8f4d48375ec35fa2 Author: Chao Yu Date: Sat Feb 20 17:35:40 2021 +0800 f2fs: fix to allow migrating fully valid segment [ Upstream commit 7dede88659df38f96128ab3922c50dde2d29c574 ] F2FS_IOC_FLUSH_DEVICE/F2FS_IOC_RESIZE_FS needs to migrate all blocks of target segment to other place, no matter the segment has partially or fully valid blocks. However, after commit 803e74be04b3 ("f2fs: stop GC when the victim becomes fully valid"), we may skip migration due to target segment is fully valid, result in failing the ioctl interface, fix this. Fixes: 803e74be04b3 ("f2fs: stop GC when the victim becomes fully valid") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit de2041d92d2af85382442795030f35a8c3fd248c Author: Chao Yu Date: Tue Nov 10 09:24:37 2020 +0800 f2fs: fix compat F2FS_IOC_{MOVE,GARBAGE_COLLECT}_RANGE [ Upstream commit 34178b1bc4b5c936eab3adb4835578093095a571 ] Eric reported a ioctl bug in below link: https://lore.kernel.org/linux-f2fs-devel/20201103032234.GB2875@sol.localdomain/ That said, on some 32-bit architectures, u64 has only 32-bit alignment, notably i386 and x86_32, so that size of struct f2fs_gc_range compiled in x86_32 is 20 bytes, however the size in x86_64 is 24 bytes, binary compiled in x86_32 can not call F2FS_IOC_GARBAGE_COLLECT_RANGE successfully due to mismatched value of ioctl command in between binary and f2fs module, similarly, F2FS_IOC_MOVE_RANGE will fail too. In this patch we introduce two ioctls for compatibility of above special 32-bit binary: - F2FS_IOC32_GARBAGE_COLLECT_RANGE - F2FS_IOC32_MOVE_RANGE Reported-by: Eric Biggers Signed-off-by: Chao Yu Reviewed-by: Eric Biggers Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit b7ff0885de7ebf70a0fdd0378a118bbda5fbd1d6 Author: Chao Yu Date: Mon Nov 2 14:21:31 2020 +0800 f2fs: move ioctl interface definitions to separated file [ Upstream commit fa4320cefb8537a70cc28c55d311a1f569697cd3 ] Like other filesystem does, we introduce a new file f2fs.h in path of include/uapi/linux/, and move f2fs-specified ioctl interface definitions to that file, after then, in order to use those definitions, userspace developer only need to include the new header file rather than copy & paste definitions from fs/f2fs/f2fs.h. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 997d24a932a9b6e2040f39a8dd76e873e6519a1c Author: Jia-Ju Bai Date: Wed Mar 10 04:24:23 2021 -0800 thermal: thermal_of: Fix error return code of thermal_of_populate_bind_params() [ Upstream commit 45c7eaeb29d67224db4ba935deb575586a1fda09 ] When kcalloc() returns NULL to __tcbp or of_count_phandle_with_args() returns zero or -ENOENT to count, no error return code of thermal_of_populate_bind_params() is assigned. To fix these bugs, ret is assigned with -ENOMEM and -ENOENT in these cases, respectively. Fixes: a92bab8919e3 ("of: thermal: Allow multiple devices to share cooling map") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210310122423.3266-1-baijiaju1990@gmail.com Signed-off-by: Sasha Levin commit a1b5fecedfa914cbd7984a4974473ec2146f1b60 Author: David Ward Date: Sun Apr 18 09:46:57 2021 -0400 ASoC: rt286: Make RT286_SET_GPIO_* readable and writable [ Upstream commit cd8499d5c03ba260e3191e90236d0e5f6b147563 ] The GPIO configuration cannot be applied if the registers are inaccessible. This prevented the headset mic from working on the Dell XPS 13 9343. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=114171 Signed-off-by: David Ward Link: https://lore.kernel.org/r/20210418134658.4333-5-david.ward@gatech.edu Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5b66867966bc04652d85d58b8500a22b99aa5dad Author: Petr Mladek Date: Thu Apr 29 22:54:33 2021 -0700 watchdog: fix barriers when printing backtraces from all CPUs [ Upstream commit 9f113bf760ca90d709f8f89a733d10abb1f04a83 ] Any parallel softlockup reports are skipped when one CPU is already printing backtraces from all CPUs. The exclusive rights are synchronized using one bit in soft_lockup_nmi_warn. There is also one memory barrier that does not make much sense. Use two barriers on the right location to prevent mixing two reports. [pmladek@suse.com: use bit lock operations to prevent multiple soft-lockup reports] Link: https://lkml.kernel.org/r/YFSVsLGVWMXTvlbk@alley Link: https://lkml.kernel.org/r/20210311122130.6788-6-pmladek@suse.com Signed-off-by: Petr Mladek Acked-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a68c246065b6042bfdb9177527fcf0e8f93dff3d Author: Petr Mladek Date: Thu Apr 29 22:54:30 2021 -0700 watchdog/softlockup: remove logic that tried to prevent repeated reports [ Upstream commit 1bc503cb4a2638fb1c57801a7796aca57845ce63 ] The softlockup detector does some gymnastic with the variable soft_watchdog_warn. It was added by the commit 58687acba59266735ad ("lockup_detector: Combine nmi_watchdog and softlockup detector"). The purpose is not completely clear. There are the following clues. They describe the situation how it looked after the above mentioned commit: 1. The variable was checked with a comment "only warn once". 2. The variable was set when softlockup was reported. It was cleared only when the CPU was not longer in the softlockup state. 3. watchdog_touch_ts was not explicitly updated when the softlockup was reported. Without this variable, the report would normally be printed again during every following watchdog_timer_fn() invocation. The logic has got even more tangled up by the commit ed235875e2ca98 ("kernel/watchdog.c: print traces for all cpus on lockup detection"). After this commit, soft_watchdog_warn is set only when softlockup_all_cpu_backtrace is enabled. But multiple reports from all CPUs are prevented by a new variable soft_lockup_nmi_warn. Conclusion: The variable probably never worked as intended. In each case, it has not worked last many years because the softlockup was reported repeatedly after the full period defined by watchdog_thresh. The reason is that watchdog gets touched in many known slow paths, for example, in printk_stack_address(). This code is called also when printing the softlockup report. It means that the watchdog timestamp gets updated after each report. Solution: Simply remove the logic. People want the periodic report anyway. Link: https://lkml.kernel.org/r/20210311122130.6788-5-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9413b1ee3858fc91198c3f68c4de254cc2e47d78 Author: Petr Mladek Date: Thu Apr 29 22:54:23 2021 -0700 watchdog: explicitly update timestamp when reporting softlockup [ Upstream commit c9ad17c991492f4390f42598f6ab0531f87eed07 ] The softlockup situation might stay for a long time or even forever. When it happens, the softlockup debug messages are printed in regular intervals defined by get_softlockup_thresh(). There is a mystery. The repeated message is printed after the full interval that is defined by get_softlockup_thresh(). But the timer callback is called more often as defined by sample_period. The code looks like the soflockup should get reported in every sample_period when it was once behind the thresh. It works only by chance. The watchdog is touched when printing the stall report, for example, in printk_stack_address(). Make the behavior clear and predictable by explicitly updating the timestamp in watchdog_timer_fn() when the report gets printed. Link: https://lkml.kernel.org/r/20210311122130.6788-3-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Ingo Molnar Cc: Laurence Oberman Cc: Michal Hocko Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vincent Whitchurch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 018655f8758a4a9307d5cfd01e47cfbc134df325 Author: Petr Mladek Date: Thu Apr 29 22:54:20 2021 -0700 watchdog: rename __touch_watchdog() to a better descriptive name [ Upstream commit 7c0012f522c802d25be102bafe54f333168e6119 ] Patch series "watchdog/softlockup: Report overall time and some cleanup", v2. I dug deep into the softlockup watchdog history when time permitted this year. And reworked the patchset that fixed timestamps and cleaned up the code[2]. I split it into very small steps and did even more code clean up. The result looks quite strightforward and I am pretty confident with the changes. [1] v2: https://lore.kernel.org/r/20201210160038.31441-1-pmladek@suse.com [2] v1: https://lore.kernel.org/r/20191024114928.15377-1-pmladek@suse.com This patch (of 6): There are many touch_*watchdog() functions. They are called in situations where the watchdog could report false positives or create unnecessary noise. For example, when CPU is entering idle mode, a virtual machine is stopped, or a lot of messages are printed in the atomic context. These functions set SOFTLOCKUP_RESET instead of a real timestamp. It allows to call them even in a context where jiffies might be outdated. For example, in an atomic context. The real timestamp is set by __touch_watchdog() that is called from the watchdog timer callback. Rename this callback to update_touch_ts(). It better describes the effect and clearly distinguish is from the other touch_*watchdog() functions. Another motivation is that two timestamps are going to be used. One will be used for the total softlockup time. The other will be used to measure time since the last report. The new function name will help to distinguish which timestamp is being updated. Link: https://lkml.kernel.org/r/20210311122130.6788-1-pmladek@suse.com Link: https://lkml.kernel.org/r/20210311122130.6788-2-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Laurence Oberman Cc: Vincent Whitchurch Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1dc55c3a486224a32081b277ed9715cf6b7a3cbc Author: Sergei Trofimovich Date: Thu Apr 29 22:53:48 2021 -0700 ia64: module: fix symbolizer crash on fdescr [ Upstream commit 99e729bd40fb3272fa4b0140839d5e957b58588a ] Noticed failure as a crash on ia64 when tried to symbolize all backtraces collected by page_owner=on: $ cat /sys/kernel/debug/page_owner CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #226 Hardware name: hp server rx3600, BIOS 04.03 04/08/2008 ip is at dereference_module_function_descriptor+0x41/0x100 Crash happens at dereference_module_function_descriptor() due to use-after-free when dereferencing ".opd" section header. All section headers are already freed after module is laoded successfully. To keep symbolizer working the change stores ".opd" address and size after module is relocated to a new place and before section headers are discarded. To make similar errors less obscure module_finalize() now zeroes out all variables relevant to module loading only. Link: https://lkml.kernel.org/r/20210403074803.3309096-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 602795e247d1b2ef9ac4687ee3cc11cec88b2980 Author: Michael Chan Date: Sun Apr 25 13:45:25 2021 -0400 bnxt_en: Add PCI IDs for Hyper-V VF devices. [ Upstream commit 7fbf359bb2c19c824cbb1954020680824f6ee5a5 ] Support VF device IDs used by the Hyper-V hypervisor. Reviewed-by: Vasundhara Volam Reviewed-by: Andy Gospodarek Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0736af81151cb6213825034da0e09a7e4ad20ea Author: Masahiro Yamada Date: Fri Mar 26 03:54:09 2021 +0900 kbuild: generate Module.symvers only when vmlinux exists [ Upstream commit 69bc8d386aebbd91a6bb44b6d33f77c8dfa9ed8c ] The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 9401b7ff91f9f28901c3aaffc71751fcbae756cc Author: Petr Machata Date: Fri Apr 23 14:19:48 2021 +0200 selftests: mlxsw: Fix mausezahn invocation in ERSPAN scale test [ Upstream commit 1233898ab758cbcf5f6fea10b8dd16a0b2c24fab ] The mirror_gre_scale test creates as many ERSPAN sessions as the underlying chip supports, and tests that they all work. In order to determine that it issues a stream of ICMP packets and checks if they are mirrored as expected. However, the mausezahn invocation missed the -6 flag to identify the use of IPv6 protocol, and was sending ICMP messages over IPv6, as opposed to ICMP6. It also didn't pass an explicit source IP address, which apparently worked at some point in the past, but does not anymore. To fix these issues, extend the function mirror_test() in mirror_lib by detecting the IPv6 protocol addresses, and using a different ICMP scheme. Fix __mirror_gre_test() in the selftest itself to pass a source IP address. Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dfa0e8461e99924a75cb0e03134475cf3b92c2a7 Author: Petr Machata Date: Fri Apr 23 14:19:47 2021 +0200 selftests: mlxsw: Increase the tolerance of backlog buildup [ Upstream commit dda7f4fa55839baeb72ae040aeaf9ccf89d3e416 ] The intention behind this test is to make sure that qdisc limit is correctly projected to the HW. However, first, due to rounding in the qdisc, and then in the driver, the number cannot actually be accurate. And second, the approach to testing this is to oversubscribe the port with traffic generated on the same switch. The actual backlog size therefore fluctuates. In practice, this test proved to be noisier than the rest, and spuriously fails every now and then. Increase the tolerance to 10 % to avoid these issues. Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 99d9989ee53bd8c75d113c9b8039724ddec5a929 Author: Felix Fietkau Date: Thu Apr 22 22:20:54 2021 -0700 net: ethernet: mtk_eth_soc: fix RX VLAN offload [ Upstream commit 3f57d8c40fea9b20543cab4da12f4680d2ef182c ] The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is set. Fixes frames wrongly marked with VLAN tags. Signed-off-by: Felix Fietkau [Ilya: fix commit message] Signed-off-by: Ilya Lipnitskiy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 320c50ff84a0fa8243b92184376e316db8a95c9a Author: Stefan Assmann Date: Tue Mar 9 15:41:42 2021 +0100 iavf: remove duplicate free resources calls [ Upstream commit 1a0e880b028f97478dc689e2900b312741d0d772 ] Both iavf_free_all_tx_resources() and iavf_free_all_rx_resources() have already been called in the very same function. Remove the duplicate calls. Signed-off-by: Stefan Assmann Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6289b028b5e21974b1761206d4c49d88a766a5af Author: Alexey Kardashevskiy Date: Mon Mar 1 17:36:53 2021 +1100 powerpc/iommu: Annotate nested lock for lockdep [ Upstream commit cc7130bf119add37f36238343a593b71ef6ecc1e ] The IOMMU table is divided into pools for concurrent mappings and each pool has a separate spinlock. When taking the ownership of an IOMMU group to pass through a device to a VM, we lock these spinlocks which triggers a false negative warning in lockdep (below). This fixes it by annotating the large pool's spinlock as a nest lock which makes lockdep not complaining when locking nested locks if the nest lock is locked already. === WARNING: possible recursive locking detected 5.11.0-le_syzkaller_a+fstn1 #100 Not tainted -------------------------------------------- qemu-system-ppc/4129 is trying to acquire lock: c0000000119bddb0 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 but task is already holding lock: c0000000119bdd30 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(p->lock)/1); lock(&(p->lock)/1); === Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210301063653.51003-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit bece6aea3653729d517299f9c5e83bf7d23319cd Author: Lee Gibson Date: Mon Apr 19 15:58:42 2021 +0100 qtnfmac: Fix possible buffer overflow in qtnf_event_handle_external_auth [ Upstream commit 130f634da1af649205f4a3dd86cbe5c126b57914 ] Function qtnf_event_handle_external_auth calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210419145842.345787-1-leegib@gmail.com Signed-off-by: Sasha Levin commit ededc7325dc204db4cfdfe9325c5543f0d9a5c05 Author: Gustavo A. R. Silva Date: Wed Apr 14 18:45:15 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_mgmt_join [ Upstream commit bb43e5718d8f1b46e7a77e7b39be3c691f293050 ] Fix the following out-of-bounds warnings by adding a new structure wl3501_req instead of duplicating the same members in structure wl3501_join_req and wl3501_scan_confirm: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [25, 95] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 22 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_req drivers/net/wireless/wl3501_cs.o struct wl3501_req { u16 beacon_period; /* 0 2 */ u16 dtim_period; /* 2 2 */ u16 cap_info; /* 4 2 */ u8 bss_type; /* 6 1 */ u8 bssid[6]; /* 7 6 */ struct iw_mgmt_essid_pset ssid; /* 13 34 */ struct iw_mgmt_ds_pset ds_pset; /* 47 3 */ struct iw_mgmt_cf_pset cf_pset; /* 50 8 */ struct iw_mgmt_ibss_pset ibss_pset; /* 58 4 */ struct iw_mgmt_data_rset bss_basic_rset; /* 62 10 */ /* size: 72, cachelines: 2, members: 10 */ /* last cacheline: 8 bytes */ }; $ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o struct wl3501_join_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ struct iw_mgmt_data_rset operational_rset; /* 4 10 */ u16 reserved2; /* 14 2 */ u16 timeout; /* 16 2 */ u16 probe_delay; /* 18 2 */ u8 timestamp[8]; /* 20 8 */ u8 local_time[8]; /* 28 8 */ struct wl3501_req req; /* 36 72 */ /* size: 108, cachelines: 2, members: 10 */ /* last cacheline: 44 bytes */ }; $ pahole -C wl3501_scan_confirm drivers/net/wireless/wl3501_cs.o struct wl3501_scan_confirm { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ u16 status; /* 4 2 */ char timestamp[8]; /* 6 8 */ char localtime[8]; /* 14 8 */ struct wl3501_req req; /* 22 72 */ /* --- cacheline 1 boundary (64 bytes) was 30 bytes ago --- */ u8 rssi; /* 94 1 */ /* size: 96, cachelines: 2, members: 8 */ /* padding: 1 */ /* last cacheline: 32 bytes */ }; The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). Now that a new struct wl3501_req enclosing all those adjacent members is introduced, memcpy() doesn't overrun the length of &sig.beacon_period and &this->bss_set[i].beacon_period, because the address of the new struct object _req_ is used as the destination, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1fbaf516da763b50edac47d792a9145aa4482e29.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit 83a7ed5b891cd2afec3f4bf8ffa641b6acb18fb2 Author: Gustavo A. R. Silva Date: Wed Apr 14 18:43:19 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_send_pkt [ Upstream commit 820aa37638a252b57967bdf4038a514b1ab85d45 ] Fix the following out-of-bounds warnings by enclosing structure members daddr and saddr into new struct addr, in structures wl3501_md_req and wl3501_md_ind: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o struct wl3501_md_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 pri; /* 8 1 */ u8 service_class; /* 9 1 */ struct { u8 daddr[6]; /* 10 6 */ u8 saddr[6]; /* 16 6 */ } addr; /* 10 12 */ /* size: 22, cachelines: 1, members: 8 */ /* last cacheline: 22 bytes */ }; $ pahole -C wl3501_md_ind drivers/net/wireless/wl3501_cs.o struct wl3501_md_ind { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 reception; /* 8 1 */ u8 pri; /* 9 1 */ u8 service_class; /* 10 1 */ struct { u8 daddr[6]; /* 11 6 */ u8 saddr[6]; /* 17 6 */ } addr; /* 11 12 */ /* size: 24, cachelines: 1, members: 9 */ /* padding: 1 */ /* last cacheline: 24 bytes */ }; The problem is that the original code is trying to copy data into a couple of arrays adjacent to each other in a single call to memcpy(). Now that a new struct _addr_ enclosing those two adjacent arrays is introduced, memcpy() doesn't overrun the length of &sig.daddr[0] and &sig.daddr, because the address of the new struct object _addr_ is used, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/d260fe56aed7112bff2be5b4d152d03ad7b78e78.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit f3a5dee0f30c898cc9273265d5f5b6bac94d49e8 Author: Sean Christopherson Date: Tue Apr 6 15:49:45 2021 -0700 crypto: ccp: Free SEV device if SEV init fails [ Upstream commit b61a9071dc72a3c709192c0c00ab87c2b3de1d94 ] Free the SEV device if later initialization fails. The memory isn't technically leaked as it's tracked in the top-level device's devres list, but unless the top-level device is removed, the memory won't be freed and is effectively leaked. Signed-off-by: Sean Christopherson Message-Id: <20210406224952.4177376-2-seanjc@google.com> Reviewed-by: Brijesh Singh Acked-by: Tom Lendacky Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 22ab352fcab7e6f4a5dd1a919b4b47b137ff507b Author: Felix Fietkau Date: Thu Apr 15 21:07:53 2021 +0200 mt76: mt7615: fix entering driver-own state on mt7663 [ Upstream commit 5c7d374444afdeb9dd534a37c4f6c13af032da0c ] Fixes hardware wakeup issues Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5b02d6efdb1bd2c4b06224067c2a8280f6fa0b79 Author: Jinzhou Su Date: Tue Apr 20 16:17:14 2021 +0800 drm/amdgpu: Add mem sync flag for IB allocated by SA [ Upstream commit 5c88e3b86a88f14efa0a3ddd28641c6ff49fb9c4 ] The buffer of SA bo will be used by many cases. So it's better to invalidate the cache of indirect buffer allocated by SA before commit the IB. Signed-off-by: Jinzhou Su Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8be5e713f725c9072cc2a4433d6ea8bae9fffbf3 Author: Dingchen (David) Zhang Date: Mon Jan 25 18:05:50 2021 -0500 drm/amd/display: add handling for hdcp2 rx id list validation [ Upstream commit 4ccf9446b2a3615615045346c97f8a1e2a16568a ] [why] the current implementation of hdcp2 rx id list validation does not have handler/checker for invalid message status, e.g. HMAC, the V parameter calculated from PSP not matching the V prime from Rx. [how] return a generic FAILURE for any message status not SUCCESS or REVOKED. Signed-off-by: Dingchen (David) Zhang Reviewed-by: Bhawanpreet Lakha Acked-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fa9952e854c4e083f83894d99f7410541dbccc80 Author: Robin Singh Date: Mon Dec 14 19:14:48 2020 -0500 drm/amd/display: fixed divide by zero kernel crash during dsc enablement [ Upstream commit 19cc1f3829567e7dca21c1389ea6407b8f5efab4 ] [why] During dsc enable, a divide by zero condition triggered the kernel crash. [how] An IGT test, which enable the DSC, was crashing at the time of restore the default dsc status, becaue of h_totals value becoming 0. So add a check before divide condition. If h_total is zero, gracefully ignore and set the default value. kernel panic log: [ 128.758827] divide error: 0000 [#1] PREEMPT SMP NOPTI [ 128.762714] CPU: 5 PID: 4562 Comm: amd_dp_dsc Tainted: G W 5.4.19-android-x86_64 #1 [ 128.769728] Hardware name: ADVANCED MICRO DEVICES, INC. Mauna/Mauna, BIOS WMN0B13N Nov 11 2020 [ 128.777695] RIP: 0010:hubp2_vready_at_or_After_vsync+0x37/0x7a [amdgpu] [ 128.785707] Code: 80 02 00 00 48 89 f3 48 8b 7f 08 b ...... [ 128.805696] RSP: 0018:ffffad8f82d43628 EFLAGS: 00010246 ...... [ 128.857707] CR2: 00007106d8465000 CR3: 0000000426530000 CR4: 0000000000140ee0 [ 128.865695] Call Trace: [ 128.869712] hubp3_setup+0x1f/0x7f [amdgpu] [ 128.873705] dcn20_update_dchubp_dpp+0xc8/0x54a [amdgpu] [ 128.877706] dcn20_program_front_end_for_ctx+0x31d/0x463 [amdgpu] [ 128.885706] dc_commit_state+0x3d2/0x658 [amdgpu] [ 128.889707] amdgpu_dm_atomic_commit_tail+0x4b3/0x1e7c [amdgpu] [ 128.897699] ? dm_read_reg_func+0x41/0xb5 [amdgpu] [ 128.901707] ? dm_read_reg_func+0x41/0xb5 [amdgpu] [ 128.905706] ? __is_insn_slot_addr+0x43/0x48 [ 128.909706] ? fill_plane_buffer_attributes+0x29e/0x3dc [amdgpu] [ 128.917705] ? dm_plane_helper_prepare_fb+0x255/0x284 [amdgpu] [ 128.921700] ? usleep_range+0x7c/0x7c [ 128.925705] ? preempt_count_sub+0xf/0x18 [ 128.929706] ? _raw_spin_unlock_irq+0x13/0x24 [ 128.933732] ? __wait_for_common+0x11e/0x18f [ 128.937705] ? _raw_spin_unlock_irq+0x13/0x24 [ 128.941706] ? __wait_for_common+0x11e/0x18f [ 128.945705] commit_tail+0x8b/0xd2 [drm_kms_helper] [ 128.949707] drm_atomic_helper_commit+0xd8/0xf5 [drm_kms_helper] [ 128.957706] amdgpu_dm_atomic_commit+0x337/0x360 [amdgpu] [ 128.961705] ? drm_atomic_check_only+0x543/0x68d [drm] [ 128.969705] ? drm_atomic_set_property+0x760/0x7af [drm] [ 128.973704] ? drm_mode_atomic_ioctl+0x6f3/0x85a [drm] [ 128.977705] drm_mode_atomic_ioctl+0x6f3/0x85a [drm] [ 128.985705] ? drm_atomic_set_property+0x7af/0x7af [drm] [ 128.989706] drm_ioctl_kernel+0x82/0xda [drm] [ 128.993706] drm_ioctl+0x225/0x319 [drm] [ 128.997707] ? drm_atomic_set_property+0x7af/0x7af [drm] [ 129.001706] ? preempt_count_sub+0xf/0x18 [ 129.005713] amdgpu_drm_ioctl+0x4b/0x76 [amdgpu] [ 129.009705] vfs_ioctl+0x1d/0x2a [ 129.013705] do_vfs_ioctl+0x419/0x43d [ 129.017707] ksys_ioctl+0x52/0x71 [ 129.021707] __x64_sys_ioctl+0x16/0x19 [ 129.025706] do_syscall_64+0x78/0x85 [ 129.029705] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Robin Singh Reviewed-by: Harry Wentland Reviewed-by: Robin Singh Acked-by: Aurabindo Pillai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d98b03bfd0c7a4d19825f611afd620c4a77e9093 Author: Michael Ellerman Date: Sun Apr 18 23:54:13 2021 +1000 powerpc/pseries: Stop calling printk in rtas_stop_self() [ Upstream commit ed8029d7b472369a010a1901358567ca3b6dbb0d ] RCU complains about us calling printk() from an offline CPU: ============================= WARNING: suspicious RCU usage 5.12.0-rc7-02874-g7cf90e481cb8 #1 Not tainted ----------------------------- kernel/locking/lockdep.c:3568 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/0/0. stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7-02874-g7cf90e481cb8 #1 Call Trace: dump_stack+0xec/0x144 (unreliable) lockdep_rcu_suspicious+0x124/0x144 __lock_acquire+0x1098/0x28b0 lock_acquire+0x128/0x600 _raw_spin_lock_irqsave+0x6c/0xc0 down_trylock+0x2c/0x70 __down_trylock_console_sem+0x60/0x140 vprintk_emit+0x1a8/0x4b0 vprintk_func+0xcc/0x200 printk+0x40/0x54 pseries_cpu_offline_self+0xc0/0x120 arch_cpu_idle_dead+0x54/0x70 do_idle+0x174/0x4a0 cpu_startup_entry+0x38/0x40 rest_init+0x268/0x388 start_kernel+0x748/0x790 start_here_common+0x1c/0x614 Which happens because by the time we get to rtas_stop_self() we are already offline. In addition the message can be spammy, and is not that helpful for users, so remove it. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210418135413.1204031-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 799c3950680a748355bc62f835ab5608b99c2288 Author: Yaqi Chen Date: Fri Apr 16 23:48:03 2021 +0800 samples/bpf: Fix broken tracex1 due to kprobe argument change [ Upstream commit 137733d08f4ab14a354dacaa9a8fc35217747605 ] >From commit c0bbbdc32feb ("__netif_receive_skb_core: pass skb by reference"), the first argument passed into __netif_receive_skb_core has changed to reference of a skb pointer. This commit fixes by using bpf_probe_read_kernel. Signed-off-by: Yaqi Chen Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210416154803.37157-1-chendotjs@gmail.com Signed-off-by: Sasha Levin commit d4b0dc31df991d347ff4be55db8e43f95ab75868 Author: Du Cheng Date: Sat Apr 17 07:30:46 2021 +0800 net: sched: tapr: prevent cycle_time == 0 in parse_taprio_schedule [ Upstream commit ed8157f1ebf1ae81a8fa2653e3f20d2076fad1c9 ] There is a reproducible sequence from the userland that will trigger a WARN_ON() condition in taprio_get_start_time, which causes kernel to panic if configured as "panic_on_warn". Catch this condition in parse_taprio_schedule to prevent this condition. Reported as bug on syzkaller: https://syzkaller.appspot.com/bug?extid=d50710fd0873a9c6b40c Reported-by: syzbot+d50710fd0873a9c6b40c@syzkaller.appspotmail.com Signed-off-by: Du Cheng Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 05916c62f54a9ae714beca5f97d28e8753b2782e Author: Gustavo A. R. Silva Date: Fri Apr 16 15:15:40 2021 -0500 ethtool: ioctl: Fix out-of-bounds warning in store_link_ksettings_for_user() [ Upstream commit c1d9e34e11281a8ba1a1c54e4db554232a461488 ] Fix the following out-of-bounds warning: net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds] The problem is that the original code is trying to copy data into a some struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &link_usettings.base. Fix this by directly using &link_usettings and _from_ as destination and source addresses, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b506357ab8bb63259d4eb578d052d7e1ef0b679f Author: David Ward Date: Sun Apr 18 09:46:58 2021 -0400 ASoC: rt286: Generalize support for ALC3263 codec [ Upstream commit aa2f9c12821e6a4ba1df4fb34a3dbc6a2a1ee7fe ] The ALC3263 codec on the XPS 13 9343 is also found on the Latitude 13 7350 and Venue 11 Pro 7140. They require the same handling for the combo jack to work with a headset: GPIO pin 6 must be set. The HDA driver always sets this pin on the ALC3263, which it distinguishes by the codec vendor/device ID 0x10ec0288 and PCI subsystem vendor ID 0x1028 (Dell). The ASoC driver does not use PCI, so adapt this check to use DMI to determine if Dell is the system vendor. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=150601 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205961 Signed-off-by: David Ward Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210418134658.4333-6-david.ward@gatech.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33eee468f83ac609dfe9333ee814491fb6d68c5b Author: Srikar Dronamraju Date: Thu Apr 1 21:12:00 2021 +0530 powerpc/smp: Set numa node before updating mask [ Upstream commit 6980d13f0dd189846887bbbfa43793d9a41768d3 ] Geethika reported a trace when doing a dlpar CPU add. ------------[ cut here ]------------ WARNING: CPU: 152 PID: 1134 at kernel/sched/topology.c:2057 CPU: 152 PID: 1134 Comm: kworker/152:1 Not tainted 5.12.0-rc5-master #5 Workqueue: events cpuset_hotplug_workfn NIP: c0000000001cfc14 LR: c0000000001cfc10 CTR: c0000000007e3420 REGS: c0000034a08eb260 TRAP: 0700 Not tainted (5.12.0-rc5-master+) MSR: 8000000000029033 CR: 28828422 XER: 00000020 CFAR: c0000000001fd888 IRQMASK: 0 #012GPR00: c0000000001cfc10 c0000034a08eb500 c000000001f35400 0000000000000027 #012GPR04: c0000035abaa8010 c0000035abb30a00 0000000000000027 c0000035abaa8018 #012GPR08: 0000000000000023 c0000035abaaef48 00000035aa540000 c0000035a49dffe8 #012GPR12: 0000000028828424 c0000035bf1a1c80 0000000000000497 0000000000000004 #012GPR16: c00000000347a258 0000000000000140 c00000000203d468 c000000001a1a490 #012GPR20: c000000001f9c160 c0000034adf70920 c0000034aec9fd20 0000000100087bd3 #012GPR24: 0000000100087bd3 c0000035b3de09f8 0000000000000030 c0000035b3de09f8 #012GPR28: 0000000000000028 c00000000347a280 c0000034aefe0b00 c0000000010a2a68 NIP [c0000000001cfc14] build_sched_domains+0x6a4/0x1500 LR [c0000000001cfc10] build_sched_domains+0x6a0/0x1500 Call Trace: [c0000034a08eb500] [c0000000001cfc10] build_sched_domains+0x6a0/0x1500 (unreliable) [c0000034a08eb640] [c0000000001d1e6c] partition_sched_domains_locked+0x3ec/0x530 [c0000034a08eb6e0] [c0000000002936d4] rebuild_sched_domains_locked+0x524/0xbf0 [c0000034a08eb7e0] [c000000000296bb0] rebuild_sched_domains+0x40/0x70 [c0000034a08eb810] [c000000000296e74] cpuset_hotplug_workfn+0x294/0xe20 [c0000034a08ebc30] [c000000000178dd0] process_one_work+0x300/0x670 [c0000034a08ebd10] [c0000000001791b8] worker_thread+0x78/0x520 [c0000034a08ebda0] [c000000000185090] kthread+0x1a0/0x1b0 [c0000034a08ebe10] [c00000000000ccec] ret_from_kernel_thread+0x5c/0x70 Instruction dump: 7d2903a6 4e800421 e8410018 7f67db78 7fe6fb78 7f45d378 7f84e378 7c681b78 3c62ff1a 3863c6f8 4802dc35 60000000 <0fe00000> 3920fff4 f9210070 e86100a0 ---[ end trace 532d9066d3d4d7ec ]--- Some of the per-CPU masks use cpu_cpu_mask as a filter to limit the search for related CPUs. On a dlpar add of a CPU, update cpu_cpu_mask before updating the per-CPU masks. This will ensure the cpu_cpu_mask is updated correctly before its used in setting the masks. Setting the numa_node will ensure that when cpu_cpu_mask() gets called, the correct node number is used. This code movement helped fix the above call trace. Reported-by: Geetika Moolchandani Signed-off-by: Srikar Dronamraju Reviewed-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210401154200.150077-1-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 245f5ab5ce5226aaaa5173c59e5fa89ea4219b41 Author: Gustavo A. R. Silva Date: Fri Apr 16 14:31:51 2021 -0500 flow_dissector: Fix out-of-bounds warning in __skb_flow_bpf_to_target() [ Upstream commit 1e3d976dbb23b3fce544752b434bdc32ce64aabc ] Fix the following out-of-bounds warning: net/core/flow_dissector.c:835:3: warning: 'memcpy' offset [33, 48] from the object at 'flow_keys' is out of the bounds of referenced subobject 'ipv6_src' with type '__u32[4]' {aka 'unsigned int[4]'} at offset 16 [-Warray-bounds] The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d5716625f185be6960732694eb9d37bca9073464 Author: Gustavo A. R. Silva Date: Fri Apr 16 14:12:36 2021 -0500 sctp: Fix out-of-bounds warning in sctp_process_asconf_param() [ Upstream commit e5272ad4aab347dde5610c0aedb786219e3ff793 ] Fix the following out-of-bounds warning: net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the object at 'addr' is out of the bounds of referenced subobject 'v4' with type 'struct sockaddr_in' at offset 0 [-Warray-bounds] This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 136b0261f119884cc8662e7d10866166a877cbd3 Author: Kai Vehmanen Date: Fri Apr 16 16:11:57 2021 +0300 ALSA: hda/hdmi: fix race in handling acomp ELD notification at resume [ Upstream commit 0c37e2eb6b83e375e8a654d01598292d5591fc65 ] When snd-hda-codec-hdmi is used with ASoC HDA controller like SOF (acomp used for ELD notifications), display connection change done during suspend, can be lost due to following sequence of events: 1. system in S3 suspend 2. DP/HDMI receiver connected 3. system resumed 4. HDA controller resumed, but card->deferred_resume_work not complete 5. acomp eld_notify callback 6. eld_notify ignored as power state is not CTL_POWER_D0 7. HDA resume deferred work completed, power state set to CTL_POWER_D0 This results in losing the notification, and the jack state reported to user-space is not correct. The check on step 6 was added in commit 8ae743e82f0b ("ALSA: hda - Skip ELD notification during system suspend"). It would seem with the deferred resume logic in ASoC core, this check is not safe. Fix the issue by modifying the check to use "dev.power.power_state.event" instead of ALSA specific card power state variable. BugLink: https://github.com/thesofproject/linux/issues/2825 Suggested-by: Takashi Iwai Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210416131157.1881366-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4ac5823083fa08edfd80808eb1437a343567b49f Author: Vamshi Krishna Gopal Date: Thu Apr 15 12:50:09 2021 -0500 ASoC: Intel: sof_sdw: add quirk for new ADL-P Rvp [ Upstream commit d25bbe80485f8bcbbeb91a2a6cd8798c124b27b7 ] Add quirks for jack detection, rt711 DAI and DMIC Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Signed-off-by: Vamshi Krishna Gopal Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210415175013.192862-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e3a2982bf63fc00e42d46a6f8cd4e964cf11d438 Author: Takashi Iwai Date: Fri Apr 16 10:12:11 2021 +0200 ALSA: hda/realtek: Add quirk for Lenovo Ideapad S740 [ Upstream commit 26928ca1f06aab4361eb5adbe7ef3b5c82f13cf2 ] Lenovo Ideapad S740 requires quite a few COEF setups to make its speakers working. The verb table was provided from Ryan Prescott as the result of investigation via qemu: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver BugLink: https://github.com/thesofproject/linux/issues/2748 Tested-by: Ryan Prescott Link: https://lore.kernel.org/r/20210416081211.20059-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cc1956f8b278d72df4bf81eee934afc01d15fe5a Author: Mihai Moldovan Date: Thu Apr 15 09:28:03 2021 +0200 kconfig: nconf: stop endless search loops [ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 06b0037e6f02e79172d97c823f50ee2362183d0e Author: Yonghong Song Date: Tue Apr 13 08:34:13 2021 -0700 selftests: Set CC to clang in lib.mk if LLVM is set [ Upstream commit 26e6dd1072763cd5696b75994c03982dde952ad9 ] selftests/bpf/Makefile includes lib.mk. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed lib.mk issue which sets CC to gcc in all cases. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210413153413.3027426-1-yhs@fb.com Signed-off-by: Sasha Levin commit f9bc5e3f3f756d9a55fe950f975748d51130dcca Author: Anthony Wang Date: Wed Mar 31 11:03:35 2021 -0400 drm/amd/display: Force vsync flip when reconfiguring MPCC [ Upstream commit 56d63782af9bbd1271bff1422a6a013123eade4d ] [Why] Underflow observed when disabling PIP overlay in-game when vsync is disabled, due to OTC master lock not working with game pipe which is immediate flip. [How] When performing a full update, override flip_immediate value to false for all planes, so that flip occurs on vsync. Signed-off-by: Anthony Wang Acked-by: Bindu Ramamurthy Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 63e9abe35df9415b8d47d9c20358e46251b13e8f Author: Suravee Suthikulpanit Date: Fri Apr 9 03:58:48 2021 -0500 iommu/amd: Remove performance counter pre-initialization test [ Upstream commit 994d6608efe4a4c8834bdc5014c86f4bc6aceea6 ] In early AMD desktop/mobile platforms (during 2013), when the IOMMU Performance Counter (PMC) support was first introduced in commit 30861ddc9cca ("perf/x86/amd: Add IOMMU Performance Counter resource management"), there was a HW bug where the counters could not be accessed. The result was reading of the counter always return zero. At the time, the suggested workaround was to add a test logic prior to initializing the PMC feature to check if the counters can be programmed and read back the same value. This has been working fine until the more recent desktop/mobile platforms start enabling power gating for the PMC, which prevents access to the counters. This results in the PMC support being disabled unnecesarily. Unfortunatly, there is no documentation of since which generation of hardware the original PMC HW bug was fixed. Although, it was fixed soon after the first introduction of the PMC. Base on this, we assume that the buggy platforms are less likely to be in used, and it should be relatively safe to remove this legacy logic. Link: https://lore.kernel.org/linux-iommu/alpine.LNX.3.20.13.2006030935570.3181@monopod.intra.ispras.ru/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753 Cc: Tj (Elloe Linux) Cc: Shuah Khan Cc: Alexander Monakov Cc: David Coe Cc: Paul Menzel Signed-off-by: Suravee Suthikulpanit Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20210409085848.3908-3-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 1097ecf826bcfc961eb4d93eb6ce58ec8c066b68 Author: Paul Menzel Date: Fri Apr 9 03:58:47 2021 -0500 Revert "iommu/amd: Fix performance counter initialization" [ Upstream commit 715601e4e36903a653cd4294dfd3ed0019101991 ] This reverts commit 6778ff5b21bd8e78c8bd547fd66437cf2657fd9b. The original commit tries to address an issue, where PMC power-gating causing the IOMMU PMC pre-init test to fail on certain desktop/mobile platforms where the power-gating is normally enabled. There have been several reports that the workaround still does not guarantee to work, and can add up to 100 ms (on the worst case) to the boot process on certain platforms such as the MSI B350M MORTAR with AMD Ryzen 3 2200G. Therefore, revert this commit as a prelude to removing the pre-init test. Link: https://lore.kernel.org/linux-iommu/alpine.LNX.3.20.13.2006030935570.3181@monopod.intra.ispras.ru/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753 Cc: Tj (Elloe Linux) Cc: Shuah Khan Cc: Alexander Monakov Cc: David Coe Signed-off-by: Paul Menzel Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20210409085848.3908-2-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a027e6155bb4d7e9e8ad89838f52ab629de26fe5 Author: Kuninori Morimoto Date: Thu Apr 8 13:28:38 2021 +0900 ASoC: rsnd: call rsnd_ssi_master_clk_start() from rsnd_ssi_init() [ Upstream commit a122a116fc6d8fcf2f202dcd185173a54268f239 ] Current rsnd needs to call .prepare (P) for clock settings, .trigger for playback start (S) and stop (E). It should be called as below from SSI point of view. P -> S -> E -> P -> S -> E -> ... But, if you used MIXer, below case might happen (2) 1: P -> S ---> E -> ... 2: P ----> S -> ... (1) (3) P(1) setups clock, but E(2) resets it. and starts playback (3). In such case, it will reports "SSI parent/child should use same rate". rsnd_ssi_master_clk_start() which is the main function at (P) was called from rsnd_ssi_init() (= S) before, but was moved by below patch to rsnd_soc_dai_prepare() (= P) to avoid using clk_get_rate() which shouldn't be used under atomic context. commit 4d230d1271064 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") Because of above patch, rsnd_ssi_master_clk_start() is now called at (P) which is for non atomic context. But (P) is assuming that spin lock is *not* used. One issue now is rsnd_ssi_master_clk_start() is checking ssi->xxx which should be protected by spin lock. After above patch, adg.c had below patch for other reasons. commit 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under atomic context") clk_get_rate() is used at probe() timing by this patch. In other words, rsnd_ssi_master_clk_start() is no longer using clk_get_rate() any more. This means we can call it from rsnd_ssi_init() (= S) again which is protected by spin lock. This patch re-move it to under spin lock, and solves 1. checking ssi->xxx without spin lock issue. 2. clk setting / device start / device stop race condition. Reported-by: Linh Phung T. Y. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/875z0x1jt5.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cc748965313bddd16944cebd71276d170a65a62f Author: Vaibhav Jain Date: Sun Apr 4 22:01:48 2021 +0530 powerpc/mm: Add cond_resched() while removing hpte mappings [ Upstream commit a5d6a3e73acbd619dd5b7b831762b755f9e2db80 ] While removing large number of mappings from hash page tables for large memory systems as soft-lockup is reported because of the time spent inside htap_remove_mapping() like one below: watchdog: BUG: soft lockup - CPU#8 stuck for 23s! NIP plpar_hcall+0x38/0x58 LR pSeries_lpar_hpte_invalidate+0x68/0xb0 Call Trace: 0x1fffffffffff000 (unreliable) pSeries_lpar_hpte_removebolted+0x9c/0x230 hash__remove_section_mapping+0xec/0x1c0 remove_section_mapping+0x28/0x3c arch_remove_memory+0xfc/0x150 devm_memremap_pages_release+0x180/0x2f0 devm_action_release+0x30/0x50 release_nodes+0x28c/0x300 device_release_driver_internal+0x16c/0x280 unbind_store+0x124/0x170 drv_attr_store+0x44/0x60 sysfs_kf_write+0x64/0x90 kernfs_fop_write+0x1b0/0x290 __vfs_write+0x3c/0x70 vfs_write+0xd4/0x270 ksys_write+0xdc/0x130 system_call+0x5c/0x70 Fix this by adding a cond_resched() to the loop in htap_remove_mapping() that issues hcall to remove hpte mapping. The call to cond_resched() is issued every HZ jiffies which should prevent the soft-lockup from being reported. Suggested-by: Aneesh Kumar K.V Signed-off-by: Vaibhav Jain Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210404163148.321346-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 26f98b2d97a883159fae5b41bfedd5b17c093161 Author: Johannes Berg Date: Tue Mar 30 16:24:58 2021 +0300 iwlwifi: pcie: make cfg vs. trans_cfg more robust [ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ] If we (for example) have a trans_cfg entry in the PCI IDs table, but then don't find a full cfg entry for it in the info table, we fall through to the code that treats the PCI ID table entry as a full cfg entry. This obviously causes crashes later, e.g. when trying to build the firmware name string. Avoid such crashes by using the low bit of the pointer as a tag for trans_cfg entries (automatically using a macro that checks the type when assigning) and then checking that before trying to use the data as a full entry - if it's just a partial entry at that point, fail. Since we're adding some macro magic, also check that the type is in fact either struct iwl_cfg_trans_params or struct iwl_cfg, failing compilation ("initializer element is not constant") if it isn't. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 2bfc47dec5b8b13b16dbab1a266ab9de387ca59b Author: Miklos Szeredi Date: Wed Apr 14 10:40:58 2021 +0200 cuse: prevent clone [ Upstream commit 8217673d07256b22881127bf50dce874d0e51653 ] For cloned connections cuse_channel_release() will be called more than once, resulting in use after free. Prevent device cloning for CUSE, which does not make sense at this point, and highly unlikely to be used in real life. Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 2c20c7d96e45fd9642fe6d12486cda9ef80661df Author: Miklos Szeredi Date: Wed Apr 14 10:40:58 2021 +0200 virtiofs: fix userns [ Upstream commit 0a7419c68a45d2d066b996be5087aa2d07ce80eb ] get_user_ns() is done twice (once in virtio_fs_get_tree() and once in fuse_conn_init()), resulting in a reference leak. Also looks better to use fsc->user_ns (which *should* be the current_user_ns() at this point). Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 87fe0ca09b2632656a6b193a16e6b458695b5c67 Author: Vivek Goyal Date: Tue Apr 6 10:07:06 2021 -0400 fuse: invalidate attrs when page writeback completes [ Upstream commit 3466958beb31a8e9d3a1441a34228ed088b84f3e ] In fuse when a direct/write-through write happens we invalidate attrs because that might have updated mtime/ctime on server and cached mtime/ctime will be stale. What about page writeback path. Looks like we don't invalidate attrs there. To be consistent, invalidate attrs in writeback path as well. Only exception is when writeback_cache is enabled. In that case we strust local mtime/ctime and there is no need to invalidate attrs. Recently users started experiencing failure of xfstests generic/080, geneirc/215 and generic/614 on virtiofs. This happened only newer "stat" utility and not older one. This patch fixes the issue. So what's the root cause of the issue. Here is detailed explanation. generic/080 test does mmap write to a file, closes the file and then checks if mtime has been updated or not. When file is closed, it leads to flushing of dirty pages (and that should update mtime/ctime on server). But we did not explicitly invalidate attrs after writeback finished. Still generic/080 passed so far and reason being that we invalidated atime in fuse_readpages_end(). This is called in fuse_readahead() path and always seems to trigger before mmaped write. So after mmaped write when lstat() is called, it sees that atleast one of the fields being asked for is invalid (atime) and that results in generating GETATTR to server and mtime/ctime also get updated and test passes. But newer /usr/bin/stat seems to have moved to using statx() syscall now (instead of using lstat()). And statx() allows it to query only ctime or mtime (and not rest of the basic stat fields). That means when querying for mtime, fuse_update_get_attr() sees that mtime is not invalid (only atime is invalid). So it does not generate a new GETATTR and fill stat with cached mtime/ctime. And that means updated mtime is not seen by xfstest and tests start failing. Invalidating attrs after writeback completion should solve this problem in a generic manner. Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit f1c230d75b47a7f368bf1ef2af7444b5def1ef48 Author: Shayne Chen Date: Thu Apr 1 10:31:29 2021 +0800 mt76: mt7915: fix txpower init for TSSI off chips [ Upstream commit a226ccd04c479ccd23d6927c64bad1b441707f70 ] Fix incorrect txpower init value for TSSI off chips which causes too small txpower. Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7eb1e84cfe2813467eae7cafad55c591a57a8780 Author: David Bauer Date: Sun Feb 7 16:09:17 2021 +0100 mt76: mt76x0: disable GTK offloading [ Upstream commit 4b36cc6b390f18dbc59a45fb4141f90d7dfe2b23 ] When operating two VAP on a MT7610 with encryption (PSK2, SAE, OWE), only the first one to be created will transmit properly encrypteded frames. All subsequently created VAPs will sent out frames with the payload left unencrypted, breaking multicast traffic (ICMP6 NDP) and potentially disclosing information to a third party. Disable GTK offloading and encrypt these frames in software to circumvent this issue. THis only seems to be necessary on MT7610 chips, as MT7612 is not affected from our testing. Signed-off-by: David Bauer Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bbd3d0014cc4e8bfd15631140e46d4ea2f224efa Author: Sander Vanheule Date: Tue Feb 2 09:59:53 2021 +0100 mt76: mt7615: support loading EEPROM for MT7613BE [ Upstream commit 858ebf446bee7d5077bd99488aae617908c3f4fe ] EEPROM blobs for MT7613BE radios start with (little endian) 0x7663, which is also the PCI device ID for this device. The EEPROM is required for the radio to work at useful power levels, otherwise only the lowest power level is available. Suggested-by: Georgi Vlaev Tested-by: Stijn Segers Signed-off-by: Sander Vanheule Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 32b3e7e303bd4d4de3dcea0b3eef6d80788e250e Author: Po-Hao Huang Date: Fri Mar 19 13:42:16 2021 +0800 rtw88: 8822c: add LC calibration for RTL8822C [ Upstream commit 7ae7784ec2a812c07d2ca91a6538ef2470154fb6 ] Fix power tracking issue by replacing unnecessary IQ calibration with LC calibration. When thermal difference exceeds limitation, let RF circuit adjsut its characteristic to fit in current environment. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210319054218.3319-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 28c2a1d650885a6855c495262c6957723bbfac17 Author: Krzysztof Kozlowski Date: Thu Apr 8 21:50:29 2021 +0200 pinctrl: samsung: use 'int' for register masks in Exynos [ Upstream commit fa0c10a5f3a49130dd11281aa27e7e1c8654abc7 ] The Special Function Registers on all Exynos SoC, including ARM64, are 32-bit wide, so entire driver uses matching functions like readl() or writel(). On 64-bit ARM using unsigned long for register masks: 1. makes little sense as immediately after bitwise operation it will be cast to 32-bit value when calling writel(), 2. is actually error-prone because it might promote other operands to 64-bit. Addresses-Coverity: Unintentional integer overflow Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki Link: https://lore.kernel.org/r/20210408195029.69974-1-krzysztof.kozlowski@canonical.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2eac474900d352ee8d4bdcd4f32fbec06b4dfc61 Author: Emmanuel Grumbach Date: Thu Apr 8 14:31:25 2021 +0200 mac80211: clear the beacon's CRC after channel switch [ Upstream commit d6843d1ee283137723b4a8c76244607ce6db1951 ] After channel switch, we should consider any beacon with a CSA IE as a new switch. If the CSA IE is a leftover from before the switch that the AP forgot to remove, we'll get a CSA-to-Self. This caused issues in iwlwifi where the firmware saw a beacon with a CSA-to-Self with mode = 1 on the new channel after a switch. The firmware considered this a new switch and closed its queues. Since the beacon didn't change between before and after the switch, we wouldn't handle it (the CRC is the same) and we wouldn't let the firmware open its queues again or disconnect if the CSA IE stays for too long. Clear the CRC valid state after we switch to make sure that we handle the beacon and handle the CSA IE as required. Signed-off-by: Emmanuel Grumbach Link: https://lore.kernel.org/r/20210408143124.b9e68aa98304.I465afb55ca2c7d59f7bf610c6046a1fd732b4c28@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 437a4746e47e17bbc7b33931187528514ad9e1aa Author: Mike Marciniszyn Date: Mon Mar 29 09:54:09 2021 -0400 IB/hfi1: Correct oversized ring allocation [ Upstream commit b536d4b2a279733f440c911dc831764690b90050 ] The completion ring for tx is using the wrong size to size the ring, oversizing the ring by two orders of magniture. Correct the allocation size and use kcalloc_node() to allocate the ring. Fix mistaken GFP defines in similar allocations. Link: https://lore.kernel.org/r/1617026056-50483-4-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d7592a5c376bf80d8839d4554784f0b85eac3642 Author: Suzuki K Poulose Date: Mon Apr 5 17:42:57 2021 +0100 coresight: Do not scan for graph if none is present [ Upstream commit 2b921b671a8d29c2adb255a86409aad1e3267309 ] If a graph node is not found for a given node, of_get_next_endpoint() will emit the following error message : OF: graph: no port node found in / If the given component doesn't have any explicit connections (e.g, ETE) we could simply ignore the graph parsing. As for any legacy component where this is mandatory, the device will not be usable as before this patch. Updating the DT bindings to Yaml and enabling the schema checks can detect such issues with the DT. Cc: Mike Leach Cc: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20210405164307.1720226-11-suzuki.poulose@arm.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 8f7806174fdbc90688a4159e07ec348f0a171572 Author: Tiezhu Yang Date: Tue Apr 6 17:25:12 2021 +0800 MIPS: Loongson64: Use _CACHE_UNCACHED instead of _CACHE_UNCACHED_ACCELERATED [ Upstream commit 5e65c52ec716af6e8f51dacdaeb4a4d872249af1 ] Loongson64 processors have a writecombine issue that maybe failed to write back framebuffer used with ATI Radeon or AMD GPU at times, after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine mapping for MIPS"), there exists some errors such as blurred screen and lockup, and so on. [ 60.958721] radeon 0000:03:00.0: ring 0 stalled for more than 10079msec [ 60.965315] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000112 last fence id 0x000000000000011d on ring 0) [ 60.976525] radeon 0000:03:00.0: ring 3 stalled for more than 10086msec [ 60.983156] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000374 last fence id 0x00000000000003a8 on ring 3) As discussed earlier [1], it might be better to disable writecombine on the CPU detection side because the root cause is unknown now. Actually, this patch is a temporary solution to just make it work well, it is not a proper and final solution, I hope someone will have a better solution to fix this issue in the future. [1] https://lore.kernel.org/patchwork/patch/1285542/ Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 2c098ad786d36a7e0027f3f33330b07a39de3ea6 Author: Bence Csókás Date: Wed Mar 31 19:19:20 2021 +0000 i2c: Add I2C_AQ_NO_REP_START adapter quirk [ Upstream commit aca01415e076aa96cca0f801f4420ee5c10c660d ] This quirk signifies that the adapter cannot do a repeated START, it always issues a STOP condition after transfers. Suggested-by: Wolfram Sang Signed-off-by: Bence Csókás Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c6d2f8ffb145765b635f1fbcb3832578aaa8309a Author: Hans de Goede Date: Fri Apr 2 16:07:45 2021 +0200 ASoC: rt5670: Add a quirk for the Dell Venue 10 Pro 5055 [ Upstream commit 84cb0d5581b6a7bd5d96013f67e9f2eb0c7b4378 ] Add a quirk with the jack-detect and dmic settings necessary to make jack-detect and the builtin mic work on Dell Venue 10 Pro 5055 tablets. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210402140747.174716-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c9b2de448126fe65d5d3476d2f6fba3f004d195 Author: mark-yw.chen Date: Mon Mar 29 01:18:33 2021 +0800 Bluetooth: btusb: Enable quirk boolean flag for Mediatek Chip. [ Upstream commit 27e554a4fcd84e499bf0a82122b8c4c3f1de38b6 ] Adding support LE scatternet and WBS for Mediatek Chip Signed-off-by: mark-yw.chen Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit c87b052deaa85f173a0bd34f3fdf1adb894f72a8 Author: Paul M Stillwell Jr Date: Tue Mar 2 10:12:05 2021 -0800 ice: handle increasing Tx or Rx ring sizes [ Upstream commit 2ec5638559c13b923250eccf495d2a033fccb3e7 ] There is an issue when the Tx or Rx ring size increases using 'ethtool -L ...' where the new rings don't get the correct ITR values because when we rebuild the VSI we don't know that some of the rings may be new. Fix this by looking at the original number of rings and determining if the rings in ice_vsi_rebuild_set_coalesce() were not present in the original rings received in ice_vsi_rebuild_get_coalesce(). Also change the code to return an error if we can't allocate memory for the coalesce data in ice_vsi_rebuild(). Signed-off-by: Paul M Stillwell Jr Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit eb28709c07a67825c146636a4013aba775bbc12d Author: Hans de Goede Date: Thu Mar 25 23:10:54 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Chuwi Hi8 tablet [ Upstream commit 875c40eadf6ac6644c0f71842a4f30dd9968d281 ] The Chuwi Hi8 tablet is using an analog mic on IN1 and has its jack-detect connected to JD2_IN4N, instead of using the default IN3 for its internal mic and JD1_IN4P for jack-detect. It also only has 1 speaker. Add a quirk applying the correct settings for this configuration. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210325221054.22714-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7bd851a6d3696edd7813f8dd88b8c30feb36fe7f Author: Eric Dumazet Date: Mon Mar 29 12:12:54 2021 -0700 ip6_vti: proper dev_{hold|put} in ndo_[un]init methods [ Upstream commit 40cb881b5aaa0b69a7d93dec8440d5c62dae299f ] After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Therefore, we need to move dev_hold() call from vti6_tnl_create2() to vti6_dev_init_gen() [1] WARNING: CPU: 0 PID: 15951 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 15951 Comm: syz-executor.3 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc90001eaef28 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520003d5dd7 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff88801bb1c568 R13: ffff88801f69e800 R14: 00000000ffffffff R15: ffff888050889d40 FS: 00007fc79314e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1c1ff47108 CR3: 0000000020fd5000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] vti6_dev_uninit+0x31a/0x360 net/ipv6/ip6_vti.c:297 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 vti6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_vti.c:190 vti6_newlink+0x9d/0xd0 net/ipv6/ip6_vti.c:1020 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 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+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b502a6a440667da6b9854ca14bbdac0fca458c58 Author: Yunsheng Lin Date: Mon Mar 29 11:57:50 2021 +0800 net: hns3: add handling for xmit skb with recursive fraglist [ Upstream commit d5d5e0193ee8f88efbbc7f1471087255657bc19a ] Currently hns3 driver only handle the xmit skb with one level of fraglist skb, add handling for multi level by calling hns3_tx_bd_num() recursively when calculating bd num and calling hns3_fill_skb_to_desc() recursively when filling tx desc. When the skb has a fraglist level of 24, the skb is simply dropped and stats.max_recursion_level is added to record the error. Move the stat handling from hns3_nic_net_xmit() to hns3_nic_maybe_stop_tx() in order to handle different error stat and add the 'max_recursion_level' and 'hw_limitation' stat. Note that the max recursive level as 24 is chose according to below: commit 48a1df65334b ("skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow"). And that we are not able to find a testcase to verify the recursive fraglist case, so Fixes tag is not provided. Reported-by: Barry Song Signed-off-by: Yunsheng Lin Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c56804f431db385d4564aee4582ac46520d44434 Author: Guangbin Huang Date: Mon Mar 29 11:57:47 2021 +0800 net: hns3: remediate a potential overflow risk of bd_num_list [ Upstream commit a2ee6fd28a190588e142ad8ea9d40069cd3c9f98 ] The array size of bd_num_list is a fixed value, it may have potential overflow risk when array size of hclge_dfx_bd_offset_list is greater than that fixed value. So modify bd_num_list as a pointer and allocate memory for it according to array size of hclge_dfx_bd_offset_list. Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 286b3ff9fd98eadeea5fde7985d464254c43064a Author: Christophe Leroy Date: Fri Mar 12 12:50:25 2021 +0000 powerpc/32: Statically initialise first emergency context [ Upstream commit a4719f5bb6d7dc220bffdc1b9f5ce5eaa5543581 ] The check of the emergency context initialisation in vmap_stack_overflow is buggy for the SMP case, as it compares r1 with 0 while in the SMP case r1 is offseted by the CPU id. Instead of fixing it, just perform static initialisation of the first emergency context. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/4a67ba422be75713286dca0c86ee0d3df2eb6dfa.1615552867.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit b9f9313c7501cb4fd7a7aac5c9a524b521079d58 Author: Russell Currey Date: Tue Feb 23 17:02:27 2021 +1000 selftests/powerpc: Fix L1D flushing tests for Power10 [ Upstream commit 3a72c94ebfb1f171eba0715998010678a09ec796 ] The rfi_flush and entry_flush selftests work by using the PM_LD_MISS_L1 perf event to count L1D misses. The value of this event has changed over time: - Power7 uses 0x400f0 - Power8 and Power9 use both 0x400f0 and 0x3e054 - Power10 uses only 0x3e054 Rather than relying on raw values, configure perf to count L1D read misses in the most explicit way available. This fixes the selftests to work on systems without 0x400f0 as PM_LD_MISS_L1, and should change no behaviour for systems that the tests already worked on. The only potential downside is that referring to a specific perf event requires PMU support implemented in the kernel for that platform. Signed-off-by: Russell Currey Acked-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210223070227.2916871-1-ruscur@russell.cc Signed-off-by: Sasha Levin commit 2033dde6aa0198b828b53b05011b59fe3902ef04 Author: Archie Pusaka Date: Tue Mar 23 16:32:20 2021 +0800 Bluetooth: check for zapped sk before connecting [ Upstream commit 3af70b39fa2d415dc86c370e5b24ddb9fdacbd6f ] There is a possibility of receiving a zapped sock on l2cap_sock_connect(). This could lead to interesting crashes, one such case is tearing down an already tore l2cap_sock as is happened with this call trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xc4/0x118 lib/dump_stack.c:56 register_lock_class kernel/locking/lockdep.c:792 [inline] register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742 __lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105 lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline] _raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175 spin_lock_bh include/linux/spinlock.h:307 [inline] lock_sock_nested+0x44/0xfa net/core/sock.c:2518 l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345 l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598 l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756 l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429 process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064 worker_thread+0x5a5/0x773 kernel/workqueue.c:2196 kthread+0x291/0x2a6 kernel/kthread.c:211 ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604 Signed-off-by: Archie Pusaka Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Guenter Roeck Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 6421cdfbb6fba9c3ac8e62ad8d3697e4a4e74e0d Author: Nikolay Aleksandrov Date: Mon Mar 22 17:45:27 2021 +0200 net: bridge: when suppression is enabled exclude RARP packets [ Upstream commit 0353b4a96b7a9f60fe20d1b3ebd4931a4085f91c ] Recently we had an interop issue where RARP packets got suppressed with bridge neigh suppression enabled, but the check in the code was meant to suppress GARP. Exclude RARP packets from it which would allow some VMWare setups to work, to quote the report: "Those RARP packets usually get generated by vMware to notify physical switches when vMotion occurs. vMware may use random sip/tip or just use sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep and other times get dropped by the logic" Reported-by: Amer Abdalamer Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fccb35bbf75f50b00a059b61ed38b2497dc50199 Author: Vladimir Oltean Date: Sun Mar 21 23:05:48 2021 +0200 net/sched: cls_flower: use ntohs for struct flow_dissector_key_ports [ Upstream commit 6215afcb9a7e35cef334dc0ae7f998cc72c8465f ] A make W=1 build complains that: net/sched/cls_flower.c:214:20: warning: cast from restricted __be16 net/sched/cls_flower.c:214:20: warning: incorrect type in argument 1 (different base types) net/sched/cls_flower.c:214:20: expected unsigned short [usertype] val net/sched/cls_flower.c:214:20: got restricted __be16 [usertype] dst This is because we use htons on struct flow_dissector_key_ports members src and dst, which are defined as __be16, so they are already in network byte order, not host. The byte swap function for the other direction should have been used. Because htons and ntohs do the same thing (either both swap, or none does), this change has no functional effect except to silence the warnings. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a019b8d7dfd53018e6a7204e1e1d3858f208c964 Author: Tetsuo Handa Date: Mon Mar 22 07:52:07 2021 +0900 Bluetooth: initialize skb_queue_head at l2cap_chan_create() [ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ] syzbot is hitting "INFO: trying to register non-static key." message [1], for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when l2cap_chan_del() is called due to e.g. timeout. Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create() immediately after "struct l2cap_chan" is allocated using kzalloc(), let's as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there. [1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842 Reported-and-tested-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit e0dc9e93f7fd908351d66acac6f3e71699d58ec8 Author: Archie Pusaka Date: Mon Mar 22 14:02:15 2021 +0800 Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default [ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ] Currently l2cap_chan_set_defaults() reset chan->conf_state to zero. However, there is a flag CONF_NOT_COMPLETE which is set when creating the l2cap_chan. It is suggested that the flag should be cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults() is called, l2cap_chan is not yet ready. Therefore, we must set this flag as the default. Example crash call trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xc4/0x118 lib/dump_stack.c:56 panic+0x1c6/0x38b kernel/panic.c:117 __warn+0x170/0x1b9 kernel/panic.c:471 warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494 debug_print_object+0x175/0x193 lib/debugobjects.c:260 debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614 debug_timer_assert_init kernel/time/timer.c:629 [inline] debug_assert_init kernel/time/timer.c:677 [inline] del_timer+0x7c/0x179 kernel/time/timer.c:1034 try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230 cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929 l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834 l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640 l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756 l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174 l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217 __sock_release+0xda/0x217 net/socket.c:580 sock_close+0x1b/0x1f net/socket.c:1039 __fput+0x322/0x55c fs/file_table.c:208 ____fput+0x17/0x19 fs/file_table.c:244 task_work_run+0x19b/0x1d3 kernel/task_work.c:115 exit_task_work include/linux/task_work.h:21 [inline] do_exit+0xe4c/0x204a kernel/exit.c:766 do_group_exit+0x291/0x291 kernel/exit.c:891 get_signal+0x749/0x1093 kernel/signal.c:2396 do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737 exit_to_usermode_loop arch/x86/entry/common.c:243 [inline] prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277 syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348 int_ret_from_sys_call+0x25/0xa3 Signed-off-by: Archie Pusaka Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Guenter Roeck Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit b972f345a17a25bad9dcc0631d3e10bb0fb707fe Author: Takashi Sakamoto Date: Sun Mar 21 12:28:31 2021 +0900 ALSA: bebob: enable to deliver MIDI messages for multiple ports [ Upstream commit d2b6f15bc18ac8fbce25398290774c21f5b2cd44 ] Current implementation of bebob driver doesn't correctly handle the case that the device has multiple MIDI ports. The cause is the number of MIDI conformant data channels is passed to AM824 data block processing layer. This commit fixes the bug. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210321032831.340278-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d398f25007d57663bf439691ab5c4bde0e1fc864 Author: Tong Zhang Date: Sun Mar 21 11:38:40 2021 -0400 ALSA: rme9652: don't disable if not enabled [ Upstream commit f57a741874bb6995089020e97a1dcdf9b165dcbe ] rme9652 wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.751595] snd_rme9652 0000:00:03.0: disabling already-disabled device [ 1.751605] WARNING: CPU: 0 PID: 174 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.759968] Call Trace: [ 1.760145] snd_rme9652_card_free+0x76/0xa0 [snd_rme9652] [ 1.760434] release_card_device+0x4b/0x80 [snd] [ 1.760679] device_release+0x3b/0xa0 [ 1.760874] kobject_put+0x94/0x1b0 [ 1.761059] put_device+0x13/0x20 [ 1.761235] snd_card_free+0x61/0x90 [snd] [ 1.761454] snd_rme9652_probe+0x3be/0x700 [snd_rme9652] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-4-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9df07b0661e7793e54464f9f115eba25397d0d5c Author: Tong Zhang Date: Sun Mar 21 11:38:39 2021 -0400 ALSA: hdspm: don't disable if not enabled [ Upstream commit 790f5719b85e12e10c41753b864e74249585ed08 ] hdspm wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.786391] snd_hdspm 0000:00:03.0: disabling already-disabled device [ 1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.795181] Call Trace: [ 1.795320] snd_hdspm_card_free+0x58/0xa0 [snd_hdspm] [ 1.795595] release_card_device+0x4b/0x80 [snd] [ 1.795860] device_release+0x3b/0xa0 [ 1.796072] kobject_put+0x94/0x1b0 [ 1.796260] put_device+0x13/0x20 [ 1.796438] snd_card_free+0x61/0x90 [snd] [ 1.796659] snd_hdspm_probe+0x97b/0x1440 [snd_hdspm] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-3-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a950cd8cb05d358fcbcd84c1a0c4760351adc82a Author: Tong Zhang Date: Sun Mar 21 11:38:38 2021 -0400 ALSA: hdsp: don't disable if not enabled [ Upstream commit 507cdb9adba006a7798c358456426e1aea3d9c4f ] hdsp wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.758292] snd_hdsp 0000:00:03.0: disabling already-disabled device [ 1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.766985] Call Trace: [ 1.767121] snd_hdsp_card_free+0x94/0xf0 [snd_hdsp] [ 1.767388] release_card_device+0x4b/0x80 [snd] [ 1.767639] device_release+0x3b/0xa0 [ 1.767838] kobject_put+0x94/0x1b0 [ 1.768027] put_device+0x13/0x20 [ 1.768207] snd_card_free+0x61/0x90 [snd] [ 1.768430] snd_hdsp_probe+0x524/0x5e0 [snd_hdsp] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-2-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit faed3150a4368d8c199d3d93340410af672c2237 Author: Wolfram Sang Date: Fri Mar 12 12:57:34 2021 +0100 i2c: bail out early when RDWR parameters are wrong [ Upstream commit 71581562ee36032d2d574a9b23ad4af6d6a64cf7 ] The buggy parameters currently get caught later, but emit a noisy WARN. Userspace should not be able to trigger this, so add similar checks much earlier. Also avoids some unneeded code paths, of course. Apply kernel coding stlye to a comment while here. Reported-by: syzbot+ffb0b3ffa6cfbc7d7b3f@syzkaller.appspotmail.com Tested-by: syzbot+ffb0b3ffa6cfbc7d7b3f@syzkaller.appspotmail.com Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 18df2bc13b1f0bce0338ccc77b184a2fa6a6645e Author: Ayush Garg Date: Wed Mar 17 16:52:14 2021 +0530 Bluetooth: Fix incorrect status handling in LE PHY UPDATE event [ Upstream commit 87df8bcccd2cede62dfb97dc3d4ca1fe66cb4f83 ] Skip updation of tx and rx PHYs values, when PHY Update event's status is not successful. Signed-off-by: Ayush Garg Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 879a96d817ed7268712ed65e6551ed4654d86ce8 Author: Mikhail Durnev Date: Tue Mar 16 14:47:35 2021 +1000 ASoC: rsnd: core: Check convert rate in rsnd_hw_params [ Upstream commit 19c6a63ced5e07e40f3a5255cb1f0fe0d3be7b14 ] snd_pcm_hw_params_set_rate_near can return incorrect sample rate in some cases, e.g. when the backend output rate is set to some value higher than 48000 Hz and the input rate is 8000 Hz. So passing the value returned by snd_pcm_hw_params_set_rate_near to snd_pcm_hw_params will result in "FSO/FSI ratio error" and playing no audio at all while the userland is not properly notified about the issue. If SRC is unable to convert the requested sample rate to the sample rate the backend is using, then the requested sample rate should be adjusted in rsnd_hw_params. The userland will be notified about that change in the returned hw_params structure. Signed-off-by: Mikhail Durnev Link: https://lore.kernel.org/r/1615870055-13954-1-git-send-email-mikhail_durnev@mentor.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2aeb5de26c1800e530b29e9a157c92c5a827293 Author: Jonathan McDowell Date: Sat Mar 13 13:18:26 2021 +0000 net: stmmac: Set FIFO sizes for ipq806x [ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ] Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") started using the TX FIFO size to verify what counts as a valid MTU request for the stmmac driver. This is unset for the ipq806x variant. Looking at older patches for this it seems the RX + TXs buffers can be up to 8k, so set appropriately. (I sent this as an RFC patch in June last year, but received no replies. I've been running with this on my hardware (a MikroTik RB3011) since then with larger MTUs to support both the internal qca8k switch and VLANs with no problems. Without the patch it's impossible to set the larger MTU required to support this.) Signed-off-by: Jonathan McDowell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c0a62a441bbdd2cb90c6e366f185d32f554f840b Author: Maxim Mikityanskiy Date: Fri Jan 29 18:43:31 2021 +0200 net/mlx5e: Use net_prefetchw instead of prefetchw in MPWQE TX datapath [ Upstream commit 991b2654605b455a94dac73e14b23480e7e20991 ] Commit e20f0dbf204f ("net/mlx5e: RX, Add a prefetch command for small L1_CACHE_BYTES") switched to using net_prefetchw at all places in mlx5e. In the same time frame, commit 5af75c747e2a ("net/mlx5e: Enhanced TX MPWQE for SKBs") added one more usage of prefetchw. When these two changes were merged, this new occurrence of prefetchw wasn't replaced with net_prefetchw. This commit fixes this last occurrence of prefetchw in mlx5e_tx_mpwqe_session_start, making the same change that was done in mlx5e_xdp_mpwqe_session_start. Signed-off-by: Maxim Mikityanskiy Reviewed-by: Saeed Mahameed Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 2d17c58a3a4f8dc4e7e770ebcdf4041eff67560f Author: Hans de Goede Date: Fri Mar 12 12:48:50 2021 +0100 ASoC: Intel: bytcr_rt5640: Enable jack-detect support on Asus T100TAF [ Upstream commit b7c7203a1f751348f35fc4bcb157572d303f7573 ] The Asus T100TAF uses the same jack-detect settings as the T100TA, this has been confirmed on actual hardware. Add these settings to the T100TAF quirks to enable jack-detect support on the T100TAF. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210312114850.13832-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d1bede85632a6330bacb77a90eeeb5a956a78d0 Author: Hoang Le Date: Thu Mar 11 10:33:22 2021 +0700 tipc: convert dest node's address to network order [ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ] (struct tipc_link_info)->dest is in network order (__be32), so we must convert the value to network order before assigning. The problem detected by sparse: net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types) net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest net/tipc/netlink_compat.c:699:24: got int Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a407b5881686a3c08902d54d958e28f7bad4070a Author: Alexander Aring Date: Mon Mar 1 17:05:19 2021 -0500 fs: dlm: flush swork on shutdown [ Upstream commit eec054b5a7cfe6d1f1598a323b05771ee99857b5 ] This patch fixes the flushing of send work before shutdown. The function cancel_work_sync() is not the right workqueue functionality to use here as it would cancel the work if the work queues itself. In cases of EAGAIN in send() for dlm message we need to be sure that everything is send out before. The function flush_work() will ensure that every send work is be done inclusive in EAGAIN cases. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ff58d1c72edfc000b3a4ec9d5c963023ef869999 Author: Alexander Aring Date: Mon Mar 1 17:05:17 2021 -0500 fs: dlm: check on minimum msglen size [ Upstream commit 710176e8363f269c6ecd73d203973b31ace119d3 ] This patch adds an additional check for minimum dlm header size which is an invalid dlm message and signals a broken stream. A msglen field cannot be less than the dlm header size because the field is inclusive header lengths. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ca973d2aeaf70c15e6663be3f71ba1b17a127051 Author: Alexander Aring Date: Mon Mar 1 17:05:12 2021 -0500 fs: dlm: add errno handling to check callback [ Upstream commit 8aa9540b49e0833feba75dbf4f45babadd0ed215 ] This allows to return individual errno values for the config attribute check callback instead of returning invalid argument only. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 06d59d21cb05765e72a53b53a86c6be106bece88 Author: Alexander Aring Date: Mon Mar 1 17:05:08 2021 -0500 fs: dlm: fix debugfs dump [ Upstream commit 92c48950b43f4a767388cf87709d8687151a641f ] This patch fixes the following message which randomly pops up during glocktop call: seq_file: buggy .next function table_seq_next did not update position index The issue is that seq_read_iter() in fs/seq_file.c also needs an increment of the index in an non next record case as well which this patch fixes otherwise seq_read_iter() will print out the above message. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit bd6017a942b9343c1e6a99eef9c64fa264a1a53b Author: Pradeep Kumar Chitrapu Date: Thu Feb 18 10:27:08 2021 -0800 ath11k: fix thermal temperature read [ Upstream commit e3de5bb7ac1a4cb262f8768924fd3ef6182b10bb ] Fix dangling pointer in thermal temperature event which causes incorrect temperature read. Tested-on: IPQ8074 AHB WLAN.HK.2.4.0.1-00041-QCAHKSWPL_SILICONZ-1 Signed-off-by: Pradeep Kumar Chitrapu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210218182708.8844-1-pradeepc@codeaurora.org Signed-off-by: Sasha Levin commit 21756f878e827784213df136e678fed0ce9f0e30 Author: David Matlack Date: Thu May 6 15:24:43 2021 +0000 kvm: Cap halt polling at kvm->max_halt_poll_ns commit 258785ef08b323bddd844b4926a32c2b2045a1b0 upstream. When growing halt-polling, there is no check that the poll time exceeds the per-VM limit. It's possible for vcpu->halt_poll_ns to grow past kvm->max_halt_poll_ns and stay there until a halt which takes longer than kvm->halt_poll_ns. Signed-off-by: David Matlack Signed-off-by: Venkatesh Srinivas Message-Id: <20210506152442.4010298-1-venkateshs@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 53d7eed0315a7e6eaf8664c11c123095cf356ece Author: Rafael J. Wysocki Date: Wed Apr 21 19:40:56 2021 +0200 cpufreq: intel_pstate: Use HWP if enabled by platform firmware commit e5af36b2adb858e982d78d41d7363d05d951a19a upstream. It turns out that there are systems where HWP is enabled during initialization by the platform firmware (BIOS), but HWP EPP support is not advertised. After commit 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported") intel_pstate refuses to use HWP on those systems, but the fallback PERF_CTL interface does not work on them either because of enabled HWP, and once enabled, HWP cannot be disabled. Consequently, the users of those systems cannot control CPU performance scaling. Address this issue by making intel_pstate use HWP unconditionally if it is enabled already when the driver starts. Fixes: 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported") Reported-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Cc: 5.9+ # 5.9+ Signed-off-by: Greg Kroah-Hartman commit 182f1f72af2e6803f1470a7e16a76ef0c63cc124 Author: Tony Lindgren Date: Wed May 5 14:09:15 2021 +0300 PM: runtime: Fix unpaired parent child_count for force_resume commit c745253e2a691a40c66790defe85c104a887e14a upstream. As pm_runtime_need_not_resume() relies also on usage_count, it can return a different value in pm_runtime_force_suspend() compared to when called in pm_runtime_force_resume(). Different return values can happen if anything calls PM runtime functions in between, and causes the parent child_count to increase on every resume. So far I've seen the issue only for omapdrm that does complicated things with PM runtime calls during system suspend for legacy reasons: omap_atomic_commit_tail() for omapdrm.0 dispc_runtime_get() wakes up 58000000.dss as it's the dispc parent dispc_runtime_resume() rpm_resume() increases parent child_count dispc_runtime_put() won't idle, PM runtime suspend blocked pm_runtime_force_suspend() for 58000000.dss, !pm_runtime_need_not_resume() __update_runtime_status() system suspended pm_runtime_force_resume() for 58000000.dss, pm_runtime_need_not_resume() pm_runtime_enable() only called because of pm_runtime_need_not_resume() omap_atomic_commit_tail() for omapdrm.0 dispc_runtime_get() wakes up 58000000.dss as it's the dispc parent dispc_runtime_resume() rpm_resume() increases parent child_count dispc_runtime_put() won't idle, PM runtime suspend blocked ... rpm_suspend for 58000000.dss but parent child_count is now unbalanced Let's fix the issue by adding a flag for needs_force_resume and use it in pm_runtime_force_resume() instead of pm_runtime_need_not_resume(). Additionally omapdrm system suspend could be simplified later on to avoid lots of unnecessary PM runtime calls and the complexity it adds. The driver can just use internal functions that are shared between the PM runtime and system suspend related functions. Fixes: 4918e1f87c5f ("PM / runtime: Rework pm_runtime_force_suspend/resume()") Signed-off-by: Tony Lindgren Reviewed-by: Ulf Hansson Tested-by: Tomi Valkeinen Cc: 4.16+ # 4.16+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e97da47e9be04b6cc98451bd6cac779d1f1a74dc Author: Sumeet Pawnikar Date: Tue May 11 23:31:42 2021 +0530 ACPI: PM: Add ACPI ID of Alder Lake Fan commit 2404b8747019184002823dba7d2f0ecf89d802b7 upstream. Add a new unique fan ACPI device ID for Alder Lake to support it in acpi_dev_pm_attach() function. Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake") Signed-off-by: Sumeet Pawnikar Acked-by: Zhang Rui Cc: 5.10+ # 5.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bfccc4eade2bec1493f891ebcd3c6751eee971c9 Author: Lai Jiangshan Date: Tue May 4 21:50:14 2021 +0200 KVM/VMX: Invoke NMI non-IST entry instead of IST entry commit a217a6593cec8b315d4c2f344bae33660b39b703 upstream. In VMX, the host NMI handler needs to be invoked after NMI VM-Exit. Before commit 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect call instead of INTn"), this was done by INTn ("int $2"). But INTn microcode is relatively expensive, so the commit reworked NMI VM-Exit handling to invoke the kernel handler by function call. But this missed a detail. The NMI entry point for direct invocation is fetched from the IDT table and called on the kernel stack. But on 64-bit the NMI entry installed in the IDT expects to be invoked on the IST stack. It relies on the "NMI executing" variable on the IST stack to work correctly, which is at a fixed position in the IST stack. When the entry point is unexpectedly called on the kernel stack, the RSP-addressed "NMI executing" variable is obviously also on the kernel stack and is "uninitialized" and can cause the NMI entry code to run in the wrong way. Provide a non-ist entry point for VMX which shares the C-function with the regular NMI entry and invoke the new asm entry point instead. On 32-bit this just maps to the regular NMI entry point as 32-bit has no ISTs and is not affected. [ tglx: Made it independent for backporting, massaged changelog ] Fixes: 1a5488ef0dcf6 ("KVM: VMX: Invoke NMI handler via indirect call instead of INTn") Signed-off-by: Lai Jiangshan Signed-off-by: Thomas Gleixner Tested-by: Lai Jiangshan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87r1imi8i1.ffs@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit 21f317826e170c1cf03944d7ce7b9142c238fb71 Author: Sean Christopherson Date: Thu Jan 14 16:40:51 2021 -0800 KVM: x86/mmu: Remove the defunct update_pte() paging hook commit c5e2184d1544f9e56140791eff1a351bea2e63b9 upstream. Remove the update_pte() shadow paging logic, which was obsoleted by commit 4731d4c7a077 ("KVM: MMU: out of sync shadow core"), but never removed. As pointed out by Yu, KVM never write protects leaf page tables for the purposes of shadow paging, and instead marks their associated shadow page as unsync so that the guest can write PTEs at will. The update_pte() path, which predates the unsync logic, optimizes COW scenarios by refreshing leaf SPTEs when they are written, as opposed to zapping the SPTE, restarting the guest, and installing the new SPTE on the subsequent fault. Since KVM no longer write-protects leaf page tables, update_pte() is unreachable and can be dropped. Reported-by: Yu Zhang Signed-off-by: Sean Christopherson Message-Id: <20210115004051.4099250-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 53171e68a509f185d38c6df9fb9727e3ca90348c Author: Jarkko Sakkinen Date: Mon May 10 15:28:31 2021 +0300 tpm, tpm_tis: Reserve locality in tpm_tis_resume() commit 8a2d296aaebadd68d9c1f6908667df1d1c84c051 upstream. Reserve locality in tpm_tis_resume(), as it could be unsert after waking up from a sleep state. Cc: stable@vger.kernel.org Cc: Lino Sanfilippo Reported-by: Hans de Goede Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 923866165610d831fe6f5e53379bd57dfa553697 Author: Jarkko Sakkinen Date: Mon May 10 15:28:30 2021 +0300 tpm, tpm_tis: Extend locality handling to TPM2 in tpm_tis_gen_interrupt() commit e630af7dfb450d1c00c30077314acf33032ff9e4 upstream. The earlier fix (linked) only partially fixed the locality handling bug in tpm_tis_gen_interrupt(), i.e. only for TPM 1.x. Extend the locality handling to cover TPM2. Cc: Hans de Goede Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-integrity/20210220125534.20707-1-jarkko@kernel.org/ Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Reported-by: Lino Sanfilippo Signed-off-by: Jarkko Sakkinen Tested-by: Lino Sanfilippo Signed-off-by: Greg Kroah-Hartman commit 8fe5a459186a2895041e97ae8c265d79725aaed5 Author: Zhen Lei Date: Wed May 12 21:39:26 2021 +0800 tpm: fix error return code in tpm2_get_cc_attrs_tbl() commit 1df83992d977355177810c2b711afc30546c81ce upstream. If the total number of commands queried through TPM2_CAP_COMMANDS is different from that queried through TPM2_CC_GET_CAPABILITY, it indicates an unknown error. In this case, an appropriate error code -EFAULT should be returned. However, we currently do not explicitly assign this error code to 'rc'. As a result, 0 was incorrectly returned. Cc: stable@vger.kernel.org Fixes: 58472f5cd4f6("tpm: validate TPM 2.0 commands") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 31c9a4b24d86cbb36ff0d7a085725a3b4f0138c8 Author: Colin Ian King Date: Fri Apr 30 12:37:24 2021 +0100 KEYS: trusted: Fix memory leak on object td commit 83a775d5f9bfda95b1c295f95a3a041a40c7f321 upstream. Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] Cc: stable@vger.kernel.org Fixes: 5df16caada3f ("KEYS: trusted: Fix incorrect handling of tpm_get_random()") Signed-off-by: Colin Ian King Reviewed-by: Nick Desaulniers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman