Website-Suche

Laden, Entladen und Blacklist von Linux-Kernel-Modulen


Linux-Kernel-Funktionalitäten, wie z.B. die Unterstützung für bestimmte Geräte oder Dateisysteme, sind in Modulen organisiert, die statisch in den Kernel eingebaut werden können oder als getrennte "Einheiten", die auf Anfrage geladen und entladen werden können. Heutzutage werden benötigte Module automatisch geladen, so dass wir sie nur noch selten explizit verwalten müssen. In bestimmten Situationen kann es jedoch erforderlich sein, solche Aktionen durchzuführen.

In diesem Tutorial lernen wir, wie man Informationen über Kernel-Module abruft, wie man das modprobe-Dienstprogramm verwendet, um Module zur Laufzeit zu laden oder zu entladen, und wie man Module beim Booten lädt oder auf die Blacklist setzt.

In diesem Tutorial lernen Sie:

  • Wie man geladene Kernel-Module auflistet
  • So erhalten Sie Informationen über ein Kernel-Modul
  • Wie man Kernel-Module mit modprobe lädt und entlädt
  • So laden Sie ein Modul automatisch beim Booten oder setzen es auf die Blacklist

KategorieAnforderungen, Konventionen oder verwendete Softwareversion
SystemVerteilungs-agnostisch
Softwarelsmod, modinfo, modprobe
AndereAdministratorrechte zum Laden oder Entladen von Modulen.
Konventionen# – erfordert, dass bestimmte Linux-Befehle mit Root-Rechten ausgeführt werden, entweder direkt als Root-Benutzer oder mit dem sudo-Befehl $– erfordert, dass bestimmte Linux-Befehle als normaler, nicht privilegierter Benutzer ausgeführt werden

Auflisten geladener Module

Um die Liste der geladenen Kernel-Module abzurufen, müssen wir lediglich den Inhalt der Datei /proc/modules überprüfen. Unten sehen Sie ein Beispiel, wie ein Eintrag in der Datei aussieht:

i915 3174400 42 - Live 0x0000000000000000

Wie Sie sehen können, ist der Inhalt der Datei in sechs Spalten organisiert. Die erste Spalte enthält den Namen des Moduls ("i915" in diesem Fall: es ist das Modul, das Unterstützung für die integrierte Intel-Grafik hinzufügt); Im zweiten wird die Speichergröße des Moduls in Bytes (3174400) angegeben. Die dritte Spalte enthält die Anzahl der aktuell geladenen Modulinstanzen, die in diesem Fall 42 beträgt.

Einige Module stützen sich, um korrekt zu funktionieren, auf Funktionalitäten, die von anderen Modulen bereitgestellt werden: Die vierte Spalte wird verwendet, um die Modulabhängigkeiten zu melden. In dem Eintrag, den wir als Beispiel genommen haben, können wir sehen, dass das Modul keine Abhängigkeiten hat: Alles, was wir in der Spalte sehen können, ist das Zeichen "-". Die fünfte Spalte zeigt den aktuellen Status des Moduls an, der einer der folgenden sein kann: Live, Laden oder Entladen.

Schließlich sehen wir in der sechsten Spalte die Speicheradresse, in die das Modul geladen wird.

Um zu vermeiden, dass der Inhalt der Datei /proc/modules direkt gelesen wird, können wir das Dienstprogramm lsmod verwenden, das eine besser lesbare und schön formatierte Ausgabe bietet, die einen Header enthält:

Module                  Size  Used by
i915                 3174400  42

Abrufen von Informationen zu einem Modul

Um Informationen über ein bestimmtes Linux-Kernel-Modul zu erhalten, können wir ein anderes Dienstprogramm verwenden: modinfo. Dieses Dienstprogramm stellt Informationen über das Modul bereit, das als Argument übergeben wird. Wir können auf ein Modul verweisen, indem wir seinen Pfad oder nur seinen Namen verwenden. Wenn wir letzteres tun, wird das Modul im Verzeichnis /lib/modules/<kernel-version> gesucht, wobei "<kernel-version>" ein Verzeichnis ist, das nach der derzeit verwendeten Linux-Kernel-Version benannt ist, die durch Ausführen von folgendem Befehl abgerufen werden kann:

uname -r

Um Informationen über das Modul "i915" zu erhalten, würden wir Folgendes ausführen:

