Date: Sun, 15 Dec 2024 21:48:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: Daniel O'Connor <darius@dons.net.au> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, freebsd-amd64@freebsd.org Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? Message-ID: <D069E39E-CC3A-4F00-8475-1F6BE10711DB@yahoo.com> In-Reply-To: <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> References: <65B0673C-287A-47E5-A732-17CC5EEE3350.ref@yahoo.com> <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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=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). 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=3Dbox,label=3D"ZFS::VDEV\nzfs::vdev\nr#4"]; z0xfffff827c9e7dc80 [label=3D"r1w1e1"]; z0xfffff827c9e7dc80 -> z0xfffff827c9e6d800; z0xfffff80105633a00 -> z0xfffff827c9e7dc80; z0xfffff8255c020300 [shape=3Dbox,label=3D"SWAP\nswap\nr#4"]; z0xfffff80e3c0bed00 [label=3D"r1w1e0"]; z0xfffff80e3c0bed00 -> z0xfffff80105633e00; z0xfffff8255c020300 -> z0xfffff80e3c0bed00; z0xfffff8010553c300 [shape=3Dbox,label=3D"PART\nda0\nr#2"]; z0xfffff80105531700 [label=3D"r0w0e0"]; z0xfffff80105531700 -> z0xfffff80105337c00; z0xfffff8010553c300 -> z0xfffff80105531700; . . . z0xfffff80105afa080 [label=3D"r0w0e0"]; z0xfffff80105afa080 -> z0xfffff80105631000; z0xfffff827c9f56400 -> z0xfffff80105afa080; z0xfffff8013806b800 [shape=3Dbox,label=3D"DEV\nnda0\nr#2"]; z0xfffff827c992f580 [label=3D"r0w0e0"]; z0xfffff827c992f580 -> z0xfffff80105931200; z0xfffff8013806b800 -> z0xfffff827c992f580; . . . kern.geom.confxml: <mesh> . . . <class id=3D"0xffffffff82461c78"> <name>ZFS::VDEV</name> <geom id=3D"0xfffff80105633a00"> <class ref=3D"0xffffffff82461c78"/> <name>zfs::vdev</name> <rank>4</rank> <consumer id=3D"0xfffff827c9e7dc80"> <geom ref=3D"0xfffff80105633a00"/> <provider ref=3D"0xfffff827c9e6d800"/> <mode>r1w1e1</mode> </consumer> </geom> </class> <class id=3D"0xffffffff819375f8"> <name>SWAP</name> <geom id=3D"0xfffff8255c020300"> <class ref=3D"0xffffffff819375f8"/> <name>swap</name> <rank>4</rank> <consumer id=3D"0xfffff80e3c0bed00"> <geom ref=3D"0xfffff8255c020300"/> <provider ref=3D"0xfffff80105633e00"/> <mode>r1w1e0</mode> </consumer> </geom> </class> . . . <geom id=3D"0xfffff8013806b800"> <class ref=3D"0xffffffff818b7560"/> <name>nda0</name> <rank>2</rank> <consumer id=3D"0xfffff827c992f580"> <geom ref=3D"0xfffff8013806b800"/> <provider ref=3D"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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D069E39E-CC3A-4F00-8475-1F6BE10711DB>