What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash problem
someone has been having over more than 2 years. There are boot time crashes
involved.

It appears that 0xFFFFF80000000007 is showing up in use and stored in data
structures as a pointer value in fields/arguments that are pointers, where such
a special value would not be expected. Later defrerencing does not go well, at
least when the dererefenced data is then in-turn put to use.

The small offset from 0xFFFFF80000000000 suggests to me that the special value likely
is inappropriately left around and somehow picked up and used. 0xFFFFF80000000000 (or
near it) might be odd enough to have only a few known likely possible usages. Such
notes in the bugzilla report would be good if such is the case. Thus my question.

The context has amdgpu raven support in use normally. Reportedly the problem has
never been seen with that disabled. (However, I'm not aware of experiments with
alternate card types, for example.)

Where, when, and if a boot crash occurs is variable, not stable. But use of the
list found_modules->tqh_first->. . . tends to be involved.



Some other modern 13.4-RELEASE related context notes
( comments #231 and #233 ):

The person with the problem reports . . .

I am not using a stock distribution of the kernel:

diff -u sys/amd64/conf/{GENERIC,M5P}
--- sys/amd64/conf/GENERIC 2024-07-03 16:23:56.252550000 -0400
+++ sys/amd64/conf/M5P 2024-07-03 16:25:05.287604000 -0400
@@ -18,12 +18,13 @@
 #
 
 cpu HAMMER
-ident GENERIC
+ident M5P
 
 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
 makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support
 
-options SCHED_ULE # ULE scheduler
+#options SCHED_ULE # ULE scheduler
+options SCHED_4BSD # 4BSD scheduler
 options NUMA # Non-Uniform Memory Architecture support
 options PREEMPTION # Enable kernel thread preemption
 options VIMAGE # Subsystem virtualization, e.g. VNET


I also noted (for modern 13.4-RELEASE times):

Also: the build is based on the -p2 source code (hash 3f40d5821):

# strings boot/kernel/kernel | grep "\-RELEASE"
@(#)FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
13.4-RELEASE-p2

Because it is a rebuild, the kernel ends up with -p2 instead
of the official -p1 ( from -p2 not updating boot/kernel/kernel
in the official distributions ).



===
Mark Millard
marklmi at yahoo.com