modinfo i915

In der Ausgabe des Befehls sehen wir unter anderem den Dateinamen des Moduls, seinen Autor, seine Lizenz und die Abhängigkeiten. Wir können auch die Liste der Parameter sehen, die an das Modul übergeben werden können, um sein Verhalten anzupassen, und eine kurze Erklärung davon:

parm:           modeset:Use kernel modesetting [KMS] (0=disable, 1=on, -1=force vga console preference [default]) (int) 
parm:           enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; 3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO) (int) 
parm:           enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int) 
parm:           lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int) 
parm:           panel_use_ssc:Use Spread Spectrum Clock with panels [LVDS/eDP] (default: auto from VBT) (int) 
parm:           vbt_sdvo_panel_type:Override/Ignore selection of SDVO panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS table) (int) 
parm:           reset:Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default]) (uint) 
parm:           vbt_firmware:Load VBT from specified file under /lib/firmware (charp) 
parm:           error_capture:Record the GPU state following a hang. This information in /sys/class/drm/card<N>/error is vital for triaging and debugging hangs. (bool) 
parm:           enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool) 
parm:           enable_psr:Enable PSR (0=disabled, 1=enable up to PSR1, 2=enable up to PSR2) Default: -1 (use per-chip default) (int) 
parm:           psr_safest_params:Replace PSR VBT parameters by the safest and not optimal ones. This is helpful to detect if PSR issues are related to bad values set in  VBT. (0=use VBT p
arameters, 1=use safest parameters) (bool) 
parm:           enable_psr2_sel_fetch:Enable PSR2 selective fetch (0=disabled, 1=enabled) Default: 0 (bool) 
parm:           force_probe:Force probe the driver for specified devices. See CONFIG_DRM_I915_FORCE_PROBE for details. (charp) 
parm:           disable_power_well:Disable display power wells when possible (-1=auto [default], 0=power wells always on, 1=power wells disabled when possible) (int) 
parm:           enable_ips:Enable IPS (default: true) (int) 
parm:           fastboot:Try to skip unnecessary mode sets at boot time (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int) 
parm:           load_detect_test:Force-enable the VGA load detect code for testing (default:false). For developers only. (bool) 
parm:           force_reset_modeset_test:Force a modeset during gpu reset for testing (default:false). For developers only. (bool) 
parm:           invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device I
D to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int) 
parm:           disable_display:Disable display (default: false) (bool) 
parm:           memtest:Perform a read/write test of all device memory on module load (default: off) (bool) 
parm:           mmio_debug:Enable the MMIO debug code for the first N failures (default: off). This may negatively affect performance. (int) 
parm:           verbose_state_checks:Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions. (bool) 
parm:           nuclear_pageflip:Force enable atomic functionality on platforms that don't have full support yet. (bool) 
parm:           edp_vswing:Ignore/Override vswing pre-emph table selection from VBT (0=use value from vbt [default], 1=low power swing(200mV),2=default swing(400mV)) (int) 
parm:           enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto [default], 0=disable, 1=GuC submission,
2=HuC load) (int) 
parm:           guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int) 
parm:           guc_firmware_path:GuC firmware path to use instead of the default one (charp) 
parm:           huc_firmware_path:HuC firmware path to use instead of the default one (charp) 
parm:           dmc_firmware_path:DMC firmware path to use instead of the default one (charp) 
parm:           enable_dp_mst:Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true) (bool) 
parm:           enable_dpcd_backlight:Enable support for DPCD backlight control(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 1=enable, 2=force VESA interface, 3=force I
ntel interface) (int) 
parm:           enable_gvt:Enable support for Intel GVT-g graphics virtualization host support(default:false) (bool) 
parm:           request_timeout_ms:Default request/fence/batch buffer expiration timeout. (uint) 
parm:           lmem_size:Set the lmem size(in MiB) for each region. (default: 0, all memory) (uint) 
parm:           lmem_bar_size:Set the lmem bar size(in MiB). (uint) 
parm:           mitigations:Selectively enable security mitigations for all Intel® GPUs in the system.

Wie können Parameter an ein Modul übergeben werden? Finden wir es heraus!

Be- und Entladen von Modulen mit modprobe

