| Age | Commit message (Collapse) | Author |
|---|
|
vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides
no matching drm_kms_helper_poll_fini(). The output poll work stays
scheduled after unbind and runs on the freed drm_device:
# modprobe vc4; rmmod vc4; sleep 10
BUG: KASAN: slab-use-after-free in delayed_work_timer_fn
BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm]
Workqueue: events output_poll_execute [drm_kms_helper]
Allocated by task 171: __devm_drm_dev_alloc
Freed by task 262 (rmmod): drm_dev_put / component_del
Use drmm_kms_helper_poll_init() so polling is finalized with the device,
as other drivers do.
Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260822143110.68594-1-kmehltretter@gmail.com
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
Improve and move diagnostics messages to the helper function to
keep the caller function tidy.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260911182306.14973-1-michal.wajdeczko@intel.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm firmware fixes for v7.3
SCPI fixes address resource leaks and invalid firmware responses, while
FF-A gains shutdown cleanup needed for normal kexec.
- Release the device node reference acquired during SCPI domain lookup.
- Validate SCPI DVFS OPP counts and indices returned by firmware to
prevent out-of-bounds accesses and invalid clock rates.
- Register the SCPI cpufreq device only once across DVFS providers,
preserving the registered device pointer for cleanup and allowing
retries after registration failure.
- Run FF-A teardown during orderly shutdown so notifications, partition
devices and RX/TX mappings are released before a replacement kernel
boots through normal kexec.
Also includes replacing a literal platform device ID with
PLATFORM_DEVID_NONE and correcting an SCMI comment typo.
* tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix typo "upto" in comment
firmware: arm_ffa: Tear down driver during shutdown
clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq
clk: scpi: register scpi-cpufreq once and clear on failure
clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate
firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS
firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes
Renesas fixes for v7.3
- Fix Ethernet stalls on RZ/V2H, RZ/V2N, RZ/G3E, RZ/T2H, and RZ/N2H.
* tag 'renesas-fixes-for-v7.3-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR
arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR
arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR
arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR
arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes
SoCFPGA DTS fix for v7.3
- Fix DTS file access permissions
* tag 'socfpga_dts_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
arm64: dts: socfpga: change access permission from 755 to 644
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes
SoCFPGA fix for v7.3
- Fix PL310_ERRATA_753970 Kconfig option
* tag 'socfpga_fix_for_v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
ARM: socfpga: select the PL310 erratum 753970 workaround
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The rt2x00 PCI and USB probe paths allocate EEPROM and RF storage with
plain kzalloc() and then free it from bus-specific teardown helpers. The
USB path also manages the CSR cache the same way. These buffers are
tied to the device lifetime, so the explicit free paths add probe and
disconnect cleanup without providing separate ownership.
Allocate the buffers with devm_kzalloc() before the mac80211 hardware is
allocated, then attach the resulting storage to struct rt2x00_dev after
the driver-private state exists. This lets driver detach and probe
failure rely on device-managed cleanup and removes the duplicated
bus-specific buffer freeing.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260904211628.83180-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, struct xe_i2c is freed before SGUnit IRQ is disabled in unbind
path, leaving a potential UAF in case I2C IRQ is hit during this small
window. Explicitly disable I2C IRQ in xe_i2c_remove() and fix this.
Fixes: 0bb78ce09926 ("drm/xe/i2c: Wire up reset/postinstall for I2C IRQ")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260911121547.2407261-1-raag.jadav@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
The last usage of the functions drm_class_device_register() and
drm_class_device_unregister() was removed in commit ed89fff97382
("drm/ttm: drop sysfs directory").
Remove such functions as they are no longer used.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260803132706.1497980-2-mcanal@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
`reset_lock` was taken by v3d_gpu_reset_for_timeout() to keep the
timeout handlers of different queues from parking the schedulers and
resetting the GPU at once. Now that all of the queues share an ordered
workqueue for their timeout work, those handlers can no longer run
concurrently and the lock guards nothing.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20260728-v3d-order-global-reset-v1-2-e47be838158d@igalia.com
|
|
Whilst the comment is correct DisCo does use upper-case for hex numbers
the number being printed here is decimal so the comment is rather
redundant.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260914131621.1461514-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This is a very old driver, and no known hardware is still around for it,
and the company says they do not need it anymore, so let's remove it as
the LLMs are starting to poke at it and find "interesting" things which
will just waste everyone's time given it's not actually used.
So let's drop it. If someone really needs it, it can come back in the
future, in a more "modern" way, as the style here is very old...
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/all/afqyY8FQ8ZfpH48_@moxa-ThinkCentre-M90t/
Acked-by: Crescent Hsieh <crescentcy.hsieh@moxa.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://patch.msgid.link/20260804-x-remove-moxa-v2-1-947c039b66e8@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
By enlisting list_count_nodes(), a recent addition to the list.h, the
code responsible for manual counting of the HDAudio PCMs can be dropped.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260914101917.2969665-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
By enlisting list_count_nodes(), a recent addition to the list.h, the
code responsible for manual counting of the HDAudio PCMs can be dropped.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260914101917.2969665-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Agilex5 SoCDK eMMC daughter card wires the shared HPS SD6HC to an
8-bit onboard eMMC with fixed 3.3 V VCC and 1.8 V I/O, supporting HS200
and HS400. The board also brings up GMAC0, I2C, I3C, LEDs, and the UART.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Document the Agilex5 SoCDK with the eMMC daughter card, which uses the
shared HPS SD/eMMC host for onboard eMMC instead of an SD slot.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
On the SOCDK OOBE card the slot is SD-only: a fixed 3.3 V card supply
and a GPIO-selected 3.3 V / 1.8 V I/O supply for UHS-I signalling up
to SDR104.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The Agilex5 HPS includes a Cadence SD6HC that can drive either an SD
card or eMMC. It uses separate SDMCLK (CIU) and L4_MP (BIU) clocks, and
has three resets for the host controller, Combo PHY, and SDMMC OCP
bridge.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Add the fpga-mgr child node under the svc firmware node and a fpga-region
node to enable FPGA configuration and partial reconfiguration on Agilex5.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
These files have an incorrect access permission of 755 instead of 644.
Change them to the correct access permission of 644.
Fixes: 4bc04eb90b7c ("arm64: dts: socfpga: stratix10: Add emmc support")
Cc: <stable@vger.kernel.org> # v7.1+
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
ARCH_INTEL_SOCFPGA selects CACHE_L2X0 and several PL310 erratum
workarounds. The 753970 workaround is still conditioned on PL310, but that
Kconfig symbol no longer exists, so this one selection is always disabled.
Select PL310_ERRATA_753970 directly, consistently with the other PL310
workarounds required by the platform.
Fixes: fbc125afdc50 ("ARM: socfpga: Turn on ARM errata for L2 cache")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Factor out a new coredump_wait_inactive() helper that
COREDUMP_CLOSE_FILES can consume in a bit.
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-13-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
coredump_wait() sets core_state->nr_threads to the number of tasks
killed and waits for the last thread to enter coredump_task_exit() to
signal completion. Let's just wait on the count directly. The exiting
tasks can use atomic_dec_and_wake_up() and the dumping task sleeps in
wait_var_event_state().
The dumping task must remain freezable since commit f5d39b020809
("freezer,sched: Rewrite core freezer logic"). So keep the wait
TASK_UNINTERRUPTIBLE|TASK_FREEZABLE.
Drop the completion and rename nr_threads to threads_remaining.
No functional changes.
Suggested-by: NeilBrown <neilb@ownmail.net>
Link: https://lore.kernel.org/178899497961.207413.10554121774377911612@noble.neil.brown.name
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-12-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
All wait_var_event() sleep in a fixed task state. For coredumps we need
a variant that takes the state from the caller the way
wait_event_state() does. This allows us to continue sleeping with
TASK_FREEZABLE. That's certainly also a useful addition for other places.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-11-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
The core_state->dumper field isn't used anymore. Only its ->next pointer
is. The current task is always the dumping thread and the ->task pointer
is never read. Replace it with a plain pointer to the list of parked
threads.
Historically, core_state->dumper was used. Its ->task pointer was read.
by fill_note_info() started at &core_state->dumper to ensure that the
dumping thread came first in the ELF thread notes. That changed in
commit 4b0e21d64253 ("[elf][regset] simplify thread list handling in
fill_note_info()"). The first iteration was taken out of the loop. So
it's been unused ever since.
No functional changes.
Suggested-by: NeilBrown <neilb@ownmail.net>
Link: https://lore.kernel.org/178900159210.207413.8292125177519817528@noble.neil.brown.name
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-10-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Punting file closing to task work during exec slows down exec
significantly when its done with a bunch of file descriptors. We can
do this in-band instead. Flush already runs synchronous. Jann moved
close-on-exec in e780259b54e6 ("exec: do_close_on_exec() before taking
exec_update_lock") outside of exec_update_lock.
The only lock that's still held now is cred_guard_mutex. It's deprecated
and has five takers
(1) exec
(2) ptrace_attach()
(3) seccomp() with SECCOMP_FILTER_FLAG_TSYNC
(4) writes to /proc/<pid>/attr/*
(5) lsm_set_self_attr()
Four of them take the task's own cred_guard_mutex. When
close_cloexec_files() runs, de_thread() ensured that the calling task is
the only one alive in its thread-group. That leaves ptrace() waiting on
cred_guard_mutex of the tracee going through exec. exec already sleeps
under cred_guard_mutex in de_thread() when it reads binary and
interpreter. So while we add wait-time to an attaching ptracer no new
lock dependency is added. vfork() als waits but that's a dup_fd() copy
of the fdtable and rarely holds the last reference. If that's an issue
we can always change that later.
Link: https://lore.kernel.org/CAGudoHEsGP1P+sAWaw_tbh1NesJhSeww8869uzmaqtgk8F43=Q@mail.gmail.com
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-9-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Rename the helper and align it with close_files().
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-8-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
__range_close() closes through filp_close() so every file the caller
held the last reference to is punted to task work. That costs one
cmpxchg per file plus a list entry for any later task_work_cancel() to
search under ->pi_lock. close_range(2) exists to close many descriptors
in one go fast. So convert it to the same synchronous treatment as
close(2) and close_files().
Flush and put each file inline while ->file_lock is dropped.
close_range(2) now behaves like close(2).
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-7-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
When the last reference to a descriptor table is dropped close_files()
closes every file but punts the actual work to task work. For an exiting
task that task work only runs in exit_task_work().
Before commit 4a9d4b024a31 ("switch fput to task_work_add") fput() was
synchronous everywhere and exit released its files in exit_files().
The deferral made fput() safe from any context. And exit_files()
offloaded to task work as a side-effect. And that has downsides.
Oleg and Neil noticed that some time ago. A task that exits with a big
descriptor table ends up queueing a very large number of files on task
work. That leaves a list for any later task_work_cancel() to search
under ->pi_lock and costs a lot of atomics too.
Let close_files() close right away. Flush and put each file inline the
way close(2) does. The final __fput() runs during the table walk now
instead of from task_work_run() in exit_task_work(). One difference is
the order: task work ran the final __fput()s in reverse and now they run
in table order.
Every put of a dying table is synchronous now:
- exit_files()
- copy_process()
- close_range(CLOSE_RANGE_UNSHARE)
- unshare(2)
- exec
Kernel threads don't own a file descriptor table and exec already splats
were they to exec. kthreadd and every kthread share init_files and
init_task pins that forever.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-6-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Currently close() already does a synchronous release of the last
reference since the task is about to return to userspace and the
deferral through task work buys nothing. Add a filp_close_sync() helper.
We'll use that in the next patches.
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-5-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
exec is the only caller left since commit 433967cab51e ("coredump: stop
unsharing the file descriptor table"). All it does is call unshare_fd()
with CLONE_FILES and install the copy. Kill the pointless helper and
open-code it.
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-4-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Move unshare_fd() where the rest of the descriptor table lifecycle
helpers live.
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-3-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Add switch_files_struct() to install another table on a task. It
consumes the reference to the new table and puts the old one. Convert
every place that switches a descriptor table except unshare_files().
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-2-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
close_fd() takes the lock, calls file_close_fd_locked() and drops the
lock, which is exactly what file_close_fd() does. Use it.
No functional changes.
Link: https://patch.msgid.link/20260910-work-coredump-unlock-self-v4-1-a5c1800dc930@kernel.org
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Christian Brauner <brauner@kernel.org> says:
Currently /proc/<pid>/coredump_filter determines what types of memory
are included in a coredump produced by <pid>. This is fairly static. The
coredump server has no easy way to configure what memory to dump even
though it can figure out all the necessary details to make an informed
decision.
Add a new COREDUMP_MEMORY_TYPES feature bit. If the coredump server
raises it the kernel will dump memory types raised in the
coredump_ack->memory_types member. Zero is valid and causes the creation
of a coredump that just includes the program headers and notes but no
memory apart from the mappings that are always dumped.
struct coredump_req gains @memory_types which is set to the default
memory types that are included in the coredump. This can be overridden by
raising bits in coredump_ack->memory_types. It also gains
@memory_types_mask which contains a bitmask of all memory types the
kernel knows about. A coredump server may only raise bits in
coredump_ack->memory_types that are raised in
coredump_req->memory_types_mask.
struct coredump_ack grows too. If COREDUMP_MEMORY_TYPES is raised in
@mask the kernel dumps the memory types set in the @memory_types mask.
Zero is valid and dumps no memory apart from the mappings that are
always dumped. A coredump server wanting to add or drop memory types
instead of outright replacing it should simply copy
coredump_req->memory_types and then mask off or raise types as needed.
@memory_types must be zero if COREDUMP_MEMORY_TYPES isn't raised.
COREDUMP_MEMORY_TYPES requires COREDUMP_KERNEL and an ack of at least
COREDUMP_ACK_SIZE_VER1 bytes.
* patches from https://patch.msgid.link/20260821-work-coredump-filter-v1-0-91f9a73ef03e@kernel.org:
selftests/coredump: test failed handshakes
selftests/coredump: improve coredump size negotiation tests
selftests/coredump: test COREDUMP_MEMORY_TYPES
selftests/coredump: simplify the refusal tests
tools: sync coredump.h header
coredump: select memory types to include
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-0-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Add more coredump refusal tests.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-6-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Improve the size handling tests when negotiating a coredump through req
and ack.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-5-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Test the new COREDUMP_MEMORY_TYPES flag.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-4-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
coredump socket"
Christian Brauner <brauner@kernel.org> says:
A coredump generated via the coredump socket ends up transferring
zeroed data when a mapping contains holes. For a large process that
maps a bunch of data that's wasting a ton of work.
Jacob ran into this and Josef has bitched^wcomplained about this to me
before. I dislike the coredump_filter bit solution in [1] which stops
each PT_LOAD at the last populated page.
The problem is real though. I don't think coredump_filter is where we
need to solve this. That mask says which kinds of memory to include and
it propagates across fork and exec, whereas what is being selected here
is an encoding mechanism.
I also think that the usermodehelper - may it swiftly die - isn't really
salvagable for this and it's not the future anyway. The coredump socket
already has a handshake for stuff like this.
I always had an idea how this would look like but punted on it back
then. So here it is.
A server that raises COREDUMP_RECORDS in coredump_ack->mask doesn't get
the coredump as a plain byte stream but as a sequence of records. Each
one a struct coredump_record_header followed by what it describes. A
data record carries its bytes. If a server also raises COREDUMP_SPARSE,
zero records are sent for unpopulated mappings. They only indicate how
many zero bytes need to be written and do not include data. Reassembling
the records gives back the same coredump. A debugger and everything else
still see an ordinary core file and nothing outside the coredump server
has to learn anything.
Numbers from the selftests, on a kernel built from this series:
- a process with 128 threads: 1424153 bytes on the socket for a
coredump of 1075150848 bytes
- a 256MB mapping with the first and last page touched: 188793 bytes on
the socket for a coredump of 268890112 bytes
- the same 256MB mapping with COREDUMP_RECORDS alone: 271009312 bytes on
the socket, so the record overhead itself is under one percent
The first one is the interesting case. Almost all of it is thread stacks.
All stacks are 8MB reservations that are nearly all holes. And they are
holes in the middle of the dump rather than at the end.
Link: https://lore.kernel.org/all/20260731171336.2255844-1-jalalonde@meta.com [1]
* patches from https://patch.msgid.link/20260820-work-coredump-sparse-v2-0-ba32dd718c51@kernel.org: (21 commits)
selftests/coredump: show how to inspect the task to decide how the coredump should be sent
selftests/coredump: simulate a blob store
selftests/coredump: put a hole in the middle of a sparse mapping
selftests/coredump: hand the record stream to a sink
selftests/coredump: test COREDUMP_RECORDS and COREDUMP_SPARSE
coredump: describe the holes when COREDUMP_SPARSE is negotiated
coredump: send the coredump in records if requested
tools: sync coredump.h header
coredump: add COREDUMP_SPARSE to the coredump socket protocol
coredump: add COREDUMP_RECORDS to the coredump socket protocol
coredump: clean up coredump state handling
coredump: always chunk writes
coredump: make the dump helper return bool
coredump: deduplicate the to_skip flush
coredump: move the negotiated mask into struct coredump_params
coredump: pin the protocol struct sizes
selftests/coredump: add a separate helper header
selftests/coredump: collapse the expected request check into the helper
selftests/coredump: discard the right amount after the coredump request
coredump: set the minimum send buffer size
...
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-0-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
A couple of tests send a coredump_ack that the kernel refuses. They then
check the marker. Make sure they all use common infrastructure.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-3-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
should be sent
The kernel blocks in the coredump req until the coredump ack is sent by
the coredump server. This allows the coredump server to decide how the
kernel is supposed to send the coredump.
Let's show how that can work:
- a task that has a large memory mapping gets sent as a sparse record
stream
- a task with a trivial memory mapping gets sent as a plain byte stream
Since the threads are parked in coredump_task_exit() with their mm
around we can look at /proc/<pid>/statm to figure out what the task has
mapped.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-22-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Sync the headers for the selftests.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-2-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Currently /proc/<pid>/coredump_filter determines what types of memory
are included in a coredump produced by <pid>. This is fairly static. The
coredump server has no easy way to configure what memory to dump even
though it can figure out all the necessary details to make an informed
decision.
Add a new COREDUMP_MEMORY_TYPES feature bit. If the coredump server
raises it the kernel will dump memory types raised in the
coredump_ack->memory_types member. Zero is valid and causes the creation
of a coredump that just includes the program headers and notes but no
memory apart from the mappings that are always dumped.
struct coredump_req gains @memory_types which is set to the default
memory types that are included in the coredump. This can be overridden by
raising bits in coredump_ack->memory_types. It also gains
@memory_types_mask which contains a bitmask of all memory types the
kernel knows about. A coredump server may only raise bits in
coredump_ack->memory_types that are raised in
coredump_req->memory_types_mask.
struct coredump_ack grows too. If COREDUMP_MEMORY_TYPES is raised in
@mask the kernel dumps the memory types set in the @memory_types mask.
Zero is valid and dumps no memory apart from the mappings that are
always dumped. A coredump server wanting to add or drop memory types
instead of outright replacing it should simply copy
coredump_req->memory_types and then mask off or raise types as needed.
@memory_types must be zero if COREDUMP_MEMORY_TYPES isn't raised.
COREDUMP_MEMORY_TYPES requires COREDUMP_KERNEL and an ack of at least
COREDUMP_ACK_SIZE_VER1 bytes.
Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-1-91f9a73ef03e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
A coredump server that uploads to a blob store must redescribe the
coredump and fixup the phdr.
A segment is split wherever a hole was left out and everything a segment
covers past p_filesz is zeroes anyway. So the blob store ends up with an
ordinary ELF core file that is missing nothing but holes. Nothing
downstream of the server has to learn a container format.
The coredump with its holes still in it is reassembled alongside the
object so the two can be compared.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-21-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
The crashing_child_sparse() helper touches the first page of the
mapping. That forces everything behind it to be a trailing hole. This is
easy to handle. Make the test more difficult meaningful by also touchin
the last page. This causes the hole to sit between two populated pages.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-20-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Currently recv_coredump_records() parses the record stream and dumps it
into a file. A coredump server may want to process the data it gets. So
split the parsing from the processing.
No functional changes.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-19-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Test the new COREDUMP_RECORDS and COREDUMP_SPARSE flags.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-18-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Make use of COREDUMP_SPARSE. Refuse it without COREDUMP_RECORDS.
Actual holes are sent as a record with length indicating how much zero
data there was.
coredump_write() flushes a trailing hole if the coredump is done.
Instead of writing the actual byte for pipes and sockets, collapse it.
This stops wasting a header with coredump records for a single byte. So
we now only write it when the coredump can be seeked. TL;DR a trailing
hole is a zero record like any other and the records still cover the
whole coredump.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-17-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
When the coredump server raises COREDUMP_RECORDS send the coredump in
records. A record consists of a struct coredump_record_header and data.
A header and the bytes it describes go out in one iovec.
A hole is flushed through __dump_emit() like before. So zeroes still are
sent on the socket as actual data records. Making holes cheap is
COREDUMP_SPARSE's job.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-16-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
|
Sync the headers for the selftests.
Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-15-ba32dd718c51@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
|
