From nobody Fri Nov 10 09:04:33 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 4SRXvZ3D3rz511Zv for ; Fri, 10 Nov 2023 09:04:42 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SRXvZ0zwPz4pZq; Fri, 10 Nov 2023 09:04:42 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699607082; 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=yotsacaKP4I+rV+V4ZdyCMb2SPntg6qDjXNeTZHaBNs=; b=fOLIRet/YT/U74JuTZif0Pl6/RW9Z/5cXXWr7f3W8ElSkoKJVd75FZuri4vjTScZCM0hnm SIdSSzBbITJy2NCILQEHOmGpR/4aLLcHT8qbiYTRmOfxjAn1kad78Ri1USJ/Ijz9+4N3ih JjZxm45BhdwdHGmd5UX+rIdA/zBRlf8bs4T7t7AWz2SAjRJZ7+o2OJUrr393LDsbTci0dS dvOXyghVYbHyOPJ2r+Fpwp5f8j7NGliYAKeHlr71U513f1afs5ZAi3WmSIn8Gys9b7MJbY OKxYgfV+4TDAFpppYttCmHqJ+vKO6JQ1ToqaQSxgVVfPu1MrCwoFFjvI+T0SxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699607082; 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=yotsacaKP4I+rV+V4ZdyCMb2SPntg6qDjXNeTZHaBNs=; b=v53x2AT+D7z0v0crdQnoNUuJt7ZAwhdZTrUHrwV49NCJqqMidiSqrbHM+0w/9df+Gwou6h 0L143ChnIZChbSz35AaCegh5XbrRB8785XqdMnJ0iSHYLZRg0q+Tf3cel7atJObi7vFMhW 9PozaN0+sXjX9xKaU/HGsZToad8gY/Xc+kZSneA5DGI6cQeyGyONXcUdBVXcBXBrFL/t4O FDJVjyrio5BkdwOeIFiIBZCMHXhUoErJbo9xo9C2wddBbGImlnAoc9VvuTngdhnDJSIAc5 vC9zDGnMS/hQ83XHZedzWIHCn80R92xz6XMa69UZTHoeuFVfJqjVRgdUEHPifQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699607082; a=rsa-sha256; cv=none; b=Xo4wQ85rSMGM3rrySgIa+eaYcWkdxpsvw8hI1CqskkmyO+hnssjCT/hwDxtrSVGt3Y6MJ4 Q1/CAcqFco8eG0IycdX8LpGi3ZRoX4eHrltbIzkpjJywe091eq32kPt/P+u6kNiQmCXWDF 4O6kZN5QNLiNx8Vzb35+xJZYmuvOptO8l9AJG2uQFd1gwmiYBxNaxZxHiKephRvERxO4k2 UAjJxyg2qEISVR8JcPra8Oy4k79UQmD7+yfQqUHFO1Jkkf+5ipFMk2kKS86sqEeVdKowCf pBv8xDvVufl22bDuVrFN21urbTvQj2CXujVbsucQx9LBFnjfT8NK0RPASDZ/qQ== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (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 4SRXvX5Pf9z11lp; Fri, 10 Nov 2023 09:04:40 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8358A87-6E1C-46E5-84D2-5E46B528A07E" 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.4\)) Subject: Re: kldunload kernel: How should the kernel behave when it is requested to unload itself Date: Fri, 10 Nov 2023 17:04:33 +0800 In-Reply-To: Cc: Doug Rabson , FreeBSD Current , Konstantin Belousov To: Warner Losh References: <07168C68-9F81-443C-AFB6-24958BB01F9E@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.4) --Apple-Mail=_D8358A87-6E1C-46E5-84D2-5E46B528A07E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 10, 2023, at 1:03 AM, Warner Losh wrote: >=20 > 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.. If we ever want to support kexec, a new kernel should be loaded into = memory before the old one is unloaded. Then probably a dedicated syscall is needed for that. The current change D42530 is mainly to prevent userland from unloading = the kernel via kldunload(2), so it should be OK. >=20 > Warner >=20 > 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. >=20 > Doug. >=20 >=20 > On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang > wrote: > Hi, >=20 > This is *NOT* joking. >=20 > 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`. >=20 > 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? >=20 > I'm proposing https://reviews.freebsd.org/D42530 = to do not allow unloading > the kernel. It is by intuition. >=20 > What do you think ? >=20 >=20 > Best regards, > Zhenlei >=20 --Apple-Mail=_D8358A87-6E1C-46E5-84D2-5E46B528A07E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Nov 10, 2023, at 1:03 AM, Warner Losh <imp@bsdimp.com> = wrote:

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..

If we ever = want to support kexec, a new kernel should be loaded into memory before = the old one is unloaded.
Then probably a dedicated = syscall is needed for that.

The= current change D42530  is mainly to prevent userland from = unloading the kernel via kldunload(2), so it should be OK.


Warner

On Thu, Nov 9, 2023, 9:34 AM Doug Rabson <dfr@rabson.org> = 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 <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




= --Apple-Mail=_D8358A87-6E1C-46E5-84D2-5E46B528A07E--