From nobody Tue Dec 24 22:59:04 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 4YHr1P3KRPz5WrnV for ; Tue, 24 Dec 2024 22:59:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4YHr1N0JT0z4bN7 for ; Tue, 24 Dec 2024 22:59:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="A6mvJGU/"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1735081157; bh=66d8YpLjoejv4cnrgWFk3SGdfIt2VqlXjgp5/75Z864=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=A6mvJGU/CMLhU/UAnxmoDnFzFnxISSvdq347VYgLTZSHOHQlV9U13enOAweIzZlx5LflR7tt6OHUsdZUkiiLbymJpfWA4mS3o5BJWl7Z/X+y1UqDVRIDM0pEBIEeAdBdKcufYZKI73RiLuzVqzpDRZiSv12dOv7h59UIj/IIFRGeBz4wWufUd2nUWHaRBStWkoWAYmibu3sOb1HRtjpKCNFj2S1SpZe23PJRJT1bYgw6nR2vslevwC4B3YSlrw2QyWBgYMnnDgCakSuv6mVH+VR58h9/hB86crnQDaTXdYp7raYPqjaBuzfDCj7u50Fh5prZp3QHcrflgNlr1R30gg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1735081157; bh=6Z3Ltrn2JbzNAgWr1yRp5Uw1yoUKp/fgGNhi/1GBKsa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OcL2gD/Nu/KIfPqOPZz12181o+wbk9gLTEuVmGHMjkCvX0Bmc/0vhyB4cepXah8lzyrbXnl/zoKe+pKcH0uz/wi9iET6feeFGopYbNB6D4x6Skqwx4MzuJFT3/FwG4JPrsZK2lcHORw+lu7wttAtqKoeouTp1p3MKpiU1C0m73KufaKH9bNcpi48wYqsdFEo3Z75U8bjtJN/VANBhlDX8rZJyUZUsnlQZQYraFw8gE9vLe37zo0EjfwzNxqfKJeUejpbjBmlTX0nqxYods8BaGHaWObe8FZIaFZwXj3K85MSjBmxoyzo1YlMfObijrnrE/z044KQ8MWcvxHSCv5EnQ== X-YMail-OSG: GtKk2.AVM1m8hJYF7OQ4t88MpzradhWJOqzstUPnI3SiK_W5vdlnXAQlyrTTrtJ uaU.rwIR9zhvHyPy.bBFrPdZnLGQKgbrlN.tjTOPJs0cw1i6A7iNDaGDwDx14hmVNvj_JbTVVmr3 WhR0dSo2ETd2YaPhbfL8jGFnXUSih_r99mV3R7KH1h0nIYTfWGLrRUnaDk0fJG8XeMS_MTA2CPTB bP_Dt1uBNx23lm6muZbFfAzxzZAkzRyUHfN6m03_sLFToobyEbBtCbIHklgToJZYS.YIx40LIDvC uIDToTs.yTATudS6tHZoxr_5SYpMEk2DnFYAd9eQNo6udJWjbaM4PDPRgHequgPplKHi_tni4UXQ zyINgVJ6BbKjWrvY71Roj74fuS1cBhIYJWirP0UBcGLGH6sa9oM5CB7GiEQZvcslOXu_sGM.d4m6 esEKqDG.6IYT3SWh_OyCFfgnPdJqdbUJHPX3hMEyl8p0LLQ2mSGABocFVvlThJvAG5FOVLvtNZeC CqUQACX5_Mfl61kXBK28inRQ47tpwRylzmm8jz7AHTBkYQP3q5w9yfer5U5F1eNsaYpHKyUTza8x awXmgM5ugI0z39NsUbgY4aoNyjOdM.1PCBZwJQs6mtFTBV8lu4gVs2ZM9BRrDwxxF416zqldQ9_B AHVAVxgwpPjTn34tlLX8zrUu9ji7y7KJywoxLDFqgfRhcVykn9MXuFLkK795dBhBB4FPhoRyGF98 GfRTItp3cB9Y0Yf3QyS1HWvG9aB1ilJ5AlEeDPuBL5V0rK1n7ghorkT_HHXKLa88RHpLiXE8_SF4 GjAs1wbSCXeDw6wOFoYnTme.Fuetuky2Di2zjWxAQKyg8edvKG0LQIGP8XWNjNNUHG6Vr16aZM02 LmU_qkd.4cI7paR96tARYrsvPPZA_VjBbwWKRcquPaKh792b9iAOnODaZ4an3yHZC7FBmKdMuE1w pF_bp3U5cDq8HZWEjK0EUypWFiRYp0QNSQLS.mp3YoxEn07Zup4QIpb6ocJF_PIeqUivKVJOPmtF FeIJVksvJe05jv9CbpM.kWM7JejhMbBEgYP6modzVpEpyp7vZNJbg9zHg8omEv2wlbrrqhBUIxT3 oG.YUjyhRpcsmmv8XU099aBMwoi7R9L4q1detSTFlFuxuGEpodiW4bH_XcKxu72zRfQUsppgwT1e W7ymRz9emL_aTSijz6fgvH4FCNNUs_T4qbD5WHkLD9daDQ3Yy2palN26JQc7k7BSqGNEx6cyaHjm _qpIXhIbGXoxhrSKZPEQnkpLnrWhbbIxI..OhmM8thub.ICRbE_iQlJUj8T3NvU9n.OGosuAsRqJ W4Hru_sjsKrMZJvxdgxxxnQ8JjxyJiFIep39kJKjp7R0KIvJH3YKxi2JAGxtwphWwf9SQrIbfvqo vLuQC8t2gsDYH8jeWKA3hKSUa7f_XymTdDuQ4Z2wVSvtme0EKhVPfgUw24N_I.efY8yCMllLTl.D .XqERXTVa4OMuyEdiP5iavQJKv_XeyFDgafUYIrtsLH1vF70qe.WiD8XFt8iQQbIPEHPkK6opbLv qrcKpQwK5SLd_dZ6LMSx8qyusIdgReHFyko82f.7peJxDul9CKdAM.kf2JrvshGYIMGrNWntkGRR Bio8VV7M9SbZxZxFY4CVTxwxSYFjCiHqKTuSVhdwEAE3fLJIGJ0LU1d5yThUgtJ46BPIc3uiFL7p awnT3WM.WuqEdFct.yLIsVaWI3AgW5WStY8VdOEBKVZtGyQYgOUyzCO4yKD0KRjF66udO.4tDQhA KZsZ.8xaWypw8bXRA_50RvGy5Z2B.LkjZvau0DOEyFwKgW8l5OH4hgJ.jfFudqXBsOTyj5YTmyyT mOxzG14MDkYRNlTaPCTiCChjeFYmpBftn.XujQZ7TmcH68LsYsFqekbYyKzTjdMVziqQ_Xb9iFHA 4yOvuUBV7uOkDNNnsuSJYcIKT9K8NCN4WSRMUQfn5JZ.5K9cC2A46nBkRd6gmSmeEeAp8Q.fWYzV 4haBDrMSMeIItY9jhSzRyk1167NcXOd1Oq9T_jkXh8YTloPv4xEMROD2yR0JAfc0T5e4pf4vhR_r cWzW9kGE4Lru.OfTY8wKtHEXEKVPL0R8J6GyKLgeEcd3cpKnPLzSvpe9ojFal2AwslwjHnaFdJI1 CNWdvEKyxZRN5ZggRDTnM5RyJGQUiJ1QCOYpFwIqEeL7HDCBlXmGX3pRYa1AYCboijer6VCKMG5b BGU1hiXAeKf5V X-Sonic-MF: X-Sonic-ID: 97456daf-faf5-4da6-a68e-a5ef388da8cc Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 24 Dec 2024 22:59:17 +0000 Received: by hermes--production-gq1-5dd4b47f46-bxhh2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6be435d67c12631047fa5ea2b3d4e104; Tue, 24 Dec 2024 22:59:16 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Should the page identified by DMAP_MIN_ADDRESS (or DMAP_BASE_ADDRESS) allow reads and modifications? Message-Id: <34600372-47D4-4FF2-9BA2-805A5DDA5402@yahoo.com> Date: Tue, 24 Dec 2024 14:59:04 -0800 To: freebsd-hackers X-Mailer: Apple Mail (2.3826.300.87.4.3) References: <34600372-47D4-4FF2-9BA2-805A5DDA5402.ref@yahoo.com> X-Spamd-Result: default: False [-2.25 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.75)[-0.751]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from] X-Rspamd-Queue-Id: 4YHr1N0JT0z4bN7 X-Spamd-Bar: -- I've been helping someone gather some evidence for amd64 crashes they have had for over 2 years. [Their context recently updated to 13.4-RELEASE-p2 (so kernel 13.4-RELEASE-p1 in official distributions. They do their own kernel builds and -kmod port builds.] Having a boot-crash is intermittent but often enough to be an issue. Most of the boot crashes have been tied to the found_modules list. But there was once rare evidence of elsewhere as well. (Another of the lists, for example.) For reference: DMAP_MIN_ADDRESS == 0xfffff80000000000 in the context, as seen via vmcore.* (kernel , *.ko, *.debug) and kgdb use: (kgdb) print &dmapbase $6 = ( *) 0xfffff80000000000 (kgdb) print dmaplimit $12 = 0x240000000 My understanding is that 0x0 (a.k.a. NULL) and DMAP_MIN_ADDRESS both identify a low byte address for the same page but via distinct address ranges. Should access into that page via the DMAP_MIN_ADDRESS based address range refuse to allow modifications to the bytes in the page? Refuse to allow reads of bytes in the page? Refusal would be a cross check on having avoided use of PHYS_TO_DMAP translations of small non-negative offsets from NULL, for example. [But, for all I know the kernel may sometimes need access to such. This is a learn-as-I-go investigation.] The refusal would also be an earlier rather than later indication of a problem if the page really should not be in use (small offsets from DMAP_MIN_ADDRESS). For reference . . . There is evidence of 0xfffff80000000007 showing up as an address that is then offset by 0x18 to produce 0xfffff8000000001F and that being used to get a char* from RAM. When that junk-value (0xe987f000fea5f0, as an example) is then in turn passed to strcmp, the strcmp operation gets a general protection fault from the junk-value's attempted dereference. I'll note that the 0xfffff80000000007 value has been stable in the vmcore.*'s that I've looked at, despite other variations across the vmcore.* 's. The node in the found_modules list varies but the value always shows up in the link.tqe_next field in the node that ends up with the value. The likes of "info sharedlibrary" and "info files" indicates more loaded after the name indicated for the node with the link.tqe_next 0xfffff80000000007 value. So far for the crash examples for found_modules related crashes, the first .ko to load after amdgpu_raven_vcn_bin.ko (the last of the sequence of amdgpu*.ko files) ends up detecting the problem during strcmp, as shown in: #6 No locals. #7 strcmp (s1=, s2=) at /usr/src/sys/libkern/strcmp.c:44 No locals. #8 0xffffffff80bc0ab4 in modlist_lookup ( name=0xffffffff829fd0c4 "vboxnetflt", ver=1) at /usr/src/sys/kern/kern_linker.c:1488 mod = 0xfffff80000000007 (mod is from a node's link.tqe_next value that was 0xfffff80000000007 . mod->name's value (a const char*) is passed to strcmp.) "vboxnetflt" is just an example. changing the ordering has had acpi_wmi.ko and zfs.ko listed there instead, what ever was next at that point. === Mark Millard marklmi at yahoo.com