From nobody Tue Mar 19 13:43:04 2024 X-Original-To: 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 4TzXx06jXHz5FMkv for ; Tue, 19 Mar 2024 13:43:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (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 4TzXwz6ScBz43QR for ; Tue, 19 Mar 2024 13:43:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net 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 A2E6C8D4A217 for ; Tue, 19 Mar 2024 13:43:06 +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 520472D029D8 for ; Tue, 19 Mar 2024 13:43:06 +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 rR2aYDcQ8q2H for ; Tue, 19 Mar 2024 13:43:05 +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 03CC52D029D2 for ; Tue, 19 Mar 2024 13:43:04 +0000 (UTC) Date: Tue, 19 Mar 2024 13:43:04 +0000 (UTC) From: "Bjoern A. Zeeb" To: hackers@freebsd.org Subject: Re: Why I dislike MPASS... In-Reply-To: Message-ID: <261pq217-nqq5-9snn-r407-oo895s6843ss@yvfgf.mnoonqbm.arg> References: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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 Content-Type: multipart/mixed; boundary="1098556516-1809024439-1710855785=:3455" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.03 / 15.00]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.728]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[zabbadoz.net]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4TzXwz6ScBz43QR This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-1809024439-1710855785=:3455 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Mar 2024, Kristof Provost wrote: > On 19 Mar 2024, at 8:46, Bjoern A. Zeeb wrote: >> Hi, >> >> needless to say, this needed a 2nd kernel, a reproducer (when no gdb and >> no crash dump was avail). >> >> XXX-BZ KABOOM 45000 > 0 && 45000 <= 360 && 45000 < 1536 >> panic: Assertion (key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < >> witness_count failed at /usr/src/sys/kern/subr_witness.c:3118 >> >> This is why I dislike MPASS; if it hits you are often no wiser as to >> why, especially if people added more than a single condition. >> >> Why do we make our life harder ourselves by not having informative >> messages (I mean that is what the comment above MPASS claims)? >> >> I still have no idea how I get to that assertion but at least key.to >> looks dodgy enough so that I can go look where-as before I really didn't >> know if I had hit a limit or which one... >> > Presumably you’d prefer something that’d log the actual compared values? Yes, because without them you still don't know what's wrong. > E.g. something like `ASSERT_GT(key.to, 0); ASSERT_LTE(key.to, > w_max_used_index); ASSERT_LT(key.to, witness_count);`? > I vaguely recall seeing discussion of similar constructs in the ZFS code. > > I’d enthusiastically support adding, and encouraging the use of, macros like > that. > > I’d object to removing or discouraging MPASS(), because I fear that will > reduce the number of assertions developers add to the code, and we’d be > objectively worse off in a world where the assertion was ` ` rather than > `MPASS((key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < > witness_count);`. > > We should probably encourage people to avoid complex expressions in MPASS(), > but I’d still much rather have the complex expression than nothing at all. Yes, MPASS should probably only be used for a single simple expression the most. And I am all for assertions as they are great documentation of assumption in code as well. It's the first stage of writing test code as well ;-) But using KASSERT with a proper message which isn't a teapot is too hard and too time consuming? Always think of when you get a PR from a user (not a machine you sit in front of) what can you do with this information and what's the first things you'd love to know. I often find that the latter changes as code changes or one has a better understanding of a problem (depending on the complexity of the problem). But I also always find that if I didn't have the initial extra information I would have to ask for it often by guessing the best three things... or if ddb is avail at least can have something looked up "type show ifnet and send that output along". /bz -- Bjoern A. Zeeb r15:7 --1098556516-1809024439-1710855785=:3455--