TDX host kernel now supports kexec/kdump. Update the documentation to
reflect that.
Opportunistically, remove the parentheses in "Kexec()" and move this
section under the "Erratum" section because the updated "Kexec" section
now refers to that erratum.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
Link: https://lore.kernel.org/all/20250901160930.1785244-7-pbonzini%40redhat.com
During kexec it is now guaranteed that all dirty cachelines of TDX
private memory are flushed before jumping to the new kernel. The TDX
private memory from the old kernel will remain as TDX private memory in
the new kernel, but it is OK because kernel read/write to TDX private
memory will never cause machine check, except on the platforms with the
TDX partial write erratum, which has already been handled.
It is safe to allow kexec to work together with TDX now. Remove the
!KEXEC_CORE dependency.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
Link: https://lore.kernel.org/all/20250901160930.1785244-6-pbonzini%40redhat.com
Some early TDX-capable platforms have an erratum: A kernel partial
write (a write transaction of less than cacheline lands at memory
controller) to TDX private memory poisons that memory, and a subsequent
read triggers a machine check.
On those platforms, the old kernel must reset TDX private memory before
jumping to the new kernel, otherwise the new kernel may see unexpected
machine check. Currently the kernel doesn't track which page is a TDX
private page. For simplicity just fail kexec/kdump for those platforms.
Leverage the existing machine_kexec_prepare() to fail kexec/kdump by
adding the check of the presence of the TDX erratum (which is only
checked for if the kernel is built with TDX host support). This rejects
kexec/kdump when the kernel is loading the kexec/kdump kernel image.
The alternative is to reject kexec/kdump when the kernel is jumping to
the new kernel. But for kexec this requires adding a new check (e.g.,
arch_kexec_allowed()) in the common code to fail kernel_kexec() at early
stage. Kdump (crash_kexec()) needs similar check, but it's hard to
justify because crash_kexec() is not supposed to abort.
It's feasible to further relax this limitation, i.e., only fail kexec
when TDX is actually enabled by the kernel. But this is still a half
measure compared to resetting TDX private memory so just do the simplest
thing for now.
The impact to userspace is the users will get an error when loading the
kexec/kdump kernel image:
kexec_load failed: Operation not supported
This might be confusing to the users, thus also print the reason in the
dmesg:
[..] kexec: Not allowed on platform with tdx_pw_mce bug.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
Link: https://lore.kernel.org/all/20250901160930.1785244-5-pbonzini%40redhat.com
On TDX platforms, dirty cacheline aliases with and without encryption
bits can coexist, and the cpu can flush them back to memory in random
order. During kexec, the caches must be flushed before jumping to the
new kernel otherwise the dirty cachelines could silently corrupt the
memory used by the new kernel due to different encryption property.
A percpu boolean is used to mark whether the cache of a given CPU may be
in an incoherent state, and the kexec performs WBINVD on the CPUs with
that boolean turned on.
For TDX, only the TDX module or the TDX guests can generate dirty
cachelines of TDX private memory, i.e., they are only generated when the
kernel does a SEAMCALL.
Set that boolean when the kernel does SEAMCALL so that kexec can flush
the cache correctly.
The kernel provides both the __seamcall*() assembly functions and the
seamcall*() wrapper ones which additionally handle running out of
entropy error in a loop. Most of the SEAMCALLs are called using the
seamcall*(), except TDH.VP.ENTER and TDH.PHYMEM.PAGE.RDMD which are
called using __seamcall*() variant directly.
To cover the two special cases, add a new __seamcall_dirty_cache()
helper which only sets the percpu boolean and calls the __seamcall*(),
and change the special cases to use the new helper. To cover all other
SEAMCALLs, change seamcall*() to call the new helper.
For the SEAMCALLs invoked via seamcall*(), they can be made from both
task context and IRQ disabled context. Given SEAMCALL is just a lengthy
instruction (e.g., thousands of cycles) from kernel's point of view and
preempt_{disable|enable}() is cheap compared to it, just unconditionally
disable preemption during setting the boolean and making SEAMCALL.
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
Link: https://lore.kernel.org/all/20250901160930.1785244-4-pbonzini%40redhat.com
TL;DR:
Prepare to unify how TDX and SME do cache flushing during kexec by
making a percpu boolean control whether to do the WBINVD.
-- Background --
On SME platforms, dirty cacheline aliases with and without encryption
bit can coexist, and the CPU can flush them back to memory in random
order. During kexec, the caches must be flushed before jumping to the
new kernel otherwise the dirty cachelines could silently corrupt the
memory used by the new kernel due to different encryption property.
TDX also needs a cache flush during kexec for the same reason. It would
be good to have a generic way to flush the cache instead of scattering
checks for each feature all around.
When SME is enabled, the kernel basically encrypts all memory including
the kernel itself and a simple memory write from the kernel could dirty
cachelines. Currently, the kernel uses WBINVD to flush the cache for
SME during kexec in two places:
1) the one in stop_this_cpu() for all remote CPUs when the kexec-ing CPU
stops them;
2) the one in the relocate_kernel() where the kexec-ing CPU jumps to the
new kernel.
-- Solution --
Unlike SME, TDX can only dirty cachelines when it is used (i.e., when
SEAMCALLs are performed). Since there are no more SEAMCALLs after the
aforementioned WBINVDs, leverage this for TDX.
To unify the approach for SME and TDX, use a percpu boolean to indicate
the cache may be in an incoherent state and needs flushing during kexec,
and set the boolean for SME. TDX can then leverage it.
While SME could use a global flag (since it's enabled at early boot and
enabled on all CPUs), the percpu flag fits TDX better:
The percpu flag can be set when a CPU makes a SEAMCALL, and cleared when
another WBINVD on the CPU obviates the need for a kexec-time WBINVD.
Saving kexec-time WBINVD is valuable, because there is an existing
race[*] where kexec could proceed while another CPU is active. WBINVD
could make this race worse, so it's worth skipping it when possible.
-- Side effect to SME --
Today the first WBINVD in the stop_this_cpu() is performed when SME is
*supported* by the platform, and the second WBINVD is done in
relocate_kernel() when SME is *activated* by the kernel. Make things
simple by changing to do the second WBINVD when the platform supports
SME. This allows the kernel to simply turn on this percpu boolean when
bringing up a CPU by checking whether the platform supports SME.
No other functional change intended.
[*] The aforementioned race:
During kexec native_stop_other_cpus() is called to stop all remote CPUs
before jumping to the new kernel. native_stop_other_cpus() firstly
sends normal REBOOT vector IPIs to stop remote CPUs and waits them to
stop. If that times out, it sends NMI to stop the CPUs that are still
alive. The race happens when native_stop_other_cpus() has to send NMIs
and could potentially result in the system hang (for more information
please see [1]).
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/kvm/b963fcd60abe26c7ec5dc20b42f1a2ebbcc72397.1750934177.git.kai.huang@intel.com/ [1]
Link: https://lore.kernel.org/all/20250901160930.1785244-3-pbonzini%40redhat.com
During kexec, the kernel jumps to the new kernel in relocate_kernel(),
which is implemented in assembly and both 32-bit and 64-bit have their
own version.
Currently, for both 32-bit and 64-bit, the last two parameters of the
relocate_kernel() are both 'unsigned int' but actually they only convey
a boolean, i.e., one bit information. The 'unsigned int' has enough
space to carry two bits information therefore there's no need to pass
the two booleans in two separate 'unsigned int'.
Consolidate the last two function parameters of relocate_kernel() into a
single 'unsigned int' and pass flags instead.
Only consolidate the 64-bit version albeit the similar optimization can
be done for the 32-bit version too. Don't bother changing the 32-bit
version while it is working (since assembly code change is required).
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/all/20250901160930.1785244-2-pbonzini%40redhat.com
- fix GPIO submenu regression in Kconfig
- fix make clean under tools/gpio/
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmi64bAACgkQEacuoBRx
13JQ+A/+K1JQDRO7nsXEOoYZI9Y/Afwf9qHYEHyCEXB1PnHZtJNTQGwlWLtQ1rXH
tuuGPToKpYGLL2wL6NCD/z7S0rmTS7m8lDOS/4JWzYkamgk3byV0Yb7owc5KsZ4o
sQTeGPz06lhgAD87c49efxJLowYFquEe6IpQ+9l+lfbF5gvCopfZMq3fqlSzAiap
F0PvliEsx3+9YYWc+OR44zhKmZNKgA6qZXuLxVCbOekCgijCs4fl0caxcVhONHlD
/cy5sj52CVuz6et6OKm2q01NbpanwGrvDb5nfw1YVNVNF4kc+YBpvQG8omgDcSxc
4JuxCjTABTc4n+fvXChMgdJ0XeeRaKBpmdoFPR3D3xV/GK1rWFPFZ3U+ORhyqK4X
sFAsClXYBzTRr5TiY4siKoaJPwWs3CA5pbhLhN0xQ+9IzKOtsenT8YQUR7ERbq5y
Ni8skAaahWfD0utSjjOaZ5SwTUh1T19ZQ2899Pw3Gbh7VtyeC+MwkQhGmg0+2jw3
qp0NXvXg3Ozr43IJgjWz4FBsWLdCnjr3mxTHLXmzZrTyW+3+cTyjsWdVptinfxRM
ujo5v8mSh9RilBBFF4T92EnKilIHfdnXA7we7v19+9Zz9In2QEUmv57WWv79kION
LXbhh05CIUcHsV4RnmikZzUX/thRwk6lz5OW4EfO7chbWWWPdhM=
=D/dx
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix GPIO submenu regression in Kconfig
- fix make clean under tools/gpio/
* tag 'gpio-fixes-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
tools: gpio: remove the include directory on make clean
gpio: fix GPIO submenu in Kconfig
Fixes and New HW Support
- acer-wmi: Stop using ACPI bitmap for platform profile choices
- amd/hfi: Fix pcct_tbl leak
- amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042 quirks
- asus-wmi:
- Fix registration races
- Fix ROG button mapping, tablet mode on ASUS ROG Z13
- Support more keys on ExpertBook B9
- hp-wmi: Add support for Fn+P hotkey
- intel/pmc: Add Bartlett Lake support
- intel/power-domains: Use topology_logical_package_id() for package ID
The following is an automated shortlog grouped by driver:
acer-wmi:
- Stop using ACPI bitmap for platform profile choices
amd: hfi:
- Fix pcct_tbl leak in amd_hfi_metadata_parser()
amd/pmc:
- Add TUXEDO IB Pro Gen10 AMD to spurious 8042 quirks list
asus-wmi:
- Fix racy registrations
- Fix ROG button mapping, tablet mode on ASUS ROG Z13
- map more keys on ExpertBook B9
- Remove extra keys from ignore_key_wlan quirk
hp-wmi:
- Add support for Fn+P hotkey
intel/pmc:
- Add Bartlett Lake support to intel_pmc_core
intel: power-domains:
- Use topology_logical_package_id() for package ID
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSCSUwRdwTNL2MhaBlZrE9hU+XOMQUCaLretwAKCRBZrE9hU+XO
MaibAPoDQK7NrixtCvXnm4fmWqttGyTBl73uqoCXL2X8LsQwMAEAkqh319fCZrjx
/4u7YThOXpLnK+PROV72YRRTeP6hRwY=
=jtzK
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
- acer-wmi: Stop using ACPI bitmap for platform profile choices
- amd/hfi: Fix pcct_tbl leak
- amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042 quirks
- asus-wmi:
- Fix registration races
- Fix ROG button mapping, tablet mode on ASUS ROG Z13
- Support more keys on ExpertBook B9
- hp-wmi: Add support for Fn+P hotkey
- intel/pmc: Add Bartlett Lake support
- intel/power-domains: Use topology_logical_package_id() for package ID
* tag 'platform-drivers-x86-v6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86/intel: power-domains: Use topology_logical_package_id() for package ID
platform/x86: acer-wmi: Stop using ACPI bitmap for platform profile choices
platform/x86: hp-wmi: Add support for Fn+P hotkey
platform/x86/intel/pmc: Add Bartlett Lake support to intel_pmc_core
platform/x86: asus-wmi: Fix racy registrations
platform/x86/amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042 quirks list
platform/x86: asus-wmi: map more keys on ExpertBook B9
platform/x86: asus-wmi: Fix ROG button mapping, tablet mode on ASUS ROG Z13
platform/x86: asus-wmi: Remove extra keys from ignore_key_wlan quirk
platform/x86/amd: hfi: Fix pcct_tbl leak in amd_hfi_metadata_parser()
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmi6xUEQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpqpwD/9mDqr7f4clwNaCgqxCVifLqiWGBHAyccXe
CgRJzcqofTDiQh3upa0C5SL5qZCTeTfir6rTf3fn3wKLP0mns55xDBmbRwylsutE
lenJbpvnPHi0/iJBgA4LpSL5IB+HsdQjKpmuYnavISlcGD8nMQZDk70h4iNu9baE
0fbyON8BvlZwq5KXDRR0sdSeyLPL6z14PkC9yScm8kwee+o+koReTM/J7aMnkzLv
0z2iibDIPyrSbHgPpV2dbAfSj+TLsuleJ3WG8cAvb3O03V91pPiLKrte5PBEaFV4
Srs0+G0kszexfeEqODhDQaLUg3k6hRl41GVnOxrS0NccTCqMe9P7rRBTys4KU6y6
fpDXYY9c1ehVyqFFDepPMSzqDa0XoBiQphblp5Yyxon2V6JK1bBQdu3eqieJyc8u
eXiDNaY1IawdGRSY8cWFwSWQk8luXvmB3TtZCyFY3g3QwAJ9+OuTaqZECs8Lh8n/
brHDb5Qij8R94DSH7HHwPZ7mEbmE+c4EBst7hruuaUVSq12XoYQFqDjyt3ino1ky
z5OENc4fXD10+b8KK9yrOxj2uYUmiia1acCEy2T2svfaKQ/ZXrCU7b1dkA04d/oC
+TA7MdSn597FLvButA+CC9oqapr9k217AhhEVCWbgY428ialeTtv5NBnOH6Ykawr
narKcKzC1g==
=WfWq
-----END PGP SIGNATURE-----
Merge tag 'block-6.17-20250905' of git://git.kernel.dk/linux
Pull block fixes from Jens Axboe:
- NVMe pull request via Keith
- Fix protection information ref tag for device side gen/strip
(Christoph)
- MD pull request via Yu
- fix data loss for writemostly in raid1 (Yu Kuai)
- fix potentional data loss by skipping recovery (Li Nan)
* tag 'block-6.17-20250905' of git://git.kernel.dk/linux:
md: prevent incorrect update of resync/recovery offset
md/raid1: fix data lost for writemostly rdev
nvme: fix PI insert on write
This is an update to reflect reality, not a signal of any seismic
change. Dave Sterba has been the acting maintainer for almost a decade,
I've simply been here as a backstop in case he gets hit by a bus. The
fact is we have a strong and thriving community with any number of more
active developers that can take on that role if it's necessary. I'm
exceedingly happy and proud of the work that Dave has done in keeping us
all in line, and know that if further changes need to be made it'll be
with the development community we've built throughout the lifetime of
btrfs.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
system_wq is a per-CPU worqueue, yet nothing in its name tells about that
CPU affinity constraint, which is very often not required by users. Make
it clear by adding a system_percpu_wq.
queue_work() / queue_delayed_work() mod_delayed_work() will now use the
new per-cpu wq: whether the user still stick on the old name a warn will
be printed along a wq redirect to the new one.
This patch add the new system_percpu_wq except for mm, fs and net
subsystem, whom are handled in separated patches.
The old wq will be kept for a few release cylces.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
queue_work() / queue_delayed_work() / mod_delayed_work() will now use the
new unbound wq: whether the user still use the old wq a warn will be
printed along with a wq redirect to the new one.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Pull for-6.17-fixes to receive 79f919a89c ("cgroup: split
cgroup_destroy_wq into 3 workqueues") to resolve its conflict with
7fa33aa3b0 ("cgroup: WQ_PERCPU added to alloc_workqueue users"). The
latter adds WQ_PERCPU when creating cgroup_destroy_wq and the former splits
the workqueue into three. Resolve by applying WQ_PERCPU to the three split
workqueues.
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This patch adds a new WQ_PERCPU flag to explicitly request the use of
the per-CPU behavior. Both flags coexist for one release cycle to allow
callers to transition their calls.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
All existing users have been updated accordingly.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
system_wq is a per-CPU worqueue, yet nothing in its name tells about that
CPU affinity constraint, which is very often not required by users. Make
it clear by adding a system_percpu_wq.
queue_work() / queue_delayed_work() mod_delayed_work() will now use the
new per-cpu wq: whether the user still stick on the old name a warn will
be printed along a wq redirect to the new one.
This patch add the new system_percpu_wq except for mm, fs and net
subsystem, whom are handled in separated patches.
The old wq will be kept for a few release cylces.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Merge series from Woodrow Douglass <wdouglass@carnegierobotics.com>:
I wrote this driver to read settings and state from the nxp pf530x
regulator. Please consider it for inclusion, any criticism is welcome.
On arm64, it has been possible for a module's sections to be placed more
than 128M away from each other since commit:
commit 3e35d303ab ("arm64: module: rework module VA range selection")
Due to this, an ftrace callsite in a module's .init.text section can be
out of branch range for the module's ftrace PLT entry (in the module's
.text section). Any attempt to enable tracing of that callsite will
result in a BRK being patched into the callsite, resulting in a fatal
exception when the callsite is later executed.
Fix this by adding an additional trampoline for .init.text, which will
be within range.
No additional trampolines are necessary due to the way a given
module's executable sections are packed together. Any executable
section beginning with ".init" will be placed in MOD_INIT_TEXT,
and any other executable section, including those beginning with ".exit",
will be placed in MOD_TEXT.
Fixes: 3e35d303ab ("arm64: module: rework module VA range selection")
Cc: <stable@vger.kernel.org> # 6.5.x
Signed-off-by: panfan <panfan@qti.qualcomm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20250905032236.3220885-1-panfan@qti.qualcomm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
scheduler:
- fix race in unschedulable tracepoint
bridge:
- ti-sn65dsi86: fix REFCLK setting
xe:
- Fix incorrect migration of backed-up object to VRAM
amdgpu:
- UserQ fixes
- MES 11 fix
- eDP/LVDS fix
- Fix non-DC audio clean up
- Fix duplicate cursor issue
- Fix error path in PSP init
nouveau:
- fix nonstall interrupt handling
- fix race on fence vs irq emission
- update MAINTAINERS entry
ivpu:
- prevent recovery work during device remove
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmi6YlIACgkQDHTzWXnE
hr5fMg//ZorOaPj0uYEU6sdT3Vkke6vxOd+GQVBdSUDhW8x5BOM6anEj0uQobxOP
qwTf9vy/LInr3ghqKc9B/hXaN/QkOCsbVvyuEXPUv1LhggLK94ThQcoY2zMkUbJP
5NfKyFRpl2Z53RdjmBTZJ+6QOVbwy6kMG5AHE9CG4ZXNC11EHQZHXdj72tvysEQf
TQlMWzTIZ6tgfBSqPjOSEs1ASeFYoS5KEJGiqCHXLvC2DbjY/71pUZCyvUQacygQ
TU+h2j4oqNuTqN7ftDw7a6R3yPEIOThGHABaQrXsyZjfHabXkvrSVERXzpexAjXG
14RInUCHNB9QbAyFOIjrGZhXneQCdy2+w37qYipkzfrVL8CN6Je565bMyZjmUW9i
+Dys3vJXk2TMn+ymblQ8JkjkA8O6D5pYFFMS24AI0Sd3h6NeTFAnWXSS/Uz4dFdB
NxEBDuOBkyRh8Hw1Bz/qOFrbECBz+/JU1qFUNoP4VeL0OlzZ7YrLMMFHQfiAV2RY
Xv9ACyqiy/k/owJuJ/yWANWk3MzpGqz3aL7V3MQXfIUvyD0xMVqRMS3bBixCSf6F
WlrWWlCVIprrUhhXnOBBZPca5764cZtsM+9wA1MoPed2IYnyFA8uHE1P2BxIOLjS
fCeQNzOV6qU4aAp2UP58H0lYDpXEYfGuthF2xMDm/pmoSXO6whU=
=LUUF
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2025-09-05' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly drm fixes roundup, nouveau has two fixes for fence/irq racing
problems that should fix a bunch of instability in userspace.
Otherwise amdgpu along with some single fixes to bridge, xe, ivpu.
Looks about usual for this time in the release.
scheduler:
- fix race in unschedulable tracepoint
bridge:
- ti-sn65dsi86: fix REFCLK setting
xe:
- Fix incorrect migration of backed-up object to VRAM
amdgpu:
- UserQ fixes
- MES 11 fix
- eDP/LVDS fix
- Fix non-DC audio clean up
- Fix duplicate cursor issue
- Fix error path in PSP init
nouveau:
- fix nonstall interrupt handling
- fix race on fence vs irq emission
- update MAINTAINERS entry
ivpu:
- prevent recovery work during device remove"
* tag 'drm-fixes-2025-09-05' of https://gitlab.freedesktop.org/drm/kernel:
drm/amd/amdgpu: Fix missing error return on kzalloc failure
drm/bridge: ti-sn65dsi86: fix REFCLK setting
MAINTAINERS: Update git entry for nouveau
drm/xe: Fix incorrect migration of backed-up object to VRAM
drm/sched: Fix racy access to drm_sched_entity.dependency
accel/ivpu: Prevent recovery work from being queued during device removal
nouveau: Membar before between semaphore writes and the interrupt
nouveau: fix disabling the nonstall irq due to storm code
drm/amd/display: Clear the CUR_ENABLE register on DCN314 w/out DPP PG
drm/amdgpu: drop hw access in non-DC audio fini
drm/amd: Re-enable common modes for eDP and LVDS
drm/amdgpu/mes11: make MES_MISC_OP_CHANGE_CONFIG failure non-fatal
drm/amdgpu/sdma: bump firmware version checks for user queue support
Online fsck has been a part of upstream for over a year now without any
serious problems. Turn it on by default in time for the 2025 LTS
kernel, and get rid of the "say N if unsure" messages for the default Y
options.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Don't roll the whole transaction after every extent, that's rather
inefficient.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
These sysctl knobs were scheduled for removal in September 2025. That
time has come, so remove them.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Delete XREAP_MAX_BINVAL and XREAP_MAX_DEFER_CHAIN because the reap code
now calculates those limits dynamically, so they're no longer needed.
Move the third limit (XREP_MAX_ITRUNCATE_EFIS) to the one file that uses
it. Note that the btree rebuilding code should reserve exactly the
number of blocks needed to rebuild a btree, so it is rare that the newbt
code will need to add any EFIs to the commit transaction. That's why
that static limit remains.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
These four mount options were scheduled for removal in September 2025,
so remove them now.
Cc: preichl@redhat.com
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
We promised to turn off these old features by default in September 2025.
Do so now.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reaping file fork mappings is a little different -- log recovery can
free the blocks for us, so we only try to process a single mapping at a
time. Therefore, we only need to figure out the maximum number of
blocks that we can invalidate in a single transaction.
The rough calculation here is:
nr_extents = (logres - reservation used by any one step) /
(space used per binval)
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Calculate the maximum number of CoW staging extents that can be reaped
in a single transaction chain. The rough calculation here is:
nr_extents = (logres - reservation used by any one step) /
(space used by intents per extent)
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Calculate the maximum number of CoW staging extents that can be reaped
in a single transaction chain. The rough calculation here is:
nr_extents = (logres - reservation used by any one step) /
(space used by intents per extent +
space used for a few buffer invalidations)
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Calculate the maximum number of extents that can be reaped in a single
transaction chain, and the number of buffers that can be invalidated in
a single transaction. The rough calculation here is:
nr_extents = (logres - reservation used by any one step) /
(space used by intents per extent +
space used per binval)
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Convert the file fork reaping code to use struct xreap_state so that we
can reuse the dynamic state tracking code.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
The online repair block reaping code employs static limits to decide if
it's time to roll the transaction or finish the deferred item chains to
avoid overflowing the scrub transaction's reservation. However, the
use of static limits aren't great -- btree blocks are assumed to be
scattered around the AG and the buffers need to be invalidated, whereas
COW staging extents are usually contiguous and do not have buffers. We
would like to configure the limits dynamically.
To get ready for this, reorganize struct xreap_state to store dynamic
limits, and add helpers to hide some of the details of how the limits
are enforced. Also rename the "xreap roll" functions to include the
word "binval" because they only exist to decide when we should roll the
transaction to deal with buffer invalidations.
No functional changes intended here.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
When we're removing rmap records for crosslinked blocks, use deferred
intent items so that we can try to free/unmap as many of the old data
structure's blocks as we can in the same transaction as the commit.
Cc: <stable@vger.kernel.org> # v6.6
Fixes: 1c7ce115e5 ("xfs: reap large AG metadata extents when possible")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
When the xe pm_notifier evicts for suspend / hibernate, there might be
racing tasks trying to re-validate again. This can lead to suspend taking
excessive time or get stuck in a live-lock. This behaviour becomes
much worse with the fix that actually makes re-validation bring back
bos to VRAM rather than letting them remain in TT.
Prevent that by having exec and the rebind worker waiting for a completion
that is set to block by the pm_notifier before suspend and is signaled
by the pm_notifier after resume / wakeup.
It's probably still possible to craft malicious applications that block
suspending. More work is pending to fix that.
v3:
- Avoid wait_for_completion() in the kernel worker since it could
potentially cause work item flushes from freezable processes to
wait forever. Instead terminate the rebind workers if needed and
re-launch at resume. (Matt Auld)
v4:
- Fix some bad naming and leftover debug printouts.
- Fix kerneldoc.
- Use drmm_mutex_init() for the xe->rebind_resume_lock (Matt Auld).
- Rework the interface of xe_vm_rebind_resume_worker (Matt Auld).
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4288
Fixes: c6a4d46ec1 ("drm/xe: evict user memory in PM notifier")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v6.16+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/20250904160715.2613-4-thomas.hellstrom@linux.intel.com
Its actions are opportunistic anyway and will be completed
on device suspend.
Marking as a fix to simplify backporting of the fix
that follows in the series.
v2:
- Keep the runtime pm reference over suspend / hibernate and
document why. (Matt Auld, Rodrigo Vivi):
Fixes: c6a4d46ec1 ("drm/xe: evict user memory in PM notifier")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v6.16+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/20250904160715.2613-3-thomas.hellstrom@linux.intel.com
VRAM+TT bos that are evicted from VRAM to TT may remain in
TT also after a revalidation following eviction or suspend.
This manifests itself as applications becoming sluggish
after buffer objects get evicted or after a resume from
suspend or hibernation.
If the bo supports placement in both VRAM and TT, and
we are on DGFX, mark the TT placement as fallback. This means
that it is tried only after VRAM + eviction.
This flaw has probably been present since the xe module was
upstreamed but use a Fixes: commit below where backporting is
likely to be simple. For earlier versions we need to open-
code the fallback algorithm in the driver.
v2:
- Remove check for dgfx. (Matthew Auld)
- Update the xe_dma_buf kunit test for the new strategy (CI)
- Allow dma-buf to pin in current placement (CI)
- Make xe_bo_validate() for pinned bos a NOP.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5995
Fixes: a78a8da51b ("drm/ttm: replace busy placement with flags v6")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v6.9+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/20250904160715.2613-2-thomas.hellstrom@linux.intel.com
Fix a regression caused by my commits that reimplemented the sha1,
sha256, and sha512 crypto_shash algorithms on top of the library API.
Specifically, the export_core and import_core methods stopped being
supported, which broke some hardware offload drivers (such as qat)
that recently started depending on these for fallback functionality.
Later I'd like to make these drivers just use the library API for
their fallback. Then these methods won't be needed anymore. But for
now, this fixes the regression for 6.17.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCaLpYrBQcZWJpZ2dlcnNA
a2VybmVsLm9yZwAKCRDzXCl4vpKOK8ZfAQDbPYyJbAS4nFIZt8wulDdw8oyMvNl9
gdo3pfJUzo/gKwEAqOLra0dEy6Bvj0HqW5C8GMtFZjKJ1NbgXs9nTMKw0gc=
=yidx
-----END PGP SIGNATURE-----
Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fixes from Eric Biggers:
"Fix a regression caused by my commits that reimplemented the sha1,
sha256, and sha512 crypto_shash algorithms on top of the library API.
Specifically, the export_core and import_core methods stopped being
supported, which broke some hardware offload drivers (such as qat)
that recently started depending on these for fallback functionality.
Later I'd like to make these drivers just use the library API for
their fallback. Then these methods won't be needed anymore. But for
now, this fixes the regression for 6.17"
* tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:
crypto: sha512 - Implement export_core() and import_core()
crypto: sha256 - Implement export_core() and import_core()
crypto: sha1 - Implement export_core() and import_core()
A number of minor PCMCIA bugfixes and cleanups, including the removal of
unused code paths.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
-----BEGIN PGP SIGNATURE-----
iQJPBAABCgA5FiEEmgXaWKgmjrvkPhLCmpdgiUyNow0FAmi30PMbHGxpbnV4QGRv
bWluaWticm9kb3dza2kubmV0AAoJEJqXYIlMjaMNke8P/1IpUvj+mdpi36r44Vt4
E5D2IruivFTyj5GFMBcGf5CpDJTvwyDi9YcQjoNmfn0FjKfyVCmu9vn2zPK4clIN
8bclmhOnK/7oEtVg0+hI7VzpMdJDUGJ3XrSio/gSVMlNK3fTitdzwnQqu8a55TLO
ftD2ykeBdiEXmVmconeFUQhdCHL1Z9eMkpp5c56rzByPUiWKdP62luf2KuHt3wtm
BzUyMiH4GPQXMwkXV9zKdynvKm6ohsA+sWCbgpgtcGdmrVsMtI9Qn308Y0SZQDu0
lHaX9URC+E2jJlGzenKfxLI+mm2oqgdSGQyVW70VmvWjcRBuyf6HyhhftvwmQ+CD
Q65TkDsd6Kji49JvevGUsGx1XXGUV9HrJJA/suGL/HEnh2hp44nUxApZ+T9RIrVZ
hz75u8wm3fqtx7EJ8bsUiXhkjs90A78pq7N0ddyfkUFSzX2IJQAIzC83rixuEVYl
azprcFDOq4rVcPWnioZzopfyZNFQ97Mg7wrLVfznNGeiIQPU4Ijph3L8Iuvw1oKr
T/YjwAscILy+NzvMD3s0kwbshty2f8kiqLeZJ2VdQy4rQ/4iGnl3LYAPXYMSrgA2
1bG+t0UhtJz1aCg1ysmoITl2kzaGyoXcOOw7ouLP2cIth8QjxCzSoPRJZTA7Dgwc
qfwLDdOQHbFQB4ZJqsGvrNwY
=bWPz
-----END PGP SIGNATURE-----
Merge tag 'pcmcia-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux
Pull PCMCIA fixes and cleanups from Dominik Brodowski:
"A number of minor PCMCIA bugfixes and cleanups, including the removal
of unused code paths"
[ Dominik suggested this might be 6.18 material, but having looked
through this, it looks appropriate early: minor trivial fixes and then
one slightly bigger patch that removes dead code - Linus ]
* tag 'pcmcia-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux:
pcmcia: Add error handling for add_interval() in do_validate_mem()
pcmcia: cs: Remove unused pcmcia_get_socket_by_nr
pcmcia: omap: Add missing check for platform_get_resource
pcmcia: Use str_off_on() and str_yes_no() helpers
pcmcia: remove PCCARD_IODYN
pcmcia: ds: Emphasize "really" epizeuxis
pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()
pcmcia: omap_cf: Mark driver struct with __refdata to prevent section mismatch
Since there are too many variants available for Foxconn T99W696 modem, and
they all share the same configuration, use PCI_ANY_ID as the subsystem
device ID to match each possible SKUs and support all of them.
Signed-off-by: Slark Xiao <slark_xiao@163.com>
[mani: reworded subject/description and dropped the fixes tag]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20250819020013.122162-1-slark_xiao@163.com
Nam Cao <namcao@linutronix.de> says:
Hi,
This v4 is the follow-up to v3 at:
https://lore.kernel.org/linux-fsdevel/20250527090836.1290532-1-namcao@linutronix.de/
which resolves a priority inversion problem.
The v3 patch was merged, but then got reverted due to regression.
The direction of v3 was wrong in the first place. It changed the
eventpoll's event list to be lockless, making the code harder to read. I
stared at the patch again, but still couldn't figure out what the bug is.
The performance numbers were indeed impressive with lockless, but the
numbers are from a benchmark, which is unclear whether it really reflects
real workload.
This v4 takes a completely different approach: it converts the rwlock to
spinlock. Unfortunately, unlike rwlock, spinlock does not allow concurrent
readers. This patch therefore reduces the performance numbers.
I have some optimization tricks to reduce spinlock contention and bring the
numbers back. But Linus appeared and declared that epoll's performance
shouldn't be the priority. So I decided not to post those optimization
patches.
* patches from https://lore.kernel.org/cover.1752581388.git.namcao@linutronix.de:
eventpoll: Replace rwlock with spinlock
Link: https://lore.kernel.org/cover.1752581388.git.namcao@linutronix.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
The ready event list of an epoll object is protected by read-write
semaphore:
- The consumer (waiter) acquires the write lock and takes items.
- the producer (waker) takes the read lock and adds items.
The point of this design is enabling epoll to scale well with large number
of producers, as multiple producers can hold the read lock at the same
time.
Unfortunately, this implementation may cause scheduling priority inversion
problem. Suppose the consumer has higher scheduling priority than the
producer. The consumer needs to acquire the write lock, but may be blocked
by the producer holding the read lock. Since read-write semaphore does not
support priority-boosting for the readers (even with CONFIG_PREEMPT_RT=y),
we have a case of priority inversion: a higher priority consumer is blocked
by a lower priority producer. This problem was reported in [1].
Furthermore, this could also cause stall problem, as described in [2].
Fix this problem by replacing rwlock with spinlock.
This reduces the event bandwidth, as the producers now have to contend with
each other for the spinlock. According to the benchmark from
https://github.com/rouming/test-tools/blob/master/stress-epoll.c:
On 12 x86 CPUs:
Before After Diff
threads events/ms events/ms
8 7162 4956 -31%
16 8733 5383 -38%
32 7968 5572 -30%
64 10652 5739 -46%
128 11236 5931 -47%
On 4 riscv CPUs:
Before After Diff
threads events/ms events/ms
8 2958 2833 -4%
16 3323 3097 -7%
32 3451 3240 -6%
64 3554 3178 -11%
128 3601 3235 -10%
Although the numbers look bad, it should be noted that this benchmark
creates multiple threads who do nothing except constantly generating new
epoll events, thus contention on the spinlock is high. For real workload,
the event rate is likely much lower, and the performance drop is not as
bad.
Using another benchmark (perf bench epoll wait) where spinlock contention
is lower, improvement is even observed on x86:
On 12 x86 CPUs:
Before: Averaged 110279 operations/sec (+- 1.09%), total secs = 8
After: Averaged 114577 operations/sec (+- 2.25%), total secs = 8
On 4 riscv CPUs:
Before: Averaged 175767 operations/sec (+- 0.62%), total secs = 8
After: Averaged 167396 operations/sec (+- 0.23%), total secs = 8
In conclusion, no one is likely to be upset over this change. After all,
spinlock was used originally for years, and the commit which converted to
rwlock didn't mention a real workload, just that the benchmark numbers are
nice.
This patch is not exactly the revert of commit a218cc4914 ("epoll: use
rwlock in order to reduce ep_poll_callback() contention"), because git
revert conflicts in some places which are not obvious on the resolution.
This patch is intended to be backported, therefore go with the obvious
approach:
- Replace rwlock_t with spinlock_t one to one
- Delete list_add_tail_lockless() and chain_epi_lockless(). These were
introduced to allow producers to concurrently add items to the list.
But now that spinlock no longer allows producers to touch the event
list concurrently, these two functions are not necessary anymore.
Fixes: a218cc4914 ("epoll: use rwlock in order to reduce ep_poll_callback() contention")
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://lore.kernel.org/ec92458ea357ec503c737ead0f10b2c6e4c37d47.1752581388.git.namcao@linutronix.de
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: stable@vger.kernel.org
Reported-by: Frederic Weisbecker <frederic@kernel.org>
Closes: https://lore.kernel.org/linux-rt-users/20210825132754.GA895675@lothringen/ [1]
Reported-by: Valentin Schneider <vschneid@redhat.com>
Closes: https://lore.kernel.org/linux-rt-users/xhsmhttqvnall.mognet@vschneid.remote.csb/ [2]
Signed-off-by: Christian Brauner <brauner@kernel.org>
The 'bridge' pointer started being assigned and used within this 'if' scope
in commit 0beba3f9d3 ("drm/bridge: connector: add support for HDMI codec
framework").
After that, commit 5d04b41889 ("drm/bridge: split HDMI Audio from
DRM_BRIDGE_OP_HDMI") removed the code dereferencing it from the same 'if'
scope, but did not remove the assignment.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250808-drm-bridge-alloc-getput-for_each_bridge-v2-2-edb6ee81edf1@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver allows reading some regulator settings and adjusting
output voltage. It is based on information from the datasheet
at https://www.nxp.com/docs/en/data-sheet/PF5300.pdf
Signed-off-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
Message-ID: <20250902-pf530x-v7-2-10eb2542f944@carnegierobotics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bindings for the pf530x series of voltage regulators
Signed-off-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Message-ID: <20250902-pf530x-v7-1-10eb2542f944@carnegierobotics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When a PCI device is removed with surprise hotplug, there may still be
attempts to attach the device to the default domain as part of tear down
via (__iommu_release_dma_ownership()), or because the removal happens
during probe (__iommu_probe_device()). In both cases zpci_register_ioat()
fails with a cc value indicating that the device handle is invalid. This
is because the device is no longer part of the instance as far as the
hypervisor is concerned.
Currently this leads to an error return and s390_iommu_attach_device()
fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()
because attaching to the default domain must never fail.
With the device fenced by the hypervisor no DMAs to or from memory are
possible and the IOMMU translations have no effect. Proceed as if the
registration was successful and let the hotplug event handling clean up
the device.
This is similar to how devices in the error state are handled since
commit 59bbf59679 ("iommu/s390: Make attach succeed even if the device
is in error state") except that for removal the domain will not be
registered later. This approach was also previously discussed at the
link.
Handle both cases, error state and removal, in a helper which checks if
the error needs to be propagated or ignored. Avoid magic number
condition codes by using the pre-existing, but never used, defines for
PCI load/store condition codes and rename them to reflect that they
apply to all PCI instructions.
Cc: stable@vger.kernel.org # v6.2
Link: https://lore.kernel.org/linux-iommu/20240808194155.GD1985367@ziepe.ca/
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Link: https://lore.kernel.org/r/20250904-iommu_succeed_attach_removed-v1-1-e7f333d2f80f@linux.ibm.com
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
switch_to_super_page() assumes the memory range it's working on is aligned
to the target large page level. Unfortunately, __domain_mapping() doesn't
take this into account when using it, and will pass unaligned ranges
ultimately freeing a PTE range larger than expected.
Take for example a mapping with the following iov_pfn range [0x3fe400,
0x4c0600), which should be backed by the following mappings:
iov_pfn [0x3fe400, 0x3fffff] covered by 2MiB pages
iov_pfn [0x400000, 0x4bffff] covered by 1GiB pages
iov_pfn [0x4c0000, 0x4c05ff] covered by 2MiB pages
Under this circumstance, __domain_mapping() will pass [0x400000, 0x4c05ff]
to switch_to_super_page() at a 1 GiB granularity, which will in turn
free PTEs all the way to iov_pfn 0x4fffff.
Mitigate this by rounding down the iov_pfn range passed to
switch_to_super_page() in __domain_mapping()
to the target large page level.
Additionally add range alignment checks to switch_to_super_page.
Fixes: 9906b9352a ("iommu/vt-d: Avoid duplicate removing in __domain_mapping()")
Signed-off-by: Eugene Koira <eugkoira@amazon.com>
Cc: stable@vger.kernel.org
Reviewed-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/20250826143816.38686-1-eugkoira@amazon.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
zpci_get_iommu_ctrs() returns counter information to be reported as part
of device statistics; these counters are stored as part of the s390_domain.
The problem, however, is that the identity domain is not backed by an
s390_domain and so the conversion via to_s390_domain() yields a bad address
that is zero'd initially and read on-demand later via a sysfs read.
These counters aren't necessary for the identity domain; just return NULL
in this case.
This issue was discovered via KASAN with reports that look like:
BUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device
when using the identity domain for a device on s390.
Cc: stable@vger.kernel.org
Fixes: 64af12c6ec ("iommu/s390: implement iommu passthrough via identity domain")
Reported-by: Cam Miller <cam@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Tested-by: Cam Miller <cam@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Link: https://lore.kernel.org/r/20250827210828.274527-1-mjrosato@linux.ibm.com
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
