NetBSD Problem Report #57985

From www@netbsd.org  Sun Mar  3 00:40:20 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D6D601A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  3 Mar 2024 00:40:20 +0000 (UTC)
Message-Id: <20240303004019.AEC221A923A@mollari.NetBSD.org>
Date: Sun,  3 Mar 2024 00:40:19 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: nvmm.kmod is class MISC but opening /dev/nvmm autoloads it as class DRIVER
X-Send-Pr-Version: www-1.0

>Number:         57985
>Category:       kern
>Synopsis:       nvmm.kmod is class MISC but opening /dev/nvmm autoloads it as class DRIVER
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 03 00:45:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9
>Organization:
The NetBSDVMM Foundation
>Environment:
>Description:
nvmm.kmod is defined with MODULE_CLASS_MISC:

   1446 MODULE(MODULE_CLASS_MISC, nvmm, NULL);

https://nxr.netbsd.org/xref/src/sys/dev/nvmm/nvmm.c?r=1.47#1446

However, the system tries to autoload it with MODULE_CLASS_DRIVER when if it is not currently loaded when you open /dev/nvmm:

    895 			(void)module_autoload(name, MODULE_CLASS_DRIVER);

https://nxr.netbsd.org/xref/src/sys/miscfs/specfs/spec_vnops.c?r=1.218#895

This mismatch produces a spurious error message to the console:

WARNING: module error: incompatible module class 1 for `nvmm' (wanted 3)

The message is spurious because there's no other harmful consequences, so this contributes to warning fatigue.
>How-To-Repeat:
modunload nvmm
qemu-system-x86_64 -accel nvmm ...
>Fix:
Yes, please!

It is tempting to just switch it to MODULE_CLASS_DRIVER, but this may have the side effect of changing when initialization happens when it is a built-in module, which means that things like cpu_feature used by nvmm init might not be ready yet:

- The kernel initializes all modules of MODULE_CLASS_DRIVER before autoconf starts, early in configure: https://nxr.netbsd.org/xref/src/sys/kern/init_main.c?r=1.547#773
- The kernel doesn't initialize modules of MODULE_CLASS_MISC until after autoconf has detected devices, shortly before selecting root and dump devices: https://nxr.netbsd.org/xref/src/sys/kern/init_main.c?r=1.547#662

This is an unfortunate conflict between two different concepts: autoconf drivers, and /dev node drivers.  Modules implementing autoconf drivers need to be loaded before autoconf, but the nvmm module implements a /dev node driver which can be triggered by autoload.

Home	PR Database Search