commit d1105a680e66b0482bd18048534c58ecabb5c284 Author: Greg Kroah-Hartman Date: Thu Sep 15 10:47:20 2022 +0200 Linux 5.19.9 Link: https://lore.kernel.org/r/20220913140410.043243217@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Fenil Jain Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 7e64f6423dc0ab61f34ed04f62b3fb29d49ef322 Author: Saaem Rizvi Date: Mon Jun 20 10:25:19 2022 -0400 drm/amd/display: Removing assert statements for Linux commit 149f6d1a6035a7aa6595ac6eeb9c8f566b2103cd upstream. [WHY] Assert statements causing several bugs on Linux DM [HOW] Removing assert statement for Linux DM (ASSERT(result == VBIOSSMC_Result_OK)). Also adding logging statements for setting dcfclk. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216092 Fixes: c1b972a18d05 ("drm/amd/display: Insert pulling smu busy status before sending another request") Reviewed-by: Gabe Teeger Acked-by: Solomon Chiu Signed-off-by: Saaem Rizvi Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 56bd559bb9d591c15e24ed80f3350d2605bbc452 Author: Saaem Rizvi Date: Thu Jun 9 15:34:43 2022 -0400 drm/amd/display: Add SMU logging code commit 4b33b5ffcf68de3a43e7dddc91c5dc86e6ed8587 upstream. [WHY] Logging for SMU response value after the wait allows us to know immediately what the response value was. Makes it easier to debug should the value be anything other than OK. [HOW] Using the the already available DC SMU logging functions. Tested-by: Daniel Wheeler Reviewed-by: Charlene Liu Acked-by: Rodrigo Siqueira Signed-off-by: Saaem Rizvi Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 32e4b8dbc9119c07ea1888e72c8a5681b82e180c Author: Jason Gunthorpe Date: Fri Sep 9 16:46:31 2022 -0300 iommu: Fix false ownership failure on AMD systems with PASID activated commit 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a upstream. The AMD IOMMU driver cannot activate PASID mode on a RID without the RID's translation being set to IDENTITY. Further it requires changing the RID's page table layout from the normal v1 IOMMU_DOMAIN_IDENTITY layout to a different v2 layout. It does this by creating a new iommu_domain, configuring that domain for v2 identity operation and then attaching it to the group, from within the driver. This logic assumes the group is already set to the IDENTITY domain and is being used by the DMA API. However, since the ownership logic is based on the group's domain pointer equaling the default domain to detect DMA API ownership, this causes it to look like the group is not attached to the DMA API any more. This blocks attaching drivers to any other devices in the group. In a real system this manifests itself as the HD-audio devices on some AMD platforms losing their device drivers. Work around this unique behavior of the AMD driver by checking for equality of IDENTITY domains based on their type, not their pointer value. This allows the AMD driver to have two IDENTITY domains for internal purposes without breaking the check. Have the AMD driver properly declare that the special domain it created is actually an IDENTITY domain. Cc: Robin Murphy Cc: stable@vger.kernel.org Fixes: 512881eacfa7 ("bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management") Reported-by: Takashi Iwai Tested-by: Takashi Iwai Signed-off-by: Jason Gunthorpe Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/0-v1-ea566e16b06b+811-amd_owner_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 77a2d61334f715293c20f4fa30df035fd870fba4 Author: Jean-Philippe Brucker Date: Thu Aug 25 16:46:24 2022 +0100 iommu/virtio: Fix interaction with VFIO commit 91c98fe7941499e4127cdc359c30841b873dd43a upstream. Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") requires IOMMU drivers to advertise IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does not provide to userspace the ability to maintain coherency through cache invalidations, it requires hardware coherency. Advertise the capability in order to restore VFIO support. The meaning of IOMMU_CAP_CACHE_COHERENCY also changed from "IOMMU can enforce cache coherent DMA transactions" to "IOMMU_CACHE is supported". While virtio-iommu cannot enforce coherency (of PCIe no-snoop transactions), it does support IOMMU_CACHE. We can distinguish different cases of non-coherent DMA: (1) When accesses from a hardware endpoint are not coherent. The host would describe such a device using firmware methods ('dma-coherent' in device-tree, '_CCA' in ACPI), since they are also needed without a vIOMMU. In this case mappings are created without IOMMU_CACHE. virtio-iommu doesn't need any additional support. It sends the same requests as for coherent devices. (2) When the physical IOMMU supports non-cacheable mappings. Supporting those would require a new feature in virtio-iommu, new PROBE request property and MAP flags. Device drivers would use a new API to discover this since it depends on the architecture and the physical IOMMU. (3) When the hardware supports PCIe no-snoop. It is possible for assigned PCIe devices to issue no-snoop transactions, and the virtio-iommu specification is lacking any mention of this. Arm platforms don't necessarily support no-snoop, and those that do cannot enforce coherency of no-snoop transactions. Device drivers must be careful about assuming that no-snoop transactions won't end up cached; see commit e02f5c1bb228 ("drm: disable uncached DMA optimization for ARM and arm64"). On x86 platforms, the host may or may not enforce coherency of no-snoop transactions with the physical IOMMU. But according to the above commit, on x86 a driver which assumes that no-snoop DMA is compatible with uncached CPU mappings will also work if the host enforces coherency. Although these issues are not specific to virtio-iommu, it could be used to facilitate discovery and configuration of no-snoop. This would require a new feature bit, PROBE property and ATTACH/MAP flags. Cc: stable@vger.kernel.org Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") Signed-off-by: Jean-Philippe Brucker Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20220825154622.86759-1-jean-philippe@linaro.org Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 420d2045715588ad44cd7d806864a223b4fc05c9 Author: Lu Baolu Date: Tue Aug 23 14:15:55 2022 +0800 iommu/vt-d: Correctly calculate sagaw value of IOMMU commit 53fc7ad6edf210b497230ce74b61b322a202470c upstream. The Intel IOMMU driver possibly selects between the first-level and the second-level translation tables for DMA address translation. However, the levels of page-table walks for the 4KB base page size are calculated from the SAGAW field of the capability register, which is only valid for the second-level page table. This causes the IOMMU driver to stop working if the hardware (or the emulated IOMMU) advertises only first-level translation capability and reports the SAGAW field as 0. This solves the above problem by considering both the first level and the second level when calculating the supported page table levels. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20220817023558.3253263-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit ded16152d248646c3e878fb37a4cc5b1a2dcce91 Author: Mark Brown Date: Mon Sep 5 15:22:55 2022 +0100 arm64/bti: Disable in kernel BTI when cross section thunks are broken commit c0a454b9044fdc99486853aa424e5b3be2107078 upstream. GCC does not insert a `bti c` instruction at the beginning of a function when it believes that all callers reach the function through a direct branch[1]. Unfortunately the logic it uses to determine this is not sufficiently robust, for example not taking account of functions being placed in different sections which may be loaded separately, so we may still see thunks being generated to these functions. If that happens, the first instruction in the callee function will result in a Branch Target Exception due to the missing landing pad. While this has currently only been observed in the case of modules having their main code loaded sufficiently far from their init section to require thunks it could potentially happen for other cases so the safest thing is to disable BTI for the kernel when building with an affected toolchain. [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 Reported-by: D Scott Phillips [Bits of the commit message are lifted from his report & workaround] Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220905142255.591990-1-broonie@kernel.org Cc: # v5.10+ Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 7d40396e6d7374e1c8bfb9dd3a1146f69375b96b Author: Eugene Shalygin Date: Fri Sep 9 17:56:53 2022 +0200 hwmon: (asus-ec-sensors) autoload module via DMI data [ Upstream commit 88700d1396bae72d9a4c23a48bbd98c1c2f53f3d ] Replace autoloading data based on the ACPI EC device with the DMI records for motherboards models. The ACPI method created a bug that when this driver returns error from the probe function because of the unsupported motherboard model, the ACPI subsystem concludes that the EC device does not work properly. Fixes: 5cd29012028d ("hwmon: (asus-ec-sensors) introduce ec_board_info struct for board data") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216412 Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2121844 Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220909155654.123398-2-eugene.shalygin@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 447fb910846cff8322ccacd3db9d37fa55e71c79 Author: Urs Schroffenegger Date: Sun Jul 10 22:26:39 2022 +0200 hwmon: (asus-ec-sensors) add definitions for ROG ZENITH II EXTREME [ Upstream commit 9992b19d756ab8f0889fcaf3e71ff93852e74694 ] Add definitions for ROG ZENITH II EXTREME and some unknown yet temperature sensors in the second EC bank. Details are available at [1, 2]. [1] https://github.com/zeule/asus-ec-sensors/pull/26 [2] https://github.com/zeule/asus-ec-sensors/issues/16 Signed-off-by: Urs Schroffenegger Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220710202639.1812058-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin commit 26464ff5cc8e30a603b986b7937c0659ed0c4e13 Author: Eugene Shalygin Date: Sun Jul 10 10:55:38 2022 +0200 hwmon: (asus-ec-sensors) add missing sensors for X570-I GAMING [ Upstream commit 1c4e4f4a0e8d9ebe8be1c838fec4fb7053a989d9 ] VRM and chipset temperature for ROG STRIX X570-I GAMING were missing according to a user contribution to the LHM project [1]. [1] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/pull/767 Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220710085539.1682869-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin commit 667cada538dac67e833b8cf7b9f919fa28cd2603 Author: Michael Carns Date: Tue Jun 28 00:54:36 2022 +0200 hwmon: (asus-ec-sensors) add support for Maximus XI Hero [ Upstream commit 8f9eb10ff71d8e3beeee3f8d19050223600faf85 ] Add definitions for ROG MAXIMUS XI HERO and ROG MAXIMUS XI HERO (WI-FI) boards. Signed-off-by: Michael Carns Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220627225437.87462-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin commit 4091d4f487e49aaea985fbd8163940b5800c8dd7 Author: Shady Nawara Date: Fri Jun 3 14:27:58 2022 +0200 hwmon: (asus-ec-sensors) add support for Strix Z690-a D4 [ Upstream commit bae26b801f98bc902ab4a43c96947f3a0ce4f3a0 ] adds T_Sensor and VRM Temp sensors for the Asus Strix z690-a D4 motherboard Signed-off-by: Shady Nawara Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220603122758.1561064-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin commit c4a068c4e0528fac0d805f1d5f191f7b5695ae90 Author: Sasha Levin Date: Mon Sep 12 07:07:56 2022 -0400 Revert "arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags"" This reverts commit add4bc9281e8704e5ab15616b429576c84f453a2. On Mon, Sep 12, 2022 at 10:52:45AM +0100, Catalin Marinas wrote: >I missed this (holidays) and it looks like it's in stable already. On >its own it will likely break kasan_hw if used together with user-space >MTE as this change relies on two previous commits: > >70c248aca9e7 ("mm: kasan: Skip unpoisoning of user pages") >6d05141a3930 ("mm: kasan: Skip page unpoisoning only if __GFP_SKIP_KASAN_UNPOISON") > >The reason I did not cc stable is that there are other dependencies in >this area. The potential issues without the above commits were rather >theoretical, so take these patches rather as clean-ups/refactoring than >fixes. Signed-off-by: Sasha Levin commit 2652720096eab15009b8ac1c84a1ae7941a90920 Author: Zhengjun Xing Date: Fri Aug 26 22:00:57 2022 +0800 perf stat: Fix L2 Topdown metrics disappear for raw events [ Upstream commit f0c86a2bae4fd12bfa8bad4d43fb59fb498cdd14 ] In perf/Documentation/perf-stat.txt, for "--td-level" the default "0" means the max level that the current hardware support. So we need initialize the stat_config.topdown_level to TOPDOWN_MAX_LEVEL when “--td-level=0” or no “--td-level” option. Otherwise, for the hardware with a max level is 2, the 2nd level metrics disappear for raw events in this case. The issue cannot be observed for the perf stat default or "--topdown" options. This commit fixes the raw events issue and removes the duplicated code for the perf stat default. Before: # ./perf stat -e "cpu-clock,context-switches,cpu-migrations,page-faults,instructions,cycles,ref-cycles,branches,branch-misses,{slots,topdown-retiring,topdown-bad-spec,topdown-fe-bound,topdown-be-bound,topdown-heavy-ops,topdown-br-mispredict,topdown-fetch-lat,topdown-mem-bound}" sleep 1 Performance counter stats for 'sleep 1': 1.03 msec cpu-clock # 0.001 CPUs utilized 1 context-switches # 966.216 /sec 0 cpu-migrations # 0.000 /sec 60 page-faults # 57.973 K/sec 1,132,112 instructions # 1.41 insn per cycle 803,872 cycles # 0.777 GHz 1,909,120 ref-cycles # 1.845 G/sec 236,634 branches # 228.640 M/sec 6,367 branch-misses # 2.69% of all branches 4,823,232 slots # 4.660 G/sec 1,210,536 topdown-retiring # 25.1% Retiring 699,841 topdown-bad-spec # 14.5% Bad Speculation 1,777,975 topdown-fe-bound # 36.9% Frontend Bound 1,134,878 topdown-be-bound # 23.5% Backend Bound 189,146 topdown-heavy-ops # 182.756 M/sec 662,012 topdown-br-mispredict # 639.647 M/sec 1,097,048 topdown-fetch-lat # 1.060 G/sec 416,121 topdown-mem-bound # 402.063 M/sec 1.002423690 seconds time elapsed 0.002494000 seconds user 0.000000000 seconds sys After: # ./perf stat -e "cpu-clock,context-switches,cpu-migrations,page-faults,instructions,cycles,ref-cycles,branches,branch-misses,{slots,topdown-retiring,topdown-bad-spec,topdown-fe-bound,topdown-be-bound,topdown-heavy-ops,topdown-br-mispredict,topdown-fetch-lat,topdown-mem-bound}" sleep 1 Performance counter stats for 'sleep 1': 1.13 msec cpu-clock # 0.001 CPUs utilized 1 context-switches # 882.128 /sec 0 cpu-migrations # 0.000 /sec 61 page-faults # 53.810 K/sec 1,137,612 instructions # 1.29 insn per cycle 881,477 cycles # 0.778 GHz 2,093,496 ref-cycles # 1.847 G/sec 236,356 branches # 208.496 M/sec 7,090 branch-misses # 3.00% of all branches 5,288,862 slots # 4.665 G/sec 1,223,697 topdown-retiring # 23.1% Retiring 767,403 topdown-bad-spec # 14.5% Bad Speculation 2,053,322 topdown-fe-bound # 38.8% Frontend Bound 1,244,438 topdown-be-bound # 23.5% Backend Bound 186,665 topdown-heavy-ops # 3.5% Heavy Operations # 19.6% Light Operations 725,922 topdown-br-mispredict # 13.7% Branch Mispredict # 0.8% Machine Clears 1,327,400 topdown-fetch-lat # 25.1% Fetch Latency # 13.7% Fetch Bandwidth 497,775 topdown-mem-bound # 9.4% Memory Bound # 14.1% Core Bound 1.002701530 seconds time elapsed 0.002744000 seconds user 0.000000000 seconds sys Fixes: 63e39aa6ae103451 ("perf stat: Support L2 Topdown events") Reviewed-by: Kan Liang Signed-off-by: Xing Zhengjun Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220826140057.3289401-1-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 61e51bae8386b260e6e71ee5a7bda693556ee4d3 Author: Kan Liang Date: Thu Jul 21 14:57:04 2022 +0800 perf evlist: Always use arch_evlist__add_default_attrs() [ Upstream commit a9c1ecdabc4f2ef04ef5334b8deb3a5c5910136d ] Current perf stat uses the evlist__add_default_attrs() to add the generic default attrs, and uses arch_evlist__add_default_attrs() to add the Arch specific default attrs, e.g., Topdown for x86. It works well for the non-hybrid platforms. However, for a hybrid platform, the hard code generic default attrs don't work. Uses arch_evlist__add_default_attrs() to replace the evlist__add_default_attrs(). The arch_evlist__add_default_attrs() is modified to invoke the same __evlist__add_default_attrs() for the generic default attrs. No functional change. Add default_null_attrs[] to indicate the arch specific attrs. No functional change for the arch specific default attrs either. Signed-off-by: Kan Liang Acked-by: Ian Rogers Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220721065706.2886112-4-zhengjun.xing@linux.intel.com Signed-off-by: Xing Zhengjun Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: f0c86a2bae4f ("perf stat: Fix L2 Topdown metrics disappear for raw events") Signed-off-by: Sasha Levin commit 9516acba29e322202674d18f4dc383879f7813a5 Author: Lu Baolu Date: Sun Sep 11 11:18:45 2022 +0800 iommu/vt-d: Fix possible recursive locking in intel_iommu_init() [ Upstream commit 9cd4f1434479f1ac25c440c421fbf52069079914 ] The global rwsem dmar_global_lock was introduced by commit 3a5670e8ac932 ("iommu/vt-d: Introduce a rwsem to protect global data structures"). It is used to protect DMAR related global data from DMAR hotplug operations. The dmar_global_lock used in the intel_iommu_init() might cause recursive locking issue, for example, intel_iommu_get_resv_regions() is taking the dmar_global_lock from within a section where intel_iommu_init() already holds it via probe_acpi_namespace_devices(). Using dmar_global_lock in intel_iommu_init() could be relaxed since it is unlikely that any IO board must be hot added before the IOMMU subsystem is initialized. This eliminates the possible recursive locking issue by moving down DMAR hotplug support after the IOMMU is initialized and removing the uses of dmar_global_lock in intel_iommu_init(). Fixes: d5692d4af08cd ("iommu/vt-d: Fix suspicious RCU usage in probe_acpi_namespace_devices()") Reported-by: Robin Murphy Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/894db0ccae854b35c73814485569b634237b5538.1657034828.git.robin.murphy@arm.com Link: https://lore.kernel.org/r/20220718235325.3952426-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 53b284a895f020c24a33181c0a7726547ae1e678 Author: Eliav Farber Date: Thu Sep 8 15:24:34 2022 +0000 hwmon: (mr75203) enable polling for all VM channels [ Upstream commit e43212e0f55dc2d6b15d6c174cc0a64b25fab5e7 ] Configure ip-polling register to enable polling for all voltage monitor channels. This enables reading the voltage values for all inputs other than just input 0. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Eliav Farber Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220908152449.35457-7-farbere@amazon.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ad460e86ad864023a6e1d4f67bf51caceb66d1f9 Author: Eliav Farber Date: Thu Sep 8 15:24:33 2022 +0000 hwmon: (mr75203) fix multi-channel voltage reading [ Upstream commit 91a9e063cdcfca8fe642b078d6fae4ce49187975 ] Fix voltage allocation and reading to support all channels in all VMs. Prior to this change allocation and reading were done only for the first channel in each VM. This change counts the total number of channels for allocation, and takes into account the channel offset when reading the sample data register. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Eliav Farber Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220908152449.35457-6-farbere@amazon.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7055f297801f645b6c2d6997dbda005f0ccacbd4 Author: Eliav Farber Date: Thu Sep 8 15:24:32 2022 +0000 hwmon: (mr75203) fix voltage equation for negative source input [ Upstream commit 227a3a2fc31d8e4bb9c88d4804e19530af245b1b ] According to Moortec Embedded Voltage Monitor (MEVM) series 3 data sheet, the minimum input signal is -100mv and maximum input signal is +1000mv. The equation used to convert the digital word to voltage uses mixed types (*val signed and n unsigned), and on 64 bit machines also has different size, since sizeof(u32) = 4 and sizeof(long) = 8. So when measuring a negative input, n will be small enough, such that PVT_N_CONST * n < PVT_R_CONST, and the result of (PVT_N_CONST * n - PVT_R_CONST) will overflow to a very big positive 32 bit number. Then when storing the result in *val it will be the same value just in 64 bit (instead of it representing a negative number which will what happen when sizeof(long) = 4). When -1023 <= (PVT_N_CONST * n - PVT_R_CONST) <= -1 dividing the number by 1024 should result of in 0, but because ">> 10" is used, and the sign bit is used to fill the vacated bit positions, it results in -1 (0xf...fffff) which is wrong. This change fixes the sign problem and supports negative values by casting n to long and replacing the shift right with div operation. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Eliav Farber Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220908152449.35457-5-farbere@amazon.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 8c9fbcaf190a08b04f583302e38b31d6bd4dfdd7 Author: Eliav Farber Date: Thu Sep 8 15:24:31 2022 +0000 hwmon: (mr75203) update pvt->v_num and vm_num to the actual number of used sensors [ Upstream commit bb9195bd6664d94d71647631593e09f705ff5edd ] This issue is relevant when "intel,vm-map" is set in device-tree, and defines a lower number of VMs than actually supported. This change is needed for all places that use pvt->v_num or vm_num later on in the code. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Eliav Farber Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220908152449.35457-4-farbere@amazon.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9c6c9aec6896f06221490d9028d15376d81059fe Author: Eliav Farber Date: Thu Sep 8 15:24:30 2022 +0000 hwmon: (mr75203) fix VM sensor allocation when "intel,vm-map" not defined [ Upstream commit 81114fc3d27bf5b06b2137d2fd2b63da656a8b90 ] Bug - in case "intel,vm-map" is missing in device-tree ,'num' is set to 0, and no voltage channel infos are allocated. The reason num is set to 0 when "intel,vm-map" is missing is to set the entire pvt->vm_idx[] with incremental channel numbers, but it didn't take into consideration that same num is used later in devm_kcalloc(). If "intel,vm-map" does exist there is no need to set the unspecified channels with incremental numbers, because the unspecified channels can't be accessed in pvt_read_in() which is the only other place besides the probe functions that uses pvt->vm_idx[]. This change fixes the bug by moving the incremental channel numbers setting to be done only if "intel,vm-map" property is defined (starting loop from 0), and removing 'num = 0'. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Eliav Farber Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220908152449.35457-3-farbere@amazon.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ee37a7045c76e79fcb4aa8172f8073db9116e4fa Author: Vladimir Oltean Date: Mon Sep 5 20:01:23 2022 +0300 net: dsa: felix: tc-taprio intervals smaller than MTU should send at least one packet [ Upstream commit 11afdc6526de0e0368c05da632a8c0d29fc60bb8 ] The blamed commit broke tc-taprio schedules such as this one: tc qdisc replace dev $swp1 root taprio \ num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 \ sched-entry S 0x7f 990000 \ sched-entry S 0x80 10000 \ flags 0x2 because the gate entry for TC 7 (S 0x80 10000 ns) now has a static guard band added earlier than its 'gate close' event, such that packet overruns won't occur in the worst case of the largest packet possible. Since guard bands are statically determined based on the per-tc QSYS_QMAXSDU_CFG_* with a fallback on the port-based QSYS_PORT_MAX_SDU, we need to discuss what happens with TC 7 depending on kernel version, since the driver, prior to commit 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port"), did not touch QSYS_QMAXSDU_CFG_*, and therefore relied on QSYS_PORT_MAX_SDU. 1 (before vsc9959_tas_guard_bands_update): QSYS_PORT_MAX_SDU defaults to 1518, and at gigabit this introduces a static guard band (independent of packet sizes) of 12144 ns, plus QSYS::HSCH_MISC_CFG.FRM_ADJ (bit time of 20 octets => 160 ns). But this is larger than the time window itself, of 10000 ns. So, the queue system never considers a frame with TC 7 as eligible for transmission, since the gate practically never opens, and these frames are forever stuck in the TX queues and hang the port. 2 (after vsc9959_tas_guard_bands_update): Under the sole goal of enabling oversized frame dropping, we make an effort to set QSYS_QMAXSDU_CFG_7 to 1230 bytes. But QSYS_QMAXSDU_CFG_7 plays one more role, which we did not take into account: per-tc static guard band, expressed in L2 byte time (auto-adjusted for FCS and L1 overhead). There is a discrepancy between what the driver thinks (that there is no guard band, and 100% of min_gate_len[tc] is available for egress scheduling) and what the hardware actually does (crops the equivalent of QSYS_QMAXSDU_CFG_7 ns out of min_gate_len[tc]). In practice, this means that the hardware thinks it has exactly 0 ns for scheduling tc 7. In both cases, even minimum sized Ethernet frames are stuck on egress rather than being considered for scheduling on TC 7, even if they would fit given a proper configuration. Considering the current situation, with vsc9959_tas_guard_bands_update(), frames between 60 octets and 1230 octets in size are not eligible for oversized dropping (because they are smaller than QSYS_QMAXSDU_CFG_7), but won't be considered as eligible for scheduling either, because the min_gate_len[7] (10000 ns) minus the guard band determined by QSYS_QMAXSDU_CFG_7 (1230 octets * 8 ns per octet == 9840 ns) minus the guard band auto-added for L1 overhead by QSYS::HSCH_MISC_CFG.FRM_ADJ (20 octets * 8 ns per octet == 160 octets) leaves 0 ns for scheduling in the queue system proper. Investigating the hardware behavior, it becomes apparent that the queue system needs precisely 33 ns of 'gate open' time in order to consider a frame as eligible for scheduling to a tc. So the solution to this problem is to amend vsc9959_tas_guard_bands_update(), by giving the per-tc guard bands less space by exactly 33 ns, just enough for one frame to be scheduled in that interval. This allows the queue system to make forward progress for that port-tc, and prevents it from hanging. Fixes: 297c4de6f780 ("net: dsa: felix: re-enable TAS guard band mode") Reported-by: Xiaoliang Yang Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c078abef701da227175cf3de0f07abddb0d3b351 Author: Vladimir Oltean Date: Tue Jun 28 17:52:38 2022 +0300 time64.h: consolidate uses of PSEC_PER_NSEC [ Upstream commit 837ced3a1a5d8bb1a637dd584711f31ae6b54d93 ] Time-sensitive networking code needs to work with PTP times expressed in nanoseconds, and with packet transmission times expressed in picoseconds, since those would be fractional at higher than gigabit speed when expressed in nanoseconds. Convert the existing uses in tc-taprio and the ocelot/felix DSA driver to a PSEC_PER_NSEC macro. This macro is placed in include/linux/time64.h as opposed to its relatives (PSEC_PER_SEC etc) from include/vdso/time64.h because the vDSO library does not (yet) need/use it. Cc: Andy Lutomirski Cc: Thomas Gleixner Signed-off-by: Vladimir Oltean Reviewed-by: Vincenzo Frascino # for the vDSO parts Signed-off-by: Jakub Kicinski Stable-dep-of: 11afdc6526de ("net: dsa: felix: tc-taprio intervals smaller than MTU should send at least one packet") Signed-off-by: Sasha Levin commit 1ceb383def1e2da5ebfd62ef5bded9cab999963c Author: Alexander Gordeev Date: Sat Aug 13 19:45:21 2022 +0200 s390/boot: fix absolute zero lowcore corruption on boot [ Upstream commit 12dd19c159659ec9050f45dc8a2ff3c3917f4be3 ] Crash dump always starts on CPU0. In case CPU0 is offline the prefix page is not installed and the absolute zero lowcore is used. However, struct lowcore::mcesad is never assigned and stays zero. That leads to __machine_kdump() -> save_vx_regs() call silently stores vector registers to the absolute lowcore at 0x11b0 offset. Fixes: a62bc0739253 ("s390/kdump: add support for vector extension") Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 7c74f03a623d1d3868e776462406ea69138053f5 Author: John Sperbeck Date: Mon Aug 1 19:22:29 2022 +0000 iommu/amd: use full 64-bit value in build_completion_wait() [ Upstream commit 94a568ce32038d8ff9257004bb4632e60eb43a49 ] We started using a 64 bit completion value. Unfortunately, we only stored the low 32-bits, so a very large completion value would never be matched in iommu_completion_wait(). Fixes: c69d89aff393 ("iommu/amd: Use 4K page for completion wait write-back semaphore") Signed-off-by: John Sperbeck Link: https://lore.kernel.org/r/20220801192229.3358786-1-jsperbeck@google.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f7f13b8d49bf3eff2c98230532e0671195277216 Author: Chao Gao Date: Fri Aug 19 16:45:37 2022 +0800 swiotlb: avoid potential left shift overflow [ Upstream commit 3f0461613ebcdc8c4073e235053d06d5aa58750f ] The second operand passed to slot_addr() is declared as int or unsigned int in all call sites. The left-shift to get the offset of a slot can overflow if swiotlb size is larger than 4G. Convert the macro to an inline function and declare the second argument as phys_addr_t to avoid the potential overflow. Fixes: 26a7e094783d ("swiotlb: refactor swiotlb_tbl_map_single") Signed-off-by: Chao Gao Reviewed-by: Dongli Zhang Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 36512a3ddd39b051c498f2ef7a191bb6d2360ab5 Author: Hangbin Liu Date: Tue Aug 30 17:37:22 2022 +0800 bonding: accept unsolicited NA message [ Upstream commit 592335a4164c3c41f57967223a1e1efe3a0c6eb3 ] The unsolicited NA message with all-nodes multicast dest address should be valid, as this also means the link could reach the target. Also rename bond_validate_ns() to bond_validate_na(). Reported-by: LiLiang Fixes: 5e1eeef69c0f ("bonding: NS target should accept link local address") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 53d3c40591ad632fda84e3a5fb004ca8862c8d2d Author: Vladimir Oltean Date: Sun Jul 31 15:41:05 2022 +0300 net: bonding: replace dev_trans_start() with the jiffies of the last ARP/NS [ Upstream commit 06799a9085e12a778fe2851db550ab5911ad28fe ] The bonding driver piggybacks on time stamps kept by the network stack for the purpose of the netdev TX watchdog, and this is problematic because it does not work with NETIF_F_LLTX devices. It is hard to say why the driver looks at dev_trans_start() of the slave->dev, considering that this is updated even by non-ARP/NS probes sent by us, and even by traffic not sent by us at all (for example PTP on physical slave devices). ARP monitoring in active-backup mode appears to still work even if we track only the last TX time of actual ARP probes. Signed-off-by: Vladimir Oltean Acked-by: Jay Vosburgh Signed-off-by: Jakub Kicinski Stable-dep-of: 592335a4164c ("bonding: accept unsolicited NA message") Signed-off-by: Sasha Levin commit 1749fdc24c54fd90ab1197d2f20c7273acd1136f Author: Przemyslaw Patynowski Date: Tue Aug 9 10:57:44 2022 +0200 i40e: Fix ADQ rate limiting for PF [ Upstream commit 45bb006d3c924b1201ed43c87a96b437662dcaa8 ] Fix HW rate limiting for ADQ. Fallback to kernel queue selection for ADQ, as it is network stack that decides which queue to use for transmit with ADQ configured. Reset PF after creation of VMDq2 VSIs required for ADQ, as to reprogram TX queue contexts in i40e_configure_tx_ring. Without this patch PF would limit TX rate only according to TC0. Fixes: a9ce82f744dc ("i40e: Enable 'channel' mode in mqprio for TC configs") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Jan Sokolowski Tested-by: Bharathi Sreenivas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2b7758a7a9da690f4079a607fd4414d12b4cb8c0 Author: Przemyslaw Patynowski Date: Wed Jun 8 13:52:48 2022 +0200 i40e: Refactor tc mqprio checks [ Upstream commit 2313e69c84c024a85d017a60ae925085de47530a ] Refactor bitwise checks for whether TC MQPRIO is enabled into one single method for improved readability. Signed-off-by: Przemyslaw Patynowski Signed-off-by: Jan Sokolowski Tested-by: Bharathi Sreenivas Signed-off-by: Tony Nguyen Stable-dep-of: 45bb006d3c92 ("i40e: Fix ADQ rate limiting for PF") Signed-off-by: Sasha Levin commit c95624ba520fcaba3fef7562f48f357eaa101eea Author: Masahiro Yamada Date: Thu Sep 1 10:12:52 2022 +0900 kbuild: disable header exports for UML in a straightforward way [ Upstream commit 1b620d539ccc18a1aca1613d9ff078115a7891a1 ] Previously 'make ARCH=um headers' stopped because of missing arch/um/include/uapi/asm/Kbuild. The error is not shown since commit ed102bf2afed ("um: Fix W=1 missing-include-dirs warnings") added arch/um/include/uapi/asm/Kbuild. Hard-code the unsupported architecture, so it works like before. Fixes: ed102bf2afed ("um: Fix W=1 missing-include-dirs warnings") Signed-off-by: Masahiro Yamada Acked-by: Richard Weinberger Signed-off-by: Sasha Levin commit bb6c5b187aaaba95f76275913694982fc9f8e5aa Author: Yang Ling Date: Tue Aug 23 19:17:25 2022 +0800 MIPS: loongson32: ls1c: Fix hang during startup [ Upstream commit 35508d2424097f9b6a1a17aac94f702767035616 ] The RTCCTRL reg of LS1C is obselete. Writing this reg will cause system hang. Fixes: 60219c563c9b6 ("MIPS: Add RTC support for Loongson1C board") Signed-off-by: Yang Ling Tested-by: Keguang Zhang Acked-by: Keguang Zhang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 37a0883c582420c13696ba33426d298a49f07cd1 Author: Casey Schaufler Date: Tue Aug 23 16:46:18 2022 -0700 Smack: Provide read control for io_uring_cmd commit dd9373402280cf4715fdc8fd5070f7d039e43511 upstream. Limit io_uring "cmd" options to files for which the caller has Smack read access. There may be cases where the cmd option may be closer to a write access than a read, but there is no way to make that determination. Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 2ad39828ee35c87e9a7eff735a4fc1ef90ba863a Author: Paul Moore Date: Wed Aug 10 15:55:36 2022 -0400 selinux: implement the security_uring_cmd() LSM hook commit f4d653dcaa4e4056e1630423e6a8ece4869b544f upstream. Add a SELinux access control for the iouring IORING_OP_URING_CMD command. This includes the addition of a new permission in the existing "io_uring" object class: "cmd". The subject of the new permission check is the domain of the process requesting access, the object is the open file which points to the device/file that is the target of the IORING_OP_URING_CMD operation. A sample policy rule is shown below: allow :io_uring { cmd }; Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 13069e1c8fef9b6f959784cc89ddbf75b31eef36 Author: Luis Chamberlain Date: Fri Jul 15 12:16:22 2022 -0700 lsm,io_uring: add LSM hooks for the new uring_cmd file op commit 2a5840124009f133bd09fd855963551fb2cefe22 upstream. io-uring cmd support was added through ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd"), this extended the struct file_operations to allow a new command which each subsystem can use to enable command passthrough. Add an LSM specific for the command passthrough which enables LSMs to inspect the command details. This was discussed long ago without no clear pointer for something conclusive, so this enables LSMs to at least reject this new file operation. [0] https://lkml.kernel.org/r/8adf55db-7bab-f59d-d612-ed906b948d19@schaufler-ca.com Cc: stable@vger.kernel.org Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd") Signed-off-by: Luis Chamberlain Acked-by: Jens Axboe Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1578775f94d141b89cb7f993fbd79ff107131702 Author: Nathan Chancellor Date: Tue Aug 9 18:08:09 2022 -0700 ASoC: mchp-spdiftx: Fix clang -Wbitfield-constant-conversion commit 5c5c2baad2b55cc0a4b190266889959642298f79 upstream. A recent change in clang strengthened its -Wbitfield-constant-conversion to warn when 1 is assigned to a 1-bit signed integer bitfield, as it can only be 0 or -1, not 1: sound/soc/atmel/mchp-spdiftx.c:505:20: error: implicit truncation from 'int' to bit-field changes value from 1 to -1 [-Werror,-Wbitfield-constant-conversion] dev->gclk_enabled = 1; ^ ~ 1 error generated. The actual value of the field is never checked, just that it is not zero, so there is not a real bug here. However, it is simple enough to silence the warning by making the bitfield unsigned, which matches the mchp-spdifrx driver. Fixes: 06ca24e98e6b ("ASoC: mchp-spdiftx: add driver for S/PDIF TX Controller") Link: https://github.com/ClangBuiltLinux/linux/issues/1686 Link: https://github.com/llvm/llvm-project/commit/82afc9b169a67e8b8a1862fb9c41a2cd974d6691 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Link: https://lore.kernel.org/r/20220810010809.2024482-1-nathan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6400eca5a3d2ff5acdd217995c83fb0b3e8ebd6c Author: Claudiu Beznea Date: Wed Jul 27 12:08:14 2022 +0300 ASoC: mchp-spdiftx: remove references to mchp_i2s_caps commit 403fcb5118a0f4091001a537e76923031fb45eaf upstream. Remove references to struct mchp_i2s_caps as they are not used. Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220727090814.2446111-3-claudiu.beznea@microchip.com Signed-off-by: Mark Brown Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit f3cf916c93dca6df7ec189d0265dd3f910bf6c7b Author: Alexandru Gagniuc Date: Mon Sep 5 09:28:04 2022 -0500 hwmon: (tps23861) fix byte order in resistance register commit 1f05f65bddd6958d25b133f886da49c1d4bff3fa upstream. The tps23861 registers are little-endian, and regmap_read_bulk() does not do byte order conversion. On BE machines, the bytes were swapped, and the interpretation of the resistance value was incorrect. To make it work on both big and little-endian machines, use le16_to_cpu() to convert the resitance register to host byte order. Signed-off-by: Alexandru Gagniuc Fixes: fff7b8ab22554 ("hwmon: add Texas Instruments TPS23861 driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220905142806.110598-1-mr.nuke.me@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0f9f9c73da37c945bb14363378908342e7e5db59 Author: Adrian Hunter Date: Wed Sep 7 19:24:58 2022 +0300 perf record: Fix synthesis failure warnings [ Upstream commit faf59ec8c3c3708c64ff76b50e6f757c6b4a1054 ] Some calls to synthesis functions set err < 0 but only warn about the failure and continue. However they do not set err back to zero, relying on subsequent code to do that. That changed with the introduction of option --synth. When --synth=no subsequent functions that set err back to zero are not called. Fix by setting err = 0 in those cases. Example: Before: $ perf record --no-bpf-event --synth=all -o /tmp/huh uname Couldn't synthesize bpf events. Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.014 MB /tmp/huh (7 samples) ] $ perf record --no-bpf-event --synth=no -o /tmp/huh uname Couldn't synthesize bpf events. After: $ perf record --no-bpf-event --synth=no -o /tmp/huh uname Couldn't synthesize bpf events. Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.014 MB /tmp/huh (7 samples) ] Fixes: 41b740b6e8a994e5 ("perf record: Add --synth option") Signed-off-by: Adrian Hunter Acked-by: Namhyung Kim Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/r/20220907162458.72817-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1b388709906b63923a1004af61605a9483851103 Author: Zhengjun Xing Date: Thu Sep 8 15:00:30 2022 +0800 perf script: Fix Cannot print 'iregs' field for hybrid systems [ Upstream commit 82b2425fad2dd47204b3da589b679220f8aacc0e ] Commit b91e5492f9d7ca89 ("perf record: Add a dummy event on hybrid systems to collect metadata records") adds a dummy event on hybrid systems to fix the symbol "unknown" issue when the workload is created in a P-core but runs on an E-core. The added dummy event will cause "perf script -F iregs" to fail. Dummy events do not have "iregs" attribute set, so when we do evsel__check_attr, the "iregs" attribute check will fail, so the issue happened. The following commit [1] has fixed a similar issue by skipping the attr check for the dummy event because it does not have any samples anyway. It works okay for the normal mode, but the issue still happened when running the test in the pipe mode. In the pipe mode, it calls process_attr() which still checks the attr for the dummy event. This commit fixed the issue by skipping the attr check for the dummy event in the API evsel__check_attr, Otherwise, we have to patch everywhere when evsel__check_attr() is called. Before: #./perf record -o - --intr-regs=di,r8,dx,cx -e br_inst_retired.near_call:p -c 1000 --per-thread true 2>/dev/null|./perf script -F iregs |head -5 Samples for 'dummy:HG' event do not have IREGS attribute set. Cannot print 'iregs' field. 0x120 [0x90]: failed to process type: 64 # After: # ./perf record -o - --intr-regs=di,r8,dx,cx -e br_inst_retired.near_call:p -c 1000 --per-thread true 2>/dev/null|./perf script -F iregs |head -5 ABI:2 CX:0x55b8efa87000 DX:0x55b8efa7e000 DI:0xffffba5e625efbb0 R8:0xffff90e51f8ae100 ABI:2 CX:0x7f1dae1e4000 DX:0xd0 DI:0xffff90e18c675ac0 R8:0x71 ABI:2 CX:0xcc0 DX:0x1 DI:0xffff90e199880240 R8:0x0 ABI:2 CX:0xffff90e180dd7500 DX:0xffff90e180dd7500 DI:0xffff90e180043500 R8:0x1 ABI:2 CX:0x50 DX:0xffff90e18c583bd0 DI:0xffff90e1998803c0 R8:0x58 # [1]https://lore.kernel.org/lkml/20220831124041.219925-1-jolsa@kernel.org/ Fixes: b91e5492f9d7ca89 ("perf record: Add a dummy event on hybrid systems to collect metadata records") Suggested-by: Namhyung Kim Signed-off-by: Xing Zhengjun Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ian Rogers Cc: Ingo Molnar Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220908070030.3455164-1-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4357706ee8f45ebb2fc9a59098d0c6a70912ca35 Author: Adrian Hunter Date: Mon Sep 5 10:47:35 2022 +0300 perf dlfilter dlfilter-show-cycles: Fix types for print format [ Upstream commit 1706623e940347ad23fdf77910eca4905dc37f91 ] Avoid compiler warning about format %llu that expects long long unsigned int but argument has type __u64. Reported-by: Arnaldo Carvalho de Melo Fixes: c3afd6e50fce824f ("perf dlfilter: Add dlfilter-show-cycles") Signed-off-by: Adrian Hunter Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/r/20220905074735.4513-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7bb2200856df14f37d54ba0bf33a9245e0573013 Author: Adrian Hunter Date: Mon Sep 5 14:42:09 2022 +0300 libperf evlist: Fix per-thread mmaps for multi-threaded targets [ Upstream commit 7864d8f7c088aad988c44c631f1ceed9179cf2cf ] The offending commit removed mmap_per_thread(), which did not consider the different set-output rules for per-thread mmaps i.e. in the per-thread case set-output is used for file descriptors of the same thread not the same cpu. This was not immediately noticed because it only happens with multi-threaded targets and we do not have a test for that yet. Reinstate mmap_per_thread() expanding it to cover also system-wide per-cpu events i.e. to continue to allow the mixing of per-thread and per-cpu mmaps. Debug messages (with -vv) show the file descriptors that are opened with sys_perf_event_open. New debug messages are added (needs -vvv) that show also which file descriptors are mmapped and which are redirected with set-output. In the per-cpu case (cpu != -1) file descriptors for the same CPU are set-output to the first file descriptor for that CPU. In the per-thread case (cpu == -1) file descriptors for the same thread are set-output to the first file descriptor for that thread. Example (process 17489 has 2 threads): Before (but with new debug prints): $ perf record --no-bpf-event -vvv --per-thread -p 17489 sys_perf_event_open: pid 17489 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 17490 cpu -1 group_fd -1 flags 0x8 = 6 libperf: idx 0: mmapping fd 5 libperf: idx 0: set output fd 6 -> 5 failed to mmap with 22 (Invalid argument) After: $ perf record --no-bpf-event -vvv --per-thread -p 17489 sys_perf_event_open: pid 17489 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 17490 cpu -1 group_fd -1 flags 0x8 = 6 libperf: mmap_per_thread: nr cpu values (may include -1) 1 nr threads 2 libperf: idx 0: mmapping fd 5 libperf: idx 1: mmapping fd 6 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.018 MB perf.data (15 samples) ] Per-cpu example (process 20341 has 2 threads, same as above): $ perf record --no-bpf-event -vvv -p 20341 sys_perf_event_open: pid 20341 cpu 0 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 20342 cpu 0 group_fd -1 flags 0x8 = 6 sys_perf_event_open: pid 20341 cpu 1 group_fd -1 flags 0x8 = 7 sys_perf_event_open: pid 20342 cpu 1 group_fd -1 flags 0x8 = 8 sys_perf_event_open: pid 20341 cpu 2 group_fd -1 flags 0x8 = 9 sys_perf_event_open: pid 20342 cpu 2 group_fd -1 flags 0x8 = 10 sys_perf_event_open: pid 20341 cpu 3 group_fd -1 flags 0x8 = 11 sys_perf_event_open: pid 20342 cpu 3 group_fd -1 flags 0x8 = 12 sys_perf_event_open: pid 20341 cpu 4 group_fd -1 flags 0x8 = 13 sys_perf_event_open: pid 20342 cpu 4 group_fd -1 flags 0x8 = 14 sys_perf_event_open: pid 20341 cpu 5 group_fd -1 flags 0x8 = 15 sys_perf_event_open: pid 20342 cpu 5 group_fd -1 flags 0x8 = 16 sys_perf_event_open: pid 20341 cpu 6 group_fd -1 flags 0x8 = 17 sys_perf_event_open: pid 20342 cpu 6 group_fd -1 flags 0x8 = 18 sys_perf_event_open: pid 20341 cpu 7 group_fd -1 flags 0x8 = 19 sys_perf_event_open: pid 20342 cpu 7 group_fd -1 flags 0x8 = 20 libperf: mmap_per_cpu: nr cpu values 8 nr threads 2 libperf: idx 0: mmapping fd 5 libperf: idx 0: set output fd 6 -> 5 libperf: idx 1: mmapping fd 7 libperf: idx 1: set output fd 8 -> 7 libperf: idx 2: mmapping fd 9 libperf: idx 2: set output fd 10 -> 9 libperf: idx 3: mmapping fd 11 libperf: idx 3: set output fd 12 -> 11 libperf: idx 4: mmapping fd 13 libperf: idx 4: set output fd 14 -> 13 libperf: idx 5: mmapping fd 15 libperf: idx 5: set output fd 16 -> 15 libperf: idx 6: mmapping fd 17 libperf: idx 6: set output fd 18 -> 17 libperf: idx 7: mmapping fd 19 libperf: idx 7: set output fd 20 -> 19 [ perf record: Woken up 7 times to write data ] [ perf record: Captured and wrote 0.020 MB perf.data (17 samples) ] Fixes: ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Reported-by: Tomáš Trnka Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216441 Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220905114209.8389-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5ec0821b85ff0097ea5e582c03f65c6014ca2807 Author: Toke Høiland-Jørgensen Date: Mon Sep 5 21:21:36 2022 +0200 sch_sfb: Also store skb len before calling child enqueue [ Upstream commit 2f09707d0c972120bf794cfe0f0c67e2c2ddb252 ] Cong Wang noticed that the previous fix for sch_sfb accessing the queued skb after enqueueing it to a child qdisc was incomplete: the SFB enqueue function was also calling qdisc_qstats_backlog_inc() after enqueue, which reads the pkt len from the skb cb field. Fix this by also storing the skb len, and using the stored value to increment the backlog after enqueueing. Fixes: 9efd23297cca ("sch_sfb: Don't assume the skb is still around after enqueueing to child") Signed-off-by: Toke Høiland-Jørgensen Acked-by: Cong Wang Link: https://lore.kernel.org/r/20220905192137.965549-1-toke@toke.dk Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9da303e1e7f9358a77f9479fb416ac7551a7b00f Author: Arun Ramadoss Date: Mon Sep 5 20:57:50 2022 +0530 net: phy: lan87xx: change interrupt src of link_up to comm_ready [ Upstream commit 5382033a35227c57a349d74752ad2527780159a9 ] Currently phy link up/down interrupt is enabled using the LAN87xx_INTERRUPT_MASK register. In the lan87xx_read_status function, phy link is determined using the T1_MODE_STAT_REG register comm_ready bit. comm_ready bit is set using the loc_rcvr_status & rem_rcvr_status. Whenever the phy link is up, LAN87xx_INTERRUPT_SOURCE link_up bit is set first but comm_ready bit takes some time to set based on local and remote receiver status. As per the current implementation, interrupt is triggered using link_up but the comm_ready bit is still cleared in the read_status function. So, link is always down. Initially tested with the shared interrupt mechanism with switch and internal phy which is working, but after implementing interrupt controller it is not working. It can fixed either by updating the read_status function to read from LAN87XX_INTERRUPT_SOURCE register or enable the interrupt mask for comm_ready bit. But the validation team recommends the use of comm_ready for link detection. This patch fixes by enabling the comm_ready bit for link_up in the LAN87XX_INTERRUPT_MASK_2 register (MISC Bank) and link_down in LAN87xx_INTERRUPT_MASK register. Fixes: 8a1b415d70b7 ("net: phy: added ethtool master-slave configuration support") Signed-off-by: Arun Ramadoss Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220905152750.5079-1-arun.ramadoss@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dde284a85f7bd8e39af5381ded106bd11376392f Author: Pavel Begunkov Date: Tue Sep 6 17:11:17 2022 +0100 io_uring: recycle kbuf recycle on tw requeue [ Upstream commit 336d28a8f38013a069f2d46e73aaa1880ef17a47 ] When we queue a request via tw for execution it's not going to be executed immediately, so when io_queue_async() hits IO_APOLL_READY and queues a tw but doesn't try to recycle/consume the buffer some other request may try to use the the buffer. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/a19bc9e211e3184215a58e129b62f440180e9212.1662480490.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde Author: Yacan Liu Date: Tue Sep 6 21:01:39 2022 +0800 net/smc: Fix possible access to freed memory in link clear [ Upstream commit e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968 ] After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example: BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20 Fixes: bd4ad57718cc ("smc: initialize IB transport incl. PD, MR, QP, CQ, event, WR") Signed-off-by: Yacan Liu Reviewed-by: Tony Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e484616810f83f70f58e5ad0d5e708332cb1708f Author: Lorenzo Bianconi Date: Mon Sep 5 14:41:28 2022 +0200 net: ethernet: mtk_eth_soc: check max allowed hash in mtk_ppe_check_skb [ Upstream commit f27b405ef43319a3ceefc2123245201a63ed4e00 ] Even if max hash configured in hw in mtk_ppe_hash_entry is MTK_PPE_ENTRIES - 1, check theoretical OOB accesses in mtk_ppe_check_skb routine Fixes: c4f033d9e03e9 ("net: ethernet: mtk_eth_soc: rework hardware flow table management") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0378b06e612e51d94312def1fc5fbd357d7d83f7 Author: Lorenzo Bianconi Date: Tue Sep 6 16:36:32 2022 +0200 net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear [ Upstream commit 0e80707d94e4c88f9879bdafcbaceb13432ec1f4 ] Set ib1 state to MTK_FOE_STATE_UNBIND in __mtk_foe_entry_clear routine. Fixes: 33fc42de33278 ("net: ethernet: mtk_eth_soc: support creating mac address based offload entries") Signed-off-by: Lorenzo Bianconi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e502794fb85859ada39b257d6942ee4f63b64abd Author: Vladimir Oltean Date: Mon Sep 5 20:01:25 2022 +0300 net: dsa: felix: access QSYS_TAG_CONFIG under tas_lock in vsc9959_sched_speed_set [ Upstream commit a4bb481aeb9d84cb53112a478e6db4705b794c34 ] The read-modify-write of QSYS_TAG_CONFIG from vsc9959_sched_speed_set() runs unlocked with respect to the other functions that access it, which are vsc9959_tas_guard_bands_update(), vsc9959_qos_port_tas_set() and vsc9959_tas_clock_adjust(). All the others are under ocelot->tas_lock, so move the vsc9959_sched_speed_set() access under that lock as well, to resolve the concurrency. Fixes: 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 27474e8bfcdf7536afeee23bc152e3ef9fafbe1e Author: Vladimir Oltean Date: Mon Sep 5 20:01:24 2022 +0300 net: dsa: felix: disable cut-through forwarding for frames oversized for tc-taprio [ Upstream commit 843794bbdef83955ae5b43dfafc355c3786e2145 ] Experimentally, it looks like when QSYS_QMAXSDU_CFG_7 is set to 605, frames even way larger than 601 octets are transmitted even though these should be considered as oversized, according to the documentation, and dropped. Since oversized frame dropping depends on frame size, which is only known at the EOF stage, and therefore not at SOF when cut-through forwarding begins, it means that the switch cannot take QSYS_QMAXSDU_CFG_* into consideration for traffic classes that are cut-through. Since cut-through forwarding has no UAPI to control it, and the driver enables it based on the mantra "if we can, then why not", the strategy is to alter vsc9959_cut_through_fwd() to take into consideration which tc's have oversize frame dropping enabled, and disable cut-through for them. Then, from vsc9959_tas_guard_bands_update(), we re-trigger the cut-through determination process. There are 2 strategies for vsc9959_cut_through_fwd() to determine whether a tc has oversized dropping enabled or not. One is to keep a bit mask of traffic classes per port, and the other is to read back from the hardware registers (a non-zero value of QSYS_QMAXSDU_CFG_* means the feature is enabled). We choose reading back from registers, because struct ocelot_port is shared with drivers (ocelot, seville) that don't support either cut-through nor tc-taprio, and we don't have a felix specific extension of struct ocelot_port. Furthermore, reading registers from the Felix hardware is quite cheap, since they are memory-mapped. Fixes: 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 02410f02f6c2019050ddacb4078ec4b8c5e156c2 Author: Sindhu-Devale Date: Tue Sep 6 17:32:44 2022 -0500 RDMA/irdma: Report RNR NAK generation in device caps [ Upstream commit a261786fdc0a5bed2e5f994dcc0ffeeeb0d662c7 ] Report RNR NAK generation when device capabilities are queried Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Sindhu-Devale Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220906223244.1119-6-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d9cfeef3a2e639772dbceead35eaef3d2cd03479 Author: Sindhu-Devale Date: Tue Sep 6 17:32:42 2022 -0500 RDMA/irdma: Return correct WC error for bind operation failure [ Upstream commit dcb23bbb1de7e009875fdfac2b8a9808a9319cc6 ] When a QP and a MR on a local host are in different PDs, the HW generates an asynchronous event (AE). The same AE is generated when a QP and a MW are in different PDs during a bind operation. Return the more appropriate IBV_WC_MW_BIND_ERR for the latter case by checking the OP type from the CQE in error. Fixes: 551c46edc769 ("RDMA/irdma: Add user/kernel shared libraries") Signed-off-by: Sindhu-Devale Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220906223244.1119-4-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 02516406f2eaea653e04a23005e5f748083f2bbe Author: Sindhu-Devale Date: Tue Sep 6 17:32:41 2022 -0500 RDMA/irdma: Return error on MR deregister CQP failure [ Upstream commit 6b227bd32db778eddc6f3b22cc72a28dda0f2272 ] The MR deregister CQP can fail if an MW is bound to it. Return an appropriate error for this case. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Sindhu-Devale Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220906223244.1119-3-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 083f5179fe6f5fd722361bf281f85ee226aa3df6 Author: Sindhu-Devale Date: Tue Sep 6 17:32:40 2022 -0500 RDMA/irdma: Report the correct max cqes from query device [ Upstream commit 12faad5e5cf2372af2d51f348b697b5edf838daf ] Report the correct max cqes available to an application taking into account a reserved entry to detect overflow. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Sindhu-Devale Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220906223244.1119-2-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ddb0d1d4d4ff1ed82418a5e522e50a03ac3b98ae Author: Dennis Maisenbacher Date: Tue Sep 6 09:39:28 2022 +0200 nvmet: fix mar and mor off-by-one errors [ Upstream commit b7e97872a65e1d57b4451769610554c131f37a0a ] Maximum Active Resources (MAR) and Maximum Open Resources (MOR) are 0's based vales where a value of 0xffffffff indicates that there is no limit. Decrement the values that are returned by bdev_max_open_zones and bdev_max_active_zones as the block layer helpers are not 0's based. A 0 returned by the block layer helpers indicates no limit, thus convert it to 0xffffffff (U32_MAX). Fixes: aaf2e048af27 ("nvmet: add ZBD over ZNS backend support") Suggested-by: Niklas Cassel Signed-off-by: Dennis Maisenbacher Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 9280b9de09fcdff9f17abb3ca6f7e146922b9a10 Author: Qu Wenruo Date: Thu Aug 18 15:06:44 2022 +0800 btrfs: fix the max chunk size and stripe length calculation [ Upstream commit 5da431b71d4b9be3c8cf6786eff9e2d41a5f9f65 ] [BEHAVIOR CHANGE] Since commit f6fca3917b4d ("btrfs: store chunk size in space-info struct"), btrfs no longer can create larger data chunks than 1G: mkfs.btrfs -f -m raid1 -d raid0 $dev1 $dev2 $dev3 $dev4 mount $dev1 $mnt btrfs balance start --full $mnt btrfs balance start --full $mnt umount $mnt btrfs ins dump-tree -t chunk $dev1 | grep "DATA|RAID0" -C 2 Before that offending commit, what we got is a 4G data chunk: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176 length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 Now what we got is only 1G data chunk: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 6271533056) itemoff 15491 itemsize 176 length 1073741824 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 This will increase the number of data chunks by the number of devices, not only increase system chunk usage, but also greatly increase mount time. Without a proper reason, we should not change the max chunk size. [CAUSE] Previously, we set max data chunk size to 10G, while max data stripe length to 1G. Commit f6fca3917b4d ("btrfs: store chunk size in space-info struct") completely ignored the 10G limit, but use 1G max stripe limit instead, causing above shrink in max data chunk size. [FIX] Fix the max data chunk size to 10G, and in decide_stripe_size_regular() we limit stripe_size to 1G manually. This should only affect data chunks, as for metadata chunks we always set the max stripe size the same as max chunk size (256M or 1G depending on fs size). Now the same script result the same old result: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176 length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 Reported-by: Wang Yugui Fixes: f6fca3917b4d ("btrfs: store chunk size in space-info struct") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3c20e4cd54eb504411253c35aebb4e1e17c990a6 Author: Neal Cardwell Date: Sat Sep 3 08:10:23 2022 -0400 tcp: fix early ETIMEDOUT after spurious non-SACK RTO [ Upstream commit 686dc2db2a0fdc1d34b424ec2c0a735becd8d62b ] Fix a bug reported and analyzed by Nagaraj Arankal, where the handling of a spurious non-SACK RTO could cause a connection to fail to clear retrans_stamp, causing a later RTO to very prematurely time out the connection with ETIMEDOUT. Here is the buggy scenario, expanding upon Nagaraj Arankal's excellent report: (*1) Send one data packet on a non-SACK connection (*2) Because no ACK packet is received, the packet is retransmitted and we enter CA_Loss; but this retransmission is spurious. (*3) The ACK for the original data is received. The transmitted packet is acknowledged. The TCP timestamp is before the retrans_stamp, so tcp_may_undo() returns true, and tcp_try_undo_loss() returns true without changing state to Open (because tcp_is_sack() is false), and tcp_process_loss() returns without calling tcp_try_undo_recovery(). Normally after undoing a CA_Loss episode, tcp_fastretrans_alert() would see that the connection has returned to CA_Open and fall through and call tcp_try_to_open(), which would set retrans_stamp to 0. However, for non-SACK connections we hold the connection in CA_Loss, so do not fall through to call tcp_try_to_open() and do not set retrans_stamp to 0. So retrans_stamp is (erroneously) still non-zero. At this point the first "retransmission event" has passed and been recovered from. Any future retransmission is a completely new "event". However, retrans_stamp is erroneously still set. (And we are still in CA_Loss, which is correct.) (*4) After 16 minutes (to correspond with tcp_retries2=15), a new data packet is sent. Note: No data is transmitted between (*3) and (*4) and we disabled keep alives. The socket's timeout SHOULD be calculated from this point in time, but instead it's calculated from the prior "event" 16 minutes ago (step (*2)). (*5) Because no ACK packet is received, the packet is retransmitted. (*6) At the time of the 2nd retransmission, the socket returns ETIMEDOUT, prematurely, because retrans_stamp is (erroneously) too far in the past (set at the time of (*2)). This commit fixes this bug by ensuring that we reuse in tcp_try_undo_loss() the same careful logic for non-SACK connections that we have in tcp_try_undo_recovery(). To avoid duplicating logic, we factor out that logic into a new tcp_is_non_sack_preventing_reopen() helper and call that helper from both undo functions. Fixes: da34ac7626b5 ("tcp: only undo on partial ACKs in CA_Loss") Reported-by: Nagaraj Arankal Link: https://lore.kernel.org/all/SJ0PR84MB1847BE6C24D274C46A1B9B0EB27A9@SJ0PR84MB1847.NAMPRD84.PROD.OUTLOOK.COM/ Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20220903121023.866900-1-ncardwell.kernel@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ba3f445d6d87d7a62064e1563d5ee78c855fb249 Author: Sagi Grimberg Date: Mon Sep 5 18:07:06 2022 +0300 nvme-tcp: fix regression that causes sporadic requests to time out [ Upstream commit 3770a42bb8ceb856877699257a43c0585a5d2996 ] When we queue requests, we strive to batch as much as possible and also signal the network stack that more data is about to be sent over a socket with MSG_SENDPAGE_NOTLAST. This flag looks at the pending requests queued as well as queue->more_requests that is derived from the block layer last-in-batch indication. We set more_request=true when we flush the request directly from .queue_rq submission context (in nvme_tcp_send_all), however this is wrongly assuming that no other requests may be queued during the execution of nvme_tcp_send_all. Due to this, a race condition may happen where: 1. request X is queued as !last-in-batch 2. request X submission context calls nvme_tcp_send_all directly 3. nvme_tcp_send_all is preempted and schedules to a different cpu 4. request Y is queued as last-in-batch 5. nvme_tcp_send_all context sends request X+Y, however signals for both MSG_SENDPAGE_NOTLAST because queue->more_requests=true. ==> none of the requests is pushed down to the wire as the network stack is waiting for more data, both requests timeout. To fix this, we eliminate queue->more_requests and only rely on the queue req_list and send_list to be not-empty. Fixes: 122e5b9f3d37 ("nvme-tcp: optimize network stack with setting msg flags according to batch size") Reported-by: Jonathan Nicklin Signed-off-by: Sagi Grimberg Tested-by: Jonathan Nicklin Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c3eb461aa56e6fa94fb80442ba2586bd223a8886 Author: Sagi Grimberg Date: Mon Sep 5 13:54:17 2022 +0300 nvme-tcp: fix UAF when detecting digest errors [ Upstream commit 160f3549a907a50e51a8518678ba2dcf2541abea ] We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Reported-by: Daniel Wagner Signed-off-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 94c34faaafe7b55adc2d8d881db195b646959b9e Author: Gao Xiang Date: Fri Sep 2 12:57:10 2022 +0800 erofs: fix pcluster use-after-free on UP platforms [ Upstream commit 2f44013e39984c127c6efedf70e6b5f4e9dcf315 ] During stress testing with CONFIG_SMP disabled, KASAN reports as below: ================================================================== BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789 CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 .. z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 The root cause is that erofs_workgroup_unfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing. Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead. Fixes: 73f5c66df3e2 ("staging: erofs: fix `erofs_workgroup_{try_to_freeze, unfreeze}'") Reviewed-by: Yue Hu Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20220902045710.109530-1-hsiangkao@linux.alibaba.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 5f7f40e0a27899411ddba7a6417931ad37e5c189 Author: Sun Ke Date: Mon Aug 15 11:48:29 2022 +0800 erofs: fix error return code in erofs_fscache_{meta_,}read_folio [ Upstream commit 5bd9628b784cc5e38e1c7ebb680bbd6ee741230e ] If erofs_fscache_alloc_request fail and then goto out, it will return 0. it should return a negative error code instead of 0. Fixes: d435d53228dd ("erofs: change to use asynchronous io for fscache readpage/readahead") Signed-off-by: Sun Ke Reviewed-by: Jingbo Xu Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20220815034829.3940803-1-sunke32@huawei.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 56fd5dcf111be825b404b51a04ca807945411295 Author: Johannes Thumshirn Date: Mon Sep 5 05:38:24 2022 -0700 btrfs: zoned: fix mounting with conventional zones [ Upstream commit 6ca64ac2763149fb66c0b4bf12f5e0977a88e51d ] Since commit 6a921de58992 ("btrfs: zoned: introduce space_info->active_total_bytes"), we're only counting the bytes of a block group on an active zone as usable for metadata writes. But on a SMR drive, we don't have active zones and short circuit some of the logic. This leads to an error on mount, because we cannot reserve space for metadata writes. Fix this by also setting the BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE bit in the block-group's runtime flag if the zone is a conventional zone. Fixes: 6a921de58992 ("btrfs: zoned: introduce space_info->active_total_bytes") Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7b4cc3e4b28a88888025de5933ded7bee4c44c5d Author: Chris Mi Date: Mon Aug 29 12:02:28 2022 +0300 RDMA/mlx5: Set local port to one when accessing counters [ Upstream commit 74b30b3ad5cec95d2647e796d10137438a098bc1 ] When accessing Ports Performance Counters Register (PPCNT), local port must be one if it is Function-Per-Port HCA that HCA_CAP.num_ports is 1. The offending patch can change the local port to other values when accessing PPCNT after enabling switchdev mode. The following syndrome will be printed: # cat /sys/class/infiniband/rdmap4s0f0/ports/2/counters/* # dmesg mlx5_core 0000:04:00.0: mlx5_cmd_check:756:(pid 12450): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x1e5585) Fix it by setting local port to one for Function-Per-Port HCA. Fixes: 210b1f78076f ("IB/mlx5: When not in dual port RoCE mode, use provided port as native") Reviewed-by: Mark Bloch Signed-off-by: Chris Mi Link: https://lore.kernel.org/r/6c5086c295c76211169e58dbd610fb0402360bab.1661763459.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 83c43fd872e32c8071d5582eb7c40f573a8342f3 Author: Yishai Hadas Date: Wed Aug 24 09:10:36 2022 +0300 IB/core: Fix a nested dead lock as part of ODP flow [ Upstream commit 85eaeb5058f0f04dffb124c97c86b4f18db0b833 ] Fix a nested dead lock as part of ODP flow by using mmput_async(). From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex. Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available. [1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? process_one_work+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? set_kthread_struct+0x50/0x50 [64843.078085] ret_from_fork+0x22/0x30 [64843.078093] Fixes: 36f30e486dce ("IB/core: Improve ODP to use hmm_range_fault()") Reviewed-by: Maor Gottlieb Signed-off-by: Yishai Hadas Link: https://lore.kernel.org/r/74d93541ea533ef7daec6f126deb1072500aeb16.1661251841.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 56ad3f475482bca55b0ae544031333018eb145b3 Author: David Lebrun Date: Fri Sep 2 10:45:06 2022 +0100 ipv6: sr: fix out-of-bounds read when setting HMAC data. [ Upstream commit 84a53580c5d2138c7361c7c3eea5b31827e63b35 ] The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 , family=, family=) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 ) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 ) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=, msg=0xffffc90000ba7e48, len=) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET. Reported-by: Lucas Leong Tested: verified that EINVAL is correctly returned when secretlen > len(secret) Fixes: 4f4853dc1c9c1 ("ipv6: sr: implement API to control SR HMAC structure") Signed-off-by: David Lebrun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 17589c4ee37068a65d02e01f75eb02d671051a65 Author: Hangbin Liu Date: Tue Aug 30 17:37:21 2022 +0800 bonding: add all node mcast address when slave up [ Upstream commit fd16eb948ea8b28afb03e11a5b11841e6ac2aa2b ] When a link is enslave to bond, it need to set the interface down first. This makes the slave remove mac multicast address 33:33:00:00:00:01(The IPv6 multicast address ff02::1 is kept even when the interface down). When bond set the slave up, ipv6_mc_up() was not called due to commit c2edacf80e15 ("bonding / ipv6: no addrconf for slaves separately from master"). This is not an issue before we adding the lladdr target feature for bonding, as the mac multicast address will be added back when bond interface up and join group ff02::1. But after adding lladdr target feature for bonding. When user set a lladdr target, the unsolicited NA message with all-nodes multicast dest will be dropped as the slave interface never add 33:33:00:00:00:01 back. Fix this by calling ipv6_mc_up() to add 33:33:00:00:00:01 back when the slave interface up. Reported-by: LiLiang Fixes: 5e1eeef69c0f ("bonding: NS target should accept link local address") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c561ad9802f627eacc7eb500d5350e3372acf260 Author: Hangbin Liu Date: Tue Aug 30 17:37:20 2022 +0800 bonding: use unspecified address if no available link local address [ Upstream commit b7f14132bf58256e841774ae07d3ffb7a841c2bc ] When ns_ip6_target was set, the ipv6_dev_get_saddr() will be called to get available source address and send IPv6 neighbor solicit message. If the target is global address, ipv6_dev_get_saddr() will get any available src address. But if the target is link local address, ipv6_dev_get_saddr() will only get available address from our interface, i.e. the corresponding bond interface. But before bond interface up, all the address is tentative, while ipv6_dev_get_saddr() will ignore tentative address. This makes we can't find available link local src address, then bond_ns_send() will not be called and no NS message was sent. Finally bond interface will keep in down state. Fix this by sending NS with unspecified address if there is no available source address. Reported-by: LiLiang Fixes: 5e1eeef69c0f ("bonding: NS target should accept link local address") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1751bf719df9280fc0adc18c828ded583d6cf726 Author: Linus Walleij Date: Fri Sep 2 23:59:18 2022 +0200 RDMA/siw: Pass a pointer to virt_to_page() [ Upstream commit 0d1b756acf60da5004c1e20ca4462f0c257bf6e1 ] Functions that work on a pointer to virtual memory such as virt_to_pfn() and users of that function such as virt_to_page() are supposed to pass a pointer to virtual memory, ideally a (void *) or other pointer. However since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). If we instead implement a proper virt_to_pfn(void *addr) function the following happens (occurred on arch/arm): drivers/infiniband/sw/siw/siw_qp_tx.c:32:23: warning: incompatible integer to pointer conversion passing 'dma_addr_t' (aka 'unsigned int') to parameter of type 'const void *' [-Wint-conversion] drivers/infiniband/sw/siw/siw_qp_tx.c:32:37: warning: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion] drivers/infiniband/sw/siw/siw_qp_tx.c:538:36: warning: incompatible integer to pointer conversion passing 'unsigned long long' to parameter of type 'const void *' [-Wint-conversion] Fix this with an explicit cast. In one case where the SIW SGE uses an unaligned u64 we need a double cast modifying the virtual address (va) to a platform-specific uintptr_t before casting to a (void *). Fixes: b9be6f18cf9e ("rdma/siw: transmit path") Cc: linux-rdma@vger.kernel.org Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220902215918.603761-1-linus.walleij@linaro.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4c9a8adb14d2a6b2f005db6b1cc68bd4492ed0e6 Author: Ming Lei Date: Tue Aug 23 18:38:19 2022 +0800 block: don't add partitions if GD_SUPPRESS_PART_SCAN is set [ Upstream commit 748008e1da926a814cc0a054c81ca614408b1b0c ] Commit b9684a71fca7 ("block, loop: support partitions without scanning") adds GD_SUPPRESS_PART_SCAN for replacing part function of GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since loop doesn't want to add partitions if GENHD_FL_NO_PART was set. And it causes regression on libblockdev (as called from udisks) which operates with the LO_FLAGS_PARTSCAN. Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is set. Fixes: b9684a71fca7 ("block, loop: support partitions without scanning") Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220823103819.395776-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 26a6d7d42972649277541483f794ec0f12b4e00c Author: Paul Durrant Date: Thu Sep 1 12:55:54 2022 +0100 xen-netback: only remove 'hotplug-status' when the vif is actually destroyed [ Upstream commit c55f34b6aec2a8cb47eadaffea773e83bf85de91 ] Removing 'hotplug-status' in backend_disconnected() means that it will be removed even in the case that the frontend unilaterally disconnects (which it is free to do at any time). The consequence of this is that, when the frontend attempts to re-connect, the backend gets stuck in 'InitWait' rather than moving straight to 'Connected' (which it can do because the hotplug script has already run). Instead, the 'hotplug-status' mode should be removed in netback_remove() i.e. when the vif really is going away. Fixes: 0f4558ae9187 ("Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"") Signed-off-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51705da8cf5e58b9bd05afe88343458ad398e0d2 Author: Ivan Vecera Date: Tue Aug 30 10:16:27 2022 +0200 iavf: Detach device during reset task [ Upstream commit aa626da947e9cd30c4cf727493903e1adbb2c0a0 ] iavf_reset_task() takes crit_lock at the beginning and holds it during whole call. The function subsequently calls iavf_init_interrupt_scheme() that grabs RTNL. Problem occurs when userspace initiates during the reset task any ndo callback that runs under RTNL like iavf_open() because some of that functions tries to take crit_lock. This leads to classic A-B B-A deadlock scenario. To resolve this situation the device should be detached in iavf_reset_task() prior taking crit_lock to avoid subsequent ndos running under RTNL and reattach the device at the end. Fixes: 62fe2a865e6d ("i40evf: add missing rtnl_lock() around i40evf_set_interrupt_capability") Cc: Jacob Keller Cc: Patryk Piotrowski Cc: SlawomirX Laba Tested-by: Vitaly Grinberg Signed-off-by: Ivan Vecera Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 38af35bec59a8431a1eb29da994a0a45cba275d9 Author: Ivan Vecera Date: Tue Aug 16 18:22:30 2022 +0200 i40e: Fix kernel crash during module removal [ Upstream commit fb8396aeda5872369a8ed6d2301e2c86e303c520 ] The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel crash. Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0 offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host# modprobe -r irdma Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [ 8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286] Call Trace: [ 8687.910737] [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040] pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188] driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693] pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e] Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL. During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is NULL -> crash. Do not remove client instance when client open callbacks fails and just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED is set. Fixes: 0ef2d5afb12d ("i40e: KISS the client interface") Signed-off-by: Ivan Vecera Tested-by: Helena Anna Dubel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 14c1d71b4330fc8a5328d657970d00825036bdee Author: Michal Swiatkowski Date: Wed Aug 17 10:53:20 2022 +0200 ice: use bitmap_free instead of devm_kfree [ Upstream commit 59ac325557b6c14f1f793b90d3946bc145ffa085 ] pf->avail_txqs was allocated using bitmap_zalloc, bitmap_free should be used to free this memory. Fixes: 78b5713ac1241 ("ice: Alloc queue management bitmaps and arrays dynamically") Signed-off-by: Michal Swiatkowski Tested-by: Gurucharan (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 07f40e9f0ff342eb3e97d5c544783b7cb641689c Author: Przemyslaw Patynowski Date: Thu Aug 11 12:09:22 2022 +0200 ice: Fix DMA mappings leak [ Upstream commit 7e753eb675f0523207b184558638ee2eed6c9ac2 ] Fix leak, when user changes ring parameters. During reallocation of RX buffers, new DMA mappings are created for those buffers. New buffers with different RX ring count should substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused leak of already mapped DMA. Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate back to rx_buf, when BPF program unloads. If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XDP_SETUP_XSK_POOL handler. Steps for reproduction: while : do for ((i=0; i<=8160; i=i+32)) do ethtool -G enp130s0f0 rx $i tx $i sleep 0.5 ethtool -g enp130s0f0 done done Fixes: 617f3e1b588c ("ice: xsk: allocate separate memory for XDP SW ring") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Mateusz Palczewski Tested-by: Chandan (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6730c48ed6b0cd939fc9b30b2d621ce0b89bea83 Author: Eric Dumazet Date: Wed Aug 31 23:38:09 2022 +0000 tcp: TX zerocopy should not sense pfmemalloc status [ Upstream commit 3261400639463a853ba2b3be8bd009c2a8089775 ] We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index. Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive. Backporting to older kernel versions seems not necessary. [1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea0004a1d288 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 Fixes: c07aea3ef4d4 ("mm: add a signature in struct page") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Shakeel Butt Reviewed-by: Shakeel Butt Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57b099b6349a6d919c7c9a8fb402796f61947d16 Author: Pavel Begunkov Date: Tue Jul 12 21:52:32 2022 +0100 net: introduce __skb_fill_page_desc_noacc [ Upstream commit 84ce071e38a6e25ea3ea91188e5482ac1f17b3af ] Managed pages contain pinned userspace pages and controlled by upper layers, there is no need in tracking skb->pfmemalloc for them. Introduce a helper for filling frags but ignoring page tracking, it'll be needed later. Signed-off-by: Pavel Begunkov Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63e19e592980b0c53cb5144646c3c33c9d3dc7a0 Author: Dan Carpenter Date: Wed Aug 31 17:47:56 2022 +0300 tipc: fix shift wrapping bug in map_get() [ Upstream commit e2b224abd9bf45dcb55750479fc35970725a430b ] There is a shift wrapping bug in this code so anything thing above 31 will return false. Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f796f36f5ba839c11eb4685150ebeed496c546f Author: Toke Høiland-Jørgensen Date: Wed Aug 31 23:52:18 2022 +0200 sch_sfb: Don't assume the skb is still around after enqueueing to child [ Upstream commit 9efd23297cca530bb35e1848665805d3fcdd7889 ] The sch_sfb enqueue() routine assumes the skb is still alive after it has been enqueued into a child qdisc, using the data in the skb cb field in the increment_qlen() routine after enqueue. However, the skb may in fact have been freed, causing a use-after-free in this case. In particular, this happens if sch_cake is used as a child of sfb, and the GSO splitting mode of CAKE is enabled (in which case the skb will be split into segments and the original skb freed). Fix this by copying the sfb cb data to the stack before enqueueing the skb, and using this stack copy in increment_qlen() instead of the skb pointer itself. Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231 Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d979f00b0feabf7d67ff8da9e654e0e45792a6d7 Author: Heiner Kallweit Date: Wed Aug 31 21:20:49 2022 +0200 Revert "net: phy: meson-gxl: improve link-up behavior" [ Upstream commit 7fdc77665f3d45c9da7c6edd4beadee9790f43aa ] This reverts commit 2c87c6f9fbddc5b84d67b2fa3f432fcac6d99d93. Meanwhile it turned out that the following commit is the proper workaround for the issue that 2c87c6f9fbdd tries to address. a3a57bf07de2 ("net: stmmac: work around sporadic tx issue on link-up") It's nor clear why the to be reverted commit helped for one user, for others it didn't make a difference. Fixes: 2c87c6f9fbdd ("net: phy: meson-gxl: improve link-up behavior") Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8deeeddc-6b71-129b-1918-495a12dc11e3@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c07642fee989d20e2ec61bf181cf6a9eae2f1c34 Author: Sander Vanheule Date: Sun Aug 21 17:01:47 2022 +0200 kunit: fix assert_type for comparison macros [ Upstream commit aded3cad909581c60335037112c4f86bbfe90f17 ] When replacing KUNIT_BINARY_*_MSG_ASSERTION() macros with KUNIT_BINARY_INT_ASSERTION(), the assert_type parameter was not always correctly transferred. Specifically, the following errors were introduced: - KUNIT_EXPECT_LE_MSG() uses KUNIT_ASSERTION - KUNIT_ASSERT_LT_MSG() uses KUNIT_EXPECTATION - KUNIT_ASSERT_GT_MSG() uses KUNIT_EXPECTATION A failing KUNIT_EXPECT_LE_MSG() test thus prevents further tests from running, while failing KUNIT_ASSERT_{LT,GT}_MSG() tests do not prevent further tests from running. This is contrary to the documentation, which states that failing KUNIT_EXPECT_* macros allow further tests to run, while failing KUNIT_ASSERT_* macros should prevent this. Revert the KUNIT_{ASSERTION,EXPECTATION} switches to fix the behaviour for the affected macros. Fixes: 40f39777ce4f ("kunit: decrease macro layering for integer asserts") Signed-off-by: Sander Vanheule Reviewed-by: Daniel Latypov Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit adbb4a4f740f0a59a53c0e0f36f78b30e8a91d0c Author: David Howells Date: Wed Aug 31 13:16:42 2022 +0100 afs: Use the operation issue time instead of the reply time for callbacks [ Upstream commit 7903192c4b4a82d792cb0dc5e2779a2efe60d45b ] rxrpc and kafs between them try to use the receive timestamp on the first data packet (ie. the one with sequence number 1) as a base from which to calculate the time at which callback promise and lock expiration occurs. However, we don't know how long it took for the server to send us the reply from it having completed the basic part of the operation - it might then, for instance, have to send a bunch of a callback breaks, depending on the particular operation. Fix this by using the time at which the operation is issued on the client as a base instead. That should never be longer than the server's idea of the expiry time. Fixes: 781070551c26 ("afs: Fix calculation of callback expiry time") Fixes: 2070a3e44962 ("rxrpc: Allow the reply time to be obtained on a client call") Suggested-by: Jeffrey E Altman Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 0ee6ec46de48cf1c361242dd0482a1ee0fc43c61 Author: David Howells Date: Wed Aug 24 22:39:28 2022 +0100 rxrpc: Fix an insufficiently large sglist in rxkad_verify_packet_2() [ Upstream commit 0d40f728e28393a8817d1fcae923dfa3409e488c ] rxkad_verify_packet_2() has a small stack-allocated sglist of 4 elements, but if that isn't sufficient for the number of fragments in the socket buffer, we try to allocate an sglist large enough to hold all the fragments. However, for large packets with a lot of fragments, this isn't sufficient and we need at least one additional fragment. The problem manifests as skb_to_sgvec() returning -EMSGSIZE and this then getting returned by userspace. Most of the time, this isn't a problem as rxrpc sets a limit of 5692, big enough for 4 jumbo subpackets to be glued together; occasionally, however, the server will ignore the reported limit and give a packet that's a lot bigger - say 19852 bytes with ->nr_frags being 7. skb_to_sgvec() then tries to return a "zeroth" fragment that seems to occur before the fragments counted by ->nr_frags and we hit the end of the sglist too early. Note that __skb_to_sgvec() also has an skb_walk_frags() loop that is recursive up to 24 deep. I'm not sure if I need to take account of that too - or if there's an easy way of counting those frags too. Fix this by counting an extra frag and allocating a larger sglist based on that. Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Signed-off-by: Sasha Levin commit 409a7486c4cfc6f457f060de5f173667118147c8 Author: David Howells Date: Fri Aug 26 15:39:28 2022 +0100 rxrpc: Fix ICMP/ICMP6 error handling [ Upstream commit ac56a0b48da86fd1b4389632fb7c4c8a5d86eefa ] Because rxrpc pretends to be a tunnel on top of a UDP/UDP6 socket, allowing it to siphon off UDP packets early in the handling of received UDP packets thereby avoiding the packet going through the UDP receive queue, it doesn't get ICMP packets through the UDP ->sk_error_report() callback. In fact, it doesn't appear that there's any usable option for getting hold of ICMP packets. Fix this by adding a new UDP encap hook to distribute error messages for UDP tunnels. If the hook is set, then the tunnel driver will be able to see ICMP packets. The hook provides the offset into the packet of the UDP header of the original packet that caused the notification. An alternative would be to call the ->error_handler() hook - but that requires that the skbuff be cloned (as ip_icmp_error() or ipv6_cmp_error() do, though isn't really necessary or desirable in rxrpc's case is we want to parse them there and then, not queue them). Changes ======= ver #3) - Fixed an uninitialised variable. ver #2) - Fixed some missing CONFIG_AF_RXRPC_IPV6 conditionals. Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit e9d0362a41d5af2cd60cce6d21fa1e5a9e133c22 Author: Takashi Iwai Date: Wed Aug 31 14:59:01 2022 +0200 ALSA: usb-audio: Register card again for iface over delayed_register option [ Upstream commit 2027f114686e0f3f1f39971964dfc618637c88c2 ] When the delayed registration is specified via either delayed_register option or the quirk, we delay the invocation of snd_card_register() until the given interface. But if a wrong value has been set there and there are more interfaces over the given interface number, snd_card_register() call would be missing for those interfaces. This patch catches up those missing calls by fixing the comparison of the interface number. Now the call is skipped only if the processed interface is less than the given interface, instead of the exact match. Fixes: b70038ef4fea ("ALSA: usb-audio: Add delayed_register option") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082 Link: https://lore.kernel.org/r/20220831125901.4660-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9cd9a55ca3dfda23e1816cb00813a17cfbb913cf Author: Takashi Iwai Date: Wed Aug 31 14:59:00 2022 +0200 ALSA: usb-audio: Inform the delayed registration more properly [ Upstream commit 7e1afce5866e02b45bf88c27dd7de1b9dfade1cc ] The info message that was added in the commit a4aad5636c72 ("ALSA: usb-audio: Inform devices that need delayed registration") is actually useful to know the need for the delayed registration. However, it turned out that this doesn't catch the all cases; namely, this warned only when a PCM stream is attached onto the existing PCM instance, but it doesn't count for a newly created PCM instance. This made confusion as if there were no further delayed registration. This patch moves the check to the code path for either adding a stream or creating a PCM instance. Also, make it simpler by checking the card->registered flag instead of querying each snd_device state. Fixes: a4aad5636c72 ("ALSA: usb-audio: Inform devices that need delayed registration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082 Link: https://lore.kernel.org/r/20220831125901.4660-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f2c70f56f762e5dc3b0d7dc438fbb137cb116413 Author: yangx.jy@fujitsu.com Date: Wed Aug 31 08:16:29 2022 +0000 RDMA/srp: Set scmnd->result only when scmnd is not NULL [ Upstream commit 12f35199a2c0551187edbf8eb01379f0598659fa ] This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally. BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] irq_poll_softirq+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/0xc0 Fixes: ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") Link: https://lore.kernel.org/r/20220831081626.18712-1-yangx.jy@fujitsu.com Signed-off-by: Xiao Yang Acked-by: Bart Van Assche Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6cf0609154b2ce8d3ae160e7506ab316400a8d3d Author: David Leadbeater Date: Fri Aug 26 14:56:58 2022 +1000 netfilter: nf_conntrack_irc: Fix forged IP logic [ Upstream commit 0efe125cfb99e6773a7434f3463f7c2fa28f3a43 ] Ensure the match happens in the right direction, previously the destination used was the server, not the NAT host, as the comment shows the code intended. Additionally nf_nat_irc uses port 0 as a signal and there's no valid way it can appear in a DCC message, so consider port 0 also forged. Fixes: 869f37d8e48f ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port") Signed-off-by: David Leadbeater Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8acba0b39cf37dd8d9a83ac178fd7397c114c4aa Author: Conor Dooley Date: Thu Aug 25 19:04:18 2022 +0100 riscv: dts: microchip: use an mpfs specific l2 compatible [ Upstream commit 0dec364ffeb6149aae572ded1e34d4b444c23be6 ] PolarFire SoC does not have the same l2 cache controller as the fu540, featuring an extra interrupt. Appease the devicetree checker overlords by adding a PolarFire SoC specific compatible to fix the below sort of warnings: mpfs-polarberry.dtb: cache-controller@2010000: interrupts: [[1], [3], [4], [2]] is too long Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE board") Fixes: 34fc9cc3aebe ("riscv: dts: microchip: correct L2 cache interrupts") Reviewed-by: Heinrich Schuchardt Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5 Author: Pablo Neira Ayuso Date: Wed Aug 31 13:11:47 2022 +0200 netfilter: nf_tables: clean up hook list when offload flags check fails [ Upstream commit 77972a36ecc4db7fc7c68f0e80714263c5f03f65 ] splice back the hook list so nft_chain_release_hook() has a chance to release the hooks. BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [] kmalloc include/linux/slab.h:600 [inline] [] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline] [] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218 [] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline] [] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [inline] [] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: d54725cd11a5 ("netfilter: nf_tables: support for multiple devices per netdev hook") Reported-by: syzbot+5fcdbfab6d6744c57418@syzkaller.appspotmail.com Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e62ff26f111977bc813ef546cc3509efba73705e Author: Harsh Modi Date: Tue Aug 30 22:36:03 2022 -0700 netfilter: br_netfilter: Drop dst references before setting. [ Upstream commit d047283a7034140ea5da759a494fd2274affdd46 ] The IPv6 path already drops dst in the daddr changed case, but the IPv4 path does not. This change makes the two code paths consistent. Further, it is possible that there is already a metadata_dst allocated from ingress that might already be attached to skbuff->dst while following the bridge path. If it is not released before setting a new metadata_dst, it will be leaked. This is similar to what is done in bpf_set_tunnel_key() or ip6_route_input(). It is important to note that the memory being leaked is not the dst being set in the bridge code, but rather memory allocated from some other code path that is not being freed correctly before the skb dst is overwritten. An example of the leakage fixed by this commit found using kmemleak: unreferenced object 0xffff888010112b00 (size 256): comm "softirq", pid 0, jiffies 4294762496 (age 32.012s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 80 16 f1 83 ff ff ff ff ................ e1 4e f6 82 ff ff ff ff 00 00 00 00 00 00 00 00 .N.............. backtrace: [<00000000d79567ea>] metadata_dst_alloc+0x1b/0xe0 [<00000000be113e13>] udp_tun_rx_dst+0x174/0x1f0 [<00000000a36848f4>] geneve_udp_encap_recv+0x350/0x7b0 [<00000000d4afb476>] udp_queue_rcv_one_skb+0x380/0x560 [<00000000ac064aea>] udp_unicast_rcv_skb+0x75/0x90 [<000000009a8ee8c5>] ip_protocol_deliver_rcu+0xd8/0x230 [<00000000ef4980bb>] ip_local_deliver_finish+0x7a/0xa0 [<00000000d7533c8c>] __netif_receive_skb_one_core+0x89/0xa0 [<00000000a879497d>] process_backlog+0x93/0x190 [<00000000e41ade9f>] __napi_poll+0x28/0x170 [<00000000b4c0906b>] net_rx_action+0x14f/0x2a0 [<00000000b20dd5d4>] __do_softirq+0xf4/0x305 [<000000003a7d7e15>] __irq_exit_rcu+0xc3/0x140 [<00000000968d39a2>] sysvec_apic_timer_interrupt+0x9e/0xc0 [<000000009e920794>] asm_sysvec_apic_timer_interrupt+0x16/0x20 [<000000008942add0>] native_safe_halt+0x13/0x20 Florian Westphal says: "Original code was likely fine because nothing ever did set a skb->dst entry earlier than bridge in those days." Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Harsh Modi Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 715ab32367f9b087ffdad340a2f9e9ed1c1a69c4 Author: Claudiu Beznea Date: Fri Aug 26 11:39:26 2022 +0300 ARM: dts: at91: sama5d2_icp: don't keep vdd_other enabled all the time [ Upstream commit 3d074b750d2b4c91962f10ea1df1c289ce0d3ce8 ] VDD_OTHER is not connected to any on board consumer thus it is not needed to keep it enabled all the time. Fixes: 68a95ef72cef ("ARM: dts: at91: sama5d2-icp: add SAMA5D2-ICP") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-9-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 495cca3f62c63d510e1e55eea6b5b5ea47fcfd62 Author: Claudiu Beznea Date: Fri Aug 26 11:39:25 2022 +0300 ARM: dts: at91: sama5d27_wlsom1: don't keep ldo2 enabled all the time [ Upstream commit 617a0d9fe6867bf5b3b7272629cd780c27c877d9 ] ldo2 is not used by any consumer on sama5d27_wlsom1 board, thus don't keep it enabled all the time. Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-8-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit b6b94483102deca2b071c5a5c944bf6932475021 Author: Claudiu Beznea Date: Fri Aug 26 11:39:24 2022 +0300 ARM: dts: at91: sama7g5ek: specify proper regulator output ranges [ Upstream commit 7f41d52ced9e1b7ed4ff8e1ae9cacbf46b64e6db ] Min and max output ranges of regulators need to satisfy board requirements not PMIC requirements. Thus adjust device tree to cope with this. Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-7-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 645ac9718e1f291df7415211465e58654d91625b Author: Claudiu Beznea Date: Fri Aug 26 11:39:23 2022 +0300 ARM: dts: at91: sama5d2_icp: specify proper regulator output ranges [ Upstream commit 7737d93666eea282febf95e5fa3b3fde1f2549f3 ] Min and max output ranges of regulators need to satisfy board requirements not PMIC requirements. Thus adjust device tree to cope with this. Fixes: 68a95ef72cef ("ARM: dts: at91: sama5d2-icp: add SAMA5D2-ICP") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-6-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 2fc2ea1341e61b7ece9ca117b77fccf834886301 Author: Claudiu Beznea Date: Fri Aug 26 11:39:22 2022 +0300 ARM: dts: at91: sama5d27_wlsom1: specify proper regulator output ranges [ Upstream commit addf7efec23af2b67547800aa232d551945e7de2 ] Min and max output ranges of regulators need to satisfy board requirements not PMIC requirements. Thus adjust device tree to cope with this. Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-5-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 7efca37d3178cbafd2d052135255f53c83924f31 Author: Claudiu Beznea Date: Fri Aug 26 11:39:21 2022 +0300 ARM: at91: pm: fix DDR recalibration when resuming from backup and self-refresh [ Upstream commit 7a94b83a7dc551607b6c4400df29151e6a951f07 ] On SAMA7G5, when resuming from backup and self-refresh, the bootloader performs DDR PHY recalibration by restoring the value of ZQ0SR0 (stored in RAM by Linux before going to backup and self-refresh). It has been discovered that the current procedure doesn't work for all possible values that might go to ZQ0SR0 due to hardware bug. The workaround to this is to avoid storing some values in ZQ0SR0. Thus Linux will read the ZQ0SR0 register and cache its value in RAM after processing it (using modified_gray_code array). The bootloader will restore the processed value. Fixes: d2d4716d8384 ("ARM: at91: pm: save ddr phy calibration data to securam") Suggested-by: Frederic Schumacher Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220826083927.3107272-4-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 86f07e220b8d439f221a9e7d0f95569c94051102 Author: Claudiu Beznea Date: Fri Aug 26 11:39:20 2022 +0300 ARM: at91: pm: fix self-refresh for sama7g5 [ Upstream commit a02875c4cbd6f3d2f33d70cc158a19ef02d4b84f ] It has been discovered that on some parts, from time to time, self-refresh procedure doesn't work as expected. Debugging and investigating it proved that disabling AC DLL introduce glitches in RAM controllers which leads to unexpected behavior. This is confirmed as a hardware bug. DLL bypass disables 3 DLLs: 2 DX DLLs and AC DLL. Thus, keep only DX DLLs disabled. This introduce 6mA extra current consumption on VDDCORE when switching to any ULP mode or standby mode but the self-refresh procedure still works. Fixes: f0bbf17958e8 ("ARM: at91: pm: add self-refresh support for sama7g5") Suggested-by: Frederic Schumacher Signed-off-by: Claudiu Beznea Tested-by: Cristian Birsan Link: https://lore.kernel.org/r/20220826083927.3107272-3-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit 5212d958f6518003cd98c9886f8e8aedcfc25741 Author: Ajay.Kathat@microchip.com Date: Tue Aug 9 07:57:56 2022 +0000 wifi: wilc1000: fix DMA on stack objects [ Upstream commit 40b717bfcefab28a0656b8caa5e43d5449e5a671 ] Sometimes 'wilc_sdio_cmd53' is called with addresses pointing to an object on the stack. Use dynamically allocated memory for cmd53 instead of stack address which is not DMA'able. Fixes: 5625f965d764 ("wilc1000: move wilc driver out of staging") Reported-by: Michael Walle Suggested-by: Michael Walle Signed-off-by: Ajay Singh Reviewed-by: Michael Walle Tested-by: Michael Walle Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220809075749.62752-1-ajay.kathat@microchip.com Signed-off-by: Sasha Levin commit 374b04cb6e7b7bf99e44a0110df83615b0fccbcd Author: Yixing Liu Date: Mon Aug 29 18:50:20 2022 +0800 RDMA/hns: Remove the num_qpc_timer variable [ Upstream commit 45baad7dd98f4d83f67c86c28769d3184390e324 ] The bt number of qpc_timer of HIP09 increases compared with that of HIP08. Therefore, qpc_timer_bt_num and num_qpc_timer do not match. As a result, the driver may fail to allocate qpc_timer. So the driver needs to uniquely uses qpc_timer_bt_num to represent the bt number of qpc_timer. Fixes: 0e40dc2f70cd ("RDMA/hns: Add timer allocation support for hip08") Link: https://lore.kernel.org/r/20220829105021.1427804-4-liangwenpeng@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Wenpeng Liang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 090f6a3c4d918adff8c754c67ebdae4e3f64f623 Author: Wenpeng Liang Date: Mon Aug 29 18:50:19 2022 +0800 RDMA/hns: Fix wrong fixed value of qp->rq.wqe_shift [ Upstream commit 0c8b5d6268d92d141bfd64d21c870d295a84dee1 ] The value of qp->rq.wqe_shift of HIP08 is always determined by the number of sge. So delete the wrong branch. Fixes: cfc85f3e4b7f ("RDMA/hns: Add profile support for hip08 driver") Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/20220829105021.1427804-3-liangwenpeng@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit dd20bd80356802acd655d1f597b338015bf460c4 Author: Chengchang Tang Date: Mon Aug 29 18:50:18 2022 +0800 RDMA/hns: Fix supported page size [ Upstream commit 55af9d498556f0860eb89ffa7677e8d73f6f643f ] The supported page size for hns is (4K, 128M), not (4K, 2G). Fixes: cfc85f3e4b7f ("RDMA/hns: Add profile support for hip08 driver") Link: https://lore.kernel.org/r/20220829105021.1427804-2-liangwenpeng@huawei.com Signed-off-by: Chengchang Tang Signed-off-by: Wenpeng Liang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 653500b400d5576940b7429690f7197199ddcc82 Author: Liang He Date: Thu Jul 7 09:56:20 2022 +0800 soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs [ Upstream commit 1085f5080647f0c9f357c270a537869191f7f2a1 ] In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220707015620.306468-1-windhl@126.com Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 811b2bfda3d6e473ff0c7cbc13f89ceda0aa681c Author: Michael Guralnik Date: Tue Aug 23 13:51:50 2022 +0300 RDMA/cma: Fix arguments order in net device validation [ Upstream commit 27cfde795a96aef1e859a5480489944b95421e46 ] Fix the order of source and destination addresses when resolving the route between server and client to validate use of correct net device. The reverse order we had so far didn't actually validate the net device as the server would try to resolve the route to itself, thus always getting the server's net device. The issue was discovered when running cm applications on a single host between 2 interfaces with same subnet and source based routing rules. When resolving the reverse route the source based route rules were ignored. Fixes: f887f2ac87c2 ("IB/cma: Validate routing of incoming requests") Link: https://lore.kernel.org/r/1c1ec2277a131d277ebcceec987fd338d35b775f.1661251872.git.leonro@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f9c6980d8fddf88f9651d2e51589b097886b9a69 Author: Geert Uytterhoeven Date: Thu Aug 25 11:24:47 2022 +0200 arm64: dts: renesas: r8a779g0: Fix HSCIF0 interrupt number [ Upstream commit ab2866f12ca18747413ba41409231d44e0c6149b ] The interrupt number for the HSCIF0 serial port, which serves as the serial console on the White Hawk board, is incorrect, causing userspace to hang immediately as soon as it tries to print something. Kernel output is unaffected, as it is printed using polling. Fixes: 987da486d84a5643 ("arm64: dts: renesas: Add Renesas R8A779G0 SoC support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/751dcef40d4534e856ed49b1d5b3a3e8d365ec42.1661419377.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 5becc531a3fa8da75158a8993f56cc3e0717716e Author: Shiraz Saleem Date: Wed Aug 24 10:43:59 2022 -0500 RDMA/irdma: Fix drain SQ hang with no completion [ Upstream commit ead54ced6321099978d30d62dc49c282a6e70574 ] SW generated completions for outstanding WRs posted on SQ after QP is in error target the wrong CQ. This causes the ib_drain_sq to hang with no completion. Fix this to generate completions on the right CQ. [ 863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds. [ 863.979224] Not tainted 5.14.0-130.el9.x86_64 #1 [ 863.986588] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 863.996997] task:kworker/u52:2 state:D stack: 0 pid: 671 ppid: 2 flags:0x00004000 [ 864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc] [ 864.014056] Call Trace: [ 864.017575] __schedule+0x206/0x580 [ 864.022296] schedule+0x43/0xa0 [ 864.026736] schedule_timeout+0x115/0x150 [ 864.032185] __wait_for_common+0x93/0x1d0 [ 864.037717] ? usleep_range_state+0x90/0x90 [ 864.043368] __ib_drain_sq+0xf6/0x170 [ib_core] [ 864.049371] ? __rdma_block_iter_next+0x80/0x80 [ib_core] [ 864.056240] ib_drain_sq+0x66/0x70 [ib_core] [ 864.062003] rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma] [ 864.069365] ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc] [ 864.076386] xprt_rdma_close+0xe/0x30 [rpcrdma] [ 864.082593] xprt_autoclose+0x52/0x100 [sunrpc] [ 864.088718] process_one_work+0x1e8/0x3c0 [ 864.094170] worker_thread+0x50/0x3b0 [ 864.099109] ? rescuer_thread+0x370/0x370 [ 864.104473] kthread+0x149/0x170 [ 864.109022] ? set_kthread_struct+0x40/0x40 [ 864.114713] ret_from_fork+0x22/0x30 Fixes: 81091d7696ae ("RDMA/irdma: Add SW mechanism to generate completions on error") Link: https://lore.kernel.org/r/20220824154358.117-1-shiraz.saleem@intel.com Reported-by: Kamal Heib Signed-off-by: Shiraz Saleem Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 26e27bcb3d3d075c1e8bfd75927a8b29f31f6e3a Author: Jens Wiklander Date: Mon Aug 22 07:43:35 2022 +0200 tee: fix compiler warning in tee_shm_register() [ Upstream commit eccd7439709810127563e7e3e49b8b44c7b2791d ] Include to avoid the warning: drivers/tee/tee_shm.c: In function 'tee_shm_register': >> drivers/tee/tee_shm.c:242:14: error: implicit declaration of function 'access_ok' [-Werror=implicit-function-declaration] 242 | if (!access_ok((void __user *)addr, length)) | ^~~~~~~~~ cc1: some warnings being treated as errors Fixes: 573ae4f13f63 ("tee: add overflow check in register_shm_helper()") Reviewed-by: Sumit Garg Reported-by: kernel test robot Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 6e4ce9eb74501f11ec28382f1710f1a7323ec14c Author: Peter Ujfalusi Date: Tue Aug 23 15:15:54 2022 +0300 ASoC: SOF: Kconfig: Make IPC_MESSAGE_INJECTOR depend on SND_SOC_SOF [ Upstream commit 2cf520ffbcbd55c0f2b4276065444d7526d9d197 ] Make sure that the IPC_MESSAGE_INJECTOR client can not be built in when SND_SOC_SOF is built as module. Fixes: cac0b0887e530 ("ASoC: SOF: Convert the generic IPC message injector into SOF client") Reported-by: kernel test robot Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220823121554.4255-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6db11941aa0fdac15b816356a1f5a02fa55342b6 Author: Peter Ujfalusi Date: Tue Aug 23 15:15:53 2022 +0300 ASoC: SOF: Kconfig: Make IPC_FLOOD_TEST depend on SND_SOC_SOF [ Upstream commit 3942499fba11de048c3ac1390b808e9e6ae88de5 ] Make sure that the IPC_FLOOD client can not be built in when SND_SOC_SOF is built as module. Fixes: 6e9548cdb30e5 ("ASoC: SOF: Convert the generic IPC flood test into SOF client") Reported-by: kernel test robot Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220823121554.4255-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8fb6a79a7e3068e354bb2481f19d7882bce35bc7 Author: Andrew Halaney Date: Fri Aug 19 14:43:36 2022 -0500 regulator: core: Clean up on enable failure [ Upstream commit c32f1ebfd26bece77141257864ed7b4720da1557 ] If regulator_enable() fails, enable_count is incremented still. A consumer, assuming no matching regulator_disable() is necessary on failure, will then get this error message upon regulator_put() since enable_count is non-zero: [ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170 The consumer could try to fix this in their driver by cleaning up on error from regulator_enable() (i.e. call regulator_disable()), but that results in the following since regulator_enable() failed and didn't increment user_count: [ 1.258112] unbalanced disables for vreg_l17c [ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190 Fix this by decrementing enable_count upon failure to enable. With this in place, just the reason for failure to enable is printed as expected and developers can focus on the root cause of their issue instead of thinking their usage of the regulator consumer api is incorrect. For example, in my case: [ 1.240426] vreg_l17c: invalid input voltage found Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Signed-off-by: Andrew Halaney Reviewed-by: Douglas Anderson Reviewed-by: Brian Masney Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99fc0f42f834db8d86c846b40c4a5398b8b5a89f Author: Marcel Ziswiler Date: Fri Aug 12 23:39:05 2022 +0200 arm64: dts: freescale: verdin-imx8mp: fix atmel_mxt_ts reset polarity [ Upstream commit 8f143b9f3849828870bb2a7f28288095ad9a329d ] Fix reset GPIO polarity in-line with the following commit feedaacdadfc ("Input: atmel_mxt_ts - fix up inverted RESET handler"). Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus") Signed-off-by: Marcel Ziswiler Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ab7db01d23adbd1405f2d8c282a1856c279fe025 Author: Marcel Ziswiler Date: Fri Aug 12 23:39:04 2022 +0200 arm64: dts: freescale: verdin-imx8mm: fix atmel_mxt_ts reset polarity [ Upstream commit 90974f655922219c0a0cdce7ae8de7f30c549cb5 ] Fix reset GPIO polarity in-line with the following commit feedaacdadfc ("Input: atmel_mxt_ts - fix up inverted RESET handler"). Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Marcel Ziswiler Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit d536d38558bd5c63aa3158030f507735a0d60f8f Author: Tim Harvey Date: Fri Aug 12 10:20:54 2022 -0700 arm64: dts: imx8mm-venice-gw7901: fix port/phy validation [ Upstream commit 7f4dbc3f26e5cb1f056faaaf14277f48c4682fff ] Since commit 65ac79e18120 ("net: dsa: microchip: add the phylink get_caps") the phy-mode must be set otherwise the switch driver will assume "NA" mode and invalidate the port. Fixes: 65ac79e18120 ("net: dsa: microchip: add the phylink get_caps") Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0c64a21e6f1567aa49dbcc96a7beefeb20cf5bce Author: Philippe Schenker Date: Thu Aug 11 16:07:38 2022 +0200 arm64: dts: verdin-imx8mm: add otg2 pd to usbphy [ Upstream commit 2fa24aa721ebb3a83dd2093814ba9a5dcdaa3183 ] The Verdin iMX8M Mini System on Module does not have USB-ID signal connected on Verdin USB_2 (usbotg2). On Verdin Development board this is no problem, as we have connected a USB-Hub that is always connected. However, if Verdin USB_2 is desired to be used as a single USB-Host port the chipidea driver does not detect if a USB device is plugged into this port, due to runtime pm shutting down the PHY. Add the power-domain &pgc_otg2 to &usbphynop2 in order to detect plugging events and enumerate the usb device. Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Philippe Schenker Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 60a7ee22e6d0a19f4d235d861319d596cfb42426 Author: Marek Vasut Date: Fri Aug 12 19:08:02 2022 +0200 soc: imx: gpcv2: Assert reset before ungating clock [ Upstream commit df88005bd81b80c944d185554e264a4b0f993c37 ] In case the power domain clock are ungated before the reset is asserted, the system might freeze completely. This is likely due to a device is an undefined state being attached to bus, which sporadically leads to a bus hang. Assert the reset before the clock are enabled to assure the device is in defined state before being attached to bus. Fixes: fe58c887fb8ca ("soc: imx: gpcv2: add support for optional resets") Signed-off-by: Marek Vasut Reviewed-by: Fabio Estevam Reviewed-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2a107bcb05023a90604fafdf9bbf13f1217637ef Author: Vladimir Oltean Date: Tue Aug 2 16:50:06 2022 +0300 arm64: dts: ls1028a-qds-65bb: don't use in-band autoneg for 2500base-x [ Upstream commit e7406f864e765c564c5cf384464faff66114f97d ] The Lynx PCS integrated with ENETC port 0 does not support in-band autoneg for the 2500base-x SERDES protocol, and prints errors from its phylink methods. Furthermore, the AQR112 card used for these boards does not expect in-band autoneg either. So delete the extraneous property. Fixes: e426d63e752b ("arm64: dts: ls1028a-qds: add overlays for various serdes protocols") Signed-off-by: Vladimir Oltean Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit cf1459d1e5937001779c643a005567bf99cc564b Author: Marco Felsch Date: Tue Jul 26 15:05:22 2022 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix spi-flash compatible [ Upstream commit af7d78c957017f8b3a0986769f6f18e57f9362ea ] Drop the "winbond,w25q16dw" compatible since it causes to set the MODALIAS to w25q16dw which is not specified within spi-nor id table. Fix this by use the common "jedec,spi-nor" compatible. Fixes: 2125212785c9 ("ARM: dts: imx6qdl-kontron-samx6i: add Kontron SMARC SoM Support") Signed-off-by: Marco Felsch Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit cc868e06303396422dea1c130fcd21a2f48523cb Author: Marco Felsch Date: Tue Jul 26 15:05:21 2022 +0200 ARM: dts: imx6qdl-kontron-samx6i: remove duplicated node [ Upstream commit 204f67d86f55dd4fa757ed04757d7273f71a169c ] The regulator node 'regulator-3p3v-s0' was dupplicated. Remove it to clean the DTS. Fixes: 2a51f9dae13d ("ARM: dts: imx6qdl-kontron-samx6i: Add iMX6-based Kontron SMARC-sAMX6i module") Signed-off-by: Marco Felsch Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8b21a2a7709baadd453fd8b5a9a2d795f271c580 Author: David Jander Date: Tue Jul 26 14:32:22 2022 +0200 ARM: dts: imx6qdl-vicut1.dtsi: Fix node name backlight_led [ Upstream commit 83c75e1bc2b83b3f0c718833bde677ebfa736283 ] This naming error slipped through, so now that a new backlight node has been added with correct spelling, fix this one also. Fixes: 98efa526a0c4 ("ARM: dts: imx6qdl-vicut1/vicutgo: Add backlight_led node") Signed-off-by: David Jander Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6f3deed67b5b3498e50d0a2d3eb06b3f805b5982 Author: Jack Wang Date: Thu Aug 18 12:53:55 2022 +0200 RDMA/rtrs-srv: Pass the correct number of entries for dma mapped SGL [ Upstream commit 56c310de0b4b3aca1c4fdd9c1093fc48372a7335 ] ib_dma_map_sg() augments the SGL into a 'dma mapped SGL'. This process may change the number of entries and the lengths of each entry. Code that touches dma_address is iterating over the 'dma mapped SGL' and must use dma_nents which returned from ib_dma_map_sg(). We should use the return count from ib_dma_map_sg for futher usage. Fixes: 9cb837480424e ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20220818105355.110344-4-haris.iqbal@ionos.com Signed-off-by: Jack Wang Reviewed-by: Aleksei Marov Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fd666940d277591a5e989a5b4228ab1ccf4e92aa Author: Jack Wang Date: Thu Aug 18 12:53:54 2022 +0200 RDMA/rtrs-clt: Use the right sg_cnt after ib_dma_map_sg [ Upstream commit b66905e04dc714825aa6cffb950e281b46bbeafe ] When iommu is enabled, we hit warnings like this: WARNING: at rtrs/rtrs.c:178 rtrs_iu_post_rdma_write_imm+0x9b/0x110 rtrs warn on one sge entry length is 0, which is unexpected. The problem is ib_dma_map_sg augments the SGL into a 'dma mapped SGL'. This process may change the number of entries and the lengths of each entry. Code that touches dma_address is iterating over the 'dma mapped SGL' and must use dma_nents which returned from ib_dma_map_sg(). So pass the count return from ib_dma_map_sg. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20220818105355.110344-3-haris.iqbal@ionos.com Signed-off-by: Jack Wang Reviewed-by: Aleksei Marov Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cffeb3b329ac4c2db16b9296a62681c6d9efaa6b Author: Alexander Stein Date: Mon Jul 25 16:17:39 2022 +0200 arm64: dts: imx8mq-tqma8mq: Remove superfluous interrupt-names [ Upstream commit 8eaac789128a84e79c193e662959469e824423ee ] This property was never needed, remove it. This also silences dtbs_check warnings. Fixes: b186b8b6e770 ("arm64: dts: freescale: add initial device tree for TQMa8Mx with i.MX8M") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2b44191290fb2efa4818cfd1218d38631073649e Author: Peng Fan Date: Sat Jul 23 18:50:05 2022 +0800 arm64: dts: imx8mp-venice-gw74xx: fix sai2 pin settings [ Upstream commit 706dd9d30d3bda4e31d423af004c22d48e89fbc9 ] The pad settings are missed, add them Fixes: 7899eb6cb15d ("arm64: dts: imx: Add i.MX8M Plus Gateworks gw7400 dts support") Signed-off-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 15ff1f17847c19174b260bd7dd0de33edcebd45e Author: Cristian Ciocaltea Date: Thu Aug 18 13:48:51 2022 +0300 regmap: spi: Reserve space for register address/padding [ Upstream commit f5723cfc01932c7a8d5c78dbf7e067e537c91439 ] Currently the max_raw_read and max_raw_write limits in regmap_spi struct do not take into account the additional size of the transmitted register address and padding. This may result in exceeding the maximum permitted SPI message size, which could cause undefined behaviour, e.g. data corruption. Fix regmap_get_spi_bus() to properly adjust the above mentioned limits by reserving space for the register address/padding as set in the regmap configuration. Fixes: f231ff38b7b2 ("regmap: spi: Set regmap max raw r/w from max_transfer_size") Signed-off-by: Cristian Ciocaltea Reviewed-by: Lucas Tanure Link: https://lore.kernel.org/r/20220818104851.429479-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5add5a89bf9a55e123075c9aecbb6763c636c505 Author: Srinivas Kandagatla Date: Tue Aug 16 17:52:29 2022 +0100 ASoC: qcom: sm8250: add missing module owner [ Upstream commit c6e14bb9f50df7126ca64405ae807d8bc7b39f9a ] Add missing module owner to able to build and load this driver as module. Fixes: aa2e2785545a ("ASoC: qcom: sm8250: add sound card qrb5165-rb5 support") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220816165229.7971-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6bdd557e6c1df51655c6e55b91273fe836e0f99b Author: Andrejs Cainikovs Date: Fri Jul 8 14:42:05 2022 +0200 arm64: dts: imx8mm-verdin: use level interrupt for mcp251xfd [ Upstream commit e9f130e0775b5a2dad0a33440347d373ff69e631 ] Switch to level interrupt for mcp251xfd. This will make sure no interrupts are lost. Signed-off-by: Andrejs Cainikovs Reported-by: Marc Kleine-Budde Acked-by: Marc Kleine-Budde Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 459b8801236cbf669a6f9cf5c06959f568db2cc0 Author: Andrejs Cainikovs Date: Fri Jul 8 14:42:04 2022 +0200 arm64: dts: imx8mm-verdin: update CAN clock to 40MHz [ Upstream commit be1e3dfecf7d2fbcb4a45b113da637983878246c ] Update SPI CAN controller clock to match current hardware design. Signed-off-by: Andrejs Cainikovs Acked-by: Marcel Ziswiler Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9383a11e4322f09179043e4922c66277d13345c2 Author: Marco Felsch Date: Fri Jul 8 11:08:53 2022 +0200 Revert "soc: imx: imx8m-blk-ctrl: set power device name" [ Upstream commit b64b46fbaa1da626324f304bcb5fe0662f28b6ce ] This reverts commit 8239d67f59cf522dd4f7135392a2f9a3a25f9cff. This change confuses the sysfs cleanup path since the rename is done after the device registration. Fixes: 8239d67f59cf ("soc: imx: imx8m-blk-ctrl: set power device name") Signed-off-by: Marco Felsch Reviewed-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit cd1e3f9993877c1354d4853ff5e127b3d24a0317 Author: Richard Fitzgerald Date: Mon Aug 15 13:31:38 2022 +0100 ASoC: cs42l42: Only report button state if there was a button interrupt [ Upstream commit ea75deef1a738d25502cfbb2caa564270b271525 ] Only report a button state change if the interrupt status shows that there was a button event. Previously the code would always drop into the button reporting at the end of interrupt handling if the jack was present. If neither of the button report interrupts were pending it would report all buttons released. This could then lead to a button being reported as released while it is still pressed. Fixes: c5b8ee0879bc ("ASoC: cs42l42: Report jack and button detection") Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20220815123138.3810249-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 048f549c629a13e8f570767bf0f9392510c39886 Author: Robin Murphy Date: Wed Aug 3 15:58:57 2022 +0100 spi: bitbang: Fix lsb-first Rx [ Upstream commit 46f7ac3d7892e808c9ba01c39da6bb85cda26ecd ] Shifting the recieved bit by "bits" inserts it at the top of the *currently remaining* Tx data, so we end up accumulating the whole transfer into bit 0 of the output word. Oops. For the algorithm to work as intended, we need to remember where the top of the *original* word was, and shift Rx to there. Fixes: 1847e3046c52 ("spi: gpio: Implement LSB First bitbang support") Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/28324d8622da80461cce35a82859b003d6f6c4b0.1659538737.git.robin.murphy@arm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a30908856904dd43900c75bb7c91acf4bd17f1f Author: David Howells Date: Tue Aug 23 01:01:36 2022 -0500 smb3: missing inode locks in zero range [ Upstream commit c919c164fc87bcca8e80b3b9224492fa5b6455ba ] smb3 fallocate zero range was not grabbing the inode or filemap_invalidate locks so could have race with pagemap reinstantiating the page. Cc: stable@vger.kernel.org Signed-off-by: David Howells Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ef69b108b52cb1ca71fdb40d360e3475fc157332 Author: Enzo Matsumiya Date: Wed Aug 17 16:08:34 2022 -0300 cifs: remove useless parameter 'is_fsctl' from SMB2_ioctl() [ Upstream commit 400d0ad63b190895e29f43bc75b1260111d3fd34 ] SMB2_ioctl() is always called with is_fsctl = true, so doesn't make any sense to have it at all. Thus, always set SMB2_0_IOCTL_IS_FSCTL flag on the request. Also, as per MS-SMB2 3.3.5.15 "Receiving an SMB2 IOCTL Request", servers must fail the request if the request flags is zero anyway. Signed-off-by: Enzo Matsumiya Reviewed-by: Tom Talpey Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c0deb027c99c099aa6b831e326bfba802b25e774 Author: Tejun Heo Date: Mon Aug 15 13:27:38 2022 -1000 cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock [ Upstream commit 4f7e7236435ca0abe005c674ebd6892c6e83aeb3 ] Bringing up a CPU may involve creating and destroying tasks which requires read-locking threadgroup_rwsem, so threadgroup_rwsem nests inside cpus_read_lock(). However, cpuset's ->attach(), which may be called with thredagroup_rwsem write-locked, also wants to disable CPU hotplug and acquires cpus_read_lock(), leading to a deadlock. Fix it by guaranteeing that ->attach() is always called with CPU hotplug disabled and removing cpus_read_lock() call from cpuset_attach(). Signed-off-by: Tejun Heo Reviewed-and-tested-by: Imran Khan Reported-and-tested-by: Xuewen Yan Fixes: 05c7b7a92cc8 ("cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug") Cc: stable@vger.kernel.org # v5.17+ Signed-off-by: Sasha Levin commit bba6910b3c6dcf05e660685c55be845192a97b24 Author: Tejun Heo Date: Thu Jul 14 18:38:15 2022 -1000 cgroup: Elide write-locking threadgroup_rwsem when updating csses on an empty subtree [ Upstream commit 671c11f0619e5ccb380bcf0f062f69ba95fc974a ] cgroup_update_dfl_csses() write-lock the threadgroup_rwsem as updating the csses can trigger process migrations. However, if the subtree doesn't contain any tasks, there aren't gonna be any cgroup migrations. This condition can be trivially detected by testing whether mgctx.preloaded_src_csets is empty. Elide write-locking threadgroup_rwsem if the subtree is empty. After this optimization, the usage pattern of creating a cgroup, enabling the necessary controllers, and then seeding it with CLONE_INTO_CGROUP and then removing the cgroup after it becomes empty doesn't need to write-lock threadgroup_rwsem at all. Signed-off-by: Tejun Heo Cc: Christian Brauner Cc: Michal Koutný Signed-off-by: Sasha Levin commit 8a8d8a1ad791591a2239b27d834df2c7d6aaef14 Author: Yang Yingliang Date: Tue Aug 23 12:42:37 2022 +0800 scsi: lpfc: Add missing destroy_workqueue() in error path commit da6d507f5ff328f346b3c50e19e19993027b8ffd upstream. Add the missing destroy_workqueue() before return from lpfc_sli4_driver_resource_setup() in the error path. Link: https://lore.kernel.org/r/20220823044237.285643-1-yangyingliang@huawei.com Fixes: 3cee98db2610 ("scsi: lpfc: Fix crash on driver unload in wq free") Reviewed-by: James Smart Signed-off-by: Yang Yingliang Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 41acb064c4e013808bc7d5fc1b506fa449425b0b Author: Sreekanth Reddy Date: Tue Sep 6 19:19:08 2022 +0530 scsi: mpt3sas: Fix use-after-free warning commit 991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34 upstream. Fix the following use-after-free warning which is observed during controller reset: refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 Link: https://lore.kernel.org/r/20220906134908.1039-2-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8974d2ab8473640fb6a49fc0b02812eeb08fd90a Author: Ville Syrjälä Date: Fri Sep 2 10:03:18 2022 +0300 drm/i915: Implement WaEdpLinkRateDataReload commit 672d6ca758651f0ec12cd0d59787067a5bde1c96 upstream. A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld Cc: Ankit Nautiyal Cc: Jani Nikula Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma Tested-by: Jason A. Donenfeld Reviewed-by: Jani Nikula (cherry picked from commit 25899c590cb5ba9b9f284c6ca8e7e9086793d641) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 3a1381628082961645c300430abb20da68f1a46f Author: Rodrigo Vivi Date: Wed Aug 31 17:45:38 2022 -0400 drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPC commit e1cab970574c001d83e59ca8388c474a57a1afb6 upstream. We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: # v5.15+ Cc: Ashutosh Dixit Tested-by: Sushma Venkatesh Reddy Signed-off-by: Rodrigo Vivi Reviewed-by: Ashutosh Dixit Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com (cherry picked from commit 018a7bdbb090b9155a6509a0d1a684db4afaa5b1) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit ab620fc788f62194db71baf2e02c398fbfbd692a Author: Ville Syrjälä Date: Mon Aug 29 16:58:34 2022 +0300 drm/i915/bios: Copy the whole MIPI sequence block commit edca5a2c373db61efa959307c13ed9156b1c14d9 upstream. Turns out the MIPI sequence block version number and new block size fields are considered part of the block header and are not included in the reported new block size field itself. Bump up the block size appropriately so that we'll copy over the last five bytes of the block as well. For this particular machine those last five bytes included parts of the GPIO op for the backlight on sequence, causing the backlight no longer to turn back on: Sequence 6 - MIPI_SEQ_BACKLIGHT_ON Delay: 20000 us - GPIO index 0, number 0, set 0 (0x00) + GPIO index 1, number 70, set 1 (0x01) Cc: stable@vger.kernel.org Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit a06289f3f72431f3777af95ea1226b5b0abdc426) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 4484ce97a78171668c402e0c45db7f760aea8060 Author: Bart Van Assche Date: Fri Aug 12 14:03:17 2022 -0700 nvmet: fix a use-after-free commit 6a02a61e81c231cc5c680c5dbf8665275147ac52 upstream. Fix the following use-after-free complaint triggered by blktests nvme/004: BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30 Cc: stable@vger.kernel.org Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Bart Van Assche Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 7ea6589d0ff6d12805af6b0ee919c2a1c369f0cb Author: Greg Kroah-Hartman Date: Thu Sep 1 18:37:34 2022 +0200 driver core: fix driver_set_override() issue with empty strings commit 5666a274a6d54372d6b79b1f78682a9d827e679e upstream. Python likes to send an empty string for some sysfs files, including the driver_override field. When commit 23d99baf9d72 ("PCI: Use driver_set_override() instead of open-coding") moved the PCI core to use the driver core function instead of hand-rolling their own handler, this showed up as a regression from some userspace tools, like DPDK. Fix this up by actually looking at the length of the string first instead of trusting that userspace got it correct. Fixes: 23d99baf9d72 ("PCI: Use driver_set_override() instead of open-coding") Cc: Krzysztof Kozlowski Cc: Bjorn Helgaas Cc: "Rafael J. Wysocki" Cc: Andy Shevchenko Cc: stable Reported-by: Stephen Hemminger Tested-by: Huisong Li Reviewed-by: Stephen Hemminger Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220901163734.3583106-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 3a6279d243cb035eaaff1450980b40cf19748f05 Author: Greg Kroah-Hartman Date: Fri Sep 2 15:01:05 2022 +0200 drm/amd/display: fix memory leak when using debugfs_lookup() commit cbfac7fa491651c57926c99edeb7495c6c1aeac2 upstream. When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: David Airlie Cc: Daniel Vetter Cc: Wayne Lin Cc: hersen wu Cc: Wenjing Liu Cc: Patrik Jakobsson Cc: Thelford Williams Cc: Fangzhi Zuo Cc: Yongzhi Liu Cc: Mikita Lipski Cc: Jiapeng Chong Cc: Bhanuprakash Modem Cc: Sean Paul Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Reviewed-by: Rodrigo Siqueira Signed-off-by: Greg Kroah-Hartman Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0c32a93963e03c03e561d5a066eedad211880ba3 Author: Greg Kroah-Hartman Date: Fri Sep 2 14:31:07 2022 +0200 sched/debug: fix dentry leak in update_sched_domain_debugfs commit c2e406596571659451f4b95e37ddfd5a8ef1d0dc upstream. Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup()) leaks a dentry and with a hotplug stress test, the machine eventually runs out of memory. Fix this up by using the newly created debugfs_lookup_and_remove() call instead which properly handles the dentry reference counting logic. Cc: Major Chen Cc: stable Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Steven Rostedt Cc: Ben Segall Cc: Mel Gorman Cc: Daniel Bristot de Oliveira Cc: Valentin Schneider Cc: Matthias Brugger Reported-by: Kuyo Chang Tested-by: Kuyo Chang Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220902123107.109274-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 69f8701fe137f5699592e852010671bd5257778d Author: Greg Kroah-Hartman Date: Fri Sep 2 16:59:15 2022 +0200 debugfs: add debugfs_lookup_and_remove() commit dec9b2f1e0455a151a7293c367da22ab973f713e upstream. There is a very common pattern of using debugfs_remove(debufs_lookup(..)) which results in a dentry leak of the dentry that was looked up. Instead of having to open-code the correct pattern of calling dput() on the dentry, create debugfs_lookup_and_remove() to handle this pattern automatically and properly without any memory leaks. Cc: stable Reported-by: Kuyo Chang Tested-by: Kuyo Chang Link: https://lore.kernel.org/r/YxIaQ8cSinDR881k@kroah.com Signed-off-by: Greg Kroah-Hartman commit 24988042c561f1b6a387119bcbba42a0286a329e Author: Sergey Matyukevich Date: Tue Aug 30 18:53:04 2022 +0300 perf: RISC-V: fix access beyond allocated array commit 20e0fbab16003ae23a9e86a64bcb93e3121587ca upstream. SBI firmware should report total number of firmware and hardware counters including unused ones or special ones. In this case the kernel doesn't need to make any assumptions about gaps in reported counters, e.g. excluded timer counter. That was fixed in OpenSBI v1.1 by commit 3f66465fb6bf ("lib: pmu: allow to use the highest available counter"). This kernel patch has no effect if SBI firmware behaves correctly. However it eliminates access beyond the allocated pmu_ctr_list if the kernel is used with OpenSBI older than v1.1. Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Signed-off-by: Sergey Matyukevich Reviewed-by: Atish Patra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220830155306.301714-2-geomatsi@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit eea55b307d961ae5c5f12b8318f7799652a9f80f Author: Christian A. Ehrhardt Date: Wed Sep 7 22:09:17 2022 +0200 kprobes: Prohibit probes in gate area commit 1efda38d6f9ba26ac88b359c6277f1172db03f1e upstream. The system call gate area counts as kernel text but trying to install a kprobe in this area fails with an Oops later on. To fix this explicitly disallow the gate area for kprobes. Found by syzkaller with the following reproducer: perf_event_open$cgroup(&(0x7f00000001c0)={0x6, 0x80, 0x0, 0x0, 0x0, 0x0, 0x80ffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext={0x0, 0xffffffffff600000}}, 0xffffffffffffffff, 0x0, 0xffffffffffffffff, 0x0) Sample report: BUG: unable to handle page fault for address: fffffbfff3ac6000 PGD 6dfcb067 P4D 6dfcb067 PUD 6df8f067 PMD 6de4d067 PTE 0 Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 21978 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b-dirty #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__insn_get_emulate_prefix arch/x86/lib/insn.c:91 [inline] RIP: 0010:insn_get_emulate_prefix arch/x86/lib/insn.c:106 [inline] RIP: 0010:insn_get_prefixes.part.0+0xa8/0x1110 arch/x86/lib/insn.c:134 Code: 49 be 00 00 00 00 00 fc ff df 48 8b 40 60 48 89 44 24 08 e9 81 00 00 00 e8 e5 4b 39 ff 4c 89 fa 4c 89 f9 48 c1 ea 03 83 e1 07 <42> 0f b6 14 32 38 ca 7f 08 84 d2 0f 85 06 10 00 00 48 89 d8 48 89 RSP: 0018:ffffc900088bf860 EFLAGS: 00010246 RAX: 0000000000040000 RBX: ffffffff9b9bebc0 RCX: 0000000000000000 RDX: 1ffffffff3ac6000 RSI: ffffc90002d82000 RDI: ffffc900088bf9e8 RBP: ffffffff9d630001 R08: 0000000000000000 R09: ffffc900088bf9e8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff9d630000 R14: dffffc0000000000 R15: ffffffff9d630000 FS: 00007f63eef63640(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff3ac6000 CR3: 0000000029d90005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: insn_get_prefixes arch/x86/lib/insn.c:131 [inline] insn_get_opcode arch/x86/lib/insn.c:272 [inline] insn_get_modrm+0x64a/0x7b0 arch/x86/lib/insn.c:343 insn_get_sib+0x29a/0x330 arch/x86/lib/insn.c:421 insn_get_displacement+0x350/0x6b0 arch/x86/lib/insn.c:464 insn_get_immediate arch/x86/lib/insn.c:632 [inline] insn_get_length arch/x86/lib/insn.c:707 [inline] insn_decode+0x43a/0x490 arch/x86/lib/insn.c:747 can_probe+0xfc/0x1d0 arch/x86/kernel/kprobes/core.c:282 arch_prepare_kprobe+0x79/0x1c0 arch/x86/kernel/kprobes/core.c:739 prepare_kprobe kernel/kprobes.c:1160 [inline] register_kprobe kernel/kprobes.c:1641 [inline] register_kprobe+0xb6e/0x1690 kernel/kprobes.c:1603 __register_trace_kprobe kernel/trace/trace_kprobe.c:509 [inline] __register_trace_kprobe+0x26a/0x2d0 kernel/trace/trace_kprobe.c:477 create_local_trace_kprobe+0x1f7/0x350 kernel/trace/trace_kprobe.c:1833 perf_kprobe_init+0x18c/0x280 kernel/trace/trace_event_perf.c:271 perf_kprobe_event_init+0xf8/0x1c0 kernel/events/core.c:9888 perf_try_init_event+0x12d/0x570 kernel/events/core.c:11261 perf_init_event kernel/events/core.c:11325 [inline] perf_event_alloc.part.0+0xf7f/0x36a0 kernel/events/core.c:11619 perf_event_alloc kernel/events/core.c:12059 [inline] __do_sys_perf_event_open+0x4a8/0x2a00 kernel/events/core.c:12157 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f63ef7efaed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f63eef63028 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RAX: ffffffffffffffda RBX: 00007f63ef90ff80 RCX: 00007f63ef7efaed RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 00000000200001c0 RBP: 00007f63ef86019c R08: 0000000000000000 R09: 0000000000000000 R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000002 R14: 00007f63ef90ff80 R15: 00007f63eef43000 Modules linked in: CR2: fffffbfff3ac6000 ---[ end trace 0000000000000000 ]--- RIP: 0010:__insn_get_emulate_prefix arch/x86/lib/insn.c:91 [inline] RIP: 0010:insn_get_emulate_prefix arch/x86/lib/insn.c:106 [inline] RIP: 0010:insn_get_prefixes.part.0+0xa8/0x1110 arch/x86/lib/insn.c:134 Code: 49 be 00 00 00 00 00 fc ff df 48 8b 40 60 48 89 44 24 08 e9 81 00 00 00 e8 e5 4b 39 ff 4c 89 fa 4c 89 f9 48 c1 ea 03 83 e1 07 <42> 0f b6 14 32 38 ca 7f 08 84 d2 0f 85 06 10 00 00 48 89 d8 48 89 RSP: 0018:ffffc900088bf860 EFLAGS: 00010246 RAX: 0000000000040000 RBX: ffffffff9b9bebc0 RCX: 0000000000000000 RDX: 1ffffffff3ac6000 RSI: ffffc90002d82000 RDI: ffffc900088bf9e8 RBP: ffffffff9d630001 R08: 0000000000000000 R09: ffffc900088bf9e8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff9d630000 R14: dffffc0000000000 R15: ffffffff9d630000 FS: 00007f63eef63640(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff3ac6000 CR3: 0000000029d90005 CR4: 0000000000770ef0 PKRU: 55555554 ================================================================== Link: https://lkml.kernel.org/r/20220907200917.654103-1-lk@c--e.de cc: "Naveen N. Rao" cc: Anil S Keshavamurthy cc: "David S. Miller" Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Christian A. Ehrhardt Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 5d721bf222936f5cf3ee15ced53cc483ecef7e46 Author: Alex Williamson Date: Mon Aug 29 21:05:40 2022 -0600 vfio/type1: Unpin zero pages commit 873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 upstream. There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. Cc: stable@vger.kernel.org Reported-by: Luboslav Pivarc Reviewed-by: David Hildenbrand Link: https://lore.kernel.org/r/166182871735.3518559.8884121293045337358.stgit@omen Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit fddebf9a35561d04566aef1993a335cf39cd2464 Author: Naohiro Aota Date: Wed Aug 31 13:55:48 2022 +0900 btrfs: zoned: fix API misuse of zone finish waiting commit d5b81ced74afded85619ffbbe9c32ba9d82c9b1e upstream. The commit 2ce543f47843 ("btrfs: zoned: wait until zone is finished when allocation didn't progress") implemented a zone finish waiting mechanism to the write path of zoned mode. However, using wait_var_event()/wake_up_all() on fs_info->zone_finish_wait is wrong and wait_var_event() just hangs because no one ever wakes it up once it goes into sleep. Instead, we can simply use wait_on_bit_io() and clear_and_wake_up_bit() on fs_info->flags with a proper barrier installed. Fixes: 2ce543f47843 ("btrfs: zoned: wait until zone is finished when allocation didn't progress") CC: stable@vger.kernel.org # 5.16+ Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9a196afce18e3eb0958f6422bba431db836fefbc Author: Shin'ichiro Kawasaki Date: Fri Aug 26 16:42:15 2022 +0900 btrfs: zoned: set pseudo max append zone limit in zone emulation mode commit cac5c44c48c9fb9cc31bea15ebd9ef0c6462314f upstream. The commit 7d7672bc5d10 ("btrfs: convert count_max_extents() to use fs_info->max_extent_size") introduced a division by fs_info->max_extent_size. This max_extent_size is initialized with max zone append limit size of the device btrfs runs on. However, in zone emulation mode, the device is not zoned then its zone append limit is zero. This resulted in zero value of fs_info->max_extent_size and caused zero division error. Fix the error by setting non-zero pseudo value to max append zone limit in zone emulation mode. Set the pseudo value based on max_segments as suggested in the commit c2ae7b772ef4 ("btrfs: zoned: revive max_zone_append_bytes"). Fixes: 7d7672bc5d10 ("btrfs: convert count_max_extents() to use fs_info->max_extent_size") CC: stable@vger.kernel.org # 5.12+ Reviewed-by: Johannes Thumshirn Reviewed-by: Naohiro Aota Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 42e84c46679163e64a627d2415a399de49eb97e7 Author: Masami Hiramatsu (Google) Date: Sun Sep 4 13:12:29 2022 +0900 tracing: Fix to check event_mutex is held while accessing trigger list commit cecf8e128ec69149fe53c9a7bafa505a4bee25d9 upstream. Since the check_user_trigger() is called outside of RCU read lock, this list_for_each_entry_rcu() caused a suspicious RCU usage warning. # echo hist:keys=pid > events/sched/sched_stat_runtime/trigger # cat events/sched/sched_stat_runtime/trigger [ 43.167032] [ 43.167418] ============================= [ 43.167992] WARNING: suspicious RCU usage [ 43.168567] 5.19.0-rc5-00029-g19ebe4651abf #59 Not tainted [ 43.169283] ----------------------------- [ 43.169863] kernel/trace/trace_events_trigger.c:145 RCU-list traversed in non-reader section!! ... However, this file->triggers list is safe when it is accessed under event_mutex is held. To fix this warning, adds a lockdep_is_held check to the list_for_each_entry_rcu(). Link: https://lkml.kernel.org/r/166226474977.223837.1992182913048377113.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 3b8291c33b76f1e3a1da9fdc31717bdc52334cc5 Author: Yipeng Zou Date: Thu Sep 1 18:45:14 2022 +0800 tracing: hold caller_addr to hardirq_{enable,disable}_ip commit 54c3931957f6a6194d5972eccc36d052964b2abe upstream. Currently, The arguments passing to lockdep_hardirqs_{on,off} was fixed in CALLER_ADDR0. The function trace_hardirqs_on_caller should have been intended to use caller_addr to represent the address that caller wants to be traced. For example, lockdep log in riscv showing the last {enabled,disabled} at __trace_hardirqs_{on,off} all the time(if called by): [ 57.853175] hardirqs last enabled at (2519): __trace_hardirqs_on+0xc/0x14 [ 57.853848] hardirqs last disabled at (2520): __trace_hardirqs_off+0xc/0x14 After use trace_hardirqs_xx_caller, we can get more effective information: [ 53.781428] hardirqs last enabled at (2595): restore_all+0xe/0x66 [ 53.782185] hardirqs last disabled at (2596): ret_from_exception+0xa/0x10 Link: https://lkml.kernel.org/r/20220901104515.135162-2-zouyipeng@huawei.com Cc: stable@vger.kernel.org Fixes: c3bc8fd637a96 ("tracing: Centralize preemptirq tracepoints and unify their usage") Signed-off-by: Yipeng Zou Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 72e9640edb2d338b1a290b7dae0fffd220c437dc Author: Brian Norris Date: Fri Aug 26 17:44:17 2022 -0700 tracefs: Only clobber mode/uid/gid on remount if asked commit 47311db8e8f33011d90dee76b39c8886120cdda4 upstream. Users may have explicitly configured their tracefs permissions; we shouldn't overwrite those just because a second mount appeared. Only clobber if the options were provided at mount time. Note: the previous behavior was especially surprising in the presence of automounted /sys/kernel/debug/tracing/. Existing behavior: ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwx------ ## Unexpected: the automount changed mode for other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwx------ New behavior (after this change): ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwxr-xr-x ## Expected: the automount does not change other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid Cc: stable@vger.kernel.org Fixes: 4282d60689d4f ("tracefs: Add new tracefs file system") Signed-off-by: Brian Norris Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 8293e61bbf908b18ff9935238d4fc2ad359e3fe0 Author: Dongxiang Ke Date: Tue Sep 6 10:49:28 2022 +0800 ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface() commit e53f47f6c1a56d2af728909f1cb894da6b43d9bf upstream. There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and the number of it's interfaces less than 4, an out-of-bounds read bug occurs when parsing the interface descriptor for this device. Fix this by checking the number of interfaces. Signed-off-by: Dongxiang Ke Link: https://lore.kernel.org/r/20220906024928.10951-1-kdx.glider@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ef38df2b19ccea905b56a4f3e37c33daebc8f512 Author: Takashi Iwai Date: Wed Sep 7 12:04:21 2022 +0200 ALSA: usb-audio: Clear fixed clock rate at closing EP commit 809f44a0cc5ad4b1209467a6287f8ac0eb49d393 upstream. The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") tries to manage the clock rate shared by several endpoints. This was intended for avoiding the unmatched rate by a different endpoint, but unfortunately, it introduced a regression for PulseAudio and pipewire, too; those applications try to probe the multiple possible rates (44.1k and 48kHz) and setting up the normal rate fails but only the last rate is applied. The cause is that the last sample rate is still left to the clock reference even after closing the endpoint, and this value is still used at the next open. It happens only when applications set up via PCM prepare but don't start/stop the stream; the rate is reset when the stream is stopped, but it's not cleared at close. This patch addresses the issue above, simply by clearing the rate set in the clock reference at the last close of each endpoint. Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Reported-by: Jason A. Donenfeld Tested-by: Jason A. Donenfeld Cc: Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/ Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620 Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 271f862ebc60b3a7ff1563654eb33cd4571c66aa Author: Takashi Iwai Date: Thu Sep 1 14:41:36 2022 +0200 ALSA: usb-audio: Split endpoint setups for hw_params and prepare commit ff878b408a03bef5d610b7e2302702e16a53636e upstream. One of the former changes for the endpoint management was the more consistent setup of endpoints at hw_params. snd_usb_endpoint_configure() is a single function that does the full setup, and it's called from both PCM hw_params and prepare callbacks. Although the EP setup at the prepare phase is usually skipped (by checking need_setup flag), it may be still effective in some cases like suspend/resume that requires the interface setup again. As it's a full and single setup, the invocation of snd_usb_endpoint_configure() includes not only the USB interface setup but also the buffer release and allocation. OTOH, doing the buffer release and re-allocation at PCM prepare phase is rather superfluous, and better to be done only in the hw_params phase. For those optimizations, this patch splits the endpoint setup to two phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(), to be called from hw_params and from prepare, respectively. Note that this patch changes the driver operation slightly, effectively moving the USB interface setup again to PCM prepare stage instead of hw_params stage, while the buffer allocation and such initializations are still done at hw_params stage. And, the change of the USB interface setup timing (moving to prepare) gave an interesting "fix", too: it was reported that the recent kernels caused silent output at the beginning on playbacks on some devices on Android, and this change casually fixed the regression. It seems that those devices are picky about the sample rate change (or the interface change?), and don't follow the too immediate rate changes. Meanwhile, Android operates the PCM in the following order: - open, then hw_params with the possibly highest sample rate - close without prepare - re-open, hw_params with the normal sample rate - prepare, and start streaming This procedure ended up the hw_params twice with different rates, and because the recent kernel did set up the sample rate twice one and after, it screwed up the device. OTOH, the earlier kernels didn't set up the USB interface at hw_params, hence this problem didn't appear. Now, with this patch, the USB interface setup is again back to the prepare phase, and it works around the problem automagically. Although we should address the sample rate problem in a more solid way in future, let's keep things working as before for now. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Cc: Reported-by: chihhao chen Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 66a0abeea469ab5c27f950ff2b43400200c59db3 Author: Pattara Teerapong Date: Thu Sep 1 14:40:36 2022 +0000 ALSA: aloop: Fix random zeros in capture data when using jiffies timer commit 3e48940abee88b8dbbeeaf8a07e7b2b6be1271b3 upstream. In loopback_jiffies_timer_pos_update(), we are getting jiffies twice. First time for playback, second time for capture. Jiffies can be updated between these two calls and if the capture jiffies is larger, extra zeros will be filled in the capture buffer. Change to get jiffies once and use it for both playback and capture. Signed-off-by: Pattara Teerapong Cc: Link: https://lore.kernel.org/r/20220901144036.4049060-1-pteerapong@chromium.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 74276092fb7f54a9873d08c3bf8209e8d8069cc6 Author: Takashi Iwai Date: Tue Sep 6 11:03:19 2022 +0200 ALSA: hda: Once again fix regression of page allocations with IOMMU commit 37137ec26c2c03039d8064c00f6eae176841ee0d upstream. The last fix for trying to recover the regression on AMD platforms, unfortunately, leaded to yet another regression: it turned out that IOMMUs don't like the usage of raw page allocations. This is yet another attempt for addressing the log saga; at this time, we re-use the existing buffer allocation mechanism with SG-pages although we require only single pages. The SG buffer allocation itself was confirmed to work for stream buffers, so it's relatively easy to adapt for other places. The only problem is: although the HD-audio code is accessing the address directly via dmab->address field, SG-pages don't set up it. For the ease of adaption, we now set up the dmab->addr field from the address of the first page as default, so that it can run with the HD-audio driver code as-is without the excessive call of snd_sgbuf_get_addr() multiple times; that's the only change in the memalloc helper side. The rest is nothing but a flip of the dma_type field in the HD-audio side. Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again") Reported-by: Mikhail Gavrilov Tested-by: Mikhail Gavrilov Cc: Link: https://lore.kernel.org/r/CABXGCsO+kB2t5QyHY-rUe76npr1m0-5JOtt8g8SiHUo34ur7Ww@mail.gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=216112 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216363 Link: https://lore.kernel.org/r/20220906090319.23358-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4204a01ffce97cae1d59edc5848f02be5b2b9178 Author: Tasos Sahanidis Date: Wed Sep 7 04:18:00 2022 +0300 ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() commit d29f59051d3a07b81281b2df2b8c9dfe4716067f upstream. The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around. This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur. This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Signed-off-by: Tasos Sahanidis Cc: Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 723ac5ab2891b6c10dd6cc78ef5456af593490eb Author: Takashi Iwai Date: Mon Sep 5 08:07:14 2022 +0200 ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC commit 8423f0b6d513b259fdab9c9bf4aaa6188d054c2d upstream. There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant. Reported-and-tested-by: butt3rflyh4ck Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ff939d25ac9775445e5941502b8c08f42ea80937 Author: Qu Huang Date: Tue Aug 23 14:44:06 2022 +0800 drm/amdgpu: mmVM_L2_CNTL3 register not initialized correctly [ Upstream commit b8983d42524f10ac6bf35bbce6a7cc8e45f61e04 ] The mmVM_L2_CNTL3 register is not assigned an initial value Signed-off-by: Qu Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 97c9341e657968396e5657752d71622d995f43ab Author: Tim Huang Date: Mon Aug 22 13:30:44 2022 +0800 drm/amdgpu: add sdma instance check for gfx11 CGCG [ Upstream commit 00047c3d967d7ef8adf8bac3c3579294a3bc0bb1 ] For some ASICs, like GFX IP v11.0.1, only have one SDMA instance, so not need to configure SDMA1_RLC_CGCG_CTRL for this case. Signed-off-by: Tim Huang Reviewed-by: Yifan Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6f197b4a53f5ebbe6552cbbbdf5981d81c566a6b Author: Borislav Petkov Date: Wed Aug 24 17:13:26 2022 +0200 x86/sev: Mark snp_abort() noreturn [ Upstream commit c93c296fff6b369a7115916145047c8a3db6e27f ] Mark both the function prototype and definition as noreturn in order to prevent the compiler from doing transformations which confuse objtool like so: vmlinux.o: warning: objtool: sme_enable+0x71: unreachable instruction This triggers with gcc-12. Add it and sev_es_terminate() to the objtool noreturn tracking array too. Sort it while at it. Suggested-by: Michael Matz Signed-off-by: Borislav Petkov Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/20220824152420.20547-1-bp@alien8.de Signed-off-by: Sasha Levin commit eab18703e0faa6ed79f6876437cd8affd284ddde Author: Yang Yingliang Date: Fri Aug 19 16:57:52 2022 +0800 fbdev: chipsfb: Add missing pci_disable_device() in chipsfb_pci_init() [ Upstream commit 07c55c9803dea748d17a054000cbf1913ce06399 ] Add missing pci_disable_device() in error path in chipsfb_pci_init(). Signed-off-by: Yang Yingliang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 914b3d999d4e1c59f2d3dc9017ed3a32f5014efd Author: Shigeru Yoshida Date: Sun Aug 21 20:17:31 2022 +0900 fbdev: fbcon: Destroy mutex on freeing struct fb_info [ Upstream commit 58559dfc1ebba2ae0c7627dc8f8991ae1984c6e3 ] It's needed to destroy bl_curve_mutex on freeing struct fb_info since the mutex is embedded in the structure and initialized when it's allocated. Signed-off-by: Shigeru Yoshida Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4b688f85e81f188bd87c34645571c36406b3f3c2 Author: Yu Zhe Date: Fri Aug 12 14:52:23 2022 +0800 fbdev: omapfb: Fix tests for platform_get_irq() failure [ Upstream commit acf4c6205e862304681234a6a4375b478af12552 ] The platform_get_irq() returns negative error codes. It can't actually return zero. Signed-off-by: Yu Zhe Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit cebda5e536438975211316da0c55d7c1f000a5c7 Author: David Sloan Date: Thu Aug 11 11:14:13 2022 -0600 md: Flush workqueue md_rdev_misc_wq in md_alloc() [ Upstream commit 5e8daf906f890560df430d30617c692a794acb73 ] A race condition still exists when removing and re-creating md devices in test cases. However, it is only seen on some setups. The race condition was tracked down to a reference still being held to the kobject by the rdev in the md_rdev_misc_wq which will be released in rdev_delayed_delete(). md_alloc() waits for previous deletions by waiting on the md_misc_wq, but the md_rdev_misc_wq may still be holding a reference to a recently removed device. To fix this, also flush the md_rdev_misc_wq in md_alloc(). Signed-off-by: David Sloan [logang@deltatee.com: rewrote commit message] Signed-off-by: Logan Gunthorpe Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit a62701db411f3cbad13479101f4e2458ffff9e06 Author: lily Date: Mon Aug 22 22:44:11 2022 -0700 net/core/skbuff: Check the return value of skb_copy_bits() [ Upstream commit c624c58e08b15105662b9ab9be23d14a6b945a49 ] skb_copy_bits() could fail, which requires a check on the return value. Signed-off-by: Li Zhong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 73085208dd6b1a83bc38aa74d79efaa5741c3436 Author: Lukasz Luba Date: Tue Aug 16 13:01:57 2022 +0100 cpufreq: check only freq_table in __resolve_freq() [ Upstream commit 6ca7076fbfaeccce173aeab832d76b9e49e1034b ] There is no need to check if the cpufreq driver implements callback cpufreq_driver::target_index. The logic in the __resolve_freq uses the frequency table available in the policy. It doesn't matter if the driver provides 'target_index' or 'target' callback. It just has to populate the 'policy->freq_table'. Thus, check only frequency table during the frequency resolving call. Acked-by: Viresh Kumar Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit dae42083b045a4ddf71c57cf350cb2412b5915c2 Author: Lee, Chun-Yi Date: Mon Aug 8 21:21:58 2022 +0800 thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR [ Upstream commit 7931e28098a4c1a2a6802510b0cbe57546d2049d ] In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault. Signed-off-by: "Lee, Chun-Yi" Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 931144e785da17db6f4f10afe2c0d6dc78ff0fc1 Author: Florian Westphal Date: Fri Aug 19 00:42:31 2022 +0200 netfilter: conntrack: work around exceeded receive window [ Upstream commit cf97769c761abfeac8931b35fe0e1a8d5fabc9d8 ] When a TCP sends more bytes than allowed by the receive window, all future packets can be marked as invalid. This can clog up the conntrack table because of 5-day default timeout. Sequence of packets: 01 initiator > responder: [S], seq 171, win 5840, options [mss 1330,sackOK,TS val 63 ecr 0,nop,wscale 1] 02 responder > initiator: [S.], seq 33211, ack 172, win 65535, options [mss 1460,sackOK,TS val 010 ecr 63,nop,wscale 8] 03 initiator > responder: [.], ack 33212, win 2920, options [nop,nop,TS val 068 ecr 010], length 0 04 initiator > responder: [P.], seq 172:240, ack 33212, win 2920, options [nop,nop,TS val 279 ecr 010], length 68 Window is 5840 starting from 33212 -> 39052. 05 responder > initiator: [.], ack 240, win 256, options [nop,nop,TS val 872 ecr 279], length 0 06 responder > initiator: [.], seq 33212:34530, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318 This is fine, conntrack will flag the connection as having outstanding data (UNACKED), which lowers the conntrack timeout to 300s. 07 responder > initiator: [.], seq 34530:35848, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318 08 responder > initiator: [.], seq 35848:37166, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318 09 responder > initiator: [.], seq 37166:38484, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318 10 responder > initiator: [.], seq 38484:39802, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 1318 Packet 10 is already sending more than permitted, but conntrack doesn't validate this (only seq is tested vs. maxend, not 'seq+len'). 38484 is acceptable, but only up to 39052, so this packet should not have been sent (or only 568 bytes, not 1318). At this point, connection is still in '300s' mode. Next packet however will get flagged: 11 responder > initiator: [P.], seq 39802:40128, ack 240, win 256, options [nop,nop,TS val 892 ecr 279], length 326 nf_ct_proto_6: SEQ is over the upper bound (over the window of the receiver) .. LEN=378 .. SEQ=39802 ACK=240 ACK PSH .. Now, a couple of replies/acks comes in: 12 initiator > responder: [.], ack 34530, win 4368, [.. irrelevant acks removed ] 16 initiator > responder: [.], ack 39802, win 8712, options [nop,nop,TS val 296201291 ecr 2982371892], length 0 This ack is significant -- this acks the last packet send by the responder that conntrack considered valid. This means that ack == td_end. This will withdraw the 'unacked data' flag, the connection moves back to the 5-day timeout of established conntracks. 17 initiator > responder: ack 40128, win 10030, ... This packet is also flagged as invalid. Because conntrack only updates state based on packets that are considered valid, packet 11 'did not exist' and that gets us: nf_ct_proto_6: ACK is over upper bound 39803 (ACKed data not seen yet) .. SEQ=240 ACK=40128 WINDOW=10030 RES=0x00 ACK URG Because this received and processed by the endpoints, the conntrack entry remains in a bad state, no packets will ever be considered valid again: 30 responder > initiator: [F.], seq 40432, ack 2045, win 391, .. 31 initiator > responder: [.], ack 40433, win 11348, .. 32 initiator > responder: [F.], seq 2045, ack 40433, win 11348 .. ... all trigger 'ACK is over bound' test and we end up with non-early-evictable 5-day default timeout. NB: This patch triggers a bunch of checkpatch warnings because of silly indent. I will resend the cleanup series linked below to reduce the indent level once this change has propagated to net-next. I could route the cleanup via nf but that causes extra backport work for stable maintainers. Link: https://lore.kernel.org/netfilter-devel/20220720175228.17880-1-fw@strlen.de/T/#mb1d7147d36294573cc4f81d00f9f8dadfdd06cd8 Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 31e75db8921cdf6b2f062535179df6471fc93a82 Author: Ionela Voinescu Date: Fri Aug 19 11:30:50 2022 +0100 arm64: errata: add detection for AMEVCNTR01 incrementing incorrectly [ Upstream commit e89d120c4b720e232cc6a94f0fcbd59c15d41489 ] The AMU counter AMEVCNTR01 (constant counter) should increment at the same rate as the system counter. On affected Cortex-A510 cores, AMEVCNTR01 increments incorrectly giving a significantly higher output value. This results in inaccurate task scheduler utilization tracking and incorrect feedback on CPU frequency. Work around this problem by returning 0 when reading the affected counter in key locations that results in disabling all users of this counter from using it either for frequency invariance or as FFH reference counter. This effect is the same to firmware disabling affected counters. Details on how the two features are affected by this erratum: - AMU counters will not be used for frequency invariance for affected CPUs and CPUs in the same cpufreq policy. AMUs can still be used for frequency invariance for unaffected CPUs in the system. Although unlikely, if no alternative method can be found to support frequency invariance for affected CPUs (cpufreq based or solution based on platform counters) frequency invariance will be disabled. Please check the chapter on frequency invariance at Documentation/scheduler/sched-capacity.rst for details of its effect. - Given that FFH can be used to fetch either the core or constant counter values, restrictions are lifted regarding any of these counters returning a valid (!0) value. Therefore FFH is considered supported if there is a least one CPU that support AMUs, independent of any counters being disabled or affected by this erratum. Clarifying comments are now added to the cpc_ffh_supported(), cpu_read_constcnt() and cpu_read_corecnt() functions. The above is achieved through adding a new erratum: ARM64_ERRATUM_2457168. Signed-off-by: Ionela Voinescu Reviewed-by: Catalin Marinas Cc: Catalin Marinas Cc: Will Deacon Cc: James Morse Link: https://lore.kernel.org/r/20220819103050.24211-1-ionela.voinescu@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 078dac729f733cbf55fd25bd0ac0ed70f299b2ab Author: Helge Deller Date: Sun Aug 21 14:49:58 2022 +0200 parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines [ Upstream commit 591d2108f3abc4db9f9073cae37cf3591fd250d6 ] If a 32-bit kernel was compiled for PA2.0 CPUs, it won't be able to run on machines with PA1.x CPUs. Add a check and bail out early if a PA1.x machine is detected. Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 050e4a4c4c2693957487160bfde41e3e1501c2b2 Author: Li Qiong Date: Fri Aug 19 12:15:10 2022 +0800 parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources() [ Upstream commit d46c742f827fa2326ab1f4faa1cccadb56912341 ] As the possible failure of the kmalloc(), it should be better to fix this error path, check and return '-ENOMEM' error code. Signed-off-by: Li Qiong Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit fe7f0ac20b86ffb74c12f0cabac085ae9609d153 Author: Helge Deller Date: Sun Aug 21 08:12:19 2022 +0200 Revert "parisc: Show error if wrong 32/64-bit compiler is being used" [ Upstream commit b4b18f47f4f9682fbf5827682645da7c8dde8f80 ] This reverts commit b160628e9ebcdc85d0db9d7f423c26b3c7c179d0. There is no need any longer to have this sanity check, because the previous commit ("parisc: Make CONFIG_64BIT available for ARCH=parisc64 only") prevents that CONFIG_64BIT is set if ARCH==parisc. Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit ab2821ca9b6ca747006eb087adc2397153b1607d Author: Bart Van Assche Date: Thu Aug 11 16:43:49 2022 -0700 scsi: ufs: core: Reduce the power mode change timeout [ Upstream commit 8f2c96420c6ec3dcb18c8be923e24c6feaa5ccf6 ] The current power mode change timeout (180 s) is so large that it can cause a watchdog timer to fire. Reduce the power mode change timeout to 10 seconds. Link: https://lore.kernel.org/r/20220811234401.1957911-1-bvanassche@acm.org Reviewed-by: Stanley Chu Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 16cb367daa446923d82e332537f446a4cc784b40 Author: Zhenneng Li Date: Thu Aug 11 15:25:40 2022 +0800 drm/radeon: add a force flush to delay work when radeon [ Upstream commit f461950fdc374a3ada5a63c669d997de4600dffe ] Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [] ra = [] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [] si_dma_is_lockup+0x34/0xd0 [] radeon_fence_check_lockup+0xd0/0x290 [] process_one_work+0x280/0x550 [] worker_thread+0x70/0x7c0 [] worker_thread+0x130/0x7c0 [] kthread+0x200/0x210 [] worker_thread+0x0/0x7c0 [] kthread+0x14c/0x210 [] ret_from_kernel_thread+0x18/0x20 [] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem. Acked-by: Christian König Signed-off-by: Zhenneng Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8e77c29c0ad3d8c385e598b146a9395c08420378 Author: shaoyunl Date: Thu Aug 18 14:13:52 2022 -0400 drm/amdgpu: Remove the additional kfd pre reset call for sriov [ Upstream commit 06671734881af2bcf7f453661b5f8616e32bb3fc ] The additional call is caused by merge conflict Reviewed-by: Felix Kuehling Signed-off-by: shaoyunl Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cb7eb0aec2338f7797300303897053d858c60c8d Author: Candice Li Date: Thu Aug 18 10:47:09 2022 +0800 drm/amdgpu: Check num_gfx_rings for gfx v9_0 rb setup. [ Upstream commit c351938350ab9b5e978dede2c321da43de7eb70c ] No need to set up rb when no gfx rings. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f589c1fcc70e1b7634c6d245e31b76b15d7c79d6 Author: YiPeng Chai Date: Fri Aug 12 14:34:35 2022 +0800 drm/amdgpu: fix hive reference leak when adding xgmi device [ Upstream commit f5994da72ba124a3d0463672fdfbec073e3bb72f ] Only amdgpu_get_xgmi_hive but no amdgpu_put_xgmi_hive which will leak the hive reference. Signed-off-by: YiPeng Chai Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b9a123550cf098bd8ac102cae716e8beb4b0b215 Author: YiPeng Chai Date: Fri Aug 12 13:38:34 2022 +0800 drm/amdgpu: Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to psp_hw_fini [ Upstream commit 9d705d7741ae70764f3d6d87e67fad3b5c30ffd0 ] V1: The amdgpu_xgmi_remove_device function will send unload command to psp through psp ring to terminate xgmi, but psp ring has been destroyed in psp_hw_fini. V2: 1. Change the commit title. 2. Restore amdgpu_xgmi_remove_device to its original calling location. Move psp_xgmi_terminate call from amdgpu_xgmi_remove_device to psp_hw_fini. Signed-off-by: YiPeng Chai Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b537612692f42fde7c9d227f9467f04f36178f2c Author: Jeffy Chen Date: Fri Aug 19 15:28:34 2022 +0800 drm/gem: Fix GEM handle release errors [ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ] Currently we are assuming a one to one mapping between dmabuf and GEM handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the imported dmabuf might not always have gem_obj->dma_buf set, which would cause leaks in drm_gem_remove_prime_handles(). Let's fix these for now by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen Reviewed-by: Christian König Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.chen@rock-chips.com Signed-off-by: Sasha Levin commit 2af3d5515ea091e198d0e1b39bab7460a8f1e4d2 Author: Guixin Liu Date: Tue Aug 2 15:18:49 2022 +0800 scsi: megaraid_sas: Fix double kfree() [ Upstream commit 8c499e49240bd93628368c3588975cfb94169b8b ] When allocating log_to_span fails, kfree(instance->ctrl_context) is called twice. Remove redundant call. Link: https://lore.kernel.org/r/1659424729-46502-1-git-send-email-kanie@linux.alibaba.com Acked-by: Sumit Saxena Signed-off-by: Guixin Liu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 480c7ffec03a04e257003e80243fd936862e267f Author: Brian Bunker Date: Fri Jul 29 14:41:10 2022 -0700 scsi: core: Allow the ALUA transitioning state enough time [ Upstream commit 54249306e2776774ccb827969e62d34570f991db ] The error path for the SCSI check condition of not ready, target in ALUA state transition, will result in the failure of that path after the retries are exhausted. In most cases that is well ahead of the transition timeout established in the SCSI ALUA device handler. Instead, reprep the command and re-add it to the queue after a 1 second delay. This will allow the handler to take care of the timeout and only fail the path if the target has exceeded the transition expiry timeout (default 60 seconds). If the expiry timeout is exceeded, the handler will change the path state from transitioning to standby leading to a path failure eliminating the potential of this re-prep to continue endlessly. In most cases the target will exit the transitioning state well before the expiry timeout but after the retries are exhausted as mentioned. Additionally remove the scsi_io_completion_reprep() function which provides little value. Link: https://lore.kernel.org/r/20220729214110.58576-1-brian@purestorage.com Reviewed-by: Martin Wilck Acked-by: Krishna Kant Acked-by: Seamus Connor Signed-off-by: Brian Bunker Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cc3f0edf00b1087f883b61d02682c6ca821797dc Author: Tony Battersby Date: Thu Jul 7 15:08:01 2022 -0400 scsi: qla2xxx: Disable ATIO interrupt coalesce for quad port ISP27XX [ Upstream commit 53661ded2460b414644532de6b99bd87f71987e9 ] This partially reverts commit d2b292c3f6fd ("scsi: qla2xxx: Enable ATIO interrupt handshake for ISP27XX") For some workloads where the host sends a batch of commands and then pauses, ATIO interrupt coalesce can cause some incoming ATIO entries to be ignored for extended periods of time, resulting in slow performance, timeouts, and aborted commands. Disable interrupt coalesce and re-enable the dedicated ATIO MSI-X interrupt. Link: https://lore.kernel.org/r/97dcf365-89ff-014d-a3e5-1404c6af511c@cybernetics.com Reviewed-by: Himanshu Madhani Reviewed-by: Nilesh Javali Signed-off-by: Tony Battersby Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 871e0612a88c5412bb28d2d669e6f4780733180d Author: Yee Lee Date: Tue Sep 6 15:03:06 2022 +0800 Revert "mm: kmemleak: take a full lowmem check in kmemleak_*_phys()" This reverts commit 23c2d497de21f25898fbea70aeb292ab8acc8c94. Commit 23c2d497de21 ("mm: kmemleak: take a full lowmem check in kmemleak_*_phys()") brought false leak alarms on some archs like arm64 that does not init pfn boundary in early booting. The final solution lands on linux-6.0: commit 0c24e061196c ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA"). Revert this commit before linux-6.0. The original issue of invalid PA can be mitigated by additional check in devicetree. The false alarm report is as following: Kmemleak output: (Qemu/arm64) unreferenced object 0xffff0000c0170a00 (size 128): comm "swapper/0", pid 1, jiffies 4294892404 (age 126.208s) hex dump (first 32 bytes): 62 61 73 65 00 00 00 00 00 00 00 00 00 00 00 00 base............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<(____ptrval____)>] __kmalloc_track_caller+0x1b0/0x2e4 [<(____ptrval____)>] kstrdup_const+0x8c/0xc4 [<(____ptrval____)>] kvasprintf_const+0xbc/0xec [<(____ptrval____)>] kobject_set_name_vargs+0x58/0xe4 [<(____ptrval____)>] kobject_add+0x84/0x100 [<(____ptrval____)>] __of_attach_node_sysfs+0x78/0xec [<(____ptrval____)>] of_core_init+0x68/0x104 [<(____ptrval____)>] driver_init+0x28/0x48 [<(____ptrval____)>] do_basic_setup+0x14/0x28 [<(____ptrval____)>] kernel_init_freeable+0x110/0x178 [<(____ptrval____)>] kernel_init+0x20/0x1a0 [<(____ptrval____)>] ret_from_fork+0x10/0x20 This pacth is also applicable to linux-5.17.y/linux-5.18.y/linux-5.19.y Cc: Signed-off-by: Yee Lee Signed-off-by: Greg Kroah-Hartman commit 77d91ec788e9bf4129238203c3909c35c7fe4c19 Author: Mathew McBride Date: Thu Sep 1 05:21:49 2022 +0000 soc: fsl: select FSL_GUTS driver for DPIO commit 9a472613f5bccf1b36837423495ae592a9c5182f upstream. The soc/fsl/dpio driver will perform a soc_device_match() to determine the optimal cache settings for a given CPU core. If FSL_GUTS is not enabled, this search will fail and the driver will not configure cache stashing for the given DPIO, and a string of "unknown SoC" messages will appear: fsl_mc_dpio dpio.7: unknown SoC version fsl_mc_dpio dpio.6: unknown SoC version fsl_mc_dpio dpio.5: unknown SoC version Fixes: 51da14e96e9b ("soc: fsl: dpio: configure cache stashing destination") Signed-off-by: Mathew McBride Reviewed-by: Ioana Ciornei Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220901052149.23873-2-matt@traverse.com.au' Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 9224d6d8159207f31f8cfaa400eb9b9d73a2a3a8 Author: Linus Torvalds Date: Wed Aug 31 09:46:12 2022 -0700 fs: only do a memory barrier for the first set_buffer_uptodate() commit 2f79cdfe58c13949bbbb65ba5926abfe9561d0ec upstream. Commit d4252071b97d ("add barriers to buffer_uptodate and set_buffer_uptodate") added proper memory barriers to the buffer head BH_Uptodate bit, so that anybody who tests a buffer for being up-to-date will be guaranteed to actually see initialized state. However, that commit didn't _just_ add the memory barrier, it also ended up dropping the "was it already set" logic that the BUFFER_FNS() macro had. That's conceptually the right thing for a generic "this is a memory barrier" operation, but in the case of the buffer contents, we really only care about the memory barrier for the _first_ time we set the bit, in that the only memory ordering protection we need is to avoid anybody seeing uninitialized memory contents. Any other access ordering wouldn't be about the BH_Uptodate bit anyway, and would require some other proper lock (typically BH_Lock or the folio lock). A reader that races with somebody invalidating the buffer head isn't an issue wrt the memory ordering, it's a serialization issue. Now, you'd think that the buffer head operations don't matter in this day and age (and I certainly thought so), but apparently some loads still end up being heavy users of buffer heads. In particular, the kernel test robot reported that not having this bit access optimization in place caused a noticeable direct IO performance regression on ext4: fxmark.ssd_ext4_no_jnl_DWTL_54_directio.works/sec -26.5% regression although you presumably need a fast disk and a lot of cores to actually notice. Link: https://lore.kernel.org/all/Yw8L7HTZ%2FdE2%2Fo9C@xsang-OptiPlex-9020/ Reported-by: kernel test robot Tested-by: Fengwei Yin Cc: Mikulas Patocka Cc: Matthew Wilcox (Oracle) Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3c2238985418139ea4c612d13e8cecedcaebc089 Author: Stanislaw Gruszka Date: Mon Aug 15 09:37:37 2022 +0200 wifi: iwlegacy: 4965: corrected fix for potential off-by-one overflow in il4965_rs_fill_link_cmd() commit 6d0ef7241553f3553a0a2764c69b07892705924c upstream. This reverts commit a8eb8e6f7159c7c20c0ddac428bde3d110890aa7 as it can cause invalid link quality command sent to the firmware and address the off-by-one issue by fixing condition of while loop. Cc: stable@vger.kernel.org Fixes: a8eb8e6f7159 ("wifi: iwlegacy: 4965: fix potential off-by-one overflow in il4965_rs_fill_link_cmd()") Signed-off-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220815073737.GA999388@wp.pl Signed-off-by: Greg Kroah-Hartman commit f7f3001723e337568017e8617974f29bc8b2f595 Author: Deren Wu Date: Tue Aug 2 23:15:07 2022 +0800 wifi: mt76: mt7921e: fix crash in chip reset fail commit fa3fbe64037839f448dc569212bafc5a495d8219 upstream. In case of drv own fail in reset, we may need to run mac_reset several times. The sequence would trigger system crash as the log below. Because we do not re-enable/schedule "tx_napi" before disable it again, the process would keep waiting for state change in napi_diable(). To avoid the problem and keep status synchronize for each run, goto final resource handling if drv own failed. [ 5857.353423] mt7921e 0000:3b:00.0: driver own failed [ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own [ 5859.633430] mt7921e 0000:3b:00.0: driver own failed [ 5859.633444] ------------[ cut here ]------------ [ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d [ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common] [ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150 [ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202 ...... [ 5859.633766] Call Trace: [ 5859.633768] [ 5859.633771] mt7921e_mac_reset+0x176/0x6f0 [mt7921e] [ 5859.633778] mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common] [ 5859.633785] ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common] [ 5859.633794] ? __kasan_check_read+0x11/0x20 [ 5859.633802] process_one_work+0x7ee/0x1320 [ 5859.633810] worker_thread+0x53c/0x1240 [ 5859.633818] kthread+0x2b8/0x370 [ 5859.633824] ? process_one_work+0x1320/0x1320 [ 5859.633828] ? kthread_complete_and_exit+0x30/0x30 [ 5859.633834] ret_from_fork+0x1f/0x30 [ 5859.633842] Cc: stable@vger.kernel.org Fixes: 0efaf31dec57 ("mt76: mt7921: fix MT7921E reset failure") Signed-off-by: Deren Wu Link: https://lore.kernel.org/r/727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d46815a8f26ca6db2336106a148265239f73b0af Author: Hyunwoo Kim Date: Wed Sep 7 09:07:14 2022 -0700 efi: capsule-loader: Fix use-after-free in efi_capsule_write commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream. A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: # v4.9+ Signed-off-by: Hyunwoo Kim Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit fba41e4fa9ff301519bc19daa028c77308e381f3 Author: Ard Biesheuvel Date: Mon Aug 22 19:20:33 2022 +0200 efi: libstub: Disable struct randomization commit 1a3887924a7e6edd331be76da7bf4c1e8eab4b1e upstream. The EFI stub is a wrapper around the core kernel that makes it look like a EFI compatible PE/COFF application to the EFI firmware. EFI applications run on top of the EFI runtime, which is heavily based on so-called protocols, which are struct types consisting [mostly] of function pointer members that are instantiated and recorded in a protocol database. These structs look like the ideal randomization candidates to the randstruct plugin (as they only carry function pointers), but of course, these protocols are contracts between the firmware that exposes them, and the EFI applications (including our stubbed kernel) that invoke them. This means that struct randomization for EFI protocols is not a great idea, and given that the stub shares very little data with the core kernel that is represented as a randomizable struct, we're better off just disabling it completely here. Cc: # v4.14+ Reported-by: Daniel Marth Tested-by: Daniel Marth Signed-off-by: Ard Biesheuvel Acked-by: Kees Cook Signed-off-by: Greg Kroah-Hartman