Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs
- Reply: Xin LI : "Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs"
- In reply to: Xin LI : "Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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]/