A possible unintended difference in 13.1-RELEASE vs., for example, 13.1-RELEASE-p3

From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 04 Nov 2022 03:50:37 UTC
I downloaded and looked at:


# mdconfig -u md0 -f FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
# mount -onoatime /dev/md0s2a /mnt
# strings /mnt/boot/kern*/kernel | grep 13.1-RELEASE
@(#)FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC

Note the: releng/13.1-n250148-fc952ac2212

Looking at the live system after the freebsd-update to
-p3 :

# strings /boot/kernel/kernel | grep 13.1-RELEASE

No text analogous to: releng/13.1-n250148-fc952ac2212

I'll note that the actual 13.1-RELEASE-p3 for the binary
release build appears to have been a build of at:

author	Mark Johnston <markj@FreeBSD.org>	2022-11-01 20:54:33 +0000
committer	Mark Johnston <markj@FreeBSD.org>	2022-11-01 20:55:10 +0000
commit	c3c13035ef270dcf0d24d2d847dd590edc535ed0 (patch)
tree	f6582d69009a70d8ae8b52e00da4cabe6d159fb7
parent	e81b1bd17fb4e83865d60461c2554d90f72cd395 (diff)
download	src-c3c13035ef270dcf0d24d2d847dd590edc535ed0.tar.gz
zfs: Fix an improperly resolved merge conflict releng/13.1
Approved by:	so
Fixes:	8838c650cb59 ("Fix use-after-free in btree code")

-rw-r--r--	sys/contrib/openzfs/module/zfs/btree.c	1	
1 files changed, 0 insertions, 1 deletions
diff --git a/sys/contrib/openzfs/module/zfs/btree.c b/sys/contrib/openzfs/module/zfs/btree.c
index 77cb2543e93d..09625bc92f92 100644
--- a/sys/contrib/openzfs/module/zfs/btree.c
+++ b/sys/contrib/openzfs/module/zfs/btree.c
@@ -1766,7 +1766,6 @@ zfs_btree_remove_idx(zfs_btree_t *tree, zfs_btree_index_t *where)
 	zfs_btree_poison_node_at(tree, keep_hdr, keep_hdr->bth_count);
 	rm_hdr->bth_count = 0;
-	zfs_btree_node_destroy(tree, rm_hdr);
 	/* Remove the emptied node from the parent. */
 	zfs_btree_remove_from_node(tree, parent, rm_hdr);
 	zfs_btree_node_destroy(tree, rm_hdr);

I'll also note that none of the FreeBSD-EN-22:* notices
lists an exact match to what was actually built for the
binary update.

That would have been true even without the merge conflict
fix, in that, without such involved, the final build would
normally be based on a "Add UPDATING entries and bump
version" type of commit after the last of the FreeBSD-EN-*
commits reported.

In other words, nothing seems to record and show anything
identifying the actual commit used for the binary update.
That could also be of interest to folks that want to build
by starting with the exact same source code vintage as the
binary update did.

In this case:


looks like it needs an update because the reference:

releng/13.1/                            8838c650cb59  releng/13.1-n250167

is to before the "zfs: Fix an improperly resolved merge conflict".
That update will identify the commit built for the binary update.

Mark Millard
marklmi at yahoo.com