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

On Dec 15, 2024, at 20:13, Daniel O'Connor <darius@dons.net.au> wrote:


> Hi Mark,

Hello Daniel,

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

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

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"];
z0xfffff827c9e7dc80 [label="r1w1e1"];
z0xfffff827c9e7dc80 -> z0xfffff827c9e6d800;
z0xfffff80105633a00 -> z0xfffff827c9e7dc80;
z0xfffff8255c020300 [shape=box,label="SWAP\nswap\nr#4"];
z0xfffff80e3c0bed00 [label="r1w1e0"];
z0xfffff80e3c0bed00 -> z0xfffff80105633e00;
z0xfffff8255c020300 -> z0xfffff80e3c0bed00;
z0xfffff8010553c300 [shape=box,label="PART\nda0\nr#2"];
z0xfffff80105531700 [label="r0w0e0"];
z0xfffff80105531700 -> z0xfffff80105337c00;
z0xfffff8010553c300 -> z0xfffff80105531700;
. . .
z0xfffff80105afa080 [label="r0w0e0"];
z0xfffff80105afa080 -> z0xfffff80105631000;
z0xfffff827c9f56400 -> z0xfffff80105afa080;
z0xfffff8013806b800 [shape=box,label="DEV\nnda0\nr#2"];
z0xfffff827c992f580 [label="r0w0e0"];
z0xfffff827c992f580 -> z0xfffff80105931200;
z0xfffff8013806b800 -> z0xfffff827c992f580;
. . .
kern.geom.confxml: <mesh>
. . .
  <class id="0xffffffff82461c78">
    <name>ZFS::VDEV</name>
    <geom id="0xfffff80105633a00">
      <class ref="0xffffffff82461c78"/>
      <name>zfs::vdev</name>
      <rank>4</rank>
        <consumer id="0xfffff827c9e7dc80">
          <geom ref="0xfffff80105633a00"/>
          <provider ref="0xfffff827c9e6d800"/>
          <mode>r1w1e1</mode>
        </consumer>
    </geom>
  </class>
  <class id="0xffffffff819375f8">
    <name>SWAP</name>
    <geom id="0xfffff8255c020300">
      <class ref="0xffffffff819375f8"/>
      <name>swap</name>
      <rank>4</rank>
        <consumer id="0xfffff80e3c0bed00">
          <geom ref="0xfffff8255c020300"/>
          <provider ref="0xfffff80105633e00"/>
          <mode>r1w1e0</mode>
        </consumer>
    </geom>
  </class>
. . .
    <geom id="0xfffff8013806b800">
      <class ref="0xffffffff818b7560"/>
      <name>nda0</name>
      <rank>2</rank>
        <consumer id="0xfffff827c992f580">
          <geom ref="0xfffff8013806b800"/>
          <provider ref="0xfffff80105931200"/>
          <mode>r0w0e0</mode>
        </consumer>
    </geom>

So: Only seen in such kern.geom.* related sysctl -ax output.

Thanks: I'd not considered looking at sysctl output.

> However it is hard to think of why that value (or a small offset to it) is getting put in places it shouldn't be..

Certainly does seem odd.


===
Mark Millard
marklmi at yahoo.com