LinuxKPI: dev_coredump implementation (NOT FOR COMMIT AS-IS)
Needs ReviewPublic
Actions

Authored by bz on Feb 3 2024, 1:08 PM.

Details

Reviewers: None

Summary

Implement the ability (for the S/G case only for now as that is what
was needed for iwlwifi(4)) to write device driver core files, usually
dumping firmware state.

This is modelled after our core(5) code currently and has a hardcoded
directory prefix (/var/crash) and some other omissions.
See comment in the file for what we likely should do.

Any suggestions for improvements are welcome, especially if we really
can get rid of all this "magic" for opening a file from within the kernel.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 55773
Build 52662: arc lint + arc unit

Event Timeline

bz created this revision.Feb 3 2024, 1:08 PM

Herald added subscribers: emaste, imp. · View Herald TranscriptFeb 3 2024, 1:08 PM

bz requested review of this revision.Feb 3 2024, 1:08 PM

Harbormaster completed remote builds in B55773: Diff 133787.Feb 3 2024, 1:09 PM

emaste added inline comments.Nov 26 2025, 12:58 AM

sys/compat/linuxkpi/common/src/linux_devcorefile.c
220	`git apply` complained about extra EOF whitespace

Writing seems fairly straightforward but indeed would be nice to have centralized infrastructure for it.

jhb added inline comments.Jan 28 2026, 10:03 PM

sys/compat/linuxkpi/common/src/linux_devcorefile.c
143	You could use a sysctl or some such for this perhaps?
153	You should assign `cred` before here so you can use it here as well to be consistent.
160	Is this really the right credential? In particular, suppose the driver does this during a system call executed by a user process. I think I'd rather have the file owned by root:wheel always instead of owned by some random user since the firmware core might contain data from other processes. My suggestion would be to use `proc0->p_ucred` instead.
189	This is fine, just add a comment that you are setting the NODUMP flag unconditionally.

The magic of vn_open_cred() is probably not something that will go away.

sys/compat/linuxkpi/common/src/linux_devcorefile.c
160	Using `proc0` also avoids problems with jailed processes that perform a system call and trigger this path.

I'll use the momentum. Would it make sense to add something like this to sys/kern and only driver it from LinuxKPI so it could be used for something else as well?

I still feel highly uncomfortable with the way it is but ... I don't live in VOP-lands.