User Details
- User Since
- Apr 1 2021, 3:21 AM (160 w, 8 h)
Thu, Apr 18
Tue, Apr 16
Mon, Apr 15
Fri, Apr 12
Wed, Apr 10
Looks good to me.
Tue, Apr 9
What about stub functions for !NUMA ?
For example, converting
static inline int vm_page_domain(vm_page_t m) { #ifdef NUMA int domn, segind;
Mon, Apr 8
Bite out the translation for errors from kernel linker.
I think I see what you meant. I'll try that.
As for
with a signature allowing to pass back a text describing the error.
I think that is perfect, but given linker_load_module() can be called recursively, the signature should be designed carefully. IMO a failure from kernel linkers should be rare thus one of the above simpler fixes should be adequate. It is not perfect but user can still get the real reason from dmesg or /var/log/message.
I would just give up on that in that revision, this would be a separate change anyway, way more useful to users than just returning EUNSDEP, but it requires some (hopefully short) design discussion. This way, we also stop delaying the current change, which is useful to users on its own, and that I personally would like to see in, e.g., 14.1-RELEASE.
As propagation error from other subsystem is a common issue. Actually languages such as C++ / Java do that well. Those languages have type exception and exceptions can be wrapped up ( nested exceptions ). I think C can mimic but that is not elegance IMO.
+1 for 14.1-RELEASE .
Sun, Apr 7
Looks good to me.
Fri, Apr 5
I spotted this while working on D44581 which intends to introduce new kernel-only error code EUNSDEP and on D44552 which uses it.
As in D44552 kern_kldload() will return the new error. It should not be leaked to the userspace. I was evaluating the impact and @olce pointed out the macro request_module is consuming kern_kldload().
Thu, Apr 4
@olce
As a side effect, the error from kern_kldload() is lost, so I think you are right , we should emit logs from kernel about the error, to help diagnosing.
Wed, Apr 3
Sorry for that.
After carefully checking, I can conclude it is safe to move the translation to sys_kldload(), as consumers of kern_kldload() either have done the translation themself, or totally ignore the return value, e.g. request_module in sys/compat/linuxkpi/common/include/linux/kmod.h, [1] and [2]. For the latter the current change will not make it worse.
I agree with the second part (some ignore the return value, so don't really care), but not with the first. Unless I'm mistaken, there are almost direct return paths to userland in these two cases:
- vfs_byname_kld()
Rechecked this, CURRENT and stable/14 vfs_byname_kld() has translated error to ENODEV. As for stable/13 it will be leaked.
- ngc_send()
ngcontrol_protosw.pr_send == ngc_send so EUNSDEP will be leaked. Really sorry I did not read the code carefully.
so EUNSDEP is going to be leaked.
Could you revert that modification? In other words, kern_kldload() still should translate the error itself, for now.
Another option could be refactor linker_file_unload() into two functions. One for normal unload and another is for abnormal ones such as unloading partially linked file.
Almost all abnormal unload requires the flag LINKER_UNLOAD_FORCE and at that moment the reference count of file should be right one. The logic will be much clear.
Tue, Apr 2
The only in-tree consumers of kld_unload_try and kld_unload even handlers are sdt and dtrace. Hopefully these even handlers are not abused by out-tree consumers.
Mon, Apr 1
Address @imp 's comments.
Move translating errno EUNSDEP from kern_kldload() to sys_kldload()
Stop translating errno from linker_reference_module() .
Moved the errno into sys/sys/errno.h, see D44581 .
Hi @imp , does this need broader attention ?
Sun, Mar 31
Looks good to me.
Fri, Mar 29
Made a reverse call graph to help evaluating the impact of this change:
linker_load_dependencies() --> linker_load_module() LINKER_LOAD_FILE() linker_load_file() linker_load_module() linker_reference_module() loadimage() TASK_INIT(&fwload_task, 0, loadimage, (void *)&fwli) kern_kldload() # syscall from userland
Wed, Mar 27
Mar 26 2024
Mar 24 2024
Looks good to me.
Generally looks good to me.
Looks good to me.
Looks good to me.
Mar 23 2024
Looks good to me.