summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-05-19PM: domains: Fix initialization of genpd's next_wakeupUlf Hansson
In the genpd governor we walk the list of child-domains to take into account their next_wakeup. If the child-domain itself, doesn't have a governor assigned to it, we can end up using the next_wakeup value before it has been properly initialized. To prevent a possible incorrect behaviour in the governor, let's initialize next_wakeup to KTIME_MAX. Fixes: c79aa080fb0f ("PM: domains: use device's next wakeup to determine domain idle state") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Fixup QoS latency measurements for IRQ safe devices in genpdUlf Hansson
When an IRQ safe device is attached to a non-IRQ safe PM domain, genpd needs to prevent the PM domain from being powered off. However, genpd still allows the device to be runtime suspended/resumed, hence it's also reasonable to think that a governor may be used to validate the QoS latency constraints. Unfortunately, genpd_runtime_resume() treats the configuration above, as a reason to skip measuring the QoS resume latency for the device. This is a legacy behaviour that was earlier correct, but should have been changed when genpd was transformed into its current behaviour around how it manages IRQ safe devices. Luckily, there's no report about problems, so let's just fixup the behaviour. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Measure suspend/resume latencies in genpd based on governorUlf Hansson
The QoS latency measurements for devices in genpd_runtime_suspend|resume() are superfluous, unless the corresponding genpd has a governor assigned to it, which would make use of the data. Therefore, let's improve the behaviour in genpd by making the measurements conditional, based upon if there's a governor assigned. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Move the next_wakeup variable into the struct gpd_timing_dataUlf Hansson
If the corresponding genpd for the device doesn't use a governor, the variable next_wakeup within the struct generic_pm_domain_data becomes superfluous. To avoid wasting memory, let's move it into the struct gpd_timing_data, which is already being allocated based upon if there is governor assigned. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Allocate gpd_timing_data dynamically based on governorUlf Hansson
If a genpd doesn't have an associated governor assigned, there's really no point to allocate the per device gpd_timing_data, as the data isn't being used by a governor anyway. To avoid wasting memory, let's therefore convert the corresponding td variable in the struct generic_pm_domain_data into a pointer and manage the allocation of its data dynamically. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Skip another warning in irq_safe_dev_in_sleep_domain()Ulf Hansson
In irq_safe_dev_in_sleep_domain() we correctly skip the dev_warn_once() if the corresponding genpd for the device, has the GENPD_FLAG_ALWAYS_ON flag being set. For the same reason (the genpd is always-on in runtime), let's also skip the warning if the GENPD_FLAG_RPM_ALWAYS_ON flag is set for the genpd. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Rename irq_safe_dev_in_no_sleep_domain() in genpdUlf Hansson
The name "irq_safe_dev_in_no_sleep_domain", doesn't really match the conditions that are being checked in the function, hence the code becomes a bit confusing to read. Let's clarify this by renaming it into "irq_safe_dev_in_sleep_domain" and let's also take the opportunity to clarify a corresponding comment in the code. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Don't check PM_QOS_FLAG_NO_POWER_OFF in genpdUlf Hansson
Back in the days when genpd supported intermediate power states of its devices, it made sense to check the PM_QOS_FLAG_NO_POWER_OFF in genpd_power_off(). This because the attached devices were all being put into low power state together when the PM domain was also being powered off. At this point, the flag PM_QOS_FLAG_NO_POWER_OFF is better checked by drivers from their ->runtime_suspend() callbacks, like in the usb_port_runtime_suspend(), for example. Or perhaps an even better option is to set the QoS resume latency constraint for the device to zero, which informs the runtime PM core to prevent the device from being runtime suspended. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Drop redundant code for genpd always-on governorUlf Hansson
Due to recent changes, the always-on governor is always used with a genpd that has the GENPD_FLAG_RPM_ALWAYS_ON flag being set. This means genpd, doesn't invoke the governor's ->power_down_ok() callback, which makes the code in the governor redundant, so let's drop it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Add GENPD_FLAG_RPM_ALWAYS_ON for the always-on governorUlf Hansson
Rather than relying on the genpd provider to set the corresponding flag, GENPD_FLAG_RPM_ALWAYS_ON, when the always-on governor is being used, let's add it in pm_genpd_init(). In this way, it starts to benefits all genpd providers immediately. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19Bluetooth: eir: Add helpers for managing service dataLuiz Augusto von Dentz
This adds helpers for accessing and appending service data (0x16) ad type. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-05-19ACPI: utils: include UUID in _DSM evaluation warningMichael Niewöhner
The _DSM evaluation warning in its current form is not very helpful, as it lacks any specific information: ACPI: \: failed to evaluate _DSM (0x1001) Thus, include the UUID of the missing _DSM: ACPI: \: failed to evaluate _DSM bf0212f2-... (0x1001) Signed-off-by: Michael Niewöhner <linux@mniewoehner.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19powercap: intel_rapl: remove redundant store to value after multiplyColin Ian King
There is no need to store the result of the multiply back to variable value after the multiplication. The store is redundant, replace *= with just *. Cleans up clang scan build warning: warning: Although the value stored to 'value' is used in the enclosing expression, the value is never actually read from 'value' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19platform/x86/intel/ifs: Add CPU_SUP_INTEL dependencyBorislav Petkov
The driver is using functions from a compilation unit which is enabled by CONFIG_CPU_SUP_INTEL. Add that dependency to Kconfig explicitly otherwise: drivers/platform/x86/intel/ifs/load.o: in function `ifs_load_firmware': load.c:(.text+0x3b8): undefined reference to `intel_cpu_collect_info' Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/YoZay8YR0zRGyVu+@zn.tnic Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19cpufreq: CPPC: Enable dvfs_possible_from_any_cpuPierre Gondois
The communication mean of the _CPC desired performance can be PCC, System Memory, System IO, or Functional Fixed Hardware (FFH). PCC, SystemMemory and SystemIo address spaces are available from any CPU. Thus, dvfs_possible_from_any_cpu should be enabled in such case. For FFH, let the FFH implementation do smp_call_function_*() calls. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19cpufreq: CPPC: Enable fast_switchPierre Gondois
The communication mean of the _CPC desired performance can be PCC, System Memory, System IO, or Functional Fixed Hardware. commit b7898fda5bc7 ("cpufreq: Support for fast frequency switching") fast_switching is 'for switching CPU frequencies from interrupt context'. Writes to SystemMemory and SystemIo are fast and suitable this. This is not the case for PCC and might not be the case for FFH. Enable fast_switching for the cppc_cpufreq driver in above cases. Add cppc_allow_fast_switch() to check the desired performance register address space and set fast_switching accordingly. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ACPI: CPPC: Assume no transition latency if no PCCTPierre Gondois
The transition_delay_us (struct cpufreq_policy) is currently defined as: Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy. To be set by the scaling driver (0, which is the default, means no preference). The transition_latency represents the amount of time necessary for a CPU to change its frequency. A PCCT table advertises mutliple values: - pcc_nominal: Expected latency to process a command, in microseconds - pcc_mpar: The maximum number of periodic requests that the subspace channel can support, reported in commands per minute. 0 indicates no limitation. - pcc_mrtt: The minimum amount of time that OSPM must wait after the completion of a command before issuing the next command, in microseconds. cppc_get_transition_latency() allows to get the max of them. commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us") allows to select transition_delay_us based on the platform, and fallbacks to cppc_get_transition_latency() otherwise. If _CPC objects are not using PCC channels (no PPCT table), the transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long periods between frequency updates (~4s). If the desired_reg, where performance requests are written, is in SystemMemory or SystemIo ACPI address space, there is no delay in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us). This patch also adds two macros to check the address spaces. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supportedPierre Gondois
The _OSC method allows the OS and firmware to communicate about supported features/capabitlities. It also allows the OS to take control of some features. In ACPI 6.4, s6.2.11.2 Platform-Wide OSPM Capabilities, the CPPC (resp. v2) bit should be set by the OS if it 'supports controlling processor performance via the interfaces described in the _CPC object'. The OS supports CPPC and parses the _CPC object only if CONFIG_ACPI_CPPC_LIB is set. Replace the x86 specific boot_cpu_has(X86_FEATURE_HWP) dynamic check with an arch generic CONFIG_ACPI_CPPC_LIB build-time check. Note: CONFIG_X86_INTEL_PSTATE selects CONFIG_ACPI_CPPC_LIB. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ACPI: CPPC: Check _OSC for flexible address spacePierre Gondois
ACPI 6.2 Section 6.2.11.2 'Platform-Wide OSPM Capabilities': Starting with ACPI Specification 6.2, all _CPC registers can be in PCC, System Memory, System IO, or Functional Fixed Hardware address spaces. OSPM support for this more flexible register space scheme is indicated by the “Flexible Address Space for CPPC Registers” _OSC bit Otherwise (cf ACPI 6.1, s8.4.7.1.1.X), _CPC registers must be in: - PCC or Functional Fixed Hardware address space if defined - SystemMemory address space (NULL register) if not defined Add the corresponding _OSC bit and check it when parsing _CPC objects. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19platform/x86: intel_cht_int33fe: Set driver dataHeikki Krogerus
Module removal fails because cht_int33fe_typec_remove() tries to access driver data that does not exist. Fixing by assigning the data at the end of probe. Fixes: 915623a80b5a ("platform/x86: intel_cht_int33fe: Switch to DMI modalias based loading") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220519122103.78546-1-heikki.krogerus@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19thermal: intel: pch: improve the cooling delay logZhang Rui
Previously, during suspend, intel_pch_thermal driver logs for every cooling iteration, about the current PCH temperature and number of cooling iterations that have been tried, like below [ 100.955526] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 1 times for 100 ms duration [ 101.064156] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 2 times for 100 ms duration After changing the default delay_cnt to 600, in practice, it is common to see tens of the above messages if the system is suspended when PCH overheats. Thus, change this log message from dev_warn to dev_dbg because it is only useful when we want to check the temperature trend. At the same time, there is always a one-line message given by the driver with the patch applied, with below four possibilities. 1. PCH is cool, no cooling delay needed [ 1791.902853] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [48C] 2. PCH overheats and becomes cool after the cooling delays [ 1475.511617] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [49C] after 30700 ms delay 3. PCH still overheats after the overall cooling timeout [ 2250.157487] intel_pch_thermal 0000:00:12.0: CPU-PCH is hot [60C] after 60000 ms delay. S0ix might fail 4. PCH aborts cooling because of wakeup event detected during the delay [ 1933.639509] intel_pch_thermal 0000:00:12.0: Wakeup event detected, abort cooling Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19thermal: intel: pch: enhance overheat handlingZhang Rui
Commit ef63b043ac86 ("thermal: intel: pch: fix S0ix failure due to PCH temperature above threshold") introduces delay loop mechanism that allows PCH temperature to go down below threshold during suspend so it won't block S0ix. And the default overall delay timeout is 1 second. However, in practice, we found that the time it takes to cool the PCH down below threshold highly depends on the initial PCH temperature when the delay starts, as well as the ambient temperature. And in some cases, the 1 second delay is not sufficient. As a result, the system stays in a shallower power state like PCx instead of S0ix, and drains the battery power, without user' notice. To make sure S0ix is not blocked by the PCH overheating, we 1. expand the default overall timeout to 60 seconds. 2. make sure the temperature is below threshold rather than equal to it. At the same time, as the cooling delay can be much longer and many wakeup events (ACPI Power Button press, USB mouse move, etc) becomes valid in the suspend_noirq phase, add detection of wakeup event so that the driver does not delay blindly when the system suspend is likely to abort soon. This patch may introduce longer suspend time, but only in the cases when the system overheats and Linux used to enter a shallower S2idle state, say, PCx instead of S0ix. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19thermal: intel: pch: move cooling delay to suspend_noirq phaseZhang Rui
Move the PCH Thermal driver suspend callback to suspend_noirq to do cooling while the system is more quiescent. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: wakeup: expose pm_wakeup_pending to modulesZhang Rui
intel_pch_thermal driver needs a long delay to cool itself (60 seconds in maximum) during suspend. When a wakeup event occures during the delay, it is better for the intel_pch_thermal driver to detect this and quit cooling because the suspend is likely to abort anyway. Thus expose pm_wakeup_pending to modules so that intel_pch_thermal driver can be aware of the wakeup events. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19platform/x86: intel-hid: fix _DSM function index handlingMichael Niewöhner
intel_hid_dsm_fn_mask is a bit mask containing one bit for each function index. Fix the function index check in intel_hid_evaluate_method accordingly, which was missed in commit 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling"). Fixes: 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling") Cc: stable@vger.kernel.org Signed-off-by: Michael Niewöhner <linux@mniewoehner.de> Link: https://lore.kernel.org/r/66f813f5bcc724a0f6dd5adefe6a9728dbe509e3.camel@mniewoehner.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-05-19cpuidle: riscv-sbi: Fix code to allow a genpd governor to be usedUlf Hansson
The intent is to use a genpd governor when there are some states that needs to be managed. Although, the current code ends up to never assign a governor, let's fix this. Fixes: 6abf32f1d9c50 ("cpuidle: Add RISC-V SBI CPU idle driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Tested-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19cpuidle: psci: Fix regression leading to no genpd governorUlf Hansson
While factoring out the PM domain related code from PSCI domain driver into a set of library functions, a regression when initializing the genpds got introduced. More precisely, we fail to assign a genpd governor, so let's fix this. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM / devfreq: passive: Return non-error when not-supported event is requiredChanwoo Choi
Each devfreq governor specifies the supported governor event such as GOV_START and GOV_STOP. When not-supported event is required, just return non-error. But, commit ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") returned the error value. So that return non-error value when not-supported event is required. Fixes: ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19Merge tag 'thermal-v5.19-rc1' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux Pull thermal control material for 5.19-rc1 from Daniel Lezcano: - Add the new k3 j72xx bangdap driver and the corresponding bindings (Keerthy) - Fix the missing of_node_put() in the SC iMX driver at probe timer (Miaoqian Lin) - Fix memory leak in __thermal_cooling_device_register() when device_register() fails by calling thermal_cooling_device_destroy_sysfs() (Yang Yingliang) - Add sc8180x and sc8280xp compatible string in the DT bindings and lMH support for QCom tsens driver (Bjorn Andersson) - Fix OTP Calibration Register values conforming to the documentation on RZ/G2L and bindings documentation for RZ/G2UL (Biju Das) - Fix type in kerneldoc description for __thermal_bind_params (Corentin Labbe) - Remove unneeded semi colon in libthermal and tools thermal as reported by cocci (Jiapeng Chong) - Fix potential NULL dereference in sr_thermal_probe() on Broadcom platform (Zheng Yongjun) - Add thermal library and thermal tools to encapsulate the netlink into event based callbacks (Daniel Lezcano) - Add change mode ops for the thermal-of sensor (Manaf Meethalavalappu Pallikunhi) - Fix non negative value support by preventing the value to be clamp to zero (Stefan Wahren) - Add compatible string and DT bindings for MSM8960 tsens driver (Dmitry Baryshkov) - Add hwmon support for K3 driver (Massimiliano Minella) - Refactor and add multiple generations support for QCom ADC driver (Jishnu Prakash) - Use platform_get_irq_optional() to get the interrupt on RCar driver and document Document RZ/V2L bindings (Lad Prabhakar) * tag 'thermal-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux: (28 commits) thermal: k3_j72xx_bandgap: Add the bandgap driver support dt-bindings: thermal: k3-j72xx: Add VTM bindings documentation thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe thermal/core: Fix memory leak in __thermal_cooling_device_register() dt-bindings: thermal: tsens: Add sc8280xp compatible dt-bindings: thermal: lmh: Add Qualcomm sc8180x compatible thermal/drivers/qcom/lmh: Add sc8180x compatible thermal/drivers/rz2gl: Fix OTP Calibration Register values dt-bindings: thermal: rzg2l-thermal: Document RZ/G2UL bindings thermal: thermal_of: fix typo on __thermal_bind_params tools/thermal: remove unneeded semicolon tools/lib/thermal: remove unneeded semicolon thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe tools/thermal: Add thermal daemon skeleton tools/thermal: Add a temperature capture tool tools/thermal: Add util library tools/lib/thermal: Add a thermal library thermal/drivers/thermal_of: Add change_mode ops support for thermal_of sensor thermal/drivers/bcm2711: Don't clamp temperature at zero thermal/drivers/tsens: Add compat string for the qcom,msm8960 ...
2022-05-19fs-verity: Use struct_size() helper in enable_verity()Zhang Jianhua
Follow the best practice for allocating a variable-sized structure. Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com> [ebiggers: adjusted commit message] Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20220519022450.2434483-1-chris.zjh@huawei.com
2022-05-19SUNRPC: Simplify synopsis of svc_pool_for_cpu()Chuck Lever
Clean up: There is one caller. The @cpu argument can be made implicit now that a get_cpu/put_cpu pair is no longer needed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Don't disable preemption while calling svc_pool_for_cpu().Sebastian Andrzej Siewior
svc_xprt_enqueue() disables preemption via get_cpu() and then asks for a pool of a specific CPU (current) via svc_pool_for_cpu(). While preemption is disabled, svc_xprt_enqueue() acquires svc_pool::sp_lock with bottom-halfs disabled, which can sleep on PREEMPT_RT. Disabling preemption is not required here. The pool is protected with a lock so the following list access is safe even cross-CPU. The following iteration through svc_pool::sp_all_threads is under RCU-readlock and remaining operations within the loop are atomic and do not rely on disabled-preemption. Use raw_smp_processor_id() as the argument for the requested CPU in svc_pool_for_cpu(). Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19NFSD: Show state of courtesy client in client infoDai Ngo
Update client_info_show to show state of courtesy client and seconds since last renew. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19NFSD: add support for lock conflict to courteous serverDai Ngo
This patch allows expired client with lock state to be in COURTESY state. Lock conflict with COURTESY client is resolved by the fs/lock code using the lm_lock_expirable and lm_expire_lock callback in the struct lock_manager_operations. If conflict client is in COURTESY state, set it to EXPIRABLE and schedule the laundromat to run immediately to expire the client. The callback lm_expire_lock waits for the laundromat to flush its work queue before returning to caller. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19fs/lock: add 2 callbacks to lock_manager_operations to resolve conflictDai Ngo
Add 2 new callbacks, lm_lock_expirable and lm_expire_lock, to lock_manager_operations to allow the lock manager to take appropriate action to resolve the lock conflict if possible. A new field, lm_mod_owner, is also added to lock_manager_operations. The lm_mod_owner is used by the fs/lock code to make sure the lock manager module such as nfsd, is not freed while lock conflict is being resolved. lm_lock_expirable checks and returns true to indicate that the lock conflict can be resolved else return false. This callback must be called with the flc_lock held so it can not block. lm_expire_lock is called to resolve the lock conflict if the returned value from lm_lock_expirable is true. This callback is called without the flc_lock held since it's allowed to block. Upon returning from this callback, the lock conflict should be resolved and the caller is expected to restart the conflict check from the beginnning of the list. Lock manager, such as NFSv4 courteous server, uses this callback to resolve conflict by destroying lock owner, or the NFSv4 courtesy client (client that has expired but allowed to maintains its states) that owns the lock. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Jeff Layton <jlayton@kernel.org>
2022-05-19fs/lock: add helper locks_owner_has_blockers to check for blockersDai Ngo
Add helper locks_owner_has_blockers to check if there is any blockers for a given lockowner. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Jeff Layton <jlayton@kernel.org>
2022-05-19NFSD: move create/destroy of laundry_wq to init_nfsd and exit_nfsdDai Ngo
This patch moves create/destroy of laundry_wq from nfs4_state_start and nfs4_state_shutdown_net to init_nfsd and exit_nfsd to prevent the laundromat from being freed while a thread is processing a conflicting lock. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19NFSD: add support for share reservation conflict to courteous serverDai Ngo
This patch allows expired client with open state to be in COURTESY state. Share/access conflict with COURTESY client is resolved by setting COURTESY client to EXPIRABLE state, schedule laundromat to run and returning nfserr_jukebox to the request client. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19NFSD: add courteous server support for thread with only delegationDai Ngo
This patch provides courteous server support for delegation only. Only expired client with delegation but no conflict and no open or lock state is allowed to be in COURTESY state. Delegation conflict with COURTESY/EXPIRABLE client is resolved by setting it to EXPIRABLE, queue work for the laundromat and return delay to the caller. Conflict is resolved when the laudromat runs and expires the EXIRABLE client while the NFS client retries the OPEN request. Local thread request that gets conflict is doing the retry in _break_lease. Client in COURTESY or EXPIRABLE state is allowed to reconnect and continues to have access to its state. Access to the nfs4_client by the reconnecting thread and the laundromat is serialized via the client_lock. Reviewed-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Remove svc_rqst::rq_xprt_hlenChuck Lever
Clean up: This field is now always set to zero. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Remove dead code in svc_tcp_release_rqst()Chuck Lever
Clean up: svc_tcp_sendto() always sets rq_xprt_ctxt to NULL. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Make cache_req::thread_wait an unsigned longChuck Lever
The second parameter of wait_for_completion_interruptible_timeout() is a jiffies value whose type is "unsigned long". Avoid an unnecessary and potentially fraught implicit type conversion at the wait_for_completion_interruptible_timeout() call site in cache_wait_req(). Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Cache deferral injectionChuck Lever
Cache deferral injection stress-tests the cache deferral logic as well as upper layer protocol deferred request handlers. This facility is for developers and professional testers to ensure coverage of the rqst deferral code paths. To date, we haven't had an adequate way to ensure these code paths are covered during testing, short of temporary code changes to force their use. A file called /sys/kernel/debug/fail_sunrpc/ignore-cache-wait enables administrators to disable cache deferral injection while allowing other types of sunrpc errors to be injected. The default setting is that cache deferral injection is enabled (ignore=false). To enable support for cache deferral injection, CONFIG_FAULT_INJECTION, CONFIG_FAULT_INJECTION_DEBUG_FS, and CONFIG_SUNRPC_DEBUG must all be set to "Y". Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19SUNRPC: Clean up svc_deferred_class trace eventsChuck Lever
Replace the temporary fix from commit 4d5004451ab2 ("SUNRPC: Fix the svc_deferred_event trace class") with the use of __sockaddr and friends, which is the preferred solution (but only available in 5.18 and newer). Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19NFSD: Clean up nfsd_splice_actor()Chuck Lever
nfsd_splice_actor() checks that the page being spliced does not match the previous element in the svc_rqst::rq_pages array. We believe this is to prevent a double put_page() in cases where the READ payload is partially contained in the xdr_buf's head buffer. However, the NFSD READ proc functions no longer place any part of the READ payload in the head buffer, in order to properly support NFS/RDMA READ with Write chunks. Therefore, simplify the logic in nfsd_splice_actor() to remove this unnecessary check. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2022-05-19Merge tag 'for-5.18/parisc-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: "We had two big outstanding issues after v5.18-rc6: a) 32-bit kernels on 64-bit machines (e.g. on a C3700 which is able to run 32- and 64-bit kernels) failed early in userspace. b) 64-bit kernels on PA8800/PA8900 CPUs (e.g. in a C8000) showed random userspace segfaults. We assumed that those problems were caused by the tmpalias flushes. Dave did a lot of testing and reorganization of the current flush code and fixed the 32-bit cache flushing. For PA8800/PA8900 CPUs he switched the code to flush using the virtual address of user and kernel pages instead of using tmpalias flushes. The tmpalias flushes don't seem to work reliable on such CPUs. We tested the patches on a wide range machines (715/64, B160L, C3000, C3700, C8000, rp3440) and they have been in for-next without any conflicts. Summary: - Rewrite the cache flush code for PA8800/PA8900 CPUs to flush using the virtual address of user and kernel pages instead of using tmpalias flushes. Testing showed, that tmpalias flushes don't work reliably on PA8800/PA8900 CPUs - Fix flush code to allow 32-bit kernels to run on 64-bit capable machines, e.g. a 32-bit kernel on C3700 machines" * tag 'for-5.18/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix patch code locking and flushing parisc: Rewrite cache flush code for PA8800/PA8900 parisc: Disable debug code regarding cache flushes in handle_nadtlb_fault()
2022-05-19Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "Two further fixes for Spectre-BHB from Ard for Cortex A15 and to use the wide branch instruction for Thumb2" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2 ARM: 9196/1: spectre-bhb: enable for Cortex-A15
2022-05-19Merge branch 'Start libbpf 1.0 dev cycle'Alexei Starovoitov
Andrii Nakryiko says: ==================== Start preparations for libbpf 1.0 release and as a first test remove bpf_create_map*() APIs. ==================== Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-05-19libbpf: remove bpf_create_map*() APIsAndrii Nakryiko
To test API removal, get rid of bpf_create_map*() APIs. Perf defines __weak implementation of bpf_map_create() that redirects to old bpf_create_map() and that seems to compile and run fine. Cc: Jiri Olsa <jolsa@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20220518185915.3529475-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-05-19libbpf: start 1.0 development cycleAndrii Nakryiko
Start libbpf 1.0 development cycle by adding LIBBPF_1.0.0 section to libbpf.map file and marking all current symbols as local. As we remove all the deprecated APIs we'll populate global list before the final 1.0 release. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20220518185915.3529475-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>