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

From: Daniel O'Connor <darius_at_dons.net.au>
Date: Mon, 16 Dec 2024 06:35:55 UTC

> On 16 Dec 2024, at 16:18, Mark Millard <marklmi@yahoo.com> wrote:
>>> On 16 Dec 2024, at 10:33, Mark Millard <marklmi@yahoo.com> wrote:
>>> 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.
>> 
>> That value (0xffffffff80000000) is kernbase (see sysctl kern.base_address).
> 
> On an amd64 system that I have access to:
> 
> # sysctl -x kern.base_address
> kern.base_address: 0xffffffff80000000
> 
> But, while looking similar, it is not the same base number:
> 
> 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:
> 
> kern.geom.confdot: digraph geom {
> z0xfffff80105633a00 [shape=box,label="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