From nobody Thu Nov 9 16:34:37 2023 X-Original-To: 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 4SR6xP6dSjz50Q1w for ; Thu, 9 Nov 2023 16:34:49 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SR6xP4yRfz4JQs for ; Thu, 9 Nov 2023 16:34:49 +0000 (UTC) (envelope-from dfr@rabson.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-dae7cc31151so1091773276.3 for ; Thu, 09 Nov 2023 08:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20230601.gappssmtp.com; s=20230601; t=1699547689; x=1700152489; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GqqR3qOXVzl2tzia4pn61DFJCLOGrJBaCu3uXIAb5nE=; b=UZdv5B3saKrNWeYVjZk4HFQYpyAV0A3M/pjI3XypsgEJMsH3i6o2COguetpldkz1lU 6qa+4l6hR1dq1z2kbeNwamS/pIdeHb6pWWiA2MP8swSny5NAcpWF/813k5zXOIHqwrfj PxxHkYHHLUyf3Uv3r47p7ZTeRSgaMRW0zIYlfvoN/gP4rU7iTpd6BWthdhluif+jLUq0 zfTJGKSmbZfqdyk9LhgmSd7JoRsKOotqFzhurGQxvrIS/IDsYMBiBqajiG05E8/LXj1Y m0A9z7c85lwHfIodfQTlF9k8Dr1TfCJMECurMjuI14sfWAFRJqwwcZx2Jl8iMus7VLjk UHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699547689; x=1700152489; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GqqR3qOXVzl2tzia4pn61DFJCLOGrJBaCu3uXIAb5nE=; b=K3Q8PK0o55O74LwnRYSZe8aRdc1Cxalm5MNvGHn1fOHCp97YszBuHjvcOWihKXk786 /HI/MqNAZPCZMbiChC3eROU6DnQYJSzqnsT7RjoiL1A7XNxKNywemFyiTmHtINyChFZo xismujJhlNW2He1FFNOnGFyv0wGOaE9kVDM1ocJjfIDktfboUOAtgzXWqtAOgtj29XK2 gTtwd9nhqluEEqD2tW1CczVYUe+T6T+zNj7+QW1Xk9Bv8V2S4qO0b4cqO3ylsUJ7YEHd eDr05cJO/buL9mFJAr9pSUgD3BFnVhBRmr9bbndZ2XT2E/ji6BFZ9l84IUuPoZ9Uu+eP E4Rg== X-Gm-Message-State: AOJu0Yw2/nL6fHsnC/VtYfLR2OfJWuAqI3mtetBFkoHFwMW0VHVl6lqG dKXBCxOJLDuen6R5iNuXT2TpqAgqBPs2yEZgM8P7hK0WqhaVs8zkHYg= X-Google-Smtp-Source: AGHT+IFEq+R4VOMrDAlhRhm0gYh3NGOps2Shy+8eTBJvPDLkPRnARX0kEvtjs9schvLUKTLF3IzTT0MVz4CTUS4S0Z8= X-Received: by 2002:a25:a507:0:b0:da0:365d:9e21 with SMTP id h7-20020a25a507000000b00da0365d9e21mr4795233ybi.22.1699547688773; Thu, 09 Nov 2023 08:34:48 -0800 (PST) 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 References: <07168C68-9F81-443C-AFB6-24958BB01F9E@FreeBSD.org> In-Reply-To: <07168C68-9F81-443C-AFB6-24958BB01F9E@FreeBSD.org> From: Doug Rabson Date: Thu, 9 Nov 2023 16:34:37 +0000 Message-ID: Subject: Re: kldunload kernel: How should the kernel behave when it is requested to unload itself To: Zhenlei Huang Cc: FreeBSD Current , Konstantin Belousov Content-Type: multipart/alternative; boundary="00000000000044bfdd0609bac883" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4SR6xP4yRfz4JQs --00000000000044bfdd0609bac883 Content-Type: text/plain; charset="UTF-8" I think your intuition is correct - it never makes sense to unload the kernel (IMO). I approved the review. Doug. On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang wrote: > Hi, > > This is *NOT* joking. > > While working on https://reviews.freebsd.org/D42527 I realized the > module kernel also has userrefs, that is to say, userland can request > to unload kernel, aka `kldunload kernel`. > > This is interesting. Well no doubt that the loader can unload kernel. > Then after the kernel is loaded and has been initialized (SYSINIT), how > should it behave when it get an unload request? > > I'm proposing https://reviews.freebsd.org/D42530 to do not allow unloading > the kernel. It is by intuition. > > What do you think ? > > > Best regards, > Zhenlei > > --00000000000044bfdd0609bac883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think your intuition is correct - it never makes sense t= o unload the kernel (IMO). I approved the review.

Doug.<= /div>


On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang <zlei@freebsd.org> wrote:
Hi,

This is *NOT* joking.

While working on https://reviews.freebsd.org/D42527 I realized= the
module kernel also has userrefs, that is to say, userland can request
to unload kernel, aka `kldunload kernel`.

This is interesting. Well no doubt that the loader can unload kernel.
Then after the kernel is loaded and has been initialized (SYSINIT), how
should it behave when it get an unload request?

I'm proposing https://reviews.freebsd.org/D42530 to do not= allow unloading
the kernel. It is by intuition.

What do you think ?


Best regards,
Zhenlei

--00000000000044bfdd0609bac883--