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

[bz]

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.

[emaste]

sys/compat/linuxkpi/common/src/linux_devcorefile.c

220

git apply complained about extra EOF whitespace

[emaste]

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

[jhb]

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.

[jhb]

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.

[bz]

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.