From nobody Thu Nov 09 17:03:05 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 4SR7ZK6pY2z50X6X for ; Thu, 9 Nov 2023 17:03:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 4SR7ZK57Hxz4Pc7 for ; Thu, 9 Nov 2023 17:03:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c6b30acacdso13536091fa.2 for ; Thu, 09 Nov 2023 09:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1699549398; x=1700154198; 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=tUVf06nHS3gRvF9wAgv8U25eVvpkGTc+pWrzdIBLFtE=; b=KOMipUIKi3nukPqv1zcIPNQkKWqXQ+qrZzHsVTSxuo+ObN+FsIwzZSPArnwtmlAd2Y oxj0A8yYeL1XeIYeOla0Si6ZN22L+U4T5mxvioX1Ek5T49OfhY8ipg0c9GEELlpa6A9T D1pf+spRy0RmGxSVfsntAWukzL07Cq/xIEL+iVf49Lp2ztjOaSRGizcVw23P9hCvrlyP H9kG2IrEbyg1ib3p7h5Sr+nyhoT3G5c/+7NHWvKr3Dk1KZ0yjQDCANFNaHHs8/FkSPb2 eNUgkmpSsh/0QJKdFwFk6ejfGr3cMcc4hkNv+Zfv5xunEzF1zu1CmgjFHq7o5t0pV2KM MSQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699549398; x=1700154198; 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=tUVf06nHS3gRvF9wAgv8U25eVvpkGTc+pWrzdIBLFtE=; b=GSOopJIWEec7zJrvlIW3aQsN+LKGA7ykFYT+Kcpxo2m0b6rrvHsmhbbfwLskVDGGor TCOZo0b8nbJ0TW6tsNcZ9YPJj48kvcewJQohMJwZQS5Xrmjt4/n6WcA1J6wDMDCcy5UB tgE8ryi7ng4+JYxoS1LhW89hT95BLGuy4+PLVCRsZwVVUIFUnpELgaZtP2/u08tYqTaF 36jpRmSuFpGttefBVNvs1C9warcQzWohHAWigvYACfbLdjeBlqu95S3ie71+TqyZPRLU dWHZ8n2caxQ3AaQskzq4odG/J/O7WVaHSjzC7u7i3Fdt/+eNXmK09EHXQLS4vJ0dFOSN qJdg== X-Gm-Message-State: AOJu0YyZR304L/dz9umWwBfgAhY8G6nm/g+MHgFRaPGQSPirqG5fHjGi NXZyGxKjUMc1MMYPAnl3MzvOFbfKx7dbLb0/rUAqpQ== X-Google-Smtp-Source: AGHT+IGwCvQBO0rAwiNf62pyJBnhWwIGWOLkDp6oOpgzZoyA9zfGpeiTH5YA4SvEI8PQmkZTTYdP7ozg8vZELeQuHXc= X-Received: by 2002:a2e:9e53:0:b0:2c5:cac:e9a3 with SMTP id g19-20020a2e9e53000000b002c50cace9a3mr4460297ljk.52.1699549397458; Thu, 09 Nov 2023 09:03:17 -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: From: Warner Losh Date: Thu, 9 Nov 2023 10:03:05 -0700 Message-ID: Subject: Re: kldunload kernel: How should the kernel behave when it is requested to unload itself To: Doug Rabson Cc: Zhenlei Huang , FreeBSD Current , Konstantin Belousov Content-Type: multipart/alternative; boundary="0000000000001d92cd0609bb2e26" 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SR7ZK57Hxz4Pc7 --0000000000001d92cd0609bb2e26 Content-Type: text/plain; charset="UTF-8" Yea. Kexec is what you'd need to do to get a new kernel... and we don't support kexec... so I agree this is good.. Warner On Thu, Nov 9, 2023, 9:34 AM Doug Rabson wrote: > 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 >> >> --0000000000001d92cd0609bb2e26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yea. Kexec is what you'd need=C2=A0to do to get a new= kernel... and we don't support kexec... so I agree this is good..

Warner

On Thu, Nov 9, 2023,= 9:34 AM Doug Rabson <dfr@rabson.org> wrote:
I th= ink your intuition is correct - it never makes sense to unload the kernel (= IMO). I approved the review.

Doug.

<= /div>
O= n 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

--0000000000001d92cd0609bb2e26--