Date: Mon, 4 Dec 2023 11:59:51 -0800 From: Xin LI <delphij@gmail.com> To: Karl Denninger <karl@denninger.net> Cc: stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs Message-ID: <CAGMYy3uvj8yXZ6j87aQvvMksn_k6aO9vHB8uvFe7=a7RELVbGQ@mail.gmail.com> In-Reply-To: <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> References: <20231201031737.DF0231B942@freefall.freebsd.org> <ZWsI4SbNU2xPjaPF@marvin.hueftgold.tld> <ZW2P8xz046Eqo_0u@fc.opsec.eu> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> <CAGMYy3vF6h=4ZM5tBFUzNk3TX83cP5j_MiRsF6J3bm6%2BWPfS8w@mail.gmail.com> <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000046c6e4060bb49013
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 4, 2023 at 10:00=E2=80=AFAM Karl Denninger <karl@denninger.net>=
wrote:
> On 12/4/2023 12:51, Xin LI wrote:
>
>
>
> On Mon, Dec 4, 2023 at 8:32=E2=80=AFAM Tomoaki AOKI <junchoon@dec.sakura.=
ne.jp>
> wrote:
>
>> On Mon, 04 Dec 2023 08:48:52 -0500
>> Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> wrote:
>>
>> > Kurt Jaeger <pi@freebsd.org> writes:
>> >
>> > > I had thought that the ZFS fix is a kernel fix so that the kernel
>> > > would also report -p1, but it does not. It might be because
>> > > zfs is a kernel module, so the kernel itself was not really patched,
>> > > but I might be wrong here.
>> >
>> > As far as I can see, that seems exactly right.
>>
>> As this kind of confusion caused by mismatch of patchlevel between
>> kernel and userland arises from time to time, now would be the time to
>> switch to keep patchlevel in sync between kernel and userland.
>>
>> This would force both kernel and userland to be built using the same
>> patchlevel, even if one of which is actually unchanged.
>> But maybe helpful to avoid confusion like this.
>>
>> What was worse this time was that a non-in-kernel-but-in-tree module,
>> zfs.ko, is updated but kernel itself is not updated.
>
>
> Part of this is because freebsd-update generally wants to exclude cosmeti=
c
> changes (like build timestamps, etc., which does not have an effect on
> runtime behavior) in binary patches, so in order to "fix" this we would
> need to change the update builder, at the expense of always delivering a
> kernel change regardless if there are any real changes to the binary. At
> the time when I owned the builder code, the consensus was that we are
> moving to a packaged base really soon (tm) and the builder is in
> "maintenance mode" so we didn't invest a lot in this front.
>
> Cheers,
>
> I would argue that if *kernel modules *are implicated in a patch then
> either (1) the kernel *version *has to come from a module (and thus be
> bumped if any of said modules are updated) or (2) the kernel *itself *has
> to be updated so its version can be patched.
>
> #1 is obviously a *lot* less intrusive and perhaps the correct answer: *T=
he
> "kernel revision" is incremented when either the kernel itself or any of
> its loadable modules are patched/updated, and the revision itself is in a
> loadable module and thus can be updated as a tiny little file instead of
> the entire kernel.*
>
They are indeed incremented as part of the kernel patching process (this
part is automated in freebsd-update builder actually), so freebsd-update
builds would actually build -p1 kernels. However, when creating binary
patches, freebsd-update would also examine the 'kernel' binary and note
that only patchlevel were bumped and there is no change to the 'kernel'
binary itself, which is considered cosmetic and ignore it when publishing
the patches.
This would be a lot easier to implement in a packaged world (where the
package's patch level is bumped, while 'kernel' binary stays the same, and
administrators examine the package's version instead of the kernel's
version string).
Cheers,
--00000000000046c6e4060bb49013
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 4, 2023 at 10:00=E2=80=
=AFAM Karl Denninger <<a href=3D"mailto:karl@denninger.net">karl@denning=
er.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><u></u>
=20
=20
=20
<div>
<div>On 12/4/2023 12:51, Xin LI wrote:<br>
</div>
<blockquote type=3D"cite">
=20
<div dir=3D"ltr">
<div dir=3D"ltr">
<div style=3D"font-family:monospace,monospace"><br>
</div>
</div>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 4, 2023 at
8:32=E2=80=AFAM Tomoaki AOKI <<a href=3D"mailto:junchoon@dec=
.sakura.ne.jp" target=3D"_blank">junchoon@dec.sakura.ne.jp</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Mon, 04 Dec 2023 08:48:52 -0500<br>
Lowell Gilbert <<a href=3D"mailto:freebsd-stable-local@be-we=
ll.ilk.org" target=3D"_blank">freebsd-stable-local@be-well.ilk.org</a>>
wrote:<br>
<br>
> Kurt Jaeger <<a href=3D"mailto:pi@freebsd.org" target=
=3D"_blank">pi@freebsd.org</a>>
writes:<br>
> <br>
> > I had thought that the ZFS fix is a kernel fix so
that the kernel<br>
> > would also report -p1, but it does not. It might
be because<br>
> > zfs is a kernel module, so the kernel itself was
not really patched,<br>
> > but I might be wrong here.<br>
> <br>
> As far as I can see, that seems exactly right.<br>
<br>
As this kind of confusion caused by mismatch of patchlevel
between<br>
kernel and userland arises from time to time, now would be
the time to<br>
switch to keep patchlevel in sync between kernel and
userland.<br>
<br>
This would force both kernel and userland to be built using
the same<br>
patchlevel, even if one of which is actually unchanged.<br>
But maybe helpful to avoid confusion like this.<br>
<br>
What was worse this time was that a
non-in-kernel-but-in-tree module,<br>
zfs.ko, is updated but kernel itself is not updated.</blockquot=
e>
<div><br>
</div>
<div style=3D"font-family:monospace,monospace">Part of this is
because freebsd-update generally wants to exclude cosmetic
changes (like build timestamps, etc., which does not have an
effect on runtime behavior) in binary patches, so in order
to "fix" this we would need to change the update buil=
der, at
the expense of always delivering a kernel change regardless
if there are any real changes to the binary.=C2=A0 At the time
when I owned the builder code, the consensus=C2=A0was that we a=
re
moving to a packaged base really soon (tm) and the builder
is in "maintenance mode" so we didn't invest a lo=
t in this
front.</div>
<div style=3D"font-family:monospace,monospace"><br>
</div>
<div style=3D"font-family:monospace,monospace">Cheers,</div>
</div>
</div>
</blockquote>
<p>I would argue that if <i>kernel modules </i>are implicated in a
patch then either (1) the kernel <i>version </i>has to come from
a module (and thus be bumped if any of said modules are updated)
or (2) the kernel <i>itself </i>has to be updated so its version
can be patched.</p>
<p>#1 is obviously a <i>lot</i> less intrusive and perhaps the
correct answer: <i>The "kernel revision" is incremented whe=
n <b><u>either</u></b>
the kernel itself or any of its loadable modules are
patched/updated, and the revision <b><u>itself</u></b> is in a
loadable module and thus can be updated as a tiny little file
instead of the entire kernel.</i><span style=3D"font-family:monospa=
ce,monospace"></span></p></div></blockquote><div class=3D"gmail_default" st=
yle=3D"font-family:monospace,monospace">They are indeed incremented as part=
of the kernel patching process (this part is automated in freebsd-update b=
uilder actually), so freebsd-update builds would actually build -p1 kernels=
.=C2=A0 However, when creating binary patches, freebsd-update would also ex=
amine the 'kernel' binary and note that only patchlevel were bumped=
and there is no change to the 'kernel' binary itself, which is con=
sidered cosmetic and ignore it when publishing the patches.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div=
class=3D"gmail_default" style=3D"font-family:monospace,monospace">This wou=
ld be a lot easier to implement in a packaged world (where the package'=
s patch level is bumped, while 'kernel' binary stays the same, and =
administrators examine the package's version instead of the kernel'=
s version string).</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace,monospace">Cheers,</div></div></div>
--00000000000046c6e4060bb49013--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3uvj8yXZ6j87aQvvMksn_k6aO9vHB8uvFe7=a7RELVbGQ>