From nobody Mon May 27 02:27:27 2024 X-Original-To: freebsd-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 4VnfgT1XZwz5L8xd for ; Mon, 27 May 2024 02:27:33 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wfout7-smtp.messagingengine.com (wfout7-smtp.messagingengine.com [64.147.123.150]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VnfgS1BdDz4tQh for ; Mon, 27 May 2024 02:27:32 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=qOqeizG5; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=eO1Tlskw; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.150 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id 997341C000C5 for ; Sun, 26 May 2024 22:27:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 26 May 2024 22:27:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1716776849; x=1716863249; bh=Z/rqEh1x28 4Nr1HGKxNfjDr7GiUq+nXkHd3frMuVhjI=; b=qOqeizG5cXEqAsc0uPSdxX/sYk YkJ/N/3FCtsnbMFZ1WorG1gE0Mdr3z8W0IJeCKohrxQ/SYYb1sIB07N0A4GEFzFp 5UwK9su6d6+iNkIjq2HSdfUARTZ8AKDiccf7MKhCcq42+Vdq26Ww83F4V+CiDp8y iJHCNH9P25AI+cC78kH+heUQHPYVTd7iFutvFxwbx6qCyGsi76FtmmKQdS45Tqdw s3Zru5bgiJZQT+wJ757LkAWWoobHzJCKAJNkr47m8QcG90+liwkPlfUdf2+Y9AQG a5sLTCY37TcnhcVVUnURaXe7BxCTmGgq9BzJEuceAIDy1o61Y+dFy3JdMYUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1716776849; x=1716863249; bh=Z/rqEh1x284Nr1HGKxNfjDr7GiUq +nXkHd3frMuVhjI=; b=eO1TlskwF9q0CZmLU6FbZx5OpQxD0FECJxTFJYJCKUl1 drqdXnMDbBq8VT64ScXUxX7aTttPi3ovKDcbIjm6/pXWTH36y/9SyPNodU3qd2HE hgFcp//Y7aVBQ2mBKhp9gX3cajOwEz2DNdv00WkcDwTz5sckfuKZLOQvMNfXJvoe o/u5TwoAWkSNmTUhIM987GcwQ5WvsBlbXeQkDj810my13as0HK1D3lU0bGdzM7V4 Lo/LPTY7cYrGWiBOFiMPXSAv/ccCDg+3J+5b6tK3hsAdiXXWI4XhPXaO/z4QN2P4 cFMqvsKBJ+P3Hb28mNsShne2sfiipzMSMLTkr+rbqQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdejfedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpehvohhiugcu oehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgvrhhnpeekleduvdelhfeileefgf fghfffkedtheellefgudfgvdegkeejjedutdehhefgueenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 26 May 2024 22:27:28 -0400 (EDT) Date: Mon, 27 May 2024 03:27:27 +0100 From: void To: FreeBSD Hackers Subject: Re: uname discrepancy Message-ID: Mail-Followup-To: FreeBSD Hackers References: 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: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.150:from]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4VnfgS1BdDz4tQh On Sun, May 26, 2024 at 06:17:41PM +0200, Juraj Lutter wrote: >Hi, > >> On 26 May 2024, at 15:08, void wrote: >> >> Sources built via 'doas git -C /usr/src checkout stable/14' creates >> a system with uname output containing >> >> FreeBSD 14.1-STABLE stable/14-n267809-432c0128bd3d >> >> My question is, why 14.1-STABLE but not 14-STABLE ? >> >> Not sure if it's always been like this and I've just not noticed... > >It was always like that. OK thanks -- From nobody Tue May 28 14:11:41 2024 X-Original-To: freebsd-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 4VpZFZ3fydz5MRtS for ; Tue, 28 May 2024 14:11:46 +0000 (UTC) (envelope-from gray@nxg.name) Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VpZFY61Nsz414H for ; Tue, 28 May 2024 14:11:45 +0000 (UTC) (envelope-from gray@nxg.name) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nxg.name header.s=mythic-beasts-k1 header.b=3piGrM40; dmarc=none; spf=pass (mx1.freebsd.org: domain of gray@nxg.name designates 2a00:1098:0:82:1000:0:2:1 as permitted sender) smtp.mailfrom=gray@nxg.name DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nxg.name; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=6SXGTAY8X52uZOduXFOuk+8tcbmhj4ahLfTVvZtvWwI=; b=3piGrM40QpnPfLdSwjyiZk1cn4 f3iZs2wPl/lm4xfdMtkhUFf8vzBwevKSAkBCUPdA6WAbPL9JdVBfzehbqCNSHapZRipbUO4+E7e/3 wdxZZoGkGwxYcIAPrIatCkxjhUtrd4jsDUyewJHyncjN2A+dbz0uiOq7Q0A7kt8xndeeqPaWQtqJ8 AZoxWsHkJI7cG7yipreQzxCOlMut1dC6jxOItlxSrazFrcx6BiQHHC2sBtGGU4jreJdHeGXtVi17B zPjCXu3jjObyZ3rcA6GIoiOyadQzlXAUQEQ4/eoywrRV3CxEatIdVXKoM55GjkH4V1oe36GpCVzbf N47zVVog==; Received: by mailhub-hex-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sBxYG-00FUqR-32; Tue, 28 May 2024 15:11:45 +0100 From: Norman Gray To: freebsd-hackers@freebsd.org Subject: quotactl(2): units of reported sizes on ZFS Date: Tue, 28 May 2024 15:11:41 +0100 X-Mailer: MailMate (1.14r5964) Message-ID: <3EAE7B9F-C672-4FE1-B28C-42F84685D585@nxg.name> 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: text/plain Content-Transfer-Encoding: quoted-printable X-BlackCat-Spam-Score: 24 X-Spam-Status: No, score=2.4 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1098:0:82:1000:0:2:0/112]; R_DKIM_ALLOW(-0.20)[nxg.name:s=mythic-beasts-k1]; RCVD_IN_DNSWL_MED(-0.20)[2a00:1098:0:82:1000:0:2:1:from]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[nxg.name]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[nxg.name:+] X-Rspamd-Queue-Id: 4VpZFY61Nsz414H Hello, list. [I might be asking on the wrong list, but would welcome redirection] I'm trying to get programmatic access to read ZFS quota information, and = I'm not finding my questions answered by what seem to be the relevant man= pages -- specifically quotactl(2) on 14.0. Though the manpage says that quotactl is supported only on UFS, it (now) = works on ZFS filesystems, too. The response from a Q_GETQUOTA call produc= es numbers in units of blocks, according to ufs/ufs/quota.h internal comm= ents, but without documenting what size those blocks are. I get the right= numbers (in the sense of matching the results from zfs userspace) if I a= ssume a block is 512B, but I can't see that written down anywhere, so don= 't in principle know if that's always true, or if it's something dependen= t on, for example, the pool's ashift value. So, questions: * I'm presuming quotactl(2) is indeed now supported on ZFS, rather than= this just working by accident (this does of course seem vanishingly unli= kely, but I'd like a manpage to tell me this in words of one syllable). = Is that correct? * What's the documented way of getting the 'block size' units in which = quotactl reports its results? Both of these boil down to: * Is there a manpage I'm missing? I feel sure there's an embarrassing aha! waiting for me here, because I'm= looking in completely the wrong place, but I'd welcome being pointed in = the right direction as tactfully as possible. I've put in a docbug report (279249, and see also 234413) noting the appa= rent gap in the quotactl(2) manpage. I also asked on one of the forums, and was pointed towards libzfs, but I = can't find any documentation on that, either. I can see libzfs in the ZF= S repo [1], but there doesn't seem to be a manpage covering the library, = nor obviously relevant comments within libzfs.h. Best wishes, Norman [1] https://github.com/openzfs/zfs/tree/master -- = Norman Gray : https://nxg.me.uk From nobody Thu May 30 05:53:35 2024 X-Original-To: freebsd-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 4Vqb664pcvz5Ly04 for ; Thu, 30 May 2024 05:53:50 +0000 (UTC) (envelope-from nkumarababu@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vqb655G6Sz4mhw for ; Thu, 30 May 2024 05:53:49 +0000 (UTC) (envelope-from nkumarababu@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kq6yMqdW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nkumarababu@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=nkumarababu@gmail.com Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6f72b8db7deso291900a34.2 for ; Wed, 29 May 2024 22:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717048428; x=1717653228; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Lsyabcg+bqs07PI+x6OyA+pg/1sNC16q3splZu/7MjI=; b=Kq6yMqdWIKY9U0sSKcfHWpRouSlMVLLHwvhIMxebgv8ymcFGICOEbj969P7tY64lXX /5jIPqOwtyl4OxHlFORvZ1ndG9lcI+eej6fEPRPU8lDgFm/yvQcearbS9h7xKJiOcSp4 mj+3d+cFSmUFPPIZhPfQRG5hbSOP60grUPQAGvL5L1T+4oJCeF191Oa0hBZ0g3ZZzQwj U90wkQs2w03Fv6EjiEkYD73MRC0jtMPBDEkttT1KprSBrSxicyqb/tC25T0rIHmAl+wg azGdbM70qOL0WmpXAPxikMw7MBdOqjkMfkv9L/SQu74FKkflrmhyNTcNYFx4NiHQGekf halA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717048428; x=1717653228; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Lsyabcg+bqs07PI+x6OyA+pg/1sNC16q3splZu/7MjI=; b=G72rr38q67q0lXac5D7hilVBhgy9aegcGtIqI63vXl2HewrhLrTzK/sSUuWd0gd7zm MpGTGf0S0wbQwEXfwF6XnwTO2s4pFALlJTS64Lly1qf2uKTd/LHmQQMCosf6/cpxw0WK ieQNZy5POjOc3PCjkXXbxEgMKhkNQq42+dbwK3d6nsxFAD3m7ITldn+FjVyDa+JL3k3R XcXqUyCjMATYMGVeU7u3DyK2x9WpTC2Lq6jtpf8HJUhMNct0wJIErCgJx+V4fhwvRLdy ZViUVxcbVIInVY1ov5fV6HflcmHmVqC/10C+3PrQdG73xakJ9UzZuaoJ9v1vzhq2isVI 9abQ== X-Gm-Message-State: AOJu0YxX1sP3I7zgWhxGH4A+2AQlM5BnKlwZoL6ca1N57UXc7njBqlON 4uqX28S81h2v/9IWQfe5foqtPa+p6h/16+JVw08TMbp5bff4n70L2bxuAliHKL/9wdh8YqC8+Xq I/P7AaMn8IzwE9uUY6Ww4Ck5+He59mnvwTG0= X-Google-Smtp-Source: AGHT+IFQLu/hjNzhffHCIfM9IklhX2JnlFWSc6SWaKMJgqaofW4siYygT5yeIV7qaiVsaUZH1lb+/Co4c8UmobOhJbQ= X-Received: by 2002:a05:6870:8921:b0:24c:ae57:b4b4 with SMTP id 586e51a60fabf-25060bda4c5mr915752fac.24.1717048427668; Wed, 29 May 2024 22:53:47 -0700 (PDT) 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 From: Kumara Babu Date: Wed, 29 May 2024 22:53:35 -0700 Message-ID: Subject: Upperlimit for bwait() To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="00000000000098c36f0619a57dd5" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::336:from] X-Rspamd-Queue-Id: 4Vqb655G6Sz4mhw --00000000000098c36f0619a57dd5 Content-Type: multipart/alternative; boundary="00000000000098c36d0619a57dd3" --00000000000098c36d0619a57dd3 Content-Type: text/plain; charset="UTF-8" Hello, There have been a few incidents reported on Juniper devices with FreeBSD, where buffer IO operations sleep for more than 30 mins. Theoretically, this can happen due to faulty hardware or in virtual platforms due to faulty connection between guest and host, filesystem corruption, too many buffer IO operations, and/or host not responding due to various reasons. When that happens, as this buffer IO writes hold a lock before going to sleep, the threads waiting for that lock would starve for so long. There is no upper limit for this bwait() as of now. If that wait goes beyond 30 mins for a sleeping thread OR 15 mins for a thread blocked on turnstile, deadlkres crashes the kernel assuming a possible deadlock. We perhaps could gracefully handle such lengthy buffer IO operations by adding a timeout in bwait() - like say 10 minutes. If the buffer IO is not completed in a few mins, it probably would not complete forever and/or would be slowing down the entire system. So it is better to stop such faulty IO operations. For now, since we had seen these instances only with BIO operations, I have a patch to set this value only from bufwait(). Please find the patch attached. I am not very sure if 10 mins is a good upper limit for all the scenarios for bwait(). If it is, then we could just change msleep() in bwait() to set a 10 mins upper limit by default. Please let me know if this approach works for all the usecases - If not, is there a better alternative ? And is 10 mins okay for a timeout ? Thanks and Regards, Kumara --00000000000098c36d0619a57dd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

There have been a few incidents reported on Juniper devic= es with FreeBSD, where buffer IO operations sleep for more than 30 mins. Th= eoretically, this can happen due to faulty hardware or in virtual platforms= due to faulty connection between guest and host, filesystem corruption, to= o many buffer IO operations, and/or host not responding due to various reas= ons. When that happens, as this buffer IO writes hold a lock before going t= o sleep, the threads waiting for that lock would starve for so long. There = is no upper limit for this bwait() as of now. If that wait goes beyond 30 m= ins for a sleeping thread OR 15 mins for a thread blocked on turnstile, dea= dlkres crashes the kernel assuming a possible deadlock.

We perhaps could grac= efully handle such lengthy buffer IO operations by adding a timeout in bwai= t() - like say 10 minutes. If the buffer IO is not completed in a few mins,= it probably would not complete forever and/or would be slowing down the en= tire system. So it is better to stop such faulty IO operations.

For now, since we= had seen these instances only with BIO operations, I have a patch to set t= his value only from bufwait(). Please find the patch attached. I am not ver= y sure if 10 mins is a good upper limit for all the scenarios for bwait(). = If it is, then we could just change msleep() in bwait() to set a 10 mins up= per limit by default.=C2=A0

Pl= ease let me know if this approach works for all the usecases - If not, is t= here a better alternative ?=C2=A0 And is 10 mins okay for a timeout ?

Thanks and Regards,

Kumara

--00000000000098c36d0619a57dd3-- --00000000000098c36f0619a57dd5 Content-Type: application/octet-stream; name="bwait_timeout.patch" Content-Disposition: attachment; filename="bwait_timeout.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lwsua22p0 ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3Zmc19iaW8uYyBiL3N5cy9rZXJuL3Zmc19iaW8uYwppbmRl eCBiNTQ2NmZiMmNkNTMuLjc4OGFiMmUxYjdmMSAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vdmZzX2Jp by5jCisrKyBiL3N5cy9rZXJuL3Zmc19iaW8uYwpAQCAtNzUsNiArNzUsNyBAQAogI2luY2x1ZGUg PHN5cy9zbXAuaD4KICNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiAjaW5jbHVkZSA8c3lzL3N5c2Nh bGxzdWJyLmg+CisjaW5jbHVkZSA8c3lzL3N5c2xvZy5oPgogI2luY2x1ZGUgPHN5cy92bWVtLmg+ CiAjaW5jbHVkZSA8c3lzL3ZtbWV0ZXIuaD4KICNpbmNsdWRlIDxzeXMvdm5vZGUuaD4KQEAgLTM5 MCw2ICszOTEsOSBAQCBzdGF0aWMgaW50IGJkaXJ0eXdhaXQ7CiAvKiBNYXhpbXVtIG51bWJlciBv ZiBidWZmZXIgZG9tYWlucy4gKi8KICNkZWZpbmUJQlVGX0RPTUFJTlMJOAogCisvKiBUaW1lb3V0 IGZvciBidWZmZXIgSS9POiAxMCBtaW5zICovCisjZGVmaW5lIEJUSU1FT1VUICAgICAgIDYwMCAq IGh6CisKIHN0cnVjdCBidWZkb21haW5zZXQgYmRsb2RpcnR5OwkJLyogRG9tYWlucyA+IGxvZGly dHkgKi8KIHN0cnVjdCBidWZkb21haW5zZXQgYmRoaWRpcnR5OwkJLyogRG9tYWlucyA+IGhpZGly dHkgKi8KIApAQCAtNDUzNyw5ICs0NTQxLDkgQEAgaW50CiBidWZ3YWl0KHN0cnVjdCBidWYgKmJw KQogewogCWlmIChicC0+Yl9pb2NtZCA9PSBCSU9fUkVBRCkKLQkJYndhaXQoYnAsIFBSSUJJTywg ImJpb3JkIik7CisJCWJ3YWl0KGJwLCBQUklCSU8sICJiaW9yZCIsIEJUSU1FT1VUKTsKIAllbHNl Ci0JCWJ3YWl0KGJwLCBQUklCSU8sICJiaW93ciIpOworCQlid2FpdChicCwgUFJJQklPLCAiYmlv d3IiLCBCVElNRU9VVCk7CiAJaWYgKGJwLT5iX2ZsYWdzICYgQl9FSU5UUikgewogCQlicC0+Yl9m bGFncyAmPSB+Ql9FSU5UUjsKIAkJcmV0dXJuIChFSU5UUik7CkBAIC01MTIxLDE0ICs1MTI1LDIy IEBAIGJkb25lKHN0cnVjdCBidWYgKmJwKQogfQogCiB2b2lkCi1id2FpdChzdHJ1Y3QgYnVmICpi cCwgdV9jaGFyIHByaSwgY29uc3QgY2hhciAqd2NoYW4pCitid2FpdChzdHJ1Y3QgYnVmICpicCwg dV9jaGFyIHByaSwgY29uc3QgY2hhciAqd2NoYW4sIGludCB0aW1vKQogewogCXN0cnVjdCBtdHgg Km10eHA7CisJaW50IHJldDsKIAogCW10eHAgPSBtdHhfcG9vbF9maW5kKG10eHBvb2xfc2xlZXAs IGJwKTsKIAltdHhfbG9jayhtdHhwKTsKLQl3aGlsZSAoKGJwLT5iX2ZsYWdzICYgQl9ET05FKSA9 PSAwKQotCQltc2xlZXAoYnAsIG10eHAsIHByaSwgd2NoYW4sIDApOworCXdoaWxlICgoYnAtPmJf ZmxhZ3MgJiBCX0RPTkUpID09IDApIHsKKwkJcmV0ID0gbXNsZWVwKGJwLCBtdHhwLCBwcmksIHdj aGFuLCB0aW1vKTsKKwkJaWYgKHJldCA9PSBFV09VTERCTE9DSykgeworCQkJbG9nIChMT0dfRVJS LCAiJXM6IFdhaXRlZCB0b28gbG9uZyglZCkgZm9yIGEgYnVmZmVyIElPIHRvIGNvbXBsZXRlXG4i LCBfX2Z1bmNfXywgdGltbyk7CisJCQlicC0+Yl9lcnJvciA9IEVUSU1FRE9VVDsKKwkJCWJwLT5i X2ZsYWdzIHw9IEJJT19FUlJPUjsKKwkJCWJyZWFrOworCQl9CisJfQogCW10eF91bmxvY2sobXR4 cCk7CiB9CiAKZGlmZiAtLWdpdCBhL3N5cy9zeXMvYnVmLmggYi9zeXMvc3lzL2J1Zi5oCmluZGV4 IDcwZmIyODEyYzNiYS4uZWY0Yzk2NTYwYTU3IDEwMDY0NAotLS0gYS9zeXMvc3lzL2J1Zi5oCisr KyBiL3N5cy9zeXMvYnVmLmgKQEAgLTYwMyw3ICs2MDMsNyBAQCB2b2lkCXBicmVsYm8oc3RydWN0 IGJ1ZiAqKTsKIHZvaWQJcGJyZWx2cChzdHJ1Y3QgYnVmICopOwogaW50CWFsbG9jYnVmKHN0cnVj dCBidWYgKmJwLCBpbnQgc2l6ZSk7CiB2b2lkCXJlYXNzaWduYnVmKHN0cnVjdCBidWYgKik7Ci12 b2lkCWJ3YWl0KHN0cnVjdCBidWYgKiwgdV9jaGFyLCBjb25zdCBjaGFyICopOwordm9pZAlid2Fp dChzdHJ1Y3QgYnVmICosIHVfY2hhciwgY29uc3QgY2hhciAqLCBpbnQpOwogdm9pZAliZG9uZShz dHJ1Y3QgYnVmICopOwogCiB0eXBlZGVmIGRhZGRyX3QgKHZiZ19nZXRfbGJsa25vX3QpKHN0cnVj dCB2bm9kZSAqLCB2bV9vb2Zmc2V0X3QpOwpkaWZmIC0tZ2l0IGEvc3lzL3Vmcy9mZnMvZmZzX3Jh d3JlYWQuYyBiL3N5cy91ZnMvZmZzL2Zmc19yYXdyZWFkLmMKaW5kZXggM2E0MTVkNzY2MzAzLi5k YjNiNmM2ZjM2YmYgMTAwNjQ0Ci0tLSBhL3N5cy91ZnMvZmZzL2Zmc19yYXdyZWFkLmMKKysrIGIv c3lzL3Vmcy9mZnMvZmZzX3Jhd3JlYWQuYwpAQCAtMzE0LDcgKzMxNCw3IEBAIGZmc19yYXdyZWFk X21haW4oc3RydWN0IHZub2RlICp2cCwKIAkJCX0KIAkJfQogCQkKLQkJYndhaXQoYnAsIFBSSUJJ TywgInJhd3JkIik7CisJCWJ3YWl0KGJwLCBQUklCSU8sICJyYXdyZCIsIDApOwogCQl2dW5tYXBi dWYoYnApOwogCQkKIAkJaW9sZW4gPSBicC0+Yl9iY291bnQgLSBicC0+Yl9yZXNpZDsKQEAgLTM4 MSw3ICszODEsNyBAQCBmZnNfcmF3cmVhZF9tYWluKHN0cnVjdCB2bm9kZSAqdnAsCiAJCXVtYV96 ZnJlZShmZnNyYXdfcGJ1Zl96b25lLCBicCk7CiAJfQogCWlmIChuYnAgIT0gTlVMTCkgewkJCS8q IFJ1biBkb3duIHJlYWRhaGVhZCBidWZmZXIgKi8KLQkJYndhaXQobmJwLCBQUklCSU8sICJyYXdy ZCIpOworCQlid2FpdChuYnAsIFBSSUJJTywgInJhd3JkIiwgMCk7CiAJCXZ1bm1hcGJ1ZihuYnAp OwogCQlwYnJlbHZwKG5icCk7CiAJCXVtYV96ZnJlZShmZnNyYXdfcGJ1Zl96b25lLCBuYnApOwpk aWZmIC0tZ2l0IGEvc3lzL3ZtL3N3YXBfcGFnZXIuYyBiL3N5cy92bS9zd2FwX3BhZ2VyLmMKaW5k ZXggZWUyMzZjN2YzOTg4Li5lOTEyYWEwODVmYzcgMTAwNjQ0Ci0tLSBhL3N5cy92bS9zd2FwX3Bh Z2VyLmMKKysrIGIvc3lzL3ZtL3N3YXBfcGFnZXIuYwpAQCAtMTU5NSw3ICsxNTk1LDcgQEAgc3dh cF9wYWdlcl9wdXRwYWdlcyh2bV9vYmplY3RfdCBvYmplY3QsIHZtX3BhZ2VfdCAqbWEsIGludCBj b3VudCwKIAkJLyoKIAkJICogV2FpdCBmb3IgdGhlIHN5bmMgSS9PIHRvIGNvbXBsZXRlLgogCQkg Ki8KLQkJYndhaXQoYnAsIFBWTSwgInN3d3J0Iik7CisJCWJ3YWl0KGJwLCBQVk0sICJzd3dydCIs IDApOwogCiAJCS8qCiAJCSAqIE5vdyB0aGF0IHdlIGFyZSB0aHJvdWdoIHdpdGggdGhlIGJwLCB3 ZSBjYW4gY2FsbCB0aGUKZGlmZiAtLWdpdCBhL3N5cy92bS92bm9kZV9wYWdlci5jIGIvc3lzL3Zt L3Zub2RlX3BhZ2VyLmMKaW5kZXggZDMyZmVjODQ1MDQzLi5hNmZjZTZiMzQ1ZWQgMTAwNjQ0Ci0t LSBhL3N5cy92bS92bm9kZV9wYWdlci5jCisrKyBiL3N5cy92bS92bm9kZV9wYWdlci5jCkBAIC03 MDcsNyArNzA3LDcgQEAgdm5vZGVfcGFnZXJfaW5wdXRfc21sZnModm1fb2JqZWN0X3Qgb2JqZWN0 LCB2bV9wYWdlX3QgbSkKIAkJCWJwLT5iX2lvb2Zmc2V0ID0gZGJ0b2IoYnAtPmJfYmxrbm8pOwog CQkJYnN0cmF0ZWd5KGJwKTsKIAotCQkJYndhaXQoYnAsIFBWTSwgInZuc3JkIik7CisJCQlid2Fp dChicCwgUFZNLCAidm5zcmQiLCAwKTsKIAogCQkJaWYgKChicC0+Yl9pb2ZsYWdzICYgQklPX0VS Uk9SKSAhPSAwKSB7CiAJCQkJS0FTU0VSVChicC0+Yl9lcnJvciAhPSAwLApAQCAtMTE2OCw3ICsx MTY4LDcgQEAgdm5vZGVfcGFnZXJfZ2VuZXJpY19nZXRwYWdlcyhzdHJ1Y3Qgdm5vZGUgKnZwLCB2 bV9wYWdlX3QgKm0sIGludCBjb3VudCwKIAl9IGVsc2UgewogCQlicC0+Yl9pb2RvbmUgPSBiZG9u ZTsKIAkJYnN0cmF0ZWd5KGJwKTsKLQkJYndhaXQoYnAsIFBWTSwgInZucmVhZCIpOworCQlid2Fp dChicCwgUFZNLCAidm5yZWFkIiwgMCk7CiAJCWVycm9yID0gdm5vZGVfcGFnZXJfZ2VuZXJpY19n ZXRwYWdlc19kb25lKGJwKTsKIAkJZm9yIChpID0gMDsgaSA8IGJwLT5iX25wYWdlczsgaSsrKQog CQkJYnAtPmJfcGFnZXNbaV0gPSBOVUxMOwo= --00000000000098c36f0619a57dd5-- From nobody Thu May 30 06:42:07 2024 X-Original-To: freebsd-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 4VqcB16bp9z5M3gG for ; Thu, 30 May 2024 06:42:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VqcB14H2bz4s3Q for ; Thu, 30 May 2024 06:42:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 1102189297; Thu, 30 May 2024 06:42:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.18.1/8.16.1) with ESMTPS id 44U6g855099330 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 30 May 2024 06:42:08 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 44U6g72B099329; Thu, 30 May 2024 06:42:07 GMT (envelope-from phk) Message-Id: <202405300642.44U6g72B099329@critter.freebsd.dk> To: Kumara Babu cc: freebsd-hackers@freebsd.org Subject: Re: Upperlimit for bwait() In-reply-to: From: "Poul-Henning Kamp" References: 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: text/plain; charset="us-ascii" Content-ID: <99327.1717051327.1@critter.freebsd.dk> Date: Thu, 30 May 2024 06:42:07 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4VqcB14H2bz4s3Q Kumara Babu writes: > We perhaps could gracefully handle such lengthy buffer IO operations by > adding a timeout in bwait() - like say 10 minutes. If the buffer IO is not > completed in a few mins, it probably would not complete forever and/or > would be slowing down the entire system. So it is better to stop such > faulty IO operations. I agree that the symptoms are bad, but disagree about putting a workaround in bread(), because you get system corruption if the I/O operation completes anyway after the timeout. The fundamental issue with timing out I/O, is stopping the operation in progress. If you do a "I'm not waiting for this any more", you have to sequester the destination of the I/O operation, until you have 100% confirmation that the operation has either been completed or sucessfuly neutered. (As a policy choice, you may also want to write-protect the source.) This is why hi-rel systems never allow direct(-mapped) I/O: By insisting that data go through dedicated I/O buffers, failing buffers can be sequestered as long as necessary, without complicating the application logic. Before Virtual Memory, the UNIX buffer-cache worked that way, and MERT did that. (MERT = Early five-nines UNIX for telephone switches.) Between "intelligent I/O controllers" with DMA access, virtual memory and direct-mapped I/O, we /have/ to make sure the underlying I/O operation is /guaranteed/ dead, before we wake up the thread. The only place that can and should happen is in the device driver, possibly assisted by infrastructure such as CAM. You need to find out which device driver is ultimately responsible for the hanging bread(), because that's where the timeout should happen. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu May 30 13:53:59 2024 X-Original-To: freebsd-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 4VqnmN61TDz5Mh4V for ; Thu, 30 May 2024 13:54:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VqnmN46yyz4cYK for ; Thu, 30 May 2024 13:54:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a630ff4ac84so77910266b.1 for ; Thu, 30 May 2024 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1717077251; x=1717682051; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yGrkIKz/V9QgsvYa362eniO8y97woF+Q+Y/FPy94zCw=; b=nOORm8N0SflDTAf3QP9iJWgmvv+o//xof1//6N1tEA3p8NNkoSrNlGK+7vm3vl22vQ eFhkdUPMo+0Yn5TILtDWJmjDBWxFsVy9pAGrLdbPTVxGWeFSaOxEskl5uej6eJCx210r dd+0h5lx0c0ESQgAAmjMd3fekveDujPTI5Ki+K0BWeIZbdE7VYqX1eU+Dzqme3tTgKE2 rq6+zm0btPjIvsYrZ4DsUfnyzE2DBksDWt72oiLUq40VcKQwvpavU9cr0u+e3ynIPgsy 6B1wCA1u9SKgmPzN3jsK+m8Bap9cgvlhHAJx+mE1+Xmo9VPxswJpDK/xvMXnooPwZmti lH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717077251; x=1717682051; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yGrkIKz/V9QgsvYa362eniO8y97woF+Q+Y/FPy94zCw=; b=SESyusDjnktHcCnfV2xRCUYn1zyD3tMdZHRinFJvMzEgOTgm8Z4iel0xdFJtINIW5Y HMHcmSlpFnUJs4UzRHwpzvbQHcypPGr3vLYM4RQr3V94WwQzW4hpDCMVndfxOGKgCmhP +4QYl/TZ2zyBZDl65AAz+JqmU3W26xp/wtpwN/yidPq0kVhgnHOn2mnaUhJ3ykZODzG3 FZfdcC2jGAR7BFx4fdVl9WOOfL596Js7FpSiTiwzNBH7EglY6A9vWK5gQT3dneVL9isz MG9IO4W9qLicePGTiOeBlfIItUZro8GVzlA8DYamIdT2u+0MSLJFkfjXyO3Rt/oFtYym CyfQ== X-Gm-Message-State: AOJu0Yx4UUoepNKn7l0EHns8rudjqG1BBk/KJbMSNT5zGbKr3PHkpp9m Z+XSD7ES7+reKvMZipJZSEkWkPwM/hqDkb3K0OsRCF8U3lirMlPPEmsGVEqO7CgpBrq/LYK29i2 JfBwjBI/DI79S67l40RQ3fOXSE8VCyp0sMarbbWA0TMcZLpR4AChzFg== X-Google-Smtp-Source: AGHT+IFLrshXYXJ9agDFXZ3+rM780alj8BLizhwYs7Vd2ZCUHjwOysw2qpiUQS8QgFiZutApVum0PtMDjPaNQ8pNS8o= X-Received: by 2002:a17:906:1717:b0:a5a:423:a69f with SMTP id a640c23a62f3a-a65e8d1857amr159078466b.9.1717077250838; Thu, 30 May 2024 06:54:10 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Thu, 30 May 2024 09:53:59 -0400 Message-ID: Subject: Re: Upperlimit for bwait() To: Kumara Babu Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000096b2160619ac3307" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VqnmN46yyz4cYK --00000000000096b2160619ac3307 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 30, 2024 at 1:54=E2=80=AFAM Kumara Babu = wrote: > Hello, > > There have been a few incidents reported on Juniper devices with FreeBSD, > where buffer IO operations sleep for more than 30 mins. Theoretically, th= is > can happen due to faulty hardware or in virtual platforms due to faulty > connection between guest and host, filesystem corruption, too many buffer > IO operations, and/or host not responding due to various reasons. When th= at > happens, as this buffer IO writes hold a lock before going to sleep, the > threads waiting for that lock would starve for so long. There is no upper > limit for this bwait() as of now. If that wait goes beyond 30 mins for a > sleeping thread OR 15 mins for a thread blocked on turnstile, deadlkres > crashes the kernel assuming a possible deadlock. > Why isn't the I/O timing out? That's the real problem. > We perhaps could gracefully handle such lengthy buffer IO operations by > adding a timeout in bwait() - like say 10 minutes. If the buffer IO is no= t > completed in a few mins, it probably would not complete forever and/or > would be slowing down the entire system. So it is better to stop such > faulty IO operations. > I think that's a terrible idea. Why aren't the I/Os timing out? > For now, since we had seen these instances only with BIO operations, I > have a patch to set this value only from bufwait(). Please find the patch > attached. I am not very sure if 10 mins is a good upper limit for all the > scenarios for bwait(). If it is, then we could just change msleep() in > bwait() to set a 10 mins upper limit by default. > I never see this on any of the thousands of systems I've used. > Please let me know if this approach works for all the usecases - If not, > is there a better alternative ? And is 10 mins okay for a timeout ? > Making sure that the I/Os timeout. And by that, I mean doing what we do in CAM. All the SIMs ensure that transactions posted to the device will timeout. Most of the SIMs create a timeout per transaction which expire and complete the CCBs with a timeout, which the periph drivers then see this status and will fail the I/O with a timed out status (or maybe retries it a couple of times, depending on the hardware and its recovery methods (eg is the timeout due to the drive, the link, the HBA, etc will result in different recovery in the face of timeouts). NVME nvd does similar things: A timeout will cause the nvme card to be reset and we try again, but eventually fail. One might also wonder why 30s is the timeout for most of the commands. I get that 'special' commands might need a longer timeout, but we likely should look at lowering this somewhat. 15s is almost certainly safe. 10s is probably safe. 5s will work, but you start to get P99.9999 outliers on popular completely working spinning rust, and P99.9 on marginal drives, so it can be a bit tricky to change (we'll have to phase it in). That could make things a bit better in terms of worse case recovery time. So why aren't the I/O's timing out is the real question here. Warner > Thanks and Regards, > > Kumara > --00000000000096b2160619ac3307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 30, 2024 at 1:54=E2=80=AF= AM Kumara Babu <nkumarababu@gma= il.com> wrote:

Hello,

There have been a few incidents reported on Juniper= devices with FreeBSD, where buffer IO operations sleep for more than 30 mi= ns. Theoretically, this can happen due to faulty hardware or in virtual pla= tforms due to faulty connection between guest and host, filesystem corrupti= on, too many buffer IO operations, and/or host not responding due to variou= s reasons. When that happens, as this buffer IO writes hold a lock before g= oing to sleep, the threads waiting for that lock would starve for so long. = There is no upper limit for this bwait() as of now. If that wait goes beyon= d 30 mins for a sleeping thread OR 15 mins for a thread blocked on turnstil= e, deadlkres crashes the kernel assuming a possible deadlock.

=
Why isn't the I/O timing out? That's the re= al problem.

= We perhaps could gracefully handle such lengthy buffer IO operations by add= ing a timeout in bwait() - like say 10 minutes. If the buffer IO is not com= pleted in a few mins, it probably would not complete forever and/or would b= e slowing down the entire system. So it is better to stop such faulty IO op= erations.

I think that's a terrible id= ea. Why aren't the I/Os timing out?=C2=A0

For now, since we had seen these ins= tances only with BIO operations, I have a patch to set this value only from= bufwait(). Please find the patch attached. I am not very sure if 10 mins i= s a good upper limit for all the scenarios for bwait(). If it is, then we c= ould just change msleep() in bwait() to set a 10 mins upper limit by defaul= t.=C2=A0

I never see this on = any of the thousands of systems I've used.

Please let me know if this approach= works for all the usecases - If not, is there a better alternative ?=C2=A0= And is 10 mins okay for a timeout ?

Makin= g sure that the I/Os timeout.

And by that, I mean = doing what we do in CAM. All the SIMs ensure that transactions posted to th= e device will timeout. Most of the SIMs create a timeout per transaction wh= ich expire and complete the CCBs with a timeout, which the periph drivers t= hen see this status and will fail the I/O with a timed out status (or maybe= retries it a couple of times, depending on the hardware and its recovery m= ethods (eg is the timeout due to the drive, the link, the HBA, etc will res= ult in different recovery in the face of timeouts). NVME nvd does similar t= hings: A timeout will cause the nvme card to be reset and we try again, but= eventually fail.

One might also wonder why 30s is= the timeout for most of the commands. I get that 'special' command= s might need a longer timeout, but we likely should look at lowering this s= omewhat. 15s is almost certainly safe. 10s is probably safe. 5s will work, = but you start to get P99.9999 outliers on popular completely working spinni= ng rust, and P99.9 on marginal drives, so it can be a bit tricky to change = (we'll have to phase it in). That could make things a bit better in ter= ms of worse case recovery time.

So why aren't = the I/O's timing out is the real question here.

Warner
=C2=A0

Thanks and Regards,

Kumara

--00000000000096b2160619ac3307-- From nobody Thu May 30 14:00:30 2024 X-Original-To: freebsd-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 4Vqnvk4RnFz5MhR9 for ; Thu, 30 May 2024 14:00:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vqnvk2CHtz4dZv for ; Thu, 30 May 2024 14:00:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4999089297; Thu, 30 May 2024 14:00:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.18.1/8.16.1) with ESMTPS id 44UE0VGt003586 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 30 May 2024 14:00:31 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 44UE0UFa003585; Thu, 30 May 2024 14:00:30 GMT (envelope-from phk) Message-Id: <202405301400.44UE0UFa003585@critter.freebsd.dk> To: Warner Losh cc: Kumara Babu , freebsd-hackers@freebsd.org Subject: Re: Upperlimit for bwait() In-reply-to: From: "Poul-Henning Kamp" References: 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: text/plain; charset="us-ascii" Content-ID: <3583.1717077630.1@critter.freebsd.dk> Date: Thu, 30 May 2024 14:00:30 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4Vqnvk2CHtz4dZv Warner Losh writes: > One might also wonder why 30s is the timeout for most of the commands. There are Hierarchial Storage Systems where 30s is not enough: You issue what you think is a disk-read, but somewhere behind the scenes, an overloaded tape-robot has no empty drives. But otherwise: 100% with Warner here. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu May 30 22:44:45 2024 X-Original-To: freebsd-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 4Vr1Xt244lz5LZg5 for ; Thu, 30 May 2024 22:45:02 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vr1Xr4f34z4btW for ; Thu, 30 May 2024 22:45:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.17.1/8.17.1) with ESMTPSA id 44UMikPm021612 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 30 May 2024 18:44:51 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <9072fb5c-b218-4891-a749-537db6f414ca@m5p.com> Date: Thu, 30 May 2024 18:44:45 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: A simpler question (FINAL comment) From: George Mitchell To: FreeBSD Hackers References: Content-Language: en-US Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M89L7yqnTYJL32WJS7ljC5uu" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-0.99)[-0.987]; NEURAL_SPAM_SHORT(0.95)[0.950]; NEURAL_HAM_MEDIUM(-0.77)[-0.775]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_ALL(0.00)[]; TAGGED_FROM(0.00)[freebsd]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[m5p.com]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] X-Rspamd-Queue-Id: 4Vr1Xr4f34z4btW This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M89L7yqnTYJL32WJS7ljC5uu Content-Type: multipart/mixed; boundary="------------rk0n6RjRKeaR1jCVhVTn0E7w"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: <9072fb5c-b218-4891-a749-537db6f414ca@m5p.com> Subject: Re: A simpler question (FINAL comment) References: In-Reply-To: --------------rk0n6RjRKeaR1jCVhVTn0E7w Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gNS8xOS8yNCAxODozNiwgR2VvcmdlIE1pdGNoZWxsIHdyb3RlOg0KPiAxLiBBcmUgeW91 IGEgVGh1bmRlcmJpcmQgdXNlciBvbiBGcmVlQlNEPw0KPiAyLiBEbyB5b3Ugc2VlIGEgImNo YXJ0IHdpdGggcmlzaW5nIHRyZW5kLCIgImNoYXJ0IHdpdGggZmFsbGluZyB0cmVuZCwiDQo+ ICJiYXIgY2hhcnQsIiBhbmQgImNsaXBib2FyZCIgZW1vamlzIChVKzFGNEM4IHRocm91Z2gg VSsxRjRDQikgb24gdGhlDQo+IG5leHQgbGluZT8NCj4g8J+TiMKgwqDCoCDwn5OJwqDCoMKg IPCfk4rCoMKgwqAg8J+Tiw0KPiBUaGFuayB5b3UgZm9yIHlvdXIgYXR0ZW50aW9uLsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIC0tIEdlb3JnZQ0KDQpUaGUgc3Rvcnkgc28gZmFyOg0KSXQgd29ya3MgZmluZSB0byBj b3B5IC91c3IvbG9jYWwvbGliL2ZpcmVmb3gvZm9udHMvVHdlbW9qaU1vemlsbGEudHRmDQp0 byB+Ly5mb250cy4NCg0KSG93ZXZlciwgaXQgYWxzbyB3b3JrcyB0byBpbnN0YWxsIGEgc3lt bGluayBpbnN0ZWFkIG9mIGNvcHlpbmcsIHNvIHRoYXQNCndoZW4geW91IHVwZGF0ZSBmaXJl Zm94LCBpbXByb3ZlbWVudHMgaW4gdGhlIGZvbnQgKGlmIHRoZXJlIGFyZSBhbnkpDQp3aWxs IGdldCB1c2VkIGF1dG9tYXRpY2FsbHkuDQoNCkNvcHlpbmcgL3Vzci9sb2NhbC9zaGFyZS9m b250cy9ub3RvL05vdG9Db2xvckVtb2ppLnR0ZiB0byB+Ly5mb250cywNCm9yIGluc3RhbGxp bmcgYSBzeW1saW5rLCBoYXMgbm8gZWZmZWN0Lg0KDQpCdXQgc3ltbGlua2luZyBmcm9tIH4v LmZvbnRzL1R3ZW1vamlNb3ppbGxhLnR0ZiB0bw0KL3Vzci9sb2NhbC9zaGFyZS9mb250cy9u b3RvL05vdG9Db2xvckVtb2ppLnR0ZiB3b3JrcyBmaW5lLCB0b28uDQoNCk9rYXk7IG5vIG1v cmUgYWJvdXQgZW1vamlzIG5vdy4gIFRoYW5rIHlvdSBhbGwgZm9yIHlvdXIgcGF0aWVuY2Uu DQotLSBHZW9yZ2UNCg== --------------rk0n6RjRKeaR1jCVhVTn0E7w-- --------------M89L7yqnTYJL32WJS7ljC5uu Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZlkBXQUDAAAAAAAKCRCaHA937rZnfUJP AP44E3nr5r8PGKQqXKVF3X6cSyC3kmrMZm91FXf+GWCJlAEAxYVvO1eEOUw8acuGbNn7tcG7kdqu BSJ1c6l5SZPrFQw= =bLzo -----END PGP SIGNATURE----- --------------M89L7yqnTYJL32WJS7ljC5uu-- From nobody Sun Jun 2 18:53:40 2024 X-Original-To: freebsd-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 4VsmGh4fS3z5JlQ6 for ; Sun, 02 Jun 2024 18:53:48 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VsmGg3xGlz4XPX for ; Sun, 2 Jun 2024 18:53:47 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.17.1/8.17.1) with ESMTPSA id 452IreYv034725 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 2 Jun 2024 14:53:46 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sun, 2 Jun 2024 14:53:40 -0400 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 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Spurious use of SQLITE_USE_ALLOCA? Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mpTWjNTGt2MjZJtGg901Rl50" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; TAGGED_FROM(0.00)[freebsd]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[m5p.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] X-Rspamd-Queue-Id: 4VsmGg3xGlz4XPX This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mpTWjNTGt2MjZJtGg901Rl50 Content-Type: multipart/mixed; boundary="------------5ZNyRqBhDTCzqWNNI3Safqi8"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: Subject: Spurious use of SQLITE_USE_ALLOCA? --------------5ZNyRqBhDTCzqWNNI3Safqi8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 KFRyaWVkIHNlbmRpbmcgdG8gY2hyb21pdW1ALCBidXQgSSdtIG5vdCBhIHN1YnNjcmliZXIu KQ0KDQpJJ20gY3VycmVudGx5IGdldHRpbmcgY29tcGlsZSBmYWlsdXJlcyBvZiBjaHJvbWl1 bSAxMjUuMC42NDIyLjExMiBvbg0KRnJlZUJTRCAxMy4yLVJFTEVBU0UtcDEwOg0KDQpJbiBm aWxlIGluY2x1ZGVkIGZyb20gLi4vLi4vdGhpcmRfcGFydHkvc3FsaXRlL3NxbGl0ZTNfc2hp bS5jOjE2Og0KLi4vLi4vdGhpcmRfcGFydHkvc3FsaXRlL3NyYy9hbWFsZ2FtYXRpb24vc3Fs aXRlMy5jOjUzNjE5OjIxOiBlcnJvcjogDQpjYWxsIHRvIHVuZGVjbGFyZWQgZnVuY3Rpb24g J2FsbG9jYSc7IElTTyBDOTkgYW5kIGxhdGVyIGRvIG5vdCBzdXBwb3J0IA0KaW1wbGljaXQg ZnVuY3Rpb24gZGVjbGFyYXRpb25zIFstV2ltcGxpY2l0LWZ1bmN0aW9uLWRlY2xhcmF0aW9u XQ0KICA1MzYxOSB8ICAgICB1MzIgKmFpVmFsdWVzID0gc3FsaXRlM1N0YWNrQWxsb2NSYXco MCwgc2l6ZW9mKHAtPnUuYUhhc2gpKTsNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IF4NCi4uLy4uL3RoaXJkX3BhcnR5L3NxbGl0ZS9zcmMvYW1hbGdhbWF0aW9uL3NxbGl0ZTMu YzoyMDUzNjozODogbm90ZTogDQpleHBhbmRlZCBmcm9tIG1hY3JvICdzcWxpdGUzU3RhY2tB bGxvY1JhdycNCiAgMjA1MzYgfCAjIGRlZmluZSBzcWxpdGUzU3RhY2tBbGxvY1JhdyhELE4p ICAgYWxsb2NhKE4pDQogICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIF4NCi4uLy4uL3RoaXJkX3BhcnR5L3NxbGl0ZS9zcmMvYW1hbGdhbWF0aW9uL3Nx bGl0ZTMuYzo1MzYxOToxMDogZXJyb3I6IA0KaW5jb21wYXRpYmxlIGludGVnZXIgdG8gcG9p bnRlciBjb252ZXJzaW9uIGluaXRpYWxpemluZyAndTMyIConIChha2EgDQondW5zaWduZWQg aW50IConKSB3aXRoIGFuIGV4cHJlc3Npb24gb2YgdHlwZSAnaW50JyBbLVdpbnQtY29udmVy c2lvbl0NCiAgNTM2MTkgfCAgICAgdTMyICphaVZhbHVlcyA9IHNxbGl0ZTNTdGFja0FsbG9j UmF3KDAsIHNpemVvZihwLT51LmFIYXNoKSk7DQogICAgICAgIHwgICAgICAgICAgXiAgICAg ICAgICB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+DQouLi8u Li90aGlyZF9wYXJ0eS9zcWxpdGUvc3JjL2FtYWxnYW1hdGlvbi9zcWxpdGUzLmM6NzgzNzE6 MTQ6IGVycm9yOiANCmNhbGwgdG8gdW5kZWNsYXJlZCBmdW5jdGlvbiAnYWxsb2NhJzsgSVNP IEM5OSBhbmQgbGF0ZXIgZG8gbm90IHN1cHBvcnQgDQppbXBsaWNpdCBmdW5jdGlvbiBkZWNs YXJhdGlvbnMgWy1XaW1wbGljaXQtZnVuY3Rpb24tZGVjbGFyYXRpb25dDQogIDc4MzcxIHwg ICBiLmFwQ2VsbCA9IHNxbGl0ZTNTdGFja0FsbG9jUmF3KDAsIHN6U2NyYXRjaCApOw0KICAg ICAgICB8ICAgICAgICAgICAgICBeDQouLi8uLi90aGlyZF9wYXJ0eS9zcWxpdGUvc3JjL2Ft YWxnYW1hdGlvbi9zcWxpdGUzLmM6MjA1MzY6Mzg6IG5vdGU6IA0KZXhwYW5kZWQgZnJvbSBt YWNybyAnc3FsaXRlM1N0YWNrQWxsb2NSYXcnDQogIDIwNTM2IHwgIyBkZWZpbmUgc3FsaXRl M1N0YWNrQWxsb2NSYXcoRCxOKSAgIGFsbG9jYShOKQ0KICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBeDQouLi8uLi90aGlyZF9wYXJ0eS9zcWxpdGUv c3JjL2FtYWxnYW1hdGlvbi9zcWxpdGUzLmM6NzgzNzE6MTI6IGVycm9yOiANCmluY29tcGF0 aWJsZSBpbnRlZ2VyIHRvIHBvaW50ZXIgY29udmVyc2lvbiBhc3NpZ25pbmcgdG8gJ3U4ICoq JyAoYWthIA0KJ3Vuc2lnbmVkIGNoYXIgKionKSBmcm9tICdpbnQnIFstV2ludC1jb252ZXJz aW9uXQ0KICA3ODM3MSB8ICAgYi5hcENlbGwgPSBzcWxpdGUzU3RhY2tBbGxvY1JhdygwLCBz elNjcmF0Y2ggKTsNCiAgICAgICAgfCAgICAgICAgICAgIF4gfn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn4NCi4uLy4uL3RoaXJkX3BhcnR5L3NxbGl0ZS9zcmMvYW1hbGdh bWF0aW9uL3NxbGl0ZTMuYzoxNjYwNTQ6MTI6IGVycm9yOiANCmNhbGwgdG8gdW5kZWNsYXJl ZCBmdW5jdGlvbiAnYWxsb2NhJzsgSVNPIEM5OSBhbmQgbGF0ZXIgZG8gbm90IHN1cHBvcnQg DQppbXBsaWNpdCBmdW5jdGlvbiBkZWNsYXJhdGlvbnMgWy1XaW1wbGljaXQtZnVuY3Rpb24t ZGVjbGFyYXRpb25dDQogIDE2NjA1NCB8ICAgcFNwYWNlID0gc3FsaXRlM1N0YWNrQWxsb2NS YXdOTihwUGFyc2UtPmRiLCBuU3BhY2UpOw0KICAgICAgICAgfCAgICAgICAgICAgIF4NCi4u Ly4uL3RoaXJkX3BhcnR5L3NxbGl0ZS9zcmMvYW1hbGdhbWF0aW9uL3NxbGl0ZTMuYzoyMDUz NzozODogbm90ZTogDQpleHBhbmRlZCBmcm9tIG1hY3JvICdzcWxpdGUzU3RhY2tBbGxvY1Jh d05OJw0KICAyMDUzNyB8ICMgZGVmaW5lIHNxbGl0ZTNTdGFja0FsbG9jUmF3Tk4oRCxOKSBh bGxvY2EoTikNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXg0KLi4vLi4vdGhpcmRfcGFydHkvc3FsaXRlL3NyYy9hbWFsZ2FtYXRpb24vc3FsaXRl My5jOjE2NjA1NDoxMDogZXJyb3I6IA0KaW5jb21wYXRpYmxlIGludGVnZXIgdG8gcG9pbnRl ciBjb252ZXJzaW9uIGFzc2lnbmluZyB0byAnY2hhciAqJyBmcm9tIA0KJ2ludCcgWy1XaW50 LWNvbnZlcnNpb25dDQogIDE2NjA1NCB8ICAgcFNwYWNlID0gc3FsaXRlM1N0YWNrQWxsb2NS YXdOTihwUGFyc2UtPmRiLCBuU3BhY2UpOw0KICAgICAgICAgfCAgICAgICAgICBeIH5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KNiBlcnJvcnMgZ2VuZXJh dGVkLg0KDQpUaGUgJ2FsbG9jYScgY29tZXMgZnJvbSB0aGUgZXhwYW5zaW9uIG9mIHNxbGl0 ZTNTdGFja0FsbG9jUmF3LCBkdWUgdG8NClNRTElURV9VU0VfQUxMT0NBIGJlaW5nIGRlZmlu ZWQgKHNlZW1zIGltcGxhdXNpYmxlKSwgZHVlIHRvIHRoZSBjb21waWxlDQpjb21tYW5kIGxp bmUgaW5jbHVkaW5nICctRFNRTElURV9VU0VfQUxMT0NBJy4gIEkgaGF2ZW4ndCBiZWVuIGFi bGUgdG8NCmZpZ3VyZSBvdXQgd2h5ICctRFNRTElURV9VU0VfQUxMT0NBJyBhcHBlYXJzIG9u IHRoZSBjb21tYW5kIGxpbmUuICBBDQpmdWxsIHR5cGVzY3JpcHQgaXMgYXQgbTVwLmNvbS9w dWJsaWMvZ2VvcmdlL3R5cGVzY3JpcHQuICBTdWdnZXN0aW9ucw0KZm9yIHByb2NlZWRpbmcg Z3JhdGVmdWxseSBhY2NlcHRlZCEgICAgICAgICAgICAgICAgICAgICAgLS0gR2VvcmdlDQo= --------------5ZNyRqBhDTCzqWNNI3Safqi8-- --------------mpTWjNTGt2MjZJtGg901Rl50 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZly/tAUDAAAAAAAKCRCaHA937rZnfSLH AP90lUJE7SO/4ARR+PaOvj40Awj/x04yRh0crMonfZuGTwD/V9/EWutzM8d9vGrzxtKvHbK9idbk 9J5thGPoC1wzQQ4= =KRD0 -----END PGP SIGNATURE----- --------------mpTWjNTGt2MjZJtGg901Rl50-- From nobody Sun Jun 2 20:05:38 2024 X-Original-To: freebsd-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 4Vsnsk5Ll3z5JsYm for ; Sun, 02 Jun 2024 20:05:46 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vsnsj68G5z4fmM for ; Sun, 2 Jun 2024 20:05:45 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.17.1/8.17.1) with ESMTPSA id 452K5cRa035019 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 2 Jun 2024 16:05:44 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sun, 2 Jun 2024 16:05:38 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: Spurious use of SQLITE_USE_ALLOCA? From: George Mitchell To: freebsd-hackers@freebsd.org References: Content-Language: en-US Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------wQOt87Ds0dTeaMEl3SuyLbul" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on mattapan.m5p.com X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.29 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[m5p.com]; HAS_ATTACHMENT(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] X-Rspamd-Queue-Id: 4Vsnsj68G5z4fmM This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------wQOt87Ds0dTeaMEl3SuyLbul Content-Type: multipart/mixed; boundary="------------eW5eCu0RWM8TOwBYdyCF5ySH"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: Spurious use of SQLITE_USE_ALLOCA? References: In-Reply-To: --------------eW5eCu0RWM8TOwBYdyCF5ySH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gNi8yLzI0IDE0OjUzLCBHZW9yZ2UgTWl0Y2hlbGwgd3JvdGU6DQo+IChUcmllZCBzZW5k aW5nIHRvIGNocm9taXVtQCwgYnV0IEknbSBub3QgYSBzdWJzY3JpYmVyLikNCj4NCj4gW1RM O0RSXQ0KDQpTZWVtcyB0byBiZSBodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEv c2hvd19idWcuY2dpP2lkPTI3OTM5Nw0KLS0gR2VvcmdlDQoNCg0K --------------eW5eCu0RWM8TOwBYdyCF5ySH-- --------------wQOt87Ds0dTeaMEl3SuyLbul Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZlzQkgUDAAAAAAAKCRCaHA937rZnfbwM AQCY6RKOks7/rGudO16rdj9/GAeExexCV9boFaLxFSdsVgD/eItyuMeRD7FgatDHPgIWe1uW4jdd XjEtUoMfNtTp2Qo= =Fnc0 -----END PGP SIGNATURE----- --------------wQOt87Ds0dTeaMEl3SuyLbul--