If CONFIG_ACPI_PROCESSOR_IDLE=n, acpi_processor_register_idle_driver()
and acpi_processor_unregister_idle_driver() are never used and the
empty stubs of them are not needed. Moreover, they cause the compiler
to complain [1], so remove them.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202508300519.tZQHY6HA-lkp@intel.com/ [1]
Fixes: 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle driver registration")
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Link: https://patch.msgid.link/20250905081900.663869-2-lihuisong@huawei.com
[ rjw: Changelog rewrite ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the case user trigger tags grow by queue sysfs attribute nr_requests,
hctx->sched_tags will be freed directly and replaced with a new
allocated tags, see blk_mq_tag_update_depth().
The problem is that hctx->sched_tags is from elevator->et->tags, while
et->tags is still the freed tags, hence later elevator exit will try to
free the tags again, causing kernel panic.
Fix this problem by replacing et->tags with new allocated tags as well.
Noted there are still some long term problems that will require some
refactor to be fixed thoroughly[1].
[1] https://lore.kernel.org/all/20250815080216.410665-1-yukuai1@huaweicloud.com/
Fixes: f5a6604f7a ("block: fix lockdep warning caused by lock dependency in elv_iosched_store")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Li Nan <linan122@huawei.com>
Link: https://lore.kernel.org/r/20250821060612.1729939-3-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Current depth_updated has some problems:
1) depth_updated() will be called for each hctx, while all elevators
will update async_depth for the disk level, this is not related to hctx;
2) In blk_mq_update_nr_requests(), if previous hctx update succeed and
this hctx update failed, q->nr_requests will not be updated, while
async_depth is already updated with new nr_reqeuests in previous
depth_updated();
3) All elevators are using q->nr_requests to calculate async_depth now,
however, q->nr_requests is still the old value when depth_updated() is
called from blk_mq_update_nr_requests();
Those problems are first from error path, then mq-deadline, and recently
for bfq and kyber, fix those problems by:
- pass in request_queue instead of hctx;
- move depth_updated() after q->nr_requests is updated in
blk_mq_update_nr_requests();
- add depth_updated() call inside init_sched() method to initialize
async_depth;
- remove init_hctx() method for mq-deadline and bfq that is useless now;
Fixes: 77f1e0a52d ("bfq: update internal depth state when queue depth changes")
Fixes: 39823b47bb ("block/mq-deadline: Fix the tag reservation code")
Fixes: 42e6c6ce03 ("lib/sbitmap: convert shallow_depth from one word to the whole sbitmap")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Li Nan <linan122@huawei.com>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Link: https://lore.kernel.org/r/20250821060612.1729939-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAmi7AksUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXMmaA/8ChtRoaZFLTFI7UTWmVo0aY7NDl77
fqjwY1ZrPsqezLYt317LCJareQOfn1/NEc1Xxb7Caz6Z35eQPUDeUnd96zEarzDL
4iYcZA1MJVO2jjnyj4lqVoSgkftQPN6qvga5osA9mMOQ24mNPAO5yZIVdzL/sekv
ewosheC6spwFD26+/uWE00sdVRhtOnUPkLmelf4wyN0WX+lStTXozLpSW1Pr0FB1
tZI/mjLyVmZ+YJtTMCMLhpM/hFIMymlSr7BZ7pO/G1w48OGzVBdUlS45bS5rMUIQ
D/MdTB2YlkMOYFyRCgoSgxaFHGHf7F6MQO0J7y/hVu2QSvGoxneUaTIszpaj7rcg
edaJKogA6DlXvauw32UQhjUTQetuppyFqAHQXsec/JVYGUJqAZWNdsThP86MGlim
INwspptaBwOULg2OTYt/+jHblbhl8BI9ayC/S4lN89MCwszLYoFmjIo+mCf9qWfE
uFsiyvvqoXaMKH/e4NkcUjT0AxzwAHF0DwU7Vh+apThOpdr7Qudr6meWEgJ+iRpO
hhWrpyPAP1pann7VebwAqWs9iG97cuwARca4EWyuSy+i11qLQ19LwC/i5vfb58TJ
Ozh9g01A65qWgA5/G14XWmN1oLYdWK+KqwmdTXtDgWXZ5hX3oMrlypRxbPxKIyVG
PsEKU7GXjze/J1s=
=g/UF
-----END PGP SIGNATURE-----
Merge tag 'audit-pr-20250905' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit
Pull audit fix from Paul Moore:
"A single small audit patch to fix a potential out-of-bounds read
caused by a negative array index when comparing paths"
* tag 'audit-pr-20250905' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit:
audit: fix out-of-bounds read in audit_compare_dname_path()
Otherwise if the nfsd filecache code releases the nfsd_file
immediately, it can trigger the BUG_ON(cred == current->cred) in
__put_cred() when it puts the nfsd_file->nf_file->f-cred.
Fixes: b9f5dd57f4 ("nfs/localio: use dedicated workqueues for filesystem read and write")
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Reviewed-by: Mike Snitzer <snitzer@kernel.org>
Link: https://lore.kernel.org/r/20250807164938.2395136-1-smayhew@redhat.com
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Add the ability to dump BPF program instructions directly from veristat.
Previously, inspecting a program required separate bpftool invocations:
one to load and another to dump it, which meant running multiple
commands.
During active development, it's common for developers to use veristat
for testing verification. Integrating instruction dumping into veristat
reduces the need to switch tools and simplifies the workflow.
By making this information more readily accessible, this change aims
to streamline the BPF development cycle and improve usability for
developers.
This implementation leverages bpftool, by running it directly via popen
to avoid any code duplication and keep veristat simple.
Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250905140835.1416179-1-mykyta.yatsenko5@gmail.com
The intel_pstate driver does not enable HWP mode when CPUID.06H:EAX[10]
is not set, indicating that EPP (Energy Performance Preference) is not
supported by the hardware.
When EPP is unavailable, the system falls back to using EPB (Energy
Performance Bias) if the feature is supported. However, since the
intel_pstate driver will not enable HWP in this scenario, any EPB-related
code becomes unreachable and irrelevant. Remove the EPB handling code
paths simplifying the driver logic and reducing code size.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20250904000608.260817-1-srinivas.pandruvada@linux.intel.com
[ rjw: Subject adjustment ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since strcpy() is deprecated and the last user of it in the thermal
subsystem is thermal_hwmon_lookup_by_type(), replace strcpy() in that
function with strscpy().
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Link: https://patch.msgid.link/20250903192059.11353-1-osama.abdelkader@gmail.com
[ rjw: Changelog rewrite ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Follow cleanup.h recommendations and define and assign a variable
in one statement when __free() is used.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Link: https://patch.msgid.link/2251447.irdbgypaU6@rafael.j.wysocki
Follow cleanup.h recommendations and always define and assign variables
in one statement when __free() is used.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/4691667.LvFx2qVVIh@rafael.j.wysocki
Follow cleanup.h recommendations and always define and assign variables
in one statement when __free() is used.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/5934556.DvuYhMxLoT@rafael.j.wysocki
If system suspend is aborted in the "noirq" phase (for instance, due to
an error returned by one of the device callbacks), power.is_noirq_suspended
will not be set for some devices and device_resume_noirq() will return
early for them. Consequently, noirq resume callbacks will not run for
them at all because the noirq suspend callbacks have not run for them
yet.
If any of them has power.must_resume set and late suspend has been
skipped for it (due to power.smart_suspend), early resume should be
skipped for it either, or its state may become inconsistent (for
instance, if the early resume assumes that it will always follow
noirq resume).
Make that happen by clearing power.must_resume in device_resume_noirq()
for devices with power.is_noirq_suspended clear that have been left in
suspend by device_suspend_late(), which will subsequently cause
device_resume_early() to leave the device in suspend and avoid
changing its state.
Fixes: 0d4b54c6fe ("PM / core: Add LEAVE_SUSPENDED driver flag")
Link: https://lore.kernel.org/linux-pm/5d692b81-6f58-4e86-9cb0-ede69a09d799@rowland.harvard.edu/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/3381776.aeNJFYEL58@rafael.j.wysocki
Change the return type of the speedstep_get_freqs() function from unsigned
int to int because it may return negative error codes. For the same
reason, change the 'ret' variables to int type as well.
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20250902114545.651661-4-rongqianfeng@vivo.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change the 'ret' variable in store_scaling_setspeed() from unsigned int to
int, as it needs to store either negative error codes or zero returned
by kstrtouint().
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20250902114545.651661-2-rongqianfeng@vivo.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ahead of the 2025 LTS kernel, disable by default the two features that
we promised to turn off in September 2025: V4 filesystems, and the
long-broken ASCII case insensitive directories.
Since online fsck has not had any major issues in the 16 months since it
was merged upstream, let's also turn that on by default.
With a bit of luck, this should all go splendidly.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCaLsHjgAKCRBKO3ySh0YR
ph/zAQDlcdAuhW/zrAqVgY79Lmtq1qVCMivrKiabSFG7yBintwEAjlzb5k3mwBAW
DUfyFOdpm1Qv/xEmeLLYCVH4VS8yGgk=
=8sPi
-----END PGP SIGNATURE-----
Merge tag 'kconfig-2025-changes_2025-09-05' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.18-merge
xfs: kconfig and feature changes for 2025 LTS [6.18 v2 2/2]
Ahead of the 2025 LTS kernel, disable by default the two features that
we promised to turn off in September 2025: V4 filesystems, and the
long-broken ASCII case insensitive directories.
Since online fsck has not had any major issues in the 16 months since it
was merged upstream, let's also turn that on by default.
With a bit of luck, this should all go splendidly.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
A few months ago, the multi-fsblock untorn writes patchset added a bunch
of log intent item helper functions to estimate the number of intent
items that could be added to a particular transaction. Those helpers
enabled us to compute a safe upper bound on the number of blocks that
could be written in an untorn fashion with filesystem-provided out of
place writes.
Currently, the online fsck code employs static limits on the number of
intent items that it's willing to accrue to a single transaction when
it's trying to reap what it thinks are the old blocks from a corrupt
structure. There have been no problems reported with this approach
after years of testing, but static limits are scary and gross because
overestimating the intent item limit could result in transaction
overflows and dead filesystems; and underestimating causes unnecessary
overhead.
This series uses the new log intent item size helpers to estimate the
limits dynamically based on worst-case per-block repair work vs. the
size of the scrub transaction. After several months of testing this,
there don't seem to be any problems here either.
v2: rearrange patches, add review tags
This has been running on the djcloud for months with no problems. Enjoy!
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCaLsHjgAKCRBKO3ySh0YR
pvmYAP9kqz/fFRwmU8Stc384u/MA1OewBpohIjjcoGL8W36VLQD8DofFiY/K7yfB
w4KUsJWk//uHFU31iRRKKp8+FCjKtgU=
=03sf
-----END PGP SIGNATURE-----
Merge tag 'fix-scrub-reap-calculations_2025-09-05' of https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.18-merge
xfs: improve online repair reap calculations [6.18 v2 1/2]
A few months ago, the multi-fsblock untorn writes patchset added a bunch
of log intent item helper functions to estimate the number of intent
items that could be added to a particular transaction. Those helpers
enabled us to compute a safe upper bound on the number of blocks that
could be written in an untorn fashion with filesystem-provided out of
place writes.
Currently, the online fsck code employs static limits on the number of
intent items that it's willing to accrue to a single transaction when
it's trying to reap what it thinks are the old blocks from a corrupt
structure. There have been no problems reported with this approach
after years of testing, but static limits are scary and gross because
overestimating the intent item limit could result in transaction
overflows and dead filesystems; and underestimating causes unnecessary
overhead.
This series uses the new log intent item size helpers to estimate the
limits dynamically based on worst-case per-block repair work vs. the
size of the scrub transaction. After several months of testing this,
there don't seem to be any problems here either.
v2: rearrange patches, add review tags
This has been running on the djcloud for months with no problems. Enjoy!
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Since commit e0b3165ba5 ("cpufreq: add 'freq_table' in struct
cpufreq_policy"), freq_table has been stored in struct cpufreq_policy
instead of being maintained separately.
However, several helpers in freq_table.c still take both policy and
freq_table as parameters, even though policy->freq_table can always be
used. This leads to redundant function arguments and increases the
chance of inconsistencies.
This patch removes the unnecessary freq_table argument from these
functions and updates their callers to only pass policy. This makes
the code simpler, more consistent, and avoids duplication.
Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/20250902073323.48330-1-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmi6TgUACgkQiiy9cAdy
T1GKNAwAwiUm61g8gGpJKN5yibpGitEF0NtZbUvdWbeySg5JM4MpkdkzAmHGOOw+
0t+1Gr8J5KQFW25YWh8cuA5enrzuGBliTMfYpevh0q8zsF6GWvxr44mVSl2zUSRf
PSQrgR4s2MKjGGpVlcdFjTJkC6De98BQffo/bQPVEuXmsN81PYDWAceO/0bFBK9J
IY1nJxsMpkfo8/MrgO8W40PsH39jZCXiYNoisOVUpiAWKuwNber2jWrbsfrEFR7Z
vRT2cuna2qgiXW7mEtdvcgO4srpjXJ1aZmTcaIszxljUgfKbeqAzplxq03XD5lBH
UEFUIwAe993bEnZYmRIq9hTHeKdcR1wa5UJoM1B82BA7VsaWUwrl9EKV0qg+rKHd
jvPKS1KpBOxhAnjcFF7N1w2gk5LCmeu5WS6f3/XlrOSPSnFzfIdigGanJpV60qPM
pFIbLPCxXVt1TkPHe0cdy5pHPpQYBR/l1EuzLd1zJ8lFVSGkV78DlW0FudYA2OaO
pg8zd8Kd
=UcJl
-----END PGP SIGNATURE-----
Merge tag '6.17-RC4-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull smb client fixes from Steve French:
- Fix two potential NULL pointer references
- Two debugging improvements (to help debug recent issues) a new
tracepoint, and minor improvement to DebugData
- Trivial comment cleanup
* tag '6.17-RC4-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: prevent NULL pointer dereference in UTF16 conversion
smb: client: show negotiated cipher in DebugData
smb: client: add new tracepoint to trace lease break notification
smb: client: fix spellings in comments
smb: client: Fix NULL pointer dereference in cifs_debug_dirs_proc_show()
- ina238: Various value range fixes when writing limit attributes
- mlxreg-fan: Prevent fans from getting stuck at 0 RPM
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmi7Fo8ACgkQyx8mb86f
mYG1Hg/+JniJ+6QLJ7PFADv5WCX/HBRt9LtupFENjdn6uHBWUWsUSDVMKsNy6v5j
ErPE0FitAg/fNSm++Bueb2bmfYYtE4YG5gMHIgsztIGL8j6kpUrafadkELaccKQD
hB9XT0RDvQ92qVjbB0qG6/7YC2s1V+p6tpW4CwKG2349YHuQl8rpzo8IMLPkU7Ex
6U/VuC6nCxKAYPwDHjKohMFoBZcu+hDnpLJqWB/wkk1ihlLVnZ10Clv8Vq4jVUn5
2HKvwwvlTfEzhZ4E9cLEgJBOKmudZNGy+N6xjMlAqXWS3yH2lF6uP8dYl8xwDIi1
2/PLpW2bp5fnZv8ZszQX1X66BWLjiRPFApOIAgeCUL/GpyLsZrB8CUpkD43dJKzw
zPc7X9A0qRUuWtAfAlW81er4pwtoaJXHp+gwddkhgf1SzKQhFn4LE4DkeNRDZpIe
Ig2j1ut2valRIBwNq6YOCqzf0NhSrDR8UsppmGHMt5tZzHbC78NMo0hSO7NFvEPO
tUXFiKamlRGFx2QEVJvyYriFLyQp42mNisIwVMkyO+nSZ8tPiwQ/G/XMG/OvDlW6
58tM87lJQEh20A+u/HzIEbuyniyqJs3y0U0NnmxYhJqas9/9eUYVgIZxd9GWWE5l
i+BallpZ2jvP36Zpei69y3vymFeWWgLnxfderATbgB0387OIWbk=
=scpq
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- ina238: Various value range fixes when writing limit attributes
- mlxreg-fan: Prevent fans from getting stuck at 0 RPM
* tag 'hwmon-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (ina238) Correctly clamp power limits
hwmon: (ina238) Correctly clamp shunt voltage limit
hwmon: (ina238) Correctly clamp temperature
hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM
The callback functions for line conversion are almost identical for
semi-planar formats. The generic READ_LINE_YUV_SEMIPLANAR macro
generate all the required boilerplate to process a line from a
semi-planar format.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-7-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-6-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The formats XRGB16161616 and ARGB16161616 were already supported.
Add the support for:
- ABGR16161616
- XBGR16161616
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-3-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The formats XRGB8888 and ARGB8888 were already supported. Add the
support for:
- XBGR8888
- ABGR8888
- RGBA8888
- BGRA8888
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-2-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The callback functions for line conversion are almost identical for
some format. The generic READ_LINE macro generate all the required
boilerplate to process a line.
Two overrides of this macro have been added to avoid duplication of
the same arguments every time.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-1-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Commit 15ae0410c37a79 ("btrfs-progs: add error handling for
device_get_partition_size_fd_stat()") in btrfs-progs inadvertently
changed it so that if the BLKGETSIZE64 ioctl on a block device returned
a size of 0, this was no longer seen as an error condition.
Unfortunately this is how disconnected NBD devices behave, meaning that
with btrfs-progs 6.16 it's now possible to add a device you can't
remove:
# btrfs device add /dev/nbd0 /root/temp
# btrfs device remove /dev/nbd0 /root/temp
ERROR: error removing device '/dev/nbd0': Invalid argument
This check should always have been done kernel-side anyway, so add a
check in btrfs_init_new_device() that the new device doesn't have a size
less than BTRFS_DEVICE_RANGE_RESERVED (i.e. 1 MB).
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Mark Harmstone <mark@harmstone.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
On TDX platforms, during kexec, the kernel needs to make sure there
are no dirty cachelines of TDX private memory before booting to the new
kernel to avoid silent memory corruption to the new kernel.
To do this, the kernel has a percpu boolean to indicate whether the
cache of a CPU may be in incoherent state. During kexec, namely in
stop_this_cpu(), the kernel does WBINVD if that percpu boolean is true.
TDX turns on that percpu boolean on a CPU when the kernel does SEAMCALL,
Thus making sure the cache will be flushed during kexec.
However, kexec has a race condition that, while remaining extremely rare,
would be more likely in the presence of a relatively long operation such
as WBINVD.
In particular, the kexec-ing CPU invokes native_stop_other_cpus()
to stop all remote CPUs before booting to the new kernel.
native_stop_other_cpus() then sends a REBOOT vector IPI to remote CPUs
and waits for them to stop; if that times out, it also sends NMIs to the
still-alive CPUs and waits again for them to stop. If the race happens,
kexec proceeds before all CPUs have processed the NMI and stopped[1],
and the system hangs.
But after tdx_disable_virtualization_cpu(), no more TDX activity
can happen on this cpu. When kexec is enabled, flush the cache
explicitly at that point; this moves the WBINVD to an earlier stage than
stop_this_cpus(), avoiding a possibly lengthy operation at a time where
it could cause this race.
[1] https://lore.kernel.org/kvm/b963fcd60abe26c7ec5dc20b42f1a2ebbcc72397.1750934177.git.kai.huang@intel.com/
[Make the new function a stub for !CONFIG_KEXEC_CORE. - Paolo]
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>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
Link: https://lore.kernel.org/all/20250901160930.1785244-8-pbonzini%40redhat.com
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>
