From nobody Mon Nov 22 15:45:09 2021 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 0DCF31898039 for ; Mon, 22 Nov 2021 15:45:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 4HyWn46gZ6z3Cwj for ; Mon, 22 Nov 2021 15:45:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x12d.google.com with SMTP id e8so18554380ilu.9 for ; Mon, 22 Nov 2021 07:45:12 -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=PtqcqwHz00OKqaLTKAZqyso2hvajGVTxS3tzAKZ04fg=; b=hBWwwKmBDLVEohU/139Iddf+rtA64DzEIFsWH+IvR/g8kppkYGaXVcAvWk9zGp4Jmr xLui5ab/+74G27ASGZq/Jeb3l0rRjsP50NuZ0y/iBSOB5i+P18xl5b4UYUGESb7tVfeM vOTNVPlzIcZASrqdhRk+XqcGV7en1oPeHf1xYlCTUHIe4NlxhdEKBOT86MjMWoI8Nm/k AgXO8G6FJHdP5FVG7U8lbWChJgv59Yiuc9n+Si/hxExfOQP4VM1yDYZpLmRnEi9mC9g8 nipve9odGcoIguwDIITiXvTWka+R1W189tilKYh6ZFx+3IhqmdNShz2RXvfC6a6SPeay a1Hw== 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=PtqcqwHz00OKqaLTKAZqyso2hvajGVTxS3tzAKZ04fg=; b=pYZw6n7vcwtx4YPtavh8O8dd+tR5OPZtwpnM/h3hqwPOaThmuOosATz7crFsSKK9AV JBpn3q+kuC3S1nPjmQm3CH67o9Ye6qpm+f+VdjmflIRbpFp+/EayuvsbyJXq6B8wUXQV vFZI3F94z9klqBwb/gTwsQXdE3BXvOwUvvYwNLPVpgu6SedBTWS2/Fy67P3nEBVeQz9c xmQWL8ZE1lRJg4nqYHB+N4Qn9p/LfrfyqEXUcieVusiEx4jwJQT49b8c3P154RdBXYvG Zx1FSgsos1053Oxpqd5pxsRTrPUWbuHta1uhZQb0/51OwgAJbtCF4HPCLfaNg8wfsacc zHpw== X-Gm-Message-State: AOAM530J3bY5XMlornD35423HgIMZNAJ8UBbGWTFGvCJ1VU8vSw2SHrX JUgOHvNW05+14n3kRkm6Gte75xQvvtw= X-Google-Smtp-Source: ABdhPJzNme+Le0rcbfeq7RGLhu7VdoqqUsTetBFly025+XhccmOMl+/LIxRMKhOPda3AdkklhWJk7Q== X-Received: by 2002:a92:c74a:: with SMTP id y10mr20271752ilp.122.1637595912118; Mon, 22 Nov 2021 07:45:12 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id x15sm6721011ill.20.2021.11.22.07.45.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Nov 2021 07:45:11 -0800 (PST) Date: Mon, 22 Nov 2021 10:45:09 -0500 From: Mark Johnston To: Peter Cc: freebsd-stable@freebsd.org Subject: Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue) 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: 4HyWn46gZ6z3Cwj 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 Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote: > ## this seems not have arrived on the list at first send ## > > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", > > line 106: failed to copy type of 'inp': Conflicting type is already defined > > > That file ipfw.d appears to be new in 12.3, but I'm clueless what > > the error means (and why it happens only to me). > > > I figured out why - I have "device dtraceall" in my kernel. This is > reproducible: > > > root@y12y:/ # dtrace -h > > dtrace: -h requires one or more scripts or enabling options > > root@y12y:/ # kldload dtraceall > > root@y12y:/ # dtrace -h > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line 106: failed to copy type of 'inp': Conflicting type is already defined > > root@y12y:/ # kldunload dtraceall > > root@y12y:/ # dtrace -h > > dtrace: -h requires one or more scripts or enabling options > > > But we do already have a bug (#254483) for this error. > > This bug was closed as duplicate to bug #258763, and the latter one > was closed as solved with a fix as stated here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7 > > > But the fancy is: > > 1. that fix appears to have missed the releng/12.3 branch by three > days, so it is not in the code. But also > > 2. if applied, (*surprize*) that fix does NOT help! Hmm, that is indeed surprising. I'm able to reproduce the problem locally. > More than one thing is wrong here, and bug #254483 is *not* a > duplicate to #258763. > > The failure does NOT come from code covered by Mark Johnstons fix. > > It comes from a neighboring section where Integers are compared, and > it fails with a type conflict 8bit vs. 32bit. > > > The problem must be within /usr/lib/dtrace/ipfw.d - and indeed > it is (irrelevant parts stripped away): > > > typedef struct ipfw_match_info { > > struct mbuf *m; > > } ipfw_match_info_t; > > > > translator ipfw_match_info_t < struct ip_fw_args *p > { > > m = p->m; > > }; > > This does not work. Within the 'struct mbuf' definition is a > construct, that looks like this: > > > uint32_t m_type:8, /* type of data in this mbuf */ > > m_flags:24; /* flags; see below */ > > And it seems that is somehow the cause for the integer size conflict > (not implemented?) How did you come to that conclusion? > In the neighboring file /usr/lib/dtrace/mbuf.d this is done > distinctively: > > > translator mbufinfo_t < struct mbuf *p > { > > mbuf_addr = (uintptr_t)p; > > m_data = p->m_data; > > m_len = p->m_len; > > m_type = p->m_type & 0xff000000; > > m_flags = p->m_type & 0x00ffffff; > >}; > > So probably we should just duplicate that approach for ipfw. > > Or, could that definition be directly included and called? Does dtrace > allow one tranlation to call another? > I can't answer that, have never been that deep in dtrace - but I > really love the idea that we now get means to look into ipfw. Comes in > handy and at the right time. :)