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

From: Karl Denninger <karl_at_denninger.net>
Date: Mon, 04 Dec 2023 18:00:17 UTC
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./

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/