From nobody Wed Aug 16 02:46:02 2023 X-Original-To: dtrace@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 4RQXZp2QHvz4q4Nc for ; Wed, 16 Aug 2023 02:46:26 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQXZm1mG6z4jHb; Wed, 16 Aug 2023 02:46:24 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F01638D4A178; Wed, 16 Aug 2023 02:46:19 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F3E5D5C3A830; Wed, 16 Aug 2023 02:46:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id c4n6AaVI7AaS; Wed, 16 Aug 2023 02:46:03 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0D2A95C3A82F; Wed, 16 Aug 2023 02:46:02 +0000 (UTC) Date: Wed, 16 Aug 2023 02:46:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: Mark Johnston cc: dtrace@freebsd.org Subject: Re: DTrace, kernel loader, unknown probes, enable on load? In-Reply-To: Message-ID: <5p24r5s1-9s7n-0644-4n27-0o82876pn107@yvfgf.mnoonqbm.arg> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: A discussion list for developers working on DTrace in FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-dtrace List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-dtrace@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spamd-Result: default: False [-2.21 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.91)[-0.913]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[dtrace@freebsd.org]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RQXZm1mG6z4jHb On Thu, 24 Mar 2022, Bjoern A. Zeeb wrote: Hi, > On Mon, 14 Feb 2022, Mark Johnston wrote: > > Hi, > > sorry I had lost track .. > >> On Sat, Feb 12, 2022 at 12:16:45AM +0000, Bjoern A. Zeeb wrote: >>> On Fri, 11 Feb 2022, Mark Johnston wrote: >>> >>>> It appears to be sufficient to simply move the kld_load hook to before >>>> module registration, patch below. In the case of a subsequent error, >>>> the unload hook is called so DTrace gets a chance to clean up. I can't >>>> see any reasons not to move it, though there's at least one non-dtrace >>>> consumer that needs a look. >>> >>> HWPMC? >> >> Yes. >> >>> >>> It does work for my case with -Z which will ease work massively. >>> I can't wait for the "morning" and more time then to look at things :-) >>> >>> Please put me on subscribers should you put up a review. >> >> So there's one wrinkle I haven't thought through: when FBT probes are >> enabled in a KLD, we use the kld_unload_try eventhandler to block >> unloading of the module. Now, if we permit FBT probes to be enabled in >> a KLD before its sysinits run, then the kldload might fail, and the >> kernel linker will try to unload the module. But then FBT will block >> the unload. What's the right thing to do there? > > I dunno. > > I can only say that the local change has helped quite a few times in the > last month in my dev tree. > > Shall we add a PR or review and track progress there with a possibly > wider audience? I just got bitten by this again running some older scripts missing output. Thankfully remembered the adjustment. Is there any way we can solve this proper? /bz >>> Thanks a lot Mark and a happy weekend! >>> Bjoern >>> >>> >>>> diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c >>>> index 2e4c95f16c8f..55661b9f9aa2 100644 >>>> --- a/sys/kern/kern_linker.c >>>> +++ b/sys/kern/kern_linker.c >>>> @@ -452,6 +452,7 @@ linker_load_file(const char *filename, linker_file_t >>>> *result) >>>> if (error != ENOENT) >>>> foundfile = 1; >>>> if (lf) { >>>> + EVENTHANDLER_INVOKE(kld_load, lf); >>>> error = linker_file_register_modules(lf); >>>> if (error == EEXIST) { >>>> linker_file_unload(lf, LINKER_UNLOAD_FORCE); >>>> @@ -472,7 +473,6 @@ linker_load_file(const char *filename, linker_file_t >>>> *result) >>>> return (ENOEXEC); >>>> } >>>> linker_file_enable_sysctls(lf); >>>> - EVENTHANDLER_INVOKE(kld_load, lf); >>>> *result = lf; >>>> return (0); >>>> } >>>> >>>> >>> >>> -- >>> Bjoern A. Zeeb r15:7 >> >> > > -- Bjoern A. Zeeb r15:7