From nobody Tue Jan 4 18:01:55 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 A9FEF1922DE5 for ; Tue, 4 Jan 2022 18:02:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT0n84H10z4sTZ; Tue, 4 Jan 2022 18:02:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x135.google.com with SMTP id c4so22529219iln.7; Tue, 04 Jan 2022 10:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KybLp83FaPTguDgvl1YQNQCWVjZ0Xly9vCom3Go7o6k=; b=fEy1eyun9vgCnedaNUglB47z50GzMr5hORiTB9fvPmfxYLWimCvhweHOW0wsdkMc89 DQsrdJzckVbIfGVI2vtxB6jKdUwk3ZYVj5B1vfYsi7R0KlIMyS2yieyXIYag6AIzkINA BoZSKoqYhHqNHk/EZKbsy7MslvoptGLGfMbdWacqkFYgMQ7nPM0gwbjWOwBV9l7/nJFx pOAqYJpvtYwaEt9DJfJVROUJDnKLlSmWd/KMyEn5hW00P3KbGHtwQYZ1ZceAyt0Ru/gD S22VLLJEGd+FJtrOvAww4P0eHk244Mv1dwSn1j5nwIfjBIahmTQf+zdKp+ZYOC6AKx6p OJsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=KybLp83FaPTguDgvl1YQNQCWVjZ0Xly9vCom3Go7o6k=; b=R6jer5px/w291PYWqbbE/k+P59W/q5wdcqMW+QxVFZEB0hEIlOH0vNbsSf/ttnrwW0 nMJyL5sFohYk/Jx0hAqaVRxeHbrP52qCR1uzlFdHjZfRcex3YrPo6PR0Oo7qdssEIEaO Cwsd/2VB+wfRtZ8JUwuWwgg6ms6Xkq1JJLLkmgPIPItfb8ByJyJqHv28MTeSNb58ZAZa o1cpXhvlJ16AXdH3t/NdC92KleKefAR2gXQ+I1ImKLiknszfbO4l3bDB/JwHAAI1uABh VsugjOyq8AstueLrhAtQxPNXmgm6CrxeQeXNgoxeSt9oteQ298TtscqM/MSUQFzyToPq dPQg== X-Gm-Message-State: AOAM530ygubQhujb2NquY9t/ijZmde1JmzntPjhPeytQca9epHjjb/Ca qKQ7U3fml+8D/ixfLcQFDc3xbGNx1/s= X-Google-Smtp-Source: ABdhPJyJkn+VU+82F3oHowTNHv33v0b5tNAsO9DLNSqGsPpYg3EvyQZO/kyw4TTRuOUG5Af3H3MAmg== X-Received: by 2002:a05:6e02:1908:: with SMTP id w8mr21088903ilu.148.1641319317965; Tue, 04 Jan 2022 10:01:57 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id j2sm22509392ilr.71.2022.01.04.10.01.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 10:01:57 -0800 (PST) Date: Tue, 4 Jan 2022 13:01:55 -0500 From: Mark Johnston To: Peter Cc: freebsd-stable@freebsd.org, jtl@freebsd.org Subject: Re: dtrace bitfields failure (was: 12.3-RC1 fails ...) Message-ID: References: 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 In-Reply-To: X-Rspamd-Queue-Id: 4JT0n84H10z4sTZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 04, 2022 at 04:05:53PM +0100, Peter wrote: > > 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. I'm not immediately sure where the problem is. Could you please post the kernel configuration and src revision that you're using, so that I can try and reproduce this? How exactly does the bug manifest?