From nobody Tue Jan 4 15:05:53 2022 X-Original-To: freebsd-stable@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 9BC50193561D for ; Tue, 4 Jan 2022 15:18:18 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSx8948fcz3pSq; Tue, 4 Jan 2022 15:18:17 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 204FI4Nc048005 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jan 2022 16:18:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with UUCP id 204FI4AZ048004; Tue, 4 Jan 2022 16:18:04 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 204F6QDt038399; Tue, 4 Jan 2022 16:06:26 +0100 (CET) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 204F5rtJ038177 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jan 2022 16:05:53 +0100 (CET) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 204F5rEY038176; Tue, 4 Jan 2022 16:05:53 +0100 (CET) (envelope-from peter) Date: Tue, 4 Jan 2022 16:05:53 +0100 From: Peter To: freebsd-stable@freebsd.org, markj@freebsd.org, jtl@freebsd.org Subject: Re: dtrace bitfields failure (was: 12.3-RC1 fails ...) Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Tue, 04 Jan 2022 16:18:07 +0100 (CET) X-Rspamd-Queue-Id: 4JSx8948fcz3pSq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org X-Spamd-Result: default: False [-2.30 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sub.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hija, sadly, I was too early in agreeing that the two patches 22082f15f9 68396709e7 together do solve the issue. They only do on a certain assumption, which does not hold true in all cases. Let's look at https://reviews.freebsd.org/D27213 This is the code in question that will trigger the action: if (dst_type == CTF_ERR && name[0] != '\0' && (hep = ctf_hash_lookup(&src_fp->ctf_names, src_fp, name, strlen(name))) != NULL && src_type != (ctf_id_t)hep->h_type) { What happens here: in the case of a bitfield type we need to also copy the corresponding intrinsic type. This condition here checks for the case and also should deliver that respective intrinsic type into the "hep" variable. But this depends on the assumption that the intrinsic type appears first in the "src_fp" container, so that the hash will point to it. And that is not necessarily true; it depends on what options you have in your kernel config. For instance, with my custom kernel, things look like this: $ ctfdump -t kernel.full - Types ---------------------------------------------------------------------- [1] STRUCT (anon) (8 bytes) sle_next type=262 off=0 [2] STRUCT (anon) (8 bytes) stqe_next type=262 off=0 [3] UNION (anon) (8 bytes) m_next type=262 off=0 m_slist type=1 off=0 m_stailq type=2 off=0 [4] UNION (anon) (8 bytes) m_nextpkt type=262 off=0 m_slistpkt type=1 off=0 m_stailqpkt type=2 off=0 <5> INTEGER char encoding=SIGNED CHAR offset=0 bits=8 <6> POINTER (anon) refers to 5 <7> TYPEDEF caddr_t refers to 6 <8> INTEGER int encoding=SIGNED offset=0 bits=32 <9> TYPEDEF __int32_t refers to 8 <10> TYPEDEF int32_t refers to 9 [11] INTEGER unsigned int encoding=0x0 offset=0 bits=8 [12] INTEGER unsigned int encoding=0x0 offset=0 bits=24 [13] STRUCT (anon) (8 bytes) cstqe_next type=229 off=0 <14> POINTER (anon) refers to 229 [15] STRUCT (anon) (16 bytes) le_next type=229 off=0 le_prev type=14 off=64 <16> INTEGER long encoding=SIGNED offset=0 bits=64 <17> ARRAY (anon) content: 5 index: 16 nelems: 16 <18> INTEGER unsigned int encoding=0x0 offset=0 bits=32 <19> TYPEDEF u_int refers to 18 [etc.etc.] As we can see, this one has the bitfield types as #11 and #12, and the intrinsic type as #18. And consequentially things do fail. I currently do not know what is the culprit. Has the linking stage of the kernel a flaw? Or is the patch D27213 based on a wrong assumption? I hope You guys can answer that. For now I changed the patch D27213 to cover the case, so that things do work. Further details on request. cheerio, PMc