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

> On 16 Dec 2024, at 16:18, Mark Millard <[email protected]> wrote:
>>> On 16 Dec 2024, at 10:33, Mark Millard <[email protected]> wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267028 is for a =
crash problem
>>> someone has been having over more than 2 years. There are boot time =
crashes
>>> involved.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> That value (0xffffffff80000000) is kernbase (see sysctl =
kern.base_address).
>=20
> On an amd64 system that I have access to:
>=20
> # sysctl -x kern.base_address
> kern.base_address: 0xffffffff80000000
>=20
> But, while looking similar, it is not the same base number:
>=20
> 0xfffff80000000007 (copied and pasted from the kgdb session on the =
vmcore.*)
> 0xffffffff80000000

Oops, my mistake!

> However, kern.base_address might be something that varies from
> system to system in some way.

Your value is the same as mine on this amd64 system - I don't think it =
varies (for a given architecture anyway)

> The closest examples I see in sysctl -ax output, start with
> 0xfffff801. . ., such as shown by:
>=20
> kern.geom.confdot: digraph geom {
> z0xfffff80105633a00 [shape=3Dbox,label=3D"ZFS::VDEV\nzfs::vdev\nr#4"];

I assume these addresses are pointers to the internal GEOM objects =
(because they must be unique) - ie they are actual memory location.

Hmm, perhaps 0xfffff80000000000 is where kernel RAM starts?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum