Date: Fri, 10 Nov 2023 17:04:33 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Doug Rabson <dfr@rabson.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: <E82260AA-501B-4608-88D5-DB4742E2A443@FreeBSD.org> In-Reply-To: <CANCZdfqzDaYfJi6XzhvfpCxEKX1FwA1A2b_dtH-h=_GTwPM8nw@mail.gmail.com> References: <07168C68-9F81-443C-AFB6-24958BB01F9E@FreeBSD.org> <CACA0VUggUqxTQ%2BrNRmAE0TyZr%2BiUumBOhwAVQATQ5MseT9A6zQ@mail.gmail.com> <CANCZdfqzDaYfJi6XzhvfpCxEKX1FwA1A2b_dtH-h=_GTwPM8nw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <imp@bsdimp.com> 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 <dfr@rabson.org = <mailto:dfr@rabson.org>> 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 <zlei@freebsd.org = <mailto:zlei@freebsd.org>> wrote: > Hi, >=20 > This is *NOT* joking. >=20 > While working on https://reviews.freebsd.org/D42527 = <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 = <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 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Nov 10, 2023, at 1:03 AM, Warner Losh <<a = href=3D"mailto:imp@bsdimp.com" class=3D"">imp@bsdimp.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"auto" class=3D"">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..</div></div></blockquote><div><br class=3D""></div><div>If we ever = want to support kexec, a new kernel should be loaded into memory before = the old one is unloaded.</div><div>Then <span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">probably a dedicated = syscall is needed for that.</span></div><div><br class=3D""></div><div>The= current change D42530 is mainly to prevent userland from = unloading the kernel via kldunload(2), so it should be OK.</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"auto" class=3D""><div dir=3D"auto" class=3D""><br = class=3D""></div><div dir=3D"auto" class=3D"">Warner</div></div><br = class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Thu, Nov 9, 2023, 9:34 AM Doug Rabson <<a = href=3D"mailto:dfr@rabson.org" class=3D"">dfr@rabson.org</a>> = wrote:<br class=3D""></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" class=3D"">I think your = intuition is correct - it never makes sense to unload the kernel (IMO). = I approved the review.<div class=3D""><br class=3D""></div><div = class=3D"">Doug.</div><div class=3D""><br class=3D""></div></div><br = class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang <<a = href=3D"mailto:zlei@freebsd.org" target=3D"_blank" rel=3D"noreferrer" = class=3D"">zlei@freebsd.org</a>> wrote:<br class=3D""></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(= 204,204,204);padding-left:1ex">Hi,<br class=3D""> <br class=3D""> This is *NOT* joking.<br class=3D""> <br class=3D""> While working on <a href=3D"https://reviews.freebsd.org/D42527" = rel=3D"noreferrer noreferrer" target=3D"_blank" = class=3D"">https://reviews.freebsd.org/D42527</a>; I realized the<br = class=3D""> module kernel also has userrefs, that is to say, userland can request<br = class=3D""> to unload kernel, aka `kldunload kernel`.<br class=3D""> <br class=3D""> This is interesting. Well no doubt that the loader can unload kernel.<br = class=3D""> Then after the kernel is loaded and has been initialized (SYSINIT), = how<br class=3D""> should it behave when it get an unload request?<br class=3D""> <br class=3D""> I'm proposing <a href=3D"https://reviews.freebsd.org/D42530" = rel=3D"noreferrer noreferrer" target=3D"_blank" = class=3D"">https://reviews.freebsd.org/D42530</a>; to do not allow = unloading<br class=3D""> the kernel. It is by intuition.<br class=3D""> <br class=3D""> What do you think ?<br class=3D""> <br class=3D""> <br class=3D""> Best regards,<br class=3D""> Zhenlei<br class=3D""> <br class=3D""> </blockquote></div> </blockquote></div> </div></blockquote></div><br class=3D""><div class=3D""> <div><br class=3D""></div> </div> <br class=3D""></body></html>= --Apple-Mail=_D8358A87-6E1C-46E5-84D2-5E46B528A07E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E82260AA-501B-4608-88D5-DB4742E2A443>