From nobody Thu Dec 12 09:46:40 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Y870T4f27z5g2wl for ; Thu, 12 Dec 2024 09:46:49 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y870T3zbtz469J; Thu, 12 Dec 2024 09:46:49 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733996809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=66rbOPJ8nQ2TDUUr9gCIjuq4jnPshpq06qlrlDlS2Zs=; b=hwW/K107SdAmiSredV+iEecSQ6rygz6tMHpsQYT9uoPHCEnnohWL+LUlxn42nHA0/oTThq mB5ucSzWe4hnHR/pUo4lzphyBBVZxVjr5dhgduoz0JoG+/9ONfVQ+ubFIxMUENWHwFYC4P mFNdgIapd6AAmRk4tyblau/fv7S6rjsT2y+GY+h8v4DxgABTP1G77fcxtPBXkAaFvj74a1 GOraibZEuMpE2DFnCVPtjcZ4zpAeDGhsFfZAIWsIcUjTI7i35FCTz8md5C/Is/7JxVjpee it6PF81+f6PCX6AQT5Cv+QMzqmBKLfp+IyKRL12rQ1ic7+Y0FM8bXaumeqORxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733996809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=66rbOPJ8nQ2TDUUr9gCIjuq4jnPshpq06qlrlDlS2Zs=; b=XtAU51sm5LC7S073/xctpDZr/QmTZfPKVdkCcr2mH+Bdm6LulorksIJlVgDvvuLXzyu1l5 YNXvsyxc2W/dU3jAYqymCrmqsLqQ9hV94p0d7vL6m79E96mj/pxnhCDc3QIF7j+xhorB/M hgNox/bLDw70ysfNJU4goA/vFhe55MGQyRGAcpXMLIvIgW7BghIpDnPypFjGLt0r8MP5B5 RYqfMElI/4fndXnmb/tkaUXNpp9e12nnC9o4uXQfpaAu6YBQRlftiiMqykCX6sdKqKr6kG gT6UhSTnS359dmutNMVeHesUqEW5mFbOIAppfkyxz17OsV0JCwA6CqLzsr/Lww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733996809; a=rsa-sha256; cv=none; b=J3LUKQm4SAx0aXQ38HxWJXZBCBz9ZNyIo7m+vNX0N85s2OSgSGMsWGQB7DiN7BqGYxCZ+C 5sQT9GqQXFaqVtc/dK3Y0ddD52W9QcQ14IUj2YMInOEdQoJxopPvgDpM4A5d7UFykEYEJR DI5ieEuHLjzjecb5doVMUyW3mUkafdaD3BTwv4fc9yVMMLNJHkqgQNzs6W3SvMSJhK0u5I W2qFvjVob9SxfEWkdixL7F1TEgLu/+BJxkfZcBpV0/Qpudo2/HtK4uJXNtF6UlJdQcdOtj N5nwc/JyfxBymzvZGsBHuzKX/vpWb/lWZCIubAAuyF4v5S6KfCJnpA9EsgvPuA== Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Y870S51vrz1D5V; Thu, 12 Dec 2024 09:46:48 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <3FBDFCF4-4427-4653-9EE4-EBC44DCB72ED@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: Module variable initialization Date: Thu, 12 Dec 2024 17:46:40 +0800 In-Reply-To: Cc: FreeBSD CURRENT To: Rick Macklem References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 12, 2024, at 10:44 AM, Rick Macklem = wrote: >=20 > Hi, >=20 > Bugzilla pr#282156 reports a crash that appears to be caused by > a NFS client variable (nfscbd_pool) not being initialized when a > NFS mount is done. >=20 > Now, the NFS client module (nfscl.ko) is weird in that it has > two definitions for the module. There is a VFS_SET() one for > the file system and a separate DECLARE_MODULE() for nfscl. > (The latter exists so that the module can refuse to unload and > define dependencies on other modules.) >=20 > The variable (nfscbd_pool) is initialized in the modevent() function > for nfscl in the MOD_LOAD section. >=20 > Does anyone know if this can somehow result in the variable not > being initialized when an NFS mount occurs? I'm not familiar with NFS. =46rom a quick look of the source code I = think `nfscbd_pool` is correctly initialized. I do not know the exact version pr#282156, so I guess and tried 14.1-p1, ``` $ addr2line -fip -e = /.zfs/snapshot/14.1-p1/usr/lib/debug/boot/kernel/kernel.debug = 0xffffffff80e1c558 svc_run at /usr/src/sys/rpc/svc.c:1414 ``` = https://cgit.freebsd.org/src/tree/sys/rpc/svc.c?h=3Dreleng/14.1&id=3D0892d= ff104440867956a53e78c12d66090fec36b#n1414 If `nfscbd_pool` is NULL, then I expect the panic should happens = earlier. Say line 1405 or event earlier line 1389 . Maybe `svc_run_internal()` is to be blamed ? >=20 > And, if the above is possible, would doing the initialization in the > vfs_init function for VFS_SET() be guaranteed to happen before > a mount is done? The order of modules seems right to me. nfscl module has order = SI_ORDER_FIRST and VFS_SET(... nfs ... ) has SI_ORDER_MIDDLE. >=20 > Thanks for any help with this, rick >=20 Best regards, Zhenlei --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 12, 2024, at 10:44 AM, Rick Macklem <rick.macklem@gmail.com> wrote:

Hi,
Bugzilla pr#282156 reports a crash that = appears to be caused by
a NFS client variable = (nfscbd_pool) not being initialized when a
NFS mount is = done.

Now, the NFS client module (nfscl.ko) = is weird in that it has
two definitions for the module. = There is a VFS_SET() one for
the file system and a = separate DECLARE_MODULE() for nfscl.
(The latter exists so = that the module can refuse to unload and
define = dependencies on other modules.)

The = variable (nfscbd_pool) is initialized in the modevent() function
for nfscl in the MOD_LOAD = section.

Does anyone know if this can = somehow result in the variable not
being initialized when = an NFS mount occurs?

I'm not familiar with NFS. =46rom a quick look of the = source code I think
`nfscbd_pool` is correctly initialized.

I do not know the exact version pr#282156, so I guess and tried = 14.1-p1,
```
$ addr2line= -fip -e /.zfs/snapshot/14.1-p1/usr/lib/debug/boot/kernel/kernel.debug = 0xffffffff80e1c558
svc_run = at /usr/src/sys/rpc/svc.c:1414
```


If `nfscbd_pool` is NULL, then I expect the panic should happens = earlier. Say line 1405 or event earlier line 1389 .

Maybe `svc_run_internal()` is to be blamed ?


And, if the above is possible, would doing the = initialization in the
vfs_init function for VFS_SET() be = guaranteed to happen before
a mount is done?

The = order of modules seems right to me. nfscl module has order  SI_ORDER_FIRST
and VFS_SET(... nfs ... ) has SI_ORDER_MIDDLE.


Thanks for any help with this, rick


Best regards,
Zhenlei

= --Apple-Mail=_B2249E63-5891-4707-AE52-79A065BDA57A--