From nobody Mon Dec 04 19:59:51 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SkZJj3jJMz52ljx for ; Mon, 4 Dec 2023 20:00:05 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SkZJj0Bjqz3c1X for ; Mon, 4 Dec 2023 20:00:05 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-54c77e0832cso3212194a12.0 for ; Mon, 04 Dec 2023 12:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701720003; x=1702324803; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ku8zh68lcxXowf5INjrFfcK0oSKST70IKvk1huhEdmM=; b=ULiaWwiLucXWBXKXJRa1+mfdOT5NBPEdqYePwV4iawWfn4Lbfrb7dNTfUwHUJ/Io3Y 1Zv7vhZGplI0IyvX0Or2d0FZOhRwWYoP1xWqMir3gswoBLUgMSweIuHacUWKlJXqx7M7 PRJ2dxC5aqIU0wZ6KWxgQQenjs7zdDrrsZZ4HHmtwSnnhcYndu2f9pmtcEy+fsO+GwvW 09v0Z+5M6jzXa6Ym26xWFkajMGJ6DFqH6mZPYMtR6U5eRJCHF67QJ2x70wGY8tOdD7qU jod8Cl4Q+8un2k5abW+npGziO+1aN6dzgTlj4kA+IDM0ccwd4vo8/x9Z8dHzFrCJ4Zb+ UJEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701720003; x=1702324803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ku8zh68lcxXowf5INjrFfcK0oSKST70IKvk1huhEdmM=; b=t+6g0XFafvTtSa3bP1CjjcVMaABWxOttHu0hDKHLhVIiOAxlZubY5mqqnsiq7LZd2u KdvPPTeHUQOP+Af15w2qZCdVKqIv63OlMNwryzCiNyywMHfnERCG8BXkqEvZgEXuqJ5B 0HeYqASj4ydR6nahiIdwLqGPxqESCZd1xW6Pg+zw3KJFnlvviEe3gzOU9sOejGhEJOSr mVHhyc8IM02LP4gZYNW+yrkGr3YZa3wn/QASeOlTH++VgWWbpPQeLpqZK7QXJ0pKYZES S4ZyBXL/hK7hquD0JUqepbZruQN0fHmQSKQ1jn33rA6M4MloPtUVzd6SwtWwND9EMFkD rNqA== X-Gm-Message-State: AOJu0YwWzypSpZuT1Clhp5clf3Hpmp4prV3vzWVDtmagpeAtRg0pXDjN vTgvxhxBJtDEiiXxR1XQsi0bVaSLbUCqAEdqOfnHJ3EJf+s= X-Google-Smtp-Source: AGHT+IGxIAi3Y/TemKJK/gNyX7OOP+ie+JCf21O+5fker+GdBCa+h312gB3v+SvoCr0u/i4UutUbJdxqeS24cyTx5bM= X-Received: by 2002:a50:8749:0:b0:54c:4837:93f5 with SMTP id 9-20020a508749000000b0054c483793f5mr2949894edv.60.1701720002838; Mon, 04 Dec 2023 12:00:02 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <20231201031737.DF0231B942@freefall.freebsd.org> <445y1eaxiz.fsf@be-well.ilk.org> <20231204230246.f11fce2914500a99e094de0b@dec.sakura.ne.jp> <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> In-Reply-To: <02ab3650-3e42-4e92-a14f-559d9d3b0b13@denninger.net> From: Xin LI Date: Mon, 4 Dec 2023 11:59:51 -0800 Message-ID: Subject: Re: FreeBSD Errata Notice FreeBSD-EN-23:16.openzfs To: Karl Denninger Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="00000000000046c6e4060bb49013" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SkZJj0Bjqz3c1X --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 = wrote: > On 12/4/2023 12:51, Xin LI wrote: > > > > On Mon, Dec 4, 2023 at 8:32=E2=80=AFAM Tomoaki AOKI > wrote: > >> On Mon, 04 Dec 2023 08:48:52 -0500 >> Lowell Gilbert wrote: >> >> > Kurt Jaeger 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


On Mon, Dec 4, 2023 at 10:00=E2=80= =AFAM Karl Denninger <karl@denning= er.net> wrote:
=20 =20 =20
On 12/4/2023 12:51, Xin LI wrote:
=20


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 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.

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 whe= n 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 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.

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).

Cheers,
--00000000000046c6e4060bb49013--