Um Linux-Kernel-Module zu laden oder zu entladen, können wir das Dienstprogramm modprobe verwenden. Modprobe ist intelligent genug, um Modulabhängigkeiten aufzulösen, so dass beim Laden eines Moduls auch seine Abhängigkeiten geladen werden. Der Befehl nimmt den Namen des Moduls, mit dem wir arbeiten möchten, als erstes Argument an. Beim Laden eines Moduls können wir auch die kommagetrennte Liste der Parameter angeben, mit denen es geladen werden soll.

Laden eines Moduls

Angenommen, wir möchten das i915-Modul laden und explizit ausführliche Zustandsüberprüfungen aktivieren. Wir würden laufen:

sudo modprobe i915 verbose_state_checks=1

Um neue Parameter auf ein Modul anzuwenden, sollten wir, wenn möglich, entweder zuerst entladen oder den Wert des Moduls ändern, wie in /sys/module/<module-name>/parameters/<parameter-name> angezeigt. Um z.B. den aktuellen Wert des Parameters "verbose_state_checks" des i915-Moduls zu überprüfen, können wir einfach den Inhalt der entsprechenden Datei überprüfen:

sudo cat /sys/module/i915/parameters/verbose_state_checks 
Y

In diesem Fall ist die Funktion aktiviert. Angenommen, wir möchten es deaktivieren, ohne das Modul zu entladen, könnten wir einfach den neuen Wert in die Datei schreiben:

echo 0 | sudo tee /sys/module/i915/parameters/verbose_state_checks

Beachten Sie, dass nicht alle Parameter geändert werden können, wie wir es oben getan haben. Wenn ein Parameter nicht geändert werden kann, hat die entsprechende Datei keine Schreibrechte.

Entladen eines Moduls

Um ein oder mehrere Module zu entladen, verwenden wir immer noch modprobe, aber wir führen es mit der Option -r aus. Wenn wir versuchen, ein Modul zu entladen, das gerade verwendet wird, erhalten wir eine Fehlermeldung:

sudo modprobe -r i915
modprobe: FATAL: Module i915 is in use.

Wie wir bereits sagten, ist modprobe abhängigkeitsbewusst, d.h. wenn ein Modul entladen wird, versucht es, alle Module zu entladen, von denen es abhängt, wenn sie nicht verwendet werden.

Laden oder Blacklisting eines Moduls beim Booten

Das Laden eines Moduls mit modprobe, wie wir es im vorherigen Beispiel getan haben, führt nicht dazu, dass das Modul beim nächsten Start des Systems automatisch geladen wird. Damit ein Modul beim Booten geladen wird, müssen wir entweder seinen Namen an die Datei /etc/modules anhängen (und sie erstellen, falls sie nicht existiert) oder an eine Datei mit der Erweiterung ".conf" im Verzeichnis /etc/modules-load.d/. Damit z.B. ein hypothetisches Modul "foo" beim Booten geladen werden kann, würden wir "foo" in die Datei /etc/modules-load.d/foo.conf schreiben:

echo "foo" | sudo tee /etc/modules-load.d/foo.conf

Wenn wir die Optionen festlegen möchten, mit denen ein Modul beim Booten geladen werden soll, oder verhindern möchten, dass ein Modul geladen wird, sollten wir stattdessen eine Datei mit der Erweiterung ".conf" im Verzeichnis /etc/modprobe.d erstellen. Damit das i915-Modul beispielsweise ohne ausführliche Statusüberprüfungen geladen werden kann, erstellen wir die Datei /etc/modprobe.d/i915.conf mit folgendem Inhalt:

options i915 verbose_state_checks=0

Um das Modul auf die Blacklist zu setzen, würden wir stattdessen die Anweisung "blacklist" verwenden:

blacklist i915

Schlüsse

Linux-Funktionalitäten sind in Modulen organisiert, die statisch in den Kernel eingebaut oder bei Bedarf geladen und entladen werden können. In diesem Tutorial haben wir gesehen, wie man geladene Module auflistet, Informationen über sie erhält und wie man Module zur Laufzeit mit dem modprobe-Dienstprogramm lädt oder entlädt. Wir haben auch gesehen, wie man ein Modul beim Booten automatisch lädt, mit oder ohne bestimmte Optionen, und wie man verhindert, dass eines Moduls geladen wird, indem man es auf die schwarze Liste setzt.

Verwandte Artikel: