Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Nov 2023 10:03:05 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Doug Rabson <dfr@rabson.org>
Cc:        Zhenlei Huang <zlei@freebsd.org>, FreeBSD Current <current@freebsd.org>,  Konstantin Belousov <kib@freebsd.org>
Subject:   Re: kldunload kernel: How should the kernel behave when it is requested to unload itself
Message-ID:  <CANCZdfqzDaYfJi6XzhvfpCxEKX1FwA1A2b_dtH-h=_GTwPM8nw@mail.gmail.com>
In-Reply-To: <CACA0VUggUqxTQ%2BrNRmAE0TyZr%2BiUumBOhwAVQATQ5MseT9A6zQ@mail.gmail.com>
References:  <07168C68-9F81-443C-AFB6-24958BB01F9E@FreeBSD.org> <CACA0VUggUqxTQ%2BrNRmAE0TyZr%2BiUumBOhwAVQATQ5MseT9A6zQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--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 <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
>>
>>

--0000000000001d92cd0609bb2e26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Yea. Kexec is what you&#39;d need=C2=A0to do to get a new=
 kernel... and we don&#39;t support kexec... so I agree this is good..<div =
dir=3D"auto"><br></div><div dir=3D"auto">Warner</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 9, 2023,=
 9:34 AM Doug Rabson &lt;<a href=3D"mailto:dfr@rabson.org">dfr@rabson.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I th=
ink your intuition is correct - it never makes sense to unload the kernel (=
IMO). I approved the review.<div><br></div><div>Doug.</div><div><br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Thu, 9 Nov 2023 at 16:10, Zhenlei Huang &lt;<a href=3D"mailto:zlei@freebs=
d.org" target=3D"_blank" rel=3D"noreferrer">zlei@freebsd.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex">Hi,<br>
<br>
This is *NOT* joking.<br>
<br>
While working on <a href=3D"https://reviews.freebsd.org/D42527" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">https://reviews.freebsd.org/D42527</a>=
 I realized the<br>
module kernel also has userrefs, that is to say, userland can request<br>
to unload kernel, aka `kldunload kernel`.<br>
<br>
This is interesting. Well no doubt that the loader can unload kernel.<br>
Then after the kernel is loaded and has been initialized (SYSINIT), how<br>
should it behave when it get an unload request?<br>
<br>
I&#39;m proposing <a href=3D"https://reviews.freebsd.org/D42530" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">https://reviews.freebsd.org/D42530</a=
> to do not allow unloading<br>
the kernel. It is by intuition.<br>
<br>
What do you think ?<br>
<br>
<br>
Best regards,<br>
Zhenlei<br>
<br>
</blockquote></div>
</blockquote></div>

--0000000000001d92cd0609bb2e26--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqzDaYfJi6XzhvfpCxEKX1FwA1A2b_dtH-h=_GTwPM8nw>