Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs

On Mon, Dec 4, 2023 at 10:00 AM Karl Denninger <karl@denninger.net> wrote:

> On 12/4/2023 12:51, Xin LI wrote:
>
>
>
> On Mon, Dec 4, 2023 at 8:32 AM 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 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 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: *The
> "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,