From nobody Mon Dec 16 05:48:45 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YBTXL3z0gz5gwcw for ; Mon, 16 Dec 2024 05:49:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YBTXK66Sjz4NCk for ; Mon, 16 Dec 2024 05:49:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734328143; bh=i2MvppBsFKhlJqN4/mEffoGFJneWWAFY/vjCRVyL1qY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZTlQblc0hsHZBjJAZa/+q7maW0tUQ/t04kiRacxAV6Zh93iiZfhKz+KO4QXOrbA2DDgp/bJds6YPX+XCrVjIbvvFBvdyx7A59ADnLE8i+4CP/+PfyscgfqSCvz8Bu9YXNoPnSZlxENugJIcupmWNOegxxhKMipxoNciloZ+4Bz8skf6I9rmatOmhgvXpne0cbpf+LRkQrwigUu+jOJAxJ0yJlHhdlkB4tIeagBPziGK7+n0ilDoCt8lki00ExHfl398kW2tEgGJgA3bRNzwag3bOl7COVQPsniLx15TGA3DqwztHRCRp/kHtAV+H5U8jFXPP5hm8wplWXav49lhNzA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1734328143; bh=bZ8pyFD11Ak73UctFbb+8i8rOwu7e6P82U6sl7fibCC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gy+N49PoWlaUf+QwAa+IEGQ8IFQF2zrRF2qE1Sl9uCRX+czHk5uq/WhnKX7wu9INBplHiRvOztL4Vtrfc443kWWCijeijhEXnxX5lySTGdMNx4ZKTjys176m9VrS3dQ0mjeX46SEX5xrTjnCJXeR9JqXvPwPnl6C9tkls/5S8UGJcAHUlWt+OeeYwjm6HGTI64KwhlRf0kgSCIfXn9dmG9LE4VI4QEWYZCf2rp1+EY9R814ctFk2Uo0s7TCtBEMu1qRGM7PqsKRzdFK3otdDqw+MhDw78CSaE3+LxBwt04mXy+oUBBSmD94l1t96dIKZS2mP+AleDk/tPRYBL+/sBg== X-YMail-OSG: 2D6y..0VM1nW733Laf0tH_CpE3xMPTI.f3btRqi26I4y0O1PZZhKAIEidK156Cf D0V8CvdcbHW5XjUHs2X7obC1RvtZ3s00m_IUPYbJiut1PRxgwCCBOtpkHouPukJ2wjLKJjzrEeDp RsTIxNdU4eoZR3QRQOiDXlTsU0A8yIbHBlR.Q2e8G36EHf6xtWFFFcgzeplBsfMKtzNQlCBeZBCA XuR26859.6NMzRIpqdtgsDIjxNq4fdFjClCJbhxH4sImZtp3ERdNwbO4bO3FmmZNniM2odqzYppH LGfYmrUs6D_VsLNBu3fjt7LV8A5PWIe3wx3G4q5dluHvuqgqdRL7NIv9ZiMbYfk5LQLWscuulqqr 4los7ehJergzMKI_bZQ8.kz43dj_mKztyb6zYKIswYeryZBWKbgJESkcBNTSuJB5v4cmfNsVXNV5 nERGES.c3yB1m3Wc_XQXrhTzt63j8xE2fUt3UT1xAjLOWCUcP9UOSVfOxyg23ERuPQkVzynBCPrY bZE.uCYwrjPb6ptaCeoOWL4s85YCrTPEU9btfqOXmr3H7fpsHGmNz4ZHhbjNxfeht67aqtnLDEpZ G5R9y.2IflEl0YvCgLpwZEX7gLaVDnr1rCG5yt1cQhIONf4JIS_QlJFZRWtliebWkGVKEbphbdlj doKKytEpj86ZS2wQZU8dWrzy7YLxmYxiTfk_tJyZcOVv6Vh8ohp5hp18F4cSXLKyQKr9uKJNsN9s a5f03QO4NwCMLDJXaCGulSWH5scCzRboxAjbXJtlMCIrc6WXSSkLSaEh2ATHrVwiNviRt2Pzy59A N958zkDhWbQ2t06_6NR.IKPP5HIbzoCFPtW4dfa9jrWIZGcAP6Dqrmak7mtR2y7nn9OaoqscAtOb jkRNDvim8mfrjFNgwPpXk1XnEH2iGp.2C0niW3bj11J1CDO3GxcNXjLb1tggepSfzM74Rxuv5_kQ Sq4_ElThKcwTpaErfY0l1xqA3Yjbo6p6nkFiOPr8hLmwf2jxm8mTGD2TUQJXrPhzIqB.Vf59cXHD 4TXG7uOW5SOEmI7bOTrhCAXyj7vSsc5EMKjfn5GuUJI0U61B8mvx9swL3ULQKOaKDCtXNtjBKTvj 8nDtpYLV70EICzoaAl9j.RoeOysrolpE59QqmmKMlESk8qe6b7qbHx_niEtyi75cVRg_J1y.x33R bXMKqPFcOuwrFd0JGQwn3IyrhrFyeS.0IMC3iKHxMe4qViUwpZPzH7gupnXg_w9Uwq87JWtvL1Ql AvPlT6zHUQvwRZoB20EMOujl.A5k6eNo.T5Qwismf8KJga64zYD0kTV9bRiRURAaU5VU57nGdXqN 1dfXVBpPm_HwEiuI9A7g28gi0Hgwlukd2mcHcnH4ZKJVQOwwwrgNiLnaRiMuVyeO5YeuOi.q7wMa bPSRg9qh4fRYfKlAijAE6g2P714Ealt.YEanklnm6bsdnKW_xPJyiQoauVDcegeYHj6cNo7nodqs bOd02Avyd6XUqWD81du02.a7MZhjyjh1sOL.lvu9uv6mOvmCQou8ASidnxgptkGxWWTeX3XUQC3k vq3xEDUdyMoJdZLujxpyA9UPXyFX1vjSeo62QBxHPAWwxJGvIfUVkiFEY9WYod6fEtQtPY6_787t imqurXEC_vIB0NN9gG9JMwTJqTY_6q4Un8KiddmBXuPlAcPG7nznDd6Dbqu7Di9mk0SLfPjuErfX xYOqlJ.S_s2eUBK0fnjZIcQrzx5GqcpNfLgGYqDRZ.XP0kiUy_EcaYzlXDdsN1_WV8h9szDN4GQe Kh0q_1bGQ1Y3aZB4tslKwlkjjTu3N1J76kJNDSItqqy1HKOomkx9tgLvo9lIL_FqoYs43kfQdpdF log3xPOjtoXeKEdoXKV7dsUZ6DibR991GIrNS75P7qr.njLwbrKIskEu.Yb64L95mArsoZMvZKrW sxRN76LuDJxmAd.VcjT3pFsm1YSf9Hytv.yhcpqkMn3UR.sRDrf4ifVHvARv0oJaqr6Cfbc2wuXe YhVGg2IPwoIPOWBK22b7GWx1JSqtbXcimoonZA_Dij26D0SKVjGPPM1Ydef5XPU0P6i_UrLAD3_k h04l3nSHzxCfw.demcEpOIRpG0wtqjos9sDH0aZY.EMcq2RhtSi8MbFzbh3Kz8N6SZ54rsArxhhY bzGjUJ839Gk03CN.FxmQvGebYjE_rJ9VzofpCdBKGgSdKHpsWQEHVnnuTWzqUX3ummgbzVQHhaWP Vh.LYWMi8bFStagLSKg07fyseTzwKlaH0DatUVLhMGt92jG0IsS6owC7U.agqIZB9HRMg1YaAqg- - X-Sonic-MF: X-Sonic-ID: 1a89d55d-ca63-4714-b2f4-3f351511bf74 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 16 Dec 2024 05:49:03 +0000 Received: by hermes--production-gq1-5dd4b47f46-5xsmt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec0cbc91b415346e55b2360efa58ebfe; Mon, 16 Dec 2024 05:48:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: What kind of code might generate amd64 addressses like 0xFFFFF80000000007 or be based on 0xFFFFF80000000000 ? From: Mark Millard In-Reply-To: <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> Date: Sun, 15 Dec 2024 21:48:45 -0800 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers , freebsd-amd64@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <65B0673C-287A-47E5-A732-17CC5EEE3350.ref@yahoo.com> <65B0673C-287A-47E5-A732-17CC5EEE3350@yahoo.com> <8C32FA41-C0EC-4679-9E26-B7CC3C69ECE6@dons.net.au> To: Daniel O'Connor X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4YBTXK66Sjz4NCk X-Spamd-Bar: ---- On Dec 15, 2024, at 20:13, Daniel O'Connor wrote: > Hi Mark, Hello Daniel, >> On 16 Dec 2024, at 10:33, Mark Millard 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: . . . ZFS::VDEV zfs::vdev 4 r1w1e1 SWAP swap 4 r1w1e0 . . . nda0 2 r0w0e0 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