commit 22c31ca7697ceab04d22dc1c50e5c9621d29d719 Author: Alexandre Frade Date: Sun Nov 21 23:14:09 2021 +0000 Linux 5.15.4-xanmod1 Signed-off-by: Alexandre Frade commit 57edb38af2e345a5d390c7668ee0fa880dc90ec6 Author: Huang Rui Date: Fri Nov 19 18:31:02 2021 +0800 Documentation: amd-pstate: add amd-pstate driver introduction Introduce the amd-pstate driver design and implementation. Signed-off-by: Huang Rui commit c391f29159876f25bb75f89a5882b560651cfb10 Author: Huang Rui Date: Fri Nov 19 18:31:01 2021 +0800 cpupower: print amd-pstate information on cpupower amd-pstate kernel module is using the fine grain frequency instead of acpi hardware pstate. So the performance and frequency values should be printed in frequency-info. Signed-off-by: Huang Rui commit 4987797c2ad40e65ac582515aa261295d7b101ba Author: Huang Rui Date: Fri Nov 19 18:31:00 2021 +0800 cpupower: move print_speed function into misc helper The print_speed can be as a common function, and expose it into misc helper header. Then it can be used on other helper files as well. Signed-off-by: Huang Rui commit 49452528f4aa81f94f237309a930433b8d647891 Author: Huang Rui Date: Fri Nov 19 18:30:59 2021 +0800 cpupower: enable boost state support for amd-pstate module The legacy ACPI hardware P-States function has 3 P-States on ACPI table, the CPU frequency only can be switched between the 3 P-States. While the processor supports the boost state, it will have another boost state that the frequency can be higher than P0 state, and the state can be decoded by the function of decode_pstates() and read by amd_pci_get_num_boost_states(). However, the new AMD P-States function is different than legacy ACPI hardware P-State on AMD processors. That has a finer grain frequency range between the highest and lowest frequency. And boost frequency is actually the frequency which is mapped on highest performance ratio. The similiar previous P0 frequency is mapped on nominal performance ratio. If the highest performance on the processor is higher than nominal performance, then we think the current processor supports the boost state. And it uses amd_pstate_boost_init() to initialize boost for AMD P-States function. Signed-off-by: Huang Rui commit 18b5107857a2ee921b260efa40cfbcac9f49d505 Author: Huang Rui Date: Fri Nov 19 18:30:58 2021 +0800 cpupower: add amd-pstate sysfs definition and access helper Introduce the marco definitions and access helper function for amd-pstate sysfs interfaces such as each performance goals and frequency levels in amd helper file. They will be used to read the sysfs attribute from amd-pstate cpufreq driver for cpupower utilities. Signed-off-by: Huang Rui commit e2aefcc0f35e57e8c641ac7cda7b432e4936599e Author: Huang Rui Date: Fri Nov 19 18:30:57 2021 +0800 cpupower: introduce acpi cppc library Kernel ACPI subsytem introduced the sysfs attributes for acpi cppc library in below path: /sys/devices/system/cpu/cpuX/acpi_cppc/ And these attributes will be used for amd-pstate driver to provide some performance and frequency values. Signed-off-by: Huang Rui commit 109f9b073aeed6c24aaf17e48220d79e9cf7e325 Author: Huang Rui Date: Fri Nov 19 18:30:56 2021 +0800 cpupower: add the function to get the sysfs value from specific table Expose the helper into cpufreq header, then cpufreq driver can use this function to get the sysfs value if it has any specific sysfs interfaces. Signed-off-by: Huang Rui commit 55e8c4159f9770e0c68c2594450b8f28fc5ce78c Author: Huang Rui Date: Fri Nov 19 18:30:55 2021 +0800 cpupower: initial AMD P-state capability If kernel starts the amd-pstate module, the cpupower will initial the capability flag as CPUPOWER_CAP_AMD_PSTATE. And once amd-pstate capability is set, it won't need to set legacy ACPI relative capabilities anymore. Signed-off-by: Huang Rui commit c568c534293dcf115a0b1f80f3a0803c0ad8c93a Author: Huang Rui Date: Fri Nov 19 18:30:54 2021 +0800 cpupower: add the function to check amd-pstate enabled The processor with amd-pstate function also supports legacy ACPI hardware P-States feature as well. Once driver sets amd-pstate eanbled, the processor will respond the finer grain amd-pstate feature instead of legacy ACPI P-States. So it introduces the cpupower_amd_pstate_enabled() to check whether the current kernel enables amd-pstate or acpi-cpufreq module. Signed-off-by: Huang Rui commit fc33b57f58746a99fa5b8ffc7e78b3070d8e6b45 Author: Huang Rui Date: Fri Nov 19 18:30:53 2021 +0800 cpupower: add AMD P-state capability flag Add AMD P-state capability flag in cpupower to indicate AMD new P-state kernel module support on Ryzen processors. Signed-off-by: Huang Rui commit d8971783d0e594608043b4457a091e6a8beb0a17 Author: Huang Rui Date: Fri Nov 19 18:30:52 2021 +0800 cpufreq: amd: add amd-pstate performance attributes Introduce sysfs attributes to get the different level amd-pstate performances. Signed-off-by: Huang Rui commit ac8e02f99d0fe5642f6d75cc2ccb2051002f7822 Author: Huang Rui Date: Fri Nov 19 18:30:51 2021 +0800 cpufreq: amd: add amd-pstate frequencies attributes Introduce sysfs attributes to get the different level processor frequencies. Signed-off-by: Huang Rui commit f7ae4f818c1a8402a1f3dd1942731e3c4cb831ce Author: Huang Rui Date: Fri Nov 19 18:30:50 2021 +0800 cpufreq: amd: add boost mode support for amd-pstate If the sbios supports the boost mode of amd-pstate, let's switch to boost enabled by default. Signed-off-by: Huang Rui commit 5ce7170d0e975377ef7ae4bacbc75a2b672d8532 Author: Huang Rui Date: Fri Nov 19 18:30:49 2021 +0800 cpufreq: amd: add trace for amd-pstate module Add trace event to monitor the performance value changes which is controlled by cpu governors. Signed-off-by: Huang Rui commit add601bb535270dcdba4b5bd93af460f51bd81ea Author: Huang Rui Date: Fri Nov 19 18:30:48 2021 +0800 cpufreq: amd: introduce the support for the processors with shared memory solution In some of Zen2 and Zen3 based processors, they are using the shared memory that exposed from ACPI SBIOS. In this kind of the processors, there is no MSR support, so we add acpi cppc function as the backend for them. It is using a module param (shared_mem) to enable related processors manually. We will enable this by default once we address performance issue on this solution. Signed-off-by: Jinzhou Su Signed-off-by: Huang Rui commit a12c35b204aea9b23287df1f7c5880b83318e95a Author: Huang Rui Date: Fri Nov 19 18:30:47 2021 +0800 cpufreq: amd: add fast switch function for amd-pstate Introduce the fast switch function for amd-pstate on the AMD processors which support the full MSR register control. It's able to decrease the latency on interrupt context. Signed-off-by: Huang Rui commit 9a1976c22841ab79f79d9f513531d45673070f47 Author: Huang Rui Date: Fri Nov 19 18:30:46 2021 +0800 cpufreq: amd: introduce a new amd pstate driver to support future processors amd-pstate is the AMD CPU performance scaling driver that introduces a new CPU frequency control mechanism on AMD Zen based CPU series in Linux kernel. The new mechanism is based on Collaborative processor performance control (CPPC) which is finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching only in 3 P-states. AMD P-States is to replace the ACPI P-states controls, allows a flexible, low-latency interface for the Linux kernel to directly communicate the performance hints to hardware. "amd-pstate" leverages the Linux kernel governors such as *schedutil*, *ondemand*, etc. to manage the performance hints which are provided by CPPC hardware functionality. The first version for amd-pstate is to support one of the Zen3 processors, and we will support more in future after we verify the hardware and SBIOS functionalities. There are two types of hardware implementations for amd-pstate: one is full MSR support and another is shared memory support. It can use X86_FEATURE_CPPC feature flag to distinguish the different types. Using the new AMD P-States method + kernel governors (*schedutil*, *ondemand*, ...) to manage the frequency update is the most appropriate bridge between AMD Zen based hardware processor and Linux kernel, the processor is able to adjust to the most efficiency frequency according to the kernel scheduler loading. Performance Per Watt (PPW) Calculation: The PPW calculation is referred by below paper: https://software.intel.com/content/dam/develop/external/us/en/documents/performance-per-what-paper.pdf Below formula is referred from below spec to measure the PPW: (F / t) / P = F * t / (t * E) = F / E, "F" is the number of frames per second. "P" is power measured in watts. "E" is energy measured in joules. We use the RAPL interface with "perf" tool to get the energy data of the package power. The data comparisons between amd-pstate and acpi-freq module are tested on AMD Cezanne processor: 1) TBench CPU benchmark: +---------------------------------------------------------------------+ | | | TBench (Performance Per Watt) | | Higher is better | +-------------------+------------------------+------------------------+ | | Performance Per Watt | Performance Per Watt | | Kernel Module | (Schedutil) | (Ondemand) | | | Unit: MB / (s * J) | Unit: MB / (s * J) | +-------------------+------------------------+------------------------+ | | | | | acpi-cpufreq | 3.022 | 2.969 | | | | | +-------------------+------------------------+------------------------+ | | | | | amd-pstate | 3.131 | 3.284 | | | | | +-------------------+------------------------+------------------------+ 2) Gitsource CPU benchmark: +---------------------------------------------------------------------+ | | | Gitsource (Performance Per Watt) | | Higher is better | +-------------------+------------------------+------------------------+ | | Performance Per Watt | Performance Per Watt | | Kernel Module | (Schedutil) | (Ondemand) | | | Unit: 1 / (s * J) | Unit: 1 / (s * J) | +-------------------+------------------------+------------------------+ | | | | | acpi-cpufreq | 3.42172E-07 | 2.74508E-07 | | | | | +-------------------+------------------------+------------------------+ | | | | | amd-pstate | 4.09141E-07 | 3.47610E-07 | | | | | +-------------------+------------------------+------------------------+ 3) Speedometer 2.0 CPU benchmark: +---------------------------------------------------------------------+ | | | Speedometer 2.0 (Performance Per Watt) | | Higher is better | +-------------------+------------------------+------------------------+ | | Performance Per Watt | Performance Per Watt | | Kernel Module | (Schedutil) | (Ondemand) | | | Unit: 1 / (s * J) | Unit: 1 / (s * J) | +-------------------+------------------------+------------------------+ | | | | | acpi-cpufreq | 0.116111767 | 0.110321664 | | | | | +-------------------+------------------------+------------------------+ | | | | | amd-pstate | 0.115825281 | 0.122024299 | | | | | +-------------------+------------------------+------------------------+ According to above average data, we can see this solution has shown better performance per watt scaling on mobile CPU benchmarks in most of cases. Signed-off-by: Huang Rui commit 4b117bda9daa037ecb98c4e5f599bfe3aee24aaa Author: Jinzhou Su Date: Fri Nov 19 18:30:45 2021 +0800 ACPI: CPPC: add cppc enable register function Add a new function to enable CPPC feature. This function will write Continuous Performance Control package EnableRegister field on the processor. CPPC EnableRegister register described in section 8.4.7.1 of ACPI 6.4: This element is optional. If supported, contains a resource descriptor with a single Register() descriptor that describes a register to which OSPM writes a One to enable CPPC on this processor. Before this register is set, the processor will be controlled by legacy mechanisms (ACPI Pstates, firmware, etc.). This register will be used for AMD processors to enable amd-pstate function instead of legacy ACPI P-States. Signed-off-by: Jinzhou Su Signed-off-by: Huang Rui commit 04dc830b93c3e421b8764437880d82ff31ed89ab Author: Mario Limonciello Date: Fri Nov 19 18:30:44 2021 +0800 ACPI: CPPC: Check present CPUs for determining _CPC is valid As this is a static check, it should be based upon what is currently present on the system. This makes probeing more deterministic. While local APIC flags field (lapic_flags) of cpu core in MADT table is 0, then the cpu core won't be enabled. In this case, _CPC won't be found in this core, and return back to _CPC invalid with walking through possible cpus (include disable cpus). This is not expected, so switch to check present CPUs instead. Reported-by: Jinzhou Su Signed-off-by: Mario Limonciello Signed-off-by: Huang Rui commit 72aaea530f26d860dc5fffb8a43d4a0e698d7b23 Author: Steven Noonan Date: Fri Nov 19 18:30:43 2021 +0800 ACPI: CPPC: implement support for SystemIO registers According to the ACPI v6.2 (and later) specification, SystemIO can be used for _CPC registers. This teaches cppc_acpi how to handle such registers. This patch was tested using the amd_pstate driver on my Zephyrus G15 (model GA503QS) using the current version 410 BIOS, which uses a SystemIO register for the HighestPerformance element in _CPC. Signed-off-by: Steven Noonan Signed-off-by: Huang Rui commit fba3e7e5bacdc36463191c2a2fbcba710cfe7c6d Author: Huang Rui Date: Fri Nov 19 18:30:42 2021 +0800 x86/msr: add AMD CPPC MSR definitions AMD CPPC (Collaborative Processor Performance Control) function uses MSR registers to manage the performance hints. So add the MSR register macro here. Signed-off-by: Huang Rui commit e465b2f610dbb4af0ed9113a5a7471a6a7d86143 Author: Huang Rui Date: Fri Nov 19 18:30:41 2021 +0800 x86/cpufreatures: add AMD Collaborative Processor Performance Control feature flag Add Collaborative Processor Performance Control feature flag for AMD processors. This feature flag will be used on the following amd-pstate driver. The amd-pstate driver has two approaches to implement the frequency control behavior. That depends on the CPU hardware implementation. One is "Full MSR Support" and another is "Shared Memory Support". The feature flag indicates the current processors with "Full MSR Support". Acked-by: Borislav Petkov Signed-off-by: Huang Rui commit fc73473aece78c09b3e66752ebf88f4c1c88c557 Author: Alexandre Frade Date: Sun Nov 21 19:48:19 2021 +0000 amd-pstate: Remove the v3 patchset Signed-off-by: Alexandre Frade commit 511ee68c8a1c02e76ae0c6467e073e726b0da69a Merge: e6f73a1266f7 9ac77cf6e1bd Author: Alexandre Frade Date: Sun Nov 21 19:50:14 2021 +0000 Merge tag 'v5.15.4' into 5.15 This is the 5.15.4 stable release commit 9ac77cf6e1bd35ef538077245feaee8f1146ca4b Author: Greg Kroah-Hartman Date: Sun Nov 21 13:44:15 2021 +0100 Linux 5.15.4 Link: https://lore.kernel.org/r/20211119171444.640508836@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Rudi Heitbaum Tested-by: Guenter Roeck Tested-By: Scott Bruce Signed-off-by: Greg Kroah-Hartman commit 1af7386f5f71f8cb23ea34862b481ed6a33ef538 Author: Rafael J. Wysocki Date: Wed Nov 17 17:05:41 2021 +0100 Revert "ACPI: scan: Release PM resources blocked by unused objects" commit 3b2b49e6dfdcf423506a771bf44cee842596351a upstream. Revert commit c10383e8ddf4 ("ACPI: scan: Release PM resources blocked by unused objects"), because it causes boot issues to appear on some platforms. Reported-by: Kyle D. Pelton Reported-by: Saranya Gopal Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ef2590a5305e0b8e9342f84c2214aa478ee7f28e Author: Subbaraman Narayanamurthy Date: Thu Nov 4 16:57:07 2021 -0700 thermal: Fix NULL pointer dereferences in of_thermal_ functions commit 96cfe05051fd8543cdedd6807ec59a0e6c409195 upstream. of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend(). Suggested-by: David Collins Signed-off-by: Subbaraman Narayanamurthy Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bd378dcd503194301eb7ee87a77342c49a0d0bcb Author: Greg Thelen Date: Wed Nov 10 18:18:14 2021 -0800 perf/core: Avoid put_page() when GUP fails commit 4716023a8f6a0f4a28047f14dd7ebdc319606b84 upstream. PEBS PERF_SAMPLE_PHYS_ADDR events use perf_virt_to_phys() to convert PMU sampled virtual addresses to physical using get_user_page_fast_only() and page_to_phys(). Some get_user_page_fast_only() error cases return false, indicating no page reference, but still initialize the output page pointer with an unreferenced page. In these error cases perf_virt_to_phys() calls put_page(). This causes page reference count underflow, which can lead to unintentional page sharing. Fix perf_virt_to_phys() to only put_page() if get_user_page_fast_only() returns a referenced page. Fixes: fc7ce9c74c3ad ("perf/core, x86: Add PERF_SAMPLE_PHYS_ADDR") Signed-off-by: Greg Thelen Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211111021814.757086-1-gthelen@google.com Signed-off-by: Greg Kroah-Hartman commit 7931b7e318827104b2bfd4c2210aa8a870258609 Author: Marc Zyngier Date: Thu Nov 4 18:01:30 2021 +0000 PCI: Add MSI masking quirk for Nvidia ION AHCI commit f21082fb20dbfb3e42b769b59ef21c2a7f2c7c1f upstream. The ION AHCI device pretends that MSI masking isn't a thing, while it actually implements it and needs MSIs to be unmasked to work. Add a quirk to that effect. Reported-by: Rui Salvaterra Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Tested-by: Rui Salvaterra Reviewed-by: Thomas Gleixner Cc: Bjorn Helgaas Link: https://lore.kernel.org/r/CALjTZvbzYfBuLB+H=fj2J+9=DxjQ2Uqcy0if_PvmJ-nU-qEgkg@mail.gmail.com Link: https://lore.kernel.org/r/20211104180130.3825416-3-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 06ce633b3bfd1077922c9ce76e0da0c3d1c527ed Author: Marc Zyngier Date: Thu Nov 4 18:01:29 2021 +0000 PCI/MSI: Deal with devices lying about their MSI mask capability commit 2226667a145db2e1f314d7f57fd644fe69863ab9 upstream. It appears that some devices are lying about their mask capability, pretending that they don't have it, while they actually do. The net result is that now that we don't enable MSIs on such endpoint. Add a new per-device flag to deal with this. Further patches will make use of it, sadly. Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20211104180130.3825416-2-maz@kernel.org Cc: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit a912418410ab64eec86d31cc166b4df48b7bd9e9 Author: Sven Schnelle Date: Sat Nov 13 20:41:17 2021 +0100 parisc/entry: fix trace test in syscall exit path commit 3ec18fc7831e7d79e2d536dd1f3bc0d3ba425e8a upstream. commit 8779e05ba8aa ("parisc: Fix ptrace check on syscall return") fixed testing of TI_FLAGS. This uncovered a bug in the test mask. syscall_restore_rfi is only used when the kernel needs to exit to usespace with single or block stepping and the recovery counter enabled. The test however used _TIF_SYSCALL_TRACE_MASK, which includes a lot of bits that shouldn't be tested here. Fix this by using TIF_SINGLESTEP and TIF_BLOCKSTEP directly. I encountered this bug by enabling syscall tracepoints. Both in qemu and on real hardware. As soon as i enabled the tracepoint (sys_exit_read, but i guess it doesn't really matter which one), i got random page faults in userspace almost immediately. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 73f1e74f9c87cf36be5429c9a18358742806d7ed Author: Nicholas Flintham Date: Thu Sep 30 09:22:39 2021 +0100 Bluetooth: btusb: Add support for TP-Link UB500 Adapter commit 4fd6d490796171bf786090fee782e252186632e4 upstream. Add support for TP-Link UB500 Adapter (RTL8761B) * /sys/kernel/debug/usb/devices T: Bus=01 Lev=02 Prnt=05 Port=01 Cnt=01 Dev#= 78 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2357 ProdID=0604 Rev= 2.00 S: Manufacturer= S: Product=TP-Link UB500 Adapter S: SerialNumber=E848B8C82000 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Nicholas Flintham Signed-off-by: Marcel Holtmann Cc: Szabolcs Sipos Signed-off-by: Greg Kroah-Hartman commit c0991182aca3d8d115de1d75ce912d8221b8a551 Author: Xie Yongji Date: Tue Oct 26 22:40:14 2021 +0800 loop: Use blk_validate_block_size() to validate block size commit af3c570fb0df422b4906ebd11c1bf363d89961d5 upstream. Remove loop_validate_block_size() and use the block layer helper to validate block size. Signed-off-by: Xie Yongji Link: https://lore.kernel.org/r/20211026144015.188-4-xieyongji@bytedance.com Signed-off-by: Jens Axboe Cc: Tadeusz Struk Signed-off-by: Greg Kroah-Hartman commit 1f124a6611910f8c875f7ff3ac84727c41a4ab72 Author: Xie Yongji Date: Tue Oct 26 22:40:12 2021 +0800 block: Add a helper to validate the block size commit 570b1cac477643cbf01a45fa5d018430a1fddbce upstream. There are some duplicated codes to validate the block size in block drivers. This limitation actually comes from block layer, so this patch tries to add a new block layer helper for that. Signed-off-by: Xie Yongji Link: https://lore.kernel.org/r/20211026144015.188-2-xieyongji@bytedance.com Signed-off-by: Jens Axboe Cc: Tadeusz Struk Signed-off-by: Greg Kroah-Hartman commit 8d0956438eecfafbefb7cd15b7773087549b38d4 Author: Kees Cook Date: Wed May 12 21:51:10 2021 -0700 fortify: Explicitly disable Clang support commit a52f8a59aef46b59753e583bf4b28fccb069ce64 upstream. Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a couple bugs: Eliding inlines with matching __builtin_* names https://bugs.llvm.org/show_bug.cgi?id=50322 Incorrect __builtin_constant_p() of some globals https://bugs.llvm.org/show_bug.cgi?id=41459 In the process of making improvements to the FORTIFY_SOURCE defenses, the first (silent) bug (coincidentally) becomes worked around, but exposes the latter which breaks the build. As such, Clang must not be used with CONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13), and the fortify routines have been rearranged. Update the Kconfig to reflect the reality of the current situation. Signed-off-by: Kees Cook Acked-by: Nick Desaulniers Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 0fc2241ac237dcfa037f97f734145d45fa6ebf3d Author: Johannes Thumshirn Date: Thu Nov 18 17:58:18 2021 +0900 btrfs: zoned: allow preallocation for relocation inodes commit 960a3166aed015887cd54423a6589ae4d0b65bd5 upstream Now that we use a dedicated block group and regular writes for data relocation, we can preallocate the space needed for a relocated inode, just like we do in regular mode. Essentially this reverts commit 32430c614844 ("btrfs: zoned: enable relocation on a zoned filesystem") as it is not needed anymore. Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit d0fdafa8fcf30e0cfbe44349563b847a1b759ba0 Author: Johannes Thumshirn Date: Thu Nov 18 17:58:17 2021 +0900 btrfs: check for relocation inodes on zoned btrfs in should_nocow commit 2adada886b26e998b5a624e72f0834ebfdc54cc7 upstream Prepare for allowing preallocation for relocation inodes. Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit 080f457f35c0218b497ea709301545b69b113184 Author: Johannes Thumshirn Date: Thu Nov 18 17:58:16 2021 +0900 btrfs: zoned: use regular writes for relocation commit e6d261e3b1f777b499ce8f535ed44dd1b69278b7 upstream Now that we have a dedicated block group for relocation, we can use REQ_OP_WRITE instead of REQ_OP_ZONE_APPEND for writing out the data on relocation. Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit f716e9827838f1554a770deec16c2968b9445b50 Author: Johannes Thumshirn Date: Thu Nov 18 17:58:15 2021 +0900 btrfs: zoned: only allow one process to add pages to a relocation inode commit 35156d852762b58855f513b4f8bb7f32d69dc9c5 upstream Don't allow more than one process to add pages to a relocation inode on a zoned filesystem, otherwise we cannot guarantee the sequential write rule once we're filling preallocated extents on a zoned filesystem. Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit d282dd7f4109a6a5fa9f8bb52cd4c23ed510f44e Author: Johannes Thumshirn Date: Thu Nov 18 17:58:14 2021 +0900 btrfs: zoned: add a dedicated data relocation block group commit c2707a25562343511bf9a3a6a636a16a822204eb upstream Relocation in a zoned filesystem can fail with a transaction abort with error -22 (EINVAL). This happens because the relocation code assumes that the extents we relocated the data to have the same size the source extents had and ensures this by preallocating the extents. But in a zoned filesystem we currently can't preallocate the extents as this would break the sequential write required rule. Therefore it can happen that the writeback process kicks in while we're still adding pages to a delalloc range and starts writing out dirty pages. This then creates destination extents that are smaller than the source extents, triggering the following safety check in get_new_location(): 1034 if (num_bytes != btrfs_file_extent_disk_num_bytes(leaf, fi)) { 1035 ret = -EINVAL; 1036 goto out; 1037 } Temporarily create a dedicated block group for the relocation process, so no non-relocation data writes can interfere with the relocation writes. This is needed that we can switch the relocation process on a zoned filesystem from the REQ_OP_ZONE_APPEND writing we use for data to a scheme like in a non-zoned filesystem using REQ_OP_WRITE and preallocation. Fixes: 32430c614844 ("btrfs: zoned: enable relocation on a zoned filesystem") Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit 02c5e9e992a221a2435b7f732aba3ac11784e7ac Author: Johannes Thumshirn Date: Thu Nov 18 17:58:13 2021 +0900 btrfs: introduce btrfs_is_data_reloc_root commit 37f00a6d2e9c97d6e7b5c3d47c49b714c3d0b99f upstream There are several places in our codebase where we check if a root is the root of the data reloc tree and subsequent patches will introduce more. Factor out the check into a small helper function instead of open coding it multiple times. Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit 19e32bd1cc37c34683a214242bee7a0b114831bd Author: David Woodhouse Date: Sun Nov 14 08:59:02 2021 +0000 KVM: Fix steal time asm constraints commit 964b7aa0b040bdc6ec1c543ee620cda3f8b4c68a upstream. In 64-bit mode, x86 instruction encoding allows us to use the low 8 bits of any GPR as an 8-bit operand. In 32-bit mode, however, we can only use the [abcd] registers. For which, GCC has the "q" constraint instead of the less restrictive "r". Also fix st->preempted, which is an input/output operand rather than an input. Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status") Reported-by: kernel test robot Signed-off-by: David Woodhouse Message-Id: <89bf72db1b859990355f9c40713a34e0d2d86c98.camel@infradead.org> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b06962406eca3d0ca818e2cda96e1b2e1f82bc94 Author: Greg Kroah-Hartman Date: Fri Nov 19 12:30:13 2021 +0100 Revert "drm: fb_helper: fix CONFIG_FB dependency" This reverts commit c95380ba527ae0aee29b2a133c5d0c481d472759 which is commit 606b102876e3741851dfb09d53f3ee57f650a52c upstream. It causes some build problems as reported by Jiri. Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org Reported-by: Jiri Slaby Cc: Arnd Bergmann Cc: Kees Cook Cc: Daniel Vetter Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3256c84aaddc803382f9818945e85f2e796b9128 Author: Greg Kroah-Hartman Date: Fri Nov 19 12:30:10 2021 +0100 Revert "drm: fb_helper: improve CONFIG_FB dependency" This reverts commit 94e18f5a5dd1b5e3b89c665fc5ff780858b1c9f6 which is commit 9d6366e743f37d36ef69347924ead7bcc596076e upstream. It causes some build problems as reported by Jiri. Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org Reported-by: Jiri Slaby Cc: Jani Nikula Cc: Javier Martinez Canillas Cc: Arnd Bergmann Cc: Kees Cook Cc: Daniel Vetter Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d27b2dcdb8d28a9435c04c9767ba18f89642a148 Author: Guenter Roeck Date: Tue Nov 2 07:24:20 2021 -0700 string: uninline memcpy_and_pad commit 5c4e0a21fae877a7ef89be6dcc6263ec672372b8 upstream. When building m68k:allmodconfig, recent versions of gcc generate the following error if the length of UTS_RELEASE is less than 8 bytes. In function 'memcpy_and_pad', inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7 Discussions around the problem suggest that this only happens if an architecture does not provide strlen(), if -ffreestanding is provided as compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case for m68k. The exact reasons are unknown, but seem to be related to the ability of the compiler to evaluate the return value of strlen() and the resulting execution flow in memcpy_and_pad(). It would be possible to work around the problem by using sizeof(UTS_RELEASE) instead of strlen(UTS_RELEASE), but that would only postpone the problem until the function is called in a similar way. Uninline memcpy_and_pad() instead to solve the problem for good. Suggested-by: Linus Torvalds Reviewed-by: Geert Uytterhoeven Acked-by: Andy Shevchenko Signed-off-by: Guenter Roeck Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman