| Age | Commit message (Collapse) | Author |
|
|
|
|
|
_before_ the module's MODULE_CMD_INIT call. Also update the unload
code to invoke the sysctl_setup and evcnt stuff _after_ the module's
MODULE_CMD_FINI call. This makes the behaviour and order consistent
whether the module is built-in or loaded at run-time.
As reported by riastradh@
|
|
Modules that have not been audited for autounload safety don't
recognize the command MODULE_CMD_AUTOUNLOAD and return ENOTTY. These
modules are not safe to autounload, so don't autounload them. Since
unload is risky business (if not careful, can lead to use-after-free,
kernel memory corruption, &c.), it needs to be opt-in by default, not
opt-out.
Modules that have been audited can return 0 or EBUSY to explicitly
allow or deny autounload. Users who want to live on the edge to try
to exercise module autounload even for unaudited modules -- and are
willing to accept the consequences, and maybe contribute to auditing!
-- can set the new sysctl knob kern.module.autounload_unsafe=1.
Discussed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2022/08/08/msg028282.html
|
|
Needs more discussion. Maybe better with an opt-in mechanism to
replace the opt-out mechanism than by disabling it altogether by
default.
|
|
I don't know why this was ever enabled by default; many modules are
still not safe to unload, let alone autounload. If any autounload is
to happen by default, it should only be for modules that have opted
into it in some way after audit.
|
|
They are called in reverse topological order on unload.
dtrace_sdt will rely on this soon to ensure provider definitions are
processed before their uses.
ok chs@
|
|
|
|
|
|
|
|
cached value will do, or if the very latest total must be fetched. It can
be called thousands of times a second and fetching the totals impacts not
only the calling LWP but other CPUs doing unrelated activity in the VM
system.
|
|
|
|
/netbsd/modules respectively instead of /netbsd and
/stand/<arch>/<version>/modules. This is only supported for x86,
and is turned off by default. To try it, add KERNEL_DIR=yes in your
/mk.conf and install a system from that build.
|
|
module vs which was requested/wanted by the caller.
|
|
defined in a module, similar to the automatic invocation of sysctl(9)
setup functions. As requested by riastradh@
|
|
of the process that triggered the autoload, as well as its p_comm
and the status.
This is only triggered if you've requested DEBUG messages by setting
the kern.module.verbose sysctl(8) variable.
|
|
|
|
|
|
|
|
|
|
(and with major contributions from) riastradh@
Welcome to 9.99.23
|
|
Should fix the build break reported by martin@
|
|
module hook, we can share a common set of synchronization structures.
This cuts the amount of cacheline_aligned data for these structures by
50%.
Note that we still have a per-hook localcount, since we need to count
individual references.
As discussed with riastradh@
Welcome to 9.99.22 !
|
|
the module's modcmd(CMD_FINI) code. If the modcmd() call returns an
error, we attempted to re-instate the module's sysctl stuff.
This doesn't work well for built-in modulesi (where "unload" actually
means "disable"), since they don't have any ``struct kobj''.
So check first, and don't try to find the __link_set_sysctl_funcs for
built-in modules.
|
|
the list of routines that need to be called for setting up sysctl
variables. This worked great for all code included in the kernel
itself, but didn't deal with modules that want to create their own
sysctl data. So, we ended up with a lot of #ifdef _MODULE blocks
so modules could explicitly call their setup functions when loaded
as non-built-in modules.
So today, we complete the task that was started so many years ago.
When modules are loaded, after we've called xxx_modcmd(INIT...) we
check if the module contains its own __link_set_sysctl_funcs, and
if so we call the functions listed. We add a struct sysctllog member
to the struct module so we can call sysctl_teardown() when the module
gets unloaded. (The sequence of events ensures that the sysctl stuff
doesn't get created until the rest of the module's init code does any
required memory allocation.)
So, no more need to explicitly call the sysctl setup routines when
built as a loadable module.
|
|
module's name still being available - it may be destroyed when
kobj_affix() unloads the object. So make a copy of the name first
so we can use it in a useful error message.
(Without this, I've have affix errors go into an infinite loop
trying to print the error message!)
|
|
|
|
module name field to check when validation name's length. Second, check
the module's mi_class to ensure it is valid.
Update the commenet in sys/module.h to indicate that the module classes
are now being validated.
|
|
|
|
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
|
|
add a mechanism for registering callbacks to be called upon module load/unload.
|
|
doesn't help. The check really cannot fail, and it only looks at the list
belonging to the current level of recursion.
Instead, verify that the module's modcmd(MODULE_CMD_INIT, ...) does not
introduce a duplicate module name as a result of recursively calling
module_do_load().
|
|
|
|
to panic when I try to modload the 'ntfs' module.
|
|
XXX Pull-up to -8
|
|
with the same internal name but no conflicting symbol definitions.
When we load a module from the file system, the filename may have no
relationship to the internal module's name. Furthermore, comparing
the module's filename is insufficient if the file is loaded from an
absolute path.
XXX pullup to netbsd-8
|
|
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
|
|
something better.
|
|
|
|
|
|
|
|
|
|
Superfluous warnings in simple userland programs is not a valid reason to
break a security model.
|
|
This allows us to return EEXIST instead of EPERM for higher secure levels.
My use case was to stop npfctl complaining that it could not load bpfjit
on ERLITE when it was compiled into the kernel.
It then went on to complain that NPF performance would be de-graded,
but this is clearly not the case.
|
|
|
|
XXX: if a driver is built-in why can't it ask for a filesystem module to
be loaded?
|
|
|
|
for these variables to be global, so they can be modified by ddb(4)
(entered via "boot -d") early in startup.
|
|
good reason to treat modules without dependencies differently from those
which do require other modules.
|
|
module names both in the built-in list and in the list of previously
"pushed" modules.
While here, delay allocating the new 'struct module' until we've passed
the duplicate-name checks.